diff --git a/doc/standardisation/draft-hartman-gss-naming-01.txt b/doc/standardisation/draft-hartman-gss-naming-01.txt
new file mode 100644
index 000000000..544eba284
--- /dev/null
+++ b/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/doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt
new file mode 100644
index 000000000..a441cfdcf
--- /dev/null
+++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt
@@ -0,0 +1,1249 @@
+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. 
\ No newline at end of file
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt
new file mode 100644
index 000000000..9b41e0430
--- /dev/null
+++ b/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/doc/standardisation/draft-ietf-krb-wg-preauth-framework-02.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-02.txt
new file mode 100644
index 000000000..e3f81542d
--- /dev/null
+++ b/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/doc/standardisation/draft-morris-java-gssapi-update-for-csharp-00.txt b/doc/standardisation/draft-morris-java-gssapi-update-for-csharp-00.txt
new file mode 100644
index 000000000..d65d8fb08
--- /dev/null
+++ b/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/doc/standardisation/draft-williams-gssapi-domain-based-names-00.txt b/doc/standardisation/draft-williams-gssapi-domain-based-names-00.txt
new file mode 100644
index 000000000..f310a0236
--- /dev/null
+++ b/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/doc/standardisation/draft-williams-gssapi-extensions-iana-00.txt b/doc/standardisation/draft-williams-gssapi-extensions-iana-00.txt
new file mode 100644
index 000000000..6184b6491
--- /dev/null
+++ b/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/doc/standardisation/draft-williams-gssapi-prf-00.txt b/doc/standardisation/draft-williams-gssapi-prf-00.txt
new file mode 100644
index 000000000..097ce8515
--- /dev/null
+++ b/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/doc/standardisation/draft-williams-gssapi-store-deleg-creds-01.txt b/doc/standardisation/draft-williams-gssapi-store-deleg-creds-01.txt
new file mode 100644
index 000000000..b14696e42
--- /dev/null
+++ b/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/doc/standardisation/draft-williams-gssapi-v3-guide-to-00.txt b/doc/standardisation/draft-williams-gssapi-v3-guide-to-00.txt
new file mode 100644
index 000000000..c7d879b04
--- /dev/null
+++ b/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/doc/standardisation/draft-williams-krb5-gssapi-domain-based-names-00.txt b/doc/standardisation/draft-williams-krb5-gssapi-domain-based-names-00.txt
new file mode 100644
index 000000000..51f154e0a
--- /dev/null
+++ b/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/doc/standardisation/draft-williams-krb5-gssapi-prf-00.txt b/doc/standardisation/draft-williams-krb5-gssapi-prf-00.txt
new file mode 100644
index 000000000..ca588cd73
--- /dev/null
+++ b/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/doc/standardisation/draft-zhu-spnego-2478bis-00.txt b/doc/standardisation/draft-zhu-spnego-2478bis-00.txt
new file mode 100644
index 000000000..d696f063e
--- /dev/null
+++ b/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