From 3c06f39e9846a7224202caca309cf53437926cb4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Love=20H=C3=B6rnquist=20=C3=85strand?= <lha@kth.se>
Date: Mon, 7 Mar 2005 17:25:58 +0000
Subject: [PATCH] x

git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@14624 ec53bebd-3082-4978-b11e-865c3cabbd6b
---
 ...ietf-kitten-gssapi-channel-bindings-00.txt |  784 ++++++++++++
 ...-ietf-kitten-gssapi-extensions-iana-00.txt |  393 ++++++
 .../draft-ietf-kitten-gssapi-prf-02.txt       |  505 ++++++++
 ...draft-ietf-kitten-gssapi-store-cred-00.txt |  560 ++++++++
 ...raft-ietf-kitten-gssapi-v3-guide-to-00.txt | 1121 +++++++++++++++++
 .../draft-ietf-kitten-krb5-gssapi-prf-02.txt  |  393 ++++++
 6 files changed, 3756 insertions(+)
 create mode 100644 doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-00.txt
 create mode 100644 doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-00.txt
 create mode 100644 doc/standardisation/draft-ietf-kitten-gssapi-prf-02.txt
 create mode 100644 doc/standardisation/draft-ietf-kitten-gssapi-store-cred-00.txt
 create mode 100644 doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-00.txt
 create mode 100644 doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-02.txt

diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-00.txt b/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-00.txt
new file mode 100644
index 000000000..b7bcc7c5e
--- /dev/null
+++ b/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-00.txt
@@ -0,0 +1,784 @@
+
+KITTEN WG                                                    N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+  Clarifications and Extensions to the GSS-API for the Use of Channel
+                                Bindings
+            draft-ietf-kitten-gssapi-channel-bindings-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on December 30, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document clarifies and generalizes the GSS-API "channel
+   bindings" facility.  This document also specifies the format of the
+   various types of channel bindings.
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+Table of Contents
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Generic Structure for GSS-API Channel Bindings . . . . . . . .  5
+     3.1   Proper Mechanism Use of Channel Bindings . . . . . . . . .  5
+   4.  Channel Bindings for SSHv2 . . . . . . . . . . . . . . . . . .  6
+     4.1   GSS_Make_sshv2_channel_bindings()  . . . . . . . . . . . .  6
+       4.1.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . .  6
+   5.  Channel Bindings for TLS . . . . . . . . . . . . . . . . . . .  7
+     5.1   GSS_Make_tls_channel_bindings()  . . . . . . . . . . . . .  7
+       5.1.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . .  7
+   6.  Channel Bindings for IPsec . . . . . . . . . . . . . . . . . .  8
+     6.1   GSS_Make_ipsec_channel_bindings()  . . . . . . . . . . . .  8
+       6.1.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   8.1   Normative  . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   8.2   Informative  . . . . . . . . . . . . . . . . . . . . . . . . 11
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
+   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
+       Intellectual Property and Copyright Statements . . . . . . . . 14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+1.  Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 3]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+2.  Introduction
+
+   The concept of "channel bindings" and the abstract construction of
+   channel bindings for several types of channels are described in
+   [CHANNEL-BINDINGS]
+
+   To actually use channel bindings in GSS-API aplications additional
+   details are required that are given below.
+
+   First the structure given to channel bindings data in [RFC2744] is
+   generalized to all of the GSS-API, not just its C-Bindings.
+
+   Then the actual construction of channel bindings to SSHv2, TLS and
+   IPsec channels is given.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+3.  Generic Structure for GSS-API Channel Bindings
+
+   The base GSS-API v2, update 1 specification [RFC2743]describes
+   channel bindings as an OCTET STRING and leaves it to the GSS-API v2,
+   update 1 C-Bindings specification to specify the structure of the
+   contents of the channel bindings OCTET STRINGs.  The C-Bindings
+   specification [RFC2744]then defines, in terms of C, what should be
+   generic structure for channel bindings.  The Kerberos V GSS mechanism
+   [RFC1964]then defines a method for encoding GSS channel bindings in a
+   way that is independent of the C-Bindings!
+
+   In other words, the structure of GSS channel bindings given in
+   [RFC2744] is actually generic, rather than specific to the C
+   programming language.
+
+   Here, then, is a generic re-statement of this structure, in
+   pseudo-ASN.1:
+
+   		GSS-CHANNEL-BINDINGS := SEQUENCE {
+   			initiator-address-type	INTEGER,
+   			initiator-address	OCTET STRING,
+   			acceptor-address-type   INTEGER,
+   			acceptor-address	OCTET STRING,
+   			application-data	OCTET STRING,
+   		}
+
+   The values for the address fields are described in [RFC2744].
+
+   Language-specific bindings of the GSS-API should specify a
+   language-specific formulation of this structure.
+
+3.1  Proper Mechanism Use of Channel Bindings
+
+   As described in [CHANNEL-BINDINGS], GSS mechanisms should exchange
+   integrity protected proofs of channel bindings, where the proof is
+   obtained by running a strong hash of the channel bindings data
+   (encoded as per some mechanism-specific, such as in [RFC1964]) and a
+   binary value to represent the initiator->acceptor, and opposite,
+   direction.
+
+   The encoding of channel bindings used in [RFC1964], with the addition
+   of a binary value as described above, and the substitution of SHA-1
+   for MD5 is a reasonable, generic encoding of GSS-CHANNEL-BINDINGS
+   that any future GSS mechanisms can use.
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+4.  Channel Bindings for SSHv2
+
+   The SSHv2 channel bindings are constructed as an octet string for the
+   'application-data' field of the channel bindings by concatenating the
+   following values and in this order:
+
+   1.  The ASCII string "GSS SSHv2 CB:"
+   2.  The SSHv2 session ID
+   3.  Any additional application-provided data, encoded as the DER
+       encoding of an ASN.1 OCTET STRING
+
+4.1  GSS_Make_sshv2_channel_bindings()
+
+   Inputs:
+
+   o  session_id OCTET STRING,
+   o  additional_app_data OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  channel_bindings_app_data OCTET STRING
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates no error.
+   o  GSS_S_FAILURE indicates failure to construct the channel bindings
+      as a result, perhaps, of a memory management, or similar failure.
+
+   This function constructs an OCTET STRING for use as the value of the
+   application-data field of the GSS-CHANNEL-BINDINGS structure
+   described above.
+
+4.1.1  C-Bindings
+
+   OM_uint32 gss_make_sshv2_channel_bindings(
+     OM_uint32			*minor_status,
+     const gss_buffer_t		session_id,
+     const gss_buffer_t		additional_app_data,
+     gss_buffer_t	     channel_bindings_app_data
+   );
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+5.  Channel Bindings for TLS
+
+   The TLS channel bindings are constructed as an octet string for the
+   'application-data' field of the channel bindings by concatenating the
+   following values and in this order:
+
+   1.  The ASCII string "GSS TLSv1.0 CB:"
+   2.  The TLS finished message sent by the client
+   3.  The TLS finished message sent by the server
+   4.  Any additional application-provided data, encoded as the DER
+       encoding of an ASN.1 OCTET STRING
+
+5.1  GSS_Make_tls_channel_bindings()
+
+   Inputs:
+
+   o  client_finished_msg OCTET STRING,
+   o  server_finished_msg OCTET STRING,
+   o  additional_app_data OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  channel_bindings_app_data OCTET STRING
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates no error.
+   o  GSS_S_FAILURE indicates failure to construct the channel bindings
+      as a result, perhaps, of a memory management, or similar failure.
+
+   This function constructs an OCTET STRING for use as the value of the
+   application-data field of the GSS-CHANNEL-BINDINGS structure
+   described above.
+
+5.1.1  C-Bindings
+
+   OM_uint32 gss_make_tls_channel_bindings(
+     OM_uint32			*minor_status,
+     const gss_buffer_t		client_finished_msg,
+     const gss_buffer_t		server_finished_msg,
+     const gss_buffer_t		additional_app_data,
+     gss_buffer_t		channel_bindings_app_data
+   );
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+6.  Channel Bindings for IPsec
+
+   The IPsec channel bindings are constructed as an octet string for the
+   'application-data' field of the channel bindings by concatenating the
+   following values and in this order:
+
+   1.  The ASCII string "GSS IPsec CB:"
+   2.  The transform ID for encryption, as a 16-bit big-endian word
+   3.  The transform ID for integrity protection, as 16-bit in
+       big-endian word
+   4.  The initiator ID payload as used in the key exchange protocol
+       used for setting up the channel's SAs
+   5.  The responder ID payload as used in the key exchange protocol
+       used for setting up the channel's SAs
+   6.  Any additional application-provided data, encoded as the DER
+       encoding of an ASN.1 OCTET STRING
+
+   Note that traffic selectors are not included.  Inclusion of
+   confidentiality/integrity algorithms protects against MITMs that can
+   compromise weaker algorithms that policy might permit, for the same
+   peers, for other traffic.
+
+6.1  GSS_Make_ipsec_channel_bindings()
+
+   Inputs:
+
+   o  encr_alg INTEGER,
+   o  integ_alg INTEGER,
+   o  initiator_id OCTET_STRING,
+   o  acceptor_id OCTET_STRING,
+   o  additional_app_data OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  channel_bindings_app_data OCTET STRING
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates no error.
+   o  GSS_S_FAILURE indicates failure to construct the channel bindings
+      as a result, perhaps, of a memory management, or similar failure.
+
+   This function constructs an OCTET STRING for use as the value of the
+   application-data field of the GSS-CHANNEL-BINDINGS structure
+   described above.
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 8]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+6.1.1  C-Bindings
+
+   OM_uint32 gss_make_ipsec_channel_bindings(
+     OM_uint32			*minor_status,
+     OM_uint32			encr_alg,
+     OM_uint32			integ_alg,
+     const gss_buffer_t		initiator_id,
+     const gss_buffer_t		acceptor_id,
+     const gss_buffer_t		additional_app_data,
+     gss_buffer_t		channel_bindings_app_data
+   );
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 9]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+7.  Security Considerations
+
+   For general security considerations relating to channel bindings see
+   [CHANNEL-BINDINGS]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 10]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+8.  References
+
+8.1  Normative
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
+              1964, June 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+8.2  Informative
+
+   [RFC0854]  Postel, J. and J. Reynolds, "Telnet Protocol
+              Specification", STD 8, RFC 854, May 1983.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
+              (SPKM)", RFC 2025, October 1996.
+
+   [RFC2203]  Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
+              Specification", RFC 2203, September 1997.
+
+   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
+              Negotiation Mechanism", RFC 2478, December 1998.
+
+   [RFC2623]  Eisler, M., "NFS Version 2 and Version 3 Security Issues
+              and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
+              RFC 2623, June 1999.
+
+   [RFC3530]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
+              Beame, C., Eisler, M. and D. Noveck, "Network File System
+              (NFS) version 4 Protocol", RFC 3530, April 2003.
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 11]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 12]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+Appendix A.  Acknowledgments
+
+   The author would like to thank Mike Eisler for his work on the
+   Channel Conjunction Mechanism I-D and for bringing the problem to a
+   head, Sam Hartman for pointing out that channel bindings provide a
+   general solution to the channel binding problem, Jeff Altman for his
+   suggestion of using the TLS finished messages as the TLS channel
+   bindings, Bill Sommerfeld, for his help in developing channel
+   bindings for IPsec, and Radia Perlman for her most helpful comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 13]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004               [Page 14]
+
+
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-00.txt b/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-00.txt
new file mode 100644
index 000000000..772f36786
--- /dev/null
+++ b/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-00.txt
@@ -0,0 +1,393 @@
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: July 2, 2005                                       January 2005
+
+
+     Namespace Considerations and Registries for GSS-API Extensions
+            draft-ietf-kitten-gssapi-extensions-iana-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 2, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).  All Rights Reserved.
+
+Abstract
+
+   This document describes the ways in which the GSS-API may be extended
+   and directs the creation of IANA registries for various GSS-API
+   namespaces.
+
+
+
+
+
+
+
+
+
+
+Williams                  Expires July 2, 2005                  [Page 1]
+
+Internet-Draft           GSS IANA Instructions              January 2005
+
+
+Table of Contents
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Extensions to the GSS-API  . . . . . . . . . . . . . . . . . .  3
+   4.  Generic GSS-API Namespaces . . . . . . . . . . . . . . . . . .  3
+   5.  Language Binding-Specific GSS-API Namespaces . . . . . . . . .  4
+   6.  Extension-Specific GSS-API Namespaces  . . . . . . . . . . . .  4
+   7.  Registration Form(s) . . . . . . . . . . . . . . . . . . . . .  4
+   8.  Initial Namespace Registrations  . . . . . . . . . . . . . . .  6
+   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
+   10. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
+       Intellectual Property and Copyright Statements . . . . . . . .  7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                  Expires July 2, 2005                  [Page 2]
+
+Internet-Draft           GSS IANA Instructions              January 2005
+
+
+1.  Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Introduction
+
+   There is a need for generic and mechanism-specific extensions to the
+   Generic Security Services Application Programming Interface
+   (GSS-API).  As such extensions are designed and standardized, both at
+   the IETF and elsewhere, there is a non-trivial risk of namespace
+   pollution and conflicts.  To avoid this we set out guidelines for
+   extending the GSS-API and create IANA registries of GSS-API
+   namespaces.
+
+   The registration of name prefixes and constant value ranges is
+   allowed so as to save the IANA the trouble of registering every
+   GSS-API name and constant, and to allow for reservation of portions
+   of some GSS namespaces for private extensions or extensions which
+   lack IETF Standards-Track extensions.
+
+3.  Extensions to the GSS-API
+
+   Extensions to the GSS-API can be categorized as follows:
+   o  Generic
+   o  Implementation-specific
+   o  Mechanism-specific
+   o  Language binding-specific
+   o  Any combination of two or all three of the last three
+
+   Extensions to the GSS-API may be purely semantic, without effect on
+   the GSS-API's namespaces.  Or they may introduce new functions,
+   constants, types, etc...; these clearly affect the GSS-API
+   namespaces.
+
+   Extensions that affect the GSS-API namespaces should be registered
+   with the IANA.
+
+4.  Generic GSS-API Namespaces
+
+   All the function, constant and type names, as well as all the
+   constant values specified in the base GSS-API specification for the
+   basic generic GSS-API namespace.
+
+   The generic GSS-API namespaces are:
+   o  Type names
+   o  Function names
+
+
+
+Williams                  Expires July 2, 2005                  [Page 3]
+
+Internet-Draft           GSS IANA Instructions              January 2005
+
+
+   o  Constant names for each type
+   o  Constant values for each type
+   o  Mechanism OIDs
+   o  Name Type OIDs
+   o  Mechanism Attribute OIDs (see [EXTENDED-INQUIRY])
+
+5.  Language Binding-Specific GSS-API Namespaces
+
+   <Add text; discuss header, module, library, class, method namespaces
+   and whatever else comes up that is language-specific and appropriate
+   for registration with the IANA.>
+
+6.  Extension-Specific GSS-API Namespaces
+
+   Extensions to the GSS-API may create additional namespaces.
+   Instructions to the IANA should included for the handling of such
+   namespaces.
+
+7.  Registration Form(s)
+
+   Registrations for GSS-API namespaces SHALL take the following form:
+
+   +----------------------+----------------------+---------------------+
+   | Registration Field   | Possible Values      | Description         |
+   +----------------------+----------------------+---------------------+
+   | Registration type    | 'Individual',        | Indicates whether   |
+   |                      | 'Prefix', 'Range'    | this entry reserves |
+   |                      |                      | a given symbol name |
+   |                      |                      | or constant value   |
+   |                      |                      | or whether it       |
+   |                      |                      | reserves an entire  |
+   |                      |                      | sub-namespace (the  |
+   |                      |                      | name is a "prefix") |
+   |                      |                      | or constant value   |
+   |                      |                      | range.              |
+   | Bindings             | 'Generic',           | Indicates the       |
+   |                      | 'C-bindings',        | language bindings   |
+   |                      | 'Java', 'C#', etc... | that this           |
+   |                      |                      | registration is     |
+   |                      |                      | for, or, if         |
+   |                      |                      | 'Generic', that     |
+   |                      |                      | this is an entry    |
+   |                      |                      | for the generic     |
+   |                      |                      | GSS-API, not        |
+   |                      |                      | specific to any     |
+   |                      |                      | programming         |
+   |                      |                      | language.           |
+   | Object Type          | 'Symbol',            | Indicates whether   |
+
+
+
+Williams                  Expires July 2, 2005                  [Page 4]
+
+Internet-Draft           GSS IANA Instructions              January 2005
+
+
+   |                      | 'Constant-Value'     | this registration   |
+   |                      |                      | is for a symbol     |
+   |                      |                      | (e.g., function,    |
+   |                      |                      | constant name(s))   |
+   |                      |                      | or constant value.  |
+   | Object Programming   | 'Data-Type',         | Indicates the type  |
+   | Type                 | 'Function',          | of the object(s)    |
+   |                      | 'Method', 'Integer', | whose symbolic name |
+   |                      | 'String', 'OID'      | or constant value   |
+   |                      |                      | is this entry       |
+   |                      |                      | registers.          |
+   | Object Name          | <Symbol name or name | The name(s) of      |
+   |                      | prefix>              | symbols or values   |
+   |                      |                      | being registered.   |
+   | Object Value         | <Constant value> or  | [Only for           |
+   |                      | <constant value      | Constant-Value      |
+   |                      | range>               | registrations.] The |
+   |                      |                      | value(s)            |
+   |                      |                      | registered.         |
+   | Description          | <Text>               | Description of      |
+   |                      |                      | object(s) being     |
+   |                      |                      | registered.         |
+   | Reference            | <Reference>          | Reference to        |
+   |                      |                      | document that       |
+   |                      |                      | describes the       |
+   |                      |                      | object(s) being     |
+   |                      |                      | registered.         |
+   | Status               | 'Standards-Track',   |                     |
+   |                      | 'Informational',     |                     |
+   |                      | 'Experimental',      |                     |
+   |                      | 'Obsolete'           |                     |
+   +----------------------+----------------------+---------------------+
+
+   The IANA should create a single GSS-API namespace registry, or
+   multiple registries, one for symbolic names and one for constant
+   values, or it may create a registry per-programming language, at its
+   convenience.
+
+   Entries in these registries should consist of all the fields from
+   their corresponding registration entries.
+
+   Entries SHOULD be sorted by object type, proggamming language, symbol
+   name.
+
+   <Add text on guidelines for IANA consideration of registration
+   applications, particularly with respect to entries lacking normative
+   references, "magic" entries (e.g., special values of 'time' types
+   which indicate something other than absolute or relative time, such
+
+
+
+Williams                  Expires July 2, 2005                  [Page 5]
+
+Internet-Draft           GSS IANA Instructions              January 2005
+
+
+   as GSS_C_INDEFINITE), expert review requirements (if any) for
+   registrations lacking normative references, etc....>
+
+8.  Initial Namespace Registrations
+
+   <Add registration entries for namespaces (name prefixes) for RFC2743/
+   RFC2744/RFC2853.>
+
+   <Add registration entries for private namespaces (name prefixes) for
+   implementation- and/or platform-specific extensions.>
+
+9.  Security Considerations
+
+   This document has no security considerations.
+
+10  Normative
+
+   [EXTENDED-INQUIRY]
+              Williams, N., "Extended Generic Security Service Mechanism
+              Inquiry APIs",
+              draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
+              progress).
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+Williams                  Expires July 2, 2005                  [Page 6]
+
+Internet-Draft           GSS IANA Instructions              January 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                  Expires July 2, 2005                  [Page 7]
+
+
+
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-prf-02.txt b/doc/standardisation/draft-ietf-kitten-gssapi-prf-02.txt
new file mode 100644
index 000000000..9afd512d2
--- /dev/null
+++ b/doc/standardisation/draft-ietf-kitten-gssapi-prf-02.txt
@@ -0,0 +1,505 @@
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+                  A PRF API extension for the GSS-API
+                  draft-ietf-kitten-gssapi-prf-02.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on December 30, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document defines a Pseudo-Random Function (PRF) extension to the
+   Generic Security Service Applicatoin Programming Interface (GSS-API)
+   for keying application protocols given an established GSS-API
+   security context.  The primary intended use of this function is to
+   key secure session layers that don't or cannot use GSS-API
+   per-message MIC (message integrity check) and wrap tokens for session
+   protection.
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+Table of Contents
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . .  5
+   3.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   5.1 Normative References . . . . . . . . . . . . . . . . . . . . .  8
+   5.2 Informative References . . . . . . . . . . . . . . . . . . . .  8
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
+       Intellectual Property and Copyright Statements . . . . . . . .  9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+1.  Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 3]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+2.  Introduction
+
+   A need has arisen for users of the GSS-API to key applications'
+   cryptographic protocols using established GSS-API security contexts.
+   Such applications can use the GSS-API for authentication, but not for
+   transport security (for whatever reasons), and since the GSS-API does
+   not provide a method for obtaining keying material from established
+   security contexts such applications cannot make effective use of the
+   GSS-API.
+
+   To address this need we define a pseudo-random function (PRF)
+   extension to the GSS-API.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+3.  GSS_Pseudo_random()
+
+   Inputs:
+
+   o  context CONTEXT handle,
+   o  prf_in OCTET STRING,
+   o  desired_output_len INTEGER
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  prf_out OCTET STRING
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates no error.
+   o  GSS_S_NO_CONTEXT indicates that a null context has been provided
+      as input.
+   o  GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
+      provided as input.
+   o  GSS_S_UNAVAILABLE indicates that the mechanism lacks support for
+      this function or, if the security context is not fully
+      established, that the context is not ready to compute the PRF.
+   o  GSS_S_FAILURE indicates failure or lack of support; the minor
+      status code may provide additional information.
+
+   This function applies the established context's mechanism's keyed PRF
+   function to the input data (prf_in), keyed with key material
+   associated with the given security context and outputs the resulting
+   octet string (prf_out) of desired_output_len length.
+
+   The output string of this function MUST be a pseudo-random function
+   [GGM1][GGM2] of the input keyed with key material from the
+   established security context -- the chances of getting the same
+   output given different input parameters should be exponentially
+   small.
+
+   This function, applied to the same inputs by an initiator and
+   acceptor using the same established context, MUST produce the *same
+   results* for both, the initiator and acceptor, even if called
+   multiple times for the same context.
+
+   Mechanisms MAY limit the output of the PRF according, possibly in
+   ways related to the types of cryptographic keys available for the PRF
+   function, thus the prf_out output of GSS_Pseudo_random() MAY be
+   smaller than requested.
+
+   Mechanisms may be able to compute PRFs with security contexts that
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+   are not fully established, therefore applications MAY call
+   GSS_Pseudo_random() with such security contexts.  Such mechanisms
+   MUST return GSS_S_UNAVAILABLE when called on to compute a PRF given a
+   security context that is not fully established and also not ready for
+   PRF computation.  Mechanisms that allow for PRF computation prior to
+   full security context establishment MUST use the same PRF and key
+   material, for any given security context, both, before and after full
+   context establishment, and the PRF and key material negotiation MUT
+   be authenticated when the security context is fully established.
+
+3.1  C-Bindings
+
+   OM_uint32 gss_pseudo_random(
+     OM_uint32			*minor_status,
+     gss_ctx_id_t			context,
+     const gss_buffer_t		prf_in,
+     ssize_t		desired_output_len,
+     gss_buffer_t		prf_out
+   );
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+4.  Security Considerations
+
+   Care should be taken in properly designing a mechanism's PRF
+   function.
+
+   GSS mechanisms' PRF functions should use a key derived from contexts'
+   session keys and should preserve the forward security properties of
+   the mechanisms' key exchanges.
+
+   Some mechanisms may support the GSS PRF function with security
+   contexts that are not fully established, but applications MUST assume
+   that authentication, mutual or otherwise, has not completed until the
+   security context is fully established
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+5.  References
+
+5.1  Normative References
+
+   [GGM1]     Goldreich, O., Goldwasser, S. and S. Micali, "How to
+              Construct Random Functions", October 1986.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+5.2  Informative References
+
+   [GGM2]     Goldreich, O., Goldwasser, S. and S. Micali, "On the
+              Cryptographic Applications of Random Functions", 1985.
+
+   [RFC1750]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+              Recommendations for Security", RFC 1750, December 1994.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 8]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004                [Page 9]
+
+
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-00.txt b/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-00.txt
new file mode 100644
index 000000000..e5398a0a4
--- /dev/null
+++ b/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-00.txt
@@ -0,0 +1,560 @@
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: August 15, 2005                               February 14, 2005
+
+
+          GSS-API Extension for Storing Delegated Credentials
+               draft-ietf-kitten-gssapi-store-cred-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 15, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).  All Rights Reserved.
+
+Abstract
+
+   This document defines a new function for the GSS-API which allows
+   applications to store delegated (and other) credentials in the
+   implicit GSS-API credential store.  This is needed for GSS-API
+   applications to use delegated credentials as they would use other
+   credentials.
+
+
+
+
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 1]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+Table of Contents
+
+   1. Conventions used in this document  . . . . . . . . . . . . . .   3
+   2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3. GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . .   5
+   4. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .   7
+   5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
+   6. Security considerations  . . . . . . . . . . . . . . . . . . .   9
+   7. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . .   9
+      Intellectual Property and Copyright Statements . . . . . . . .  10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 2]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+1.  Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 3]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+2.  Introduction
+
+   The GSS-API [RFC2743] clearly assumes that credentials exist in an
+   implicit store whence they can be acquired using GSS_Acquire_cred()
+   and GSS_Add_cred() or through use of the default credential.
+   Multiple credential stores may exist on a given host, but only one
+   store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
+   given time.
+
+   This assumption can be seen in sections 1.1.1.2 and 1.1.1.3 of
+   [RFC2743] as well as in section 3.5 of [RFC2744].
+
+   Note to the RFC editor: please remove this note before publication.]
+
+   Applications may be able to change the credential store from which
+   credentials can be acquired, either by changing user contexts (where
+   the applications have the privilege to do so) or by other means
+   (where a user may have multiple credential stores).
+
+   Some GSS-API acceptor applications always change user contexts, after
+   accepting a GSS-API security context and making appropriate
+   authorization checks, to the user context corresponding to the
+   initiator principal name or to a context requested by the initiator.
+   The means by which credential stores are managed are generally beyond
+   the scope of the GSS-API.
+
+   In the case of delegated credential handles however, such credentials
+   do not exist in the acceptor's credential store or in the credential
+   stores of the user contexts to which the acceptor application might
+   change - which is precisely the raison d'etre of credential
+   delegation.  But the GSS-API provides no mechanism by which delegated
+   credential handles can be made available for acquisition through
+   GSS_Acquire_cred()/GSS_Add_cred().  The GSS-API also does not provide
+   any credential import/export interfaces like the GSS-API context
+   import/export interfaces.
+
+   Thus acceptors are limited to making only direct use of delegated
+   credential handles and only with GSS_Init_sec_context(),
+   GSS_Inquire_cred*() and GSS_Release_cred().  This limitation is
+   particularly onerous on Unix systems where a call to exec() to
+   replace the process image obliterates the delegated credentials
+   handle.
+
+   In order to make delegated credentials generally as useful as
+   credentials that can be acquired with GSS_Acquire_cred() and
+   GSS_Add_cred() a primitive is needed which allows storing of
+   credentials in the implicit credential store.  This primitive we call
+   "GSS_Store_cred()."
+
+
+
+Williams                Expires August 15, 2005                 [Page 4]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+3.  GSS_Store_cred()
+
+   Inputs:
+   o  input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
+      NOT be GSS_C_NO_CREDENTIAL
+   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+      2=ACCEPT-ONLY
+   o  desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID then
+      store all the elements of the input_cred_handle, otherwise store
+      only the element of the corresponding mechanism
+   o  overwrite_cred BOOLEAN, -- if TRUE replace any credential for the
+      same principal in the credential store
+   o  default_cred BOOLEAN -- if TRUE make the stored credential
+      available as the default credential (for acquisition with
+      GSS_C_NO_NAME as the desired name or for use as
+      GSS_C_NO_CREDENTIAL)
+
+   Outputs:
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
+      mechanism OIDs for which credential elements were successfully
+      stored
+   o  cred_usage_stored INTEGER -- like cred_usage, but indicates what
+      kind of credential was stored (useful when the cred_usage input
+      parameter is set to INITIATE-AND-ACCEPT)
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates that the credentials were successfully
+      stored.
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had
+      expired or expired before they could be stored.
+   o  GSS_S_NO_CRED indicates that no input credentials were given.
+   o  GSS_S_UNAVAILABLE indicates that the credential store is not
+      available.
+   o  GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
+      credential could not be stored because a credential for the same
+      principal exists in the current credential store and the
+      overwrite_cred input argument was FALSE.
+   o  GSS_S_FAILURE indicates that the credential could not be stored
+      for some other reason.  The minor status code may provide more
+      information if a non-GSS_C_NULL_OID desired_mech_element was
+      given.
+
+   GSS_Store_cred() is used to store, in the current credential store, a
+   given credential that has either been acquired from a different
+   credential store or been accepted as a delegated credential.
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 5]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+   Specific mechanism elements of a credential can be stored one at a
+   time by specifying a non-GSS_C_NULL_OID mechanism OID as the
+   desired_mech_element input argument, in which case the minor status
+   output SHOULD have a mechanism-specific value when the major status
+   is not GSS_S_COMPLETE.
+
+   The initiator, acceptor or both usages of the input credential may be
+   stored as per the cred_usage input argument.
+
+   The credential elements that were actually stored, when the major
+   status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
+   and mech_elements_stored function outputs.
+
+   If credentials already exist in the current store for the principal
+   of the input_cred_handle, then those credentials are not replaced
+   with the input credentials unless the overwrite_cred input argument
+   is TRUE.
+
+   Finally, if the current credential store has no default credential
+   (that is, no credential that could be acquired for GSS_C_NO_NAME) or
+   if the default_cred input argument is TRUE, and the input credential
+   can be successfully stored, then the input credential will be
+   available for acquisition with GSS_C_NO_NAME as the desired name
+   input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as
+   GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(),
+   GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and
+   GSS_Accept_sec_context().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 6]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+4.  C-Bindings
+
+   The C-bindings for GSS_Store_cred() make use of types from and are
+   designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
+
+
+      OM_uint32 gss_store_cred(
+         OM_uint32         *minor_status,
+         gss_cred_id_t     input_cred,
+         gss_cred_usage_t  cred_usage,
+         const gss_OID     desired_mech,
+         OM_uint32         overwrite_cred,
+         OM_uint32         default_cred,
+         gss_OID_set       *elements_stored,
+         gss_cred_usage_t  *cred_usage_stored)
+
+
+                                Figure 1
+
+   The two boolean arguments, 'overwrite_cred' and 'default_cred' are
+   typed as OM_uint32; 0 corresponds to FALSE, non-zero values
+   correspond to TRUE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 7]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+5.   Examples
+
+   The intended usage of GSS_Store_cred() is to make delegated
+   credentials available to child processes of GSS-API acceptor
+   applications.  Example pseudo-code:
+
+
+      /*
+       * <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE,
+       * an initiator name (hereafter, "src_name") and a delegated
+       * credential handle (hereafter "deleg_cred").>
+       *
+       * <"requested_username" is a username derived from the
+       * initiator name or explicitly requested by the initiator
+       * application.>
+       */
+      ...
+
+      if (authorize_gss_client(src_name, requested_username)) {
+         /*
+          * For Unix-type platforms this may mean calling setuid() and
+          * it may or may not also mean setting/unsetting such
+          * environment variables as KRB5CCNAME and what not.
+          */
+         if (change_user_context(requested_username))
+            (void) gss_store_creds(&minor_status, deleg_cred,
+   				GSS_C_INITIATE, actual_mech,
+   				0, 1, NULL, NULL);
+         }
+         else ...
+      }
+      else ...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 8]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+6.  Security considerations
+
+   Acceptor applications MUST only store delegated credentials into
+   appropriate credential stores and only after proper authorization of
+   the authenticated initiator principal to the requested service(s).
+
+   Acceptor applications that have no use for delegated credentials MUST
+   release them (such acceptor applications that use the GSS-API
+   C-Bindings may simply provide a NULL value for the
+   delegated_cred_handle argument to gss_accept_sec_context()).
+
+7  Normative
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 9]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                Expires August 15, 2005                [Page 10]
+
+
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-00.txt b/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-00.txt
new file mode 100644
index 000000000..98da42e87
--- /dev/null
+++ b/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-00.txt
@@ -0,0 +1,1121 @@
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: July 26, 2005                                  January 25, 2005
+
+
+                         Guide to the GSS-APIv3
+              draft-ietf-kitten-gssapi-v3-guide-to-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 26, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).  All Rights Reserved.
+
+Abstract
+
+   Extensions to the GSS-APIv2 are needed for a number of reasons.  This
+   documents describes the extensions being proposed, the resons,
+   possible future directions, and portability, IANA and security
+   considerations.  This document does not define any protocol or
+   interface and is purely informational.
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 1]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+Table of Contents
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  A Pseudo-Mechanism OID for the GSS-API Itself  . . . . . . . .  5
+   4.  Mechanism Attribute Inquiry Facilities . . . . . . . . . . . .  6
+   5.  Security Context Extensibility Extensions  . . . . . . . . . .  7
+   6.  Credential Extensibility Extensions  . . . . . . . . . . . . .  8
+   7.  Credential Export/Import . . . . . . . . . . . . . . . . . . .  9
+   8.  GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 10
+   9.  Pseudo-Mechanism Stacking  . . . . . . . . . . . . . . . . . . 11
+   10. Naming Extensions  . . . . . . . . . . . . . . . . . . . . . . 12
+   11. Additional Name Types  . . . . . . . . . . . . . . . . . . . . 13
+   12. GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . . 14
+   13. Channel Bindings Specifications  . . . . . . . . . . . . . . . 15
+   14. Semantic and Miscallaneous Extensions  . . . . . . . . . . . . 16
+   15. Portability Considerations . . . . . . . . . . . . . . . . . . 17
+   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
+   17. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
+   18. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
+       Intellectual Property and Copyright Statements . . . . . . . . 20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 2]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+1.  Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 3]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+2.  Introduction
+
+   [NOTE: the references section is current fairly empty; the various
+   KITTEN WG work items will be added to this I-D in a subsequent
+   revision.]
+
+   Since the advent of the GSS-APIv2 it has come to be used in a number
+   of Internet (and other) protocols and a number of implementations
+   exist.  In that time implementors and protocol designers have come to
+   understand both, the GSS-API's strengths, and its shortcommings; we
+   believe now that a number of extensions to the GSS-API are needed.
+   Here these proposed extensions, forming what we may call the GSS-API
+   version 3, are described at a high-level.;
+
+   Some of these extensions are intended to facilitate further
+   extensions, so that further major revisions to the GSS-API may not be
+   necessary.  Others are intended to fill voids in the the GSS-APIv2.
+
+   The extensions being proposed are:
+      A pseudo-mechanism OID for the GSS-API itself
+      Mechanism attribute inquiry facilities
+      Security context extensibility extensions
+      Credential extensibility extensions
+      Credential export/import
+      GSS_Store_cred(), for making delegated credentials available for
+      acquisition
+      Pseudo-mechanism stacking
+      Naming extensions, to facilitate authorization by identifiers
+      other than names
+      Additional name types, specifically domain-based naming
+      A pseudo-random function interface
+      Channel bindings specifications
+      Semantic extensions relating to thread- and/or fork-safety
+      [Have I missed anything?  I have a feeling I have.  Re-keying?]
+      ...
+
+   Additionally, because we foresee future minor extensions, including,
+   specifically, extensions which may impact the various namespaces
+   associated with APIs (symbol names, constant values, class names,
+   etc...) we also propose the establishment of IANA registries for
+   these namespaces.
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 4]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+3.  A Pseudo-Mechanism OID for the GSS-API Itself
+
+   A mechanism OID is assigned to identify and refer to the GSS-API
+   iself.  This is necessary to enable the use of extended inquiry
+   interfaces to inquire about features of a GSS-API implementation
+   specifically, apart from actual mechanisms.
+
+   But also, this OID is needed for better error handling, so that minor
+   status codes produced in generic contexts that lack a mechanism OID
+   can be distinguished from minor status codes for a "default"
+   mechanism and properly displayed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 5]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+4.  Mechanism Attribute Inquiry Facilities
+
+   In the course of designing a pseudo-mechanism stacking facility, as
+   well as while considering the impact of all of these extensions on
+   portability, a need for interfaces through which to discover or
+   inquire by features provided by GSS-API mechanisms was discovered.
+
+   The proposed mechanism attribute inquiry interfaces consist of:
+      GSS_Inquire_mech_attrs_for_mech()
+      GSS_Indicate_mechs_by_mech_attrs()
+      GSS_Display_mech_attr()
+
+   These extensions facilitate portability by allowing GSS-APIv3
+   applications to discover the features provided by a given
+   implementation of the GSS-API or any mechanisms.  These extensions
+   are also useful in facilitating stackable pseudo-mechanisms.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 6]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+5.  Security Context Extensibility Extensions
+
+   In order to facilitate future security context options we introduce a
+   GSS_Create_sec_context() interface that creates a security context
+   object, for use with extensions and with GSS_Init_sec_context(),
+   GSS_Accept_sec_context(), and GSS_Inquire_sec_context().  Such
+   security contexts are in a non-established state until they are
+   established through the use of GSS_Init_sec_context() or
+   GSS_Accept_sec_context().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 7]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+6.  Credential Extensibility Extensions
+
+   In order to facilitate future extensions to GSS credentials we
+   introduce a GSS_Create_credential(), similar to
+   GSS_Create_sec_context(), interface that creates an "empty"
+   credential.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 8]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+7.  Credential Export/Import
+
+   To allow for passing of credentials between different "session
+   contexts," between different hosts, or for storage of post-dated
+   credentials, we introduce a credential export/import facility, much
+   like the security context export/import facility of the GSS-APIv2.
+
+   Together with credential extensibility and other extensions this
+   facility may allow for:
+      Credential delegation at any time
+      Post-dated credentials, and storage of the such for subsequent
+      use.
+      ...?
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 9]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+8.  GSS_Store_cred()
+
+   This extension fills a void in the GSS-APIv2 where delegated
+   credentials could not be used except in the context of the same
+   process that received them.  With this extension acceptor
+   applications can now make delegated credentials available for use,
+   with GSS_Acquire_cred() et.  al., in other process contexts.
+
+   [Manipulation of "credential stores" is (may be?) out of scope for
+   this document.]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 10]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+9.  Pseudo-Mechanism Stacking
+
+   A number of pseudo-mechanisms are being proposed which are designed
+   to "stack" atop other mechanisms.  The possiblities are many,
+   including: a compression mechanism, a perfect forward security
+   mechanism, an many others.
+
+   The GSS-APIv2 only had concrete mechanisms and one pseudo-mechanism
+   (SPNEGO) available.  With this proposal the mechanism taxonomy is
+   quite expanded:
+      Concrete mechanisms (e.g., the Kerberos V mechanism)
+      Composite mechanisms (a concrete mechanism composed with one or
+      more stackable pseudo-mechanisms)
+      Stackable pseudo-mechanisms
+      Other pseudo-mechanisms (e.g., SPNEGO, the GSS-API itself)
+
+   Although composed mechanisms may be made available for use by
+   GSS-APIv2 applications without any further extensions, use of
+   stackable pseudo-mechanisms can complicate mechanism negotiation;
+   additionally, discovery of mechanisms appropriate for use in one or
+   another context would require hard-coding information about them in
+   GSS-APIv2 applications.  Extensions to the GSS-APIv2 could facilitate
+   use of composite.
+
+   The mechanism attribute inquiry facilities, together with the
+   forllowing additional interfaces, provide for a complete interface to
+   mechanism composition and for managing the complexity of mechanism
+   negotiation:
+      GSS_Compose_oid()
+      GSS_Decompose_oid()
+      GSS_Release_oid()
+      GSS_Indicate_negotiable_mechs()
+      GSS_Negotiate_mechs()
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 11]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+10.  Naming Extensions
+
+   Some applications make use of exported names, as produced by
+   GSS_Export_name(), to create/manage/evaluate access control lists; we
+   call this name-based authorization.
+
+   Exported names typically encode names that are meant for display to
+   humans, not internal identifiers.
+
+   In practice this creates a number of problems.  E.g., the referential
+   integrity of such access control lists is hard to maintain as
+   principals are added, removed, renamed or old principal names reused.
+
+   Additionally, some mechanisms may lack a notion of a "canonical" name
+   for some or all of their principals.  Such mechanisms cannot be used
+   by applications that rely on name-based authorization.
+
+   <Describe the proposed extensions in this area.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 12]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+11.  Additional Name Types
+
+   <Decribe domain-based names and the need for them.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 13]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+12.  GSS_Pseudo_random()
+
+   <Decribe GSS_Pseudo_random() and the need for it.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 14]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+13.  Channel Bindings Specifications
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 15]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+14.  Semantic and Miscallaneous Extensions
+
+   The GSS-APIv2 specifications say nothing about the thread-safety,
+   much less the fork-safety, of the GSS-API.  Thread-safety and
+   fork-safety are, after all, platform- and/or language-specific
+   matters.  But as support for multi-threading spreads the matter of
+   thread-safety cannot be avoided.  The matter of fork-safety is
+   specific to platforms that provide a "fork()" function, or similar.
+
+   <describe the GSS-APIv3's thread-safety requirements>
+
+   <reference the portability considerations section>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 16]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+15.  Portability Considerations
+
+   The potential for additional generic, mechanism-specific, language
+   binding-specific and, most importantly, semantic extensions to the
+   GSS-APIv3 may create application portability problems.  The mechanism
+   attribute inquiry facilities of the GSS-APIv3 and the
+   pseudo-mechanism OID for the GSS-API itself double as a run-time
+   facility for discovery of feature availability.  Run-time feature
+   discovery facilities, in turn, can be used at application build-time
+   as well by building small applications to display the available
+   features.
+
+   <...>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 17]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+16.  IANA Considerations
+
+   <Describe the namespace issues associated with future minor
+   extensions to the GSS-APIv3 and the IANA registries to be created to
+   cope with them.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 18]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+17.  Security Considerations
+
+   <...>
+
+18  Normative
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 19]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 20]
+
+
diff --git a/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-02.txt b/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-02.txt
new file mode 100644
index 000000000..6521f9875
--- /dev/null
+++ b/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-02.txt
@@ -0,0 +1,393 @@
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+               A PRF for the Kerberos V GSS-API Mechanism
+                draft-ietf-kitten-krb5-gssapi-prf-02.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on December 30, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document defines the Pseudo-Random Function (PRF) for the
+   Kerberos V mechanism for the Generic Security Service Application
+   Programming Interface (GSS-API), based on the PRF defined for the
+   Kerberos V cryptographic framework, for keying application protocols
+   given an established Kerberos V GSS-API security context.
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+Table of Contents
+
+   1. Conventions used in this document  . . . . . . . . . . . . . . . 3
+   2. Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . . . 4
+   3. Security Considerations  . . . . . . . . . . . . . . . . . . . . 5
+   4. Normative References . . . . . . . . . . . . . . . . . . . . . . 5
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
+      Intellectual Property and Copyright Statements . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+1.  Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 3]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+2.  Kerberos V GSS Mechanism PRF
+
+   The GSS-API PRF [GSS-PRF] function for the Kerberos V mechanism [CFX]
+   shall be the output of a PRF+ function based on the enctype's PRF
+   function keyed with the negotiated session key of the security
+   context and key usage X (TBD).
+
+   The security context MUST be fully established, else the mechanism
+   MUST fail with GSS_S_UNAVAILABLE as the major status code and
+   GSS_KRB5_S_KG_CTX_INCOMPLETE as the minor status code.
+
+   This PRF+ MUST be keyed with a key derived, with key usage (TBD),
+   from the session used by the initiator and acceptor, after the
+   security context is fully established, to derive keys for per-message
+   tokens.  For the current Kerberos V mechanism [CFX] this means that
+   the PRF+ MUST be keyed with the acceptor-asserted subkey, if it did
+   assert such a key, or the initiator's sub-session key otherwise.
+
+   The PRF+ function is a simple counter-based extension of the Kerberos
+   V pseudo-random function [KRB5-CRYPTO] for the enctype of the
+   security context's keys:
+
+   	PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
+
+   	Tn = pseudo-random-function(K, n || S)
+
+   	where '||' is the concatenation operator, 'n' is encoded as a
+   	network byte order 32-bit unsigned binary number, and where
+   	truncate(L, S) truncates the input octet string S to length L.
+
+   The maximum output size of the Kerberos V mechanism's GSS-API PRF
+   then is, necessarily, 2^32 octets.
+
+   Implementations MUST support output size of up to 2^14 octets at
+   least.
+
+   If the implementation cannot produce the desired output then it MUST
+   output what it can.
+
+   The minimum input octet string length that implementations MUST
+   support is also 2^14 octets.  If the input octet string is longer
+   than the maximum that an implementation can process then the
+   implementation MUST fail with GSS_S_FAILURE as the major status code
+   and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status code.
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+3.  Security Considerations
+
+   Kerberos V enctypes' PRF functions use a key derived from contexts'
+   session keys and should preserve the forward security properties of
+   the mechanisms' key exchanges.
+
+   Legacy Kerberos V enctypes may be weak, particularly the single-DES
+   enctypes.
+
+   See also [GSS-PRF] for generic security considerations of
+   GSS_Pseudo_random().
+
+   The computational cost of computing this PRF+ may vary depending on
+   the Kerberos V enctypes being used, but generally the computation of
+   this PRF+ gets more expensive as the input and output octet string
+   lengths grow (note that the use of a counter in the PRF+ construction
+   allows for parallelization).  This means that if an application can
+   be tricked into providing very large input octet strings and
+   requesting very long output octet strings then that may constitue a
+   denial of service attack on the application; therefore applications
+   SHOULD place appropriate limits on the size of any input octet
+   strings received from their peers without integrity protection.
+
+4  Normative References
+
+   [CFX]      Zhu, L., Jaganathan, K. and S. Hartman, "The Kerberos
+              Version 5 GSS-API Mechanism: Version 2".
+
+   [GSS-PRF]  Williams, N., "A PRF API extension for the GSS-API".
+
+   [KRB5-CRYPTO]
+              Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5".
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7]
+
+