diff --git a/doc/standardisation/draft-ietf-kitten-2478bis-00.txt b/doc/standardisation/draft-ietf-kitten-2478bis-00.txt
new file mode 100644
index 000000000..91071f378
--- /dev/null
+++ b/doc/standardisation/draft-ietf-kitten-2478bis-00.txt
@@ -0,0 +1,1230 @@
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                                  P. Leach
+Obsoletes: 2478 (if approved)                              K. Jaganathan
+Expires: May 22, 2005                              Microsoft Corporation
+                                                               S. Harman
+                                                                     MIT
+                                                            W. Ingersoll
+                                                        Sun Microsystems
+                                                       November 21, 2004
+
+
+         The Simple and Protected GSS-API Negotiation Mechanism
+                        draft-ietf-kitten-2478bis-00
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on May 22, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document specifies a negotiation mechanism for the Generic
+   Security Service Application Program Interface (GSS-API) which is
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 1]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+   described in RFC 2743.
+
+   GSS-API peers can use this negotiation mechanism to choose from a
+   common set of security mechanisms.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
+   3.  Negotiation Protocol . . . . . . . . . . . . . . . . . . . . .  6
+     3.1   Negotiation Description  . . . . . . . . . . . . . . . . .  6
+     3.2   Negotiation Procedure  . . . . . . . . . . . . . . . . . .  7
+   4.  Token Definitions  . . . . . . . . . . . . . . . . . . . . . .  9
+     4.1   Mechanism Types  . . . . . . . . . . . . . . . . . . . . .  9
+     4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . .  9
+       4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 10
+       4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 11
+   5.  Processing of mechListMIC  . . . . . . . . . . . . . . . . . . 13
+   6.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 15
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
+   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
+   A.  GSS-API Negotiation Support API  . . . . . . . . . . . . . . . 19
+     A.1   GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 19
+     A.2   GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 19
+   B.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 21
+       Intellectual Property and Copyright Statements . . . . . . . . 22
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 2]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+1.  Introduction
+
+   The GSS-API [RFC2743] provides a generic interface which can be
+   layered atop different security mechanisms such that if communicating
+   peers acquire GSS-API credentials for the same security mechanism,
+   then a security context may be established between them (subject to
+   policy).  However, GSS-API doesn't prescribe the method by which
+   GSS-API peers can establish whether they have a common security
+   mechanism.
+
+   The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
+   defined here is a pseudo security mechanism, represented by the
+   Object Identifier iso.org.dod.internet.security.mechanism.snego
+   (1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band
+   whether their credentials share common GSS-API security mechanism(s),
+   and if so, to invoke normal security context establishment for a
+   selected common security mechanism.  This is most useful for
+   applications that are based on GSS-API implementations and multiple
+   mechanisms are shared between the peers.
+
+   The SPNEGO mechanism negotiation is based on the following
+   negotiation model: the initiator proposes a list of security
+   mechanism(s), in its preference order (favorite choice first), the
+   acceptor (also known as the target) either accepts the initiator's
+   preferred security mechanism (the first in the list), or chooses one
+   that is available from the offered list, or rejects the proposed
+   value(s).  The target then informs the initiator of its choice.
+
+   Once a common security mechanism is chosen, it MAY also negotiate
+   mechanism-specific options during its context establishment, but that
+   will be inside the mechanism tokens and invisible to this protocol.
+
+   If per-message integrity services are available on the established
+   mechanism security context, the peers can then exchange MIC tokens to
+   ensure that the mechanism list was not tampered with.  This MIC token
+   exchange is OPTIONAL if no interference could have material impact on
+   the negotiation, i.e., when the selected mechanism is the first
+   choice for both peers.
+
+   In order to avoid an extra round trip, the first security token of
+   the preferred mechanism SHOULD be embedded in the initial negotiation
+   message (as defined in Section 4.2).  This mechanism token is
+   referred to as the optimistic token in this document.  If the
+   selected mechanism matches the initiator's preferred mechanism, no
+   additional round trips need to be incurred by using this protocol.
+   In addition, by using the optimistic token, the initiator can recover
+   from a non-fatal error in producing the first token before a
+   mechanism can be selected.  Implementations, however, MAY omit the
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 3]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+   optimistic token, to avoid the cost of generating it in cases where
+   the initiator's preferred mechanism is not selected by the acceptor.
+
+   SPNEGO uses the concepts developed in the GSS-API specification
+   [RFC2743].  The negotiation data is encapsulated in context-level
+   tokens.  Therefore, callers of the GSS-API do not need to be aware of
+   the existence of the negotiation tokens but only of the new
+   pseudo-security mechanism.  A failure in the negotiation phase causes
+   a major status code to be returned: GSS_S_BAD_MECH.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 4]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 5]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+3.  Negotiation Protocol
+
+   When the established mechanism context provides for integrity
+   protection, the mechanism negotiation can be protected.  When
+   acquiring negotiated security mechanism tokens, per-message integrity
+   services are always requested by the SPNEGO mechanism.
+
+   When the established mechanism context supports per-message integrity
+   services, SPNEGO guarantees that the selected mechanism is mutually
+   preferred.
+
+   This section describes the negotiation process of this protocol.
+
+3.1  Negotiation Description
+
+   The first negotiation token sent by the initiator contains an ordered
+   list of mechanisms (in preference order, favorite choice first), and
+   optionally the initial security token for the preferred mechanism of
+   the initiator (i.e., the first in the list).  The list of security
+   mechanisms available for negotiation is based on the credentials
+   being used.
+
+   The target then processes the token from the initiator.  This will
+   result in one of four possible states (as defined in Section 4.2.2):
+   accept_completed, accept_incomplete, reject, or request_mic.  A
+   reject state will terminate the negotiation;  an accept_completed
+   state indicates that not only was the initiator-selected mechanism
+   acceptable to the target, but that the initial token was sufficient
+   to complete the authentication;  an accept_incomplete state indicates
+   that further message exchange is needed but the MIC token exchange as
+   described in Section 5 is OPITONAL;  a request_mic state (this state
+   can only be present in the first reply message from the target)
+   indicates the MIC token exchange is REQUIRED if per-message integrity
+   services are available.
+
+   Unless the preference order is specified by the application (see
+   Appendix A), the policy by which the target chooses a mechanism is an
+   implementation-specific local matter.  In the absence of application
+   specified preference order or other policy, the target SHALL choose
+   the first mechanism in the initiator proposed list for which it has
+   valid credentials.
+
+   In case of a successful negotiation, the security mechanism in the
+   first reply message represents the value suitable for the target, and
+   picked up from the list offered by the initiator.  A context level
+   token for a reject state is OPTIONAL.
+
+   Once a mechanism has been selected, the tokens specific to the
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 6]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+   selected mechanism are carried within the negotiation tokens.
+
+   Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the
+   mechanism list as seen by the target.
+
+   To avoid conflicts with the use of MIC tokens by SPNEGO,
+   partially-established contexts are not used for per-message calls:
+   the prot_ready_state [RFC2743] will be false even if the underlying
+   mechanism would return true natively.
+
+3.2  Negotiation Procedure
+
+   The basic form of the procedure assumes that per-message integrity
+   services are available on the established mechanism context, and it
+   is summarized as follows:
+
+   (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
+      but requests (either explicitly, with the negotiation mechanism,
+      or through accepting a default, when the default is this
+      negotiation mechanism) that SPNEGO is used.
+
+   (b) The initiator GSS-API implementation emits a negotiation token
+      containing a list of supported security mechanisms (possible just
+      one mechanism) for the credentials used for this context
+      establishment, and optionally an initial security token for the
+      first mechanism from that list.
+
+   (c) The GSS-API initiator application sends the token to the target
+      application.  The GSS-API target application deposits the token
+      through invoking GSS_Accept_sec_context().  The acceptor will do
+      one of the following:
+
+      (I) No proposed mechanism is acceptable, the negotiation SHALL be
+         terminated.  GSS_Accept_sec_context indicates GSS_S_BAD_MECH.
+         The acceptor MAY output a negotiation token containing a reject
+         state.
+
+      (II) If either the initiator's preferred mechanism is not accepted
+         by the target, or this mechanism is accepted but it is not the
+         most preferred mechanism available for the acceptor (see
+         Section 3.1 and Section 5), GSS_Accept_sec_context() indicates
+         GSS_S_CONTINUE_NEEDED.  The acceptor MUST output a negotiation
+         token containing a request_mic state.
+
+      (III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE
+         or GSS_S_CONTINUE_NEEDED, depending on if at least one
+         additional negotiation token from the initiator is needed to
+         establish this context.  The acceptor outputs a negotiation
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 7]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+         token containing an accept_complete or accept_incomplete state,
+         respectively.
+
+      If the initiator's preferred mechanism is accepted, and an
+      optimistic mechanism token was included, this mechanism token MUST
+      be deposited to the selected mechanism through invoking
+      GSS_Accept_sec_context() and if a response mechanism token is
+      emitted, it MUST be included in the response negotiation token.
+      Otherwise, the target will not emit a response mechanism token in
+      the first reply.
+
+   (d) The GSS-API target application returns the negotiation token to
+      the initiator application.  The GSS-API initiator application
+      deposits the token through invoking GSS_Init_sec_context().  The
+      security context initialization is then continued according to the
+      standard GSS-API conventions for the selected mechanism, where the
+      tokens of the selected mechanism are encapsulated until the
+      GSS_S_COMPLETE is returned for both the initiator and the target
+      by the selected security mechanism.
+
+   (e) MIC tokens are then either skipped or exchanged according to
+      Section 5.
+
+   Note that the *_req_flag input parameters for context establishment
+   are relative to the selected mechanism, as are the *_state output
+   parameters.  i.e., these parameters are not applicable to the
+   negotiation process per se.
+
+   On receipt of a negotiation token on the target side, a GSS-API
+   implementation that does not support negotiation would indicate the
+   GSS_S_BAD_MECH status as if a particular basic security mechanism had
+   been requested but was not supported.
+
+   When GSS_Acquire_cred is invoked with this SPNEGO mechanism as
+   desired_mechs, an implementation-specific default credential is used
+   to carry on the negotiation.  A set of mechanisms as specified
+   locally by the system administrator is then available for
+   negotiation.  If there is a desire for the caller to make its own
+   choice, then an additional API has to be used (see Appendix A).
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 8]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+4.  Token Definitions
+
+   The type definitions in this section assume an ASN.1 module
+   definition of the following form:
+
+
+      SPNEGOASNOneSpec {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) mechanism(5) snego (2) modules(4) spec2(2)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      -- rest of definitions here
+
+      END
+
+
+   This specifies that the tagging context for the module will be
+   explicit and non-automatic.
+
+   The encoding of SPNEGO protocol messages shall obey the Distinguished
+   Encoding Rules (DER) of ASN.1 as described in [X690].
+
+4.1  Mechanism Types
+
+   In this negotiation model, each OID represents one GSS-API mechanism
+   or one variant of it according to [RFC2743].
+
+
+       MechType ::= OBJECT IDENTIFIER
+           -- OID represents each security mechanism as suggested by
+           -- [RFC2743]
+
+       MechTypeList ::= SEQUENCE OF MechType
+
+
+4.2  Negotiation Tokens
+
+   The syntax of the initial negotiation tokens follows the
+   initialContextToken syntax defined in Section 3.1 of [RFC2743].  The
+   SPNEGO pseudo mechanism is identified by the Object Identifier
+   specified in Section 1.  Subsequent tokens are not encapsulated in
+   this GSS-API generic token framing.
+
+   This section specifies the syntax of the inner token for the initial
+   message, and the syntax of subsequent context establishment tokens.
+
+       NegotiationToken ::= CHOICE {
+           negTokenInit    [0] NegTokenInit,
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 9]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+           negTokenResp    [1] negTokenResp
+       }
+
+
+
+4.2.1  negTokenInit
+
+       NegTokenInit ::= SEQUENCE {
+           mechTypes       [0] MechTypeList,
+           reqFlags        [1] ContextFlags  OPTIONAL,
+           mechToken       [2] OCTET STRING  OPTIONAL,
+           mechListMIC     [3] OCTET STRING  OPTIONAL,
+           ...
+       }
+       ContextFlags ::= BIT STRING {
+           delegFlag       (0),
+           mutualFlag      (1),
+           replayFlag      (2),
+           sequenceFlag    (3),
+           anonFlag        (4),
+           confFlag        (5),
+           integFlag       (6)
+       }
+
+   This is the syntax for the inner token of the initial negotiation
+   message.
+
+   mechTypes
+
+         This field contains one or more security mechanisms available
+         for the initiator in preference order (favorite choice first).
+
+   reqFlags
+
+         This field, if present, contains the service options that are
+         requested to establish the context.  The context flags SHOULD
+         be filled in from the req_flags parameter of
+         GSS_Init_sec_context().  This field SHALL NOT have impact on
+         the negotiation.
+
+   mechToken
+
+         This field, is present, contains the optimistic security
+         mechanism token.
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 10]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+   mechlistMIC
+
+         This field, is present, contains a MIC token, which is computed
+         according to Section 5, for the mechanism list in the initial
+         negotiation message.
+
+
+4.2.2  negTokenResp
+
+       NegTokenResp ::= SEQUENCE {
+           negResult       [0] ENUMERATED {
+               accept_completed    (0),
+               accept_incomplete   (1),
+               reject              (2),
+               request_mic         (3)
+           },
+           supportedMech   [1] MechType      OPTIONAL,
+           responseToken   [2] OCTET STRING  OPTIONAL,
+           mechListMIC     [3] OCTET STRING  OPTIONAL,
+           ...
+       }
+
+   This is the syntax for all subsequent negotiation messages.
+
+   negResult
+
+         This field contains the state of the negotiation.  This can be:
+
+         accept_completed
+            No further negotiation message from the peer is expected,
+            and the security context is established for the sender.
+
+         accept_incomplete
+            At least one more negotiation message from the peer is
+            needed to establish the security context.
+
+         reject
+            The sender terminates the negotiation.
+
+         request_mic
+            The sender indicates that the exchange of MIC tokens, as
+            described in Section 5, will be REQUIRED if per-message
+            integrity services are available on the mechanism context to
+            be established.  This value SHALL only be present in the
+            first reply from the target.
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 11]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+   supportedMech
+
+         This field SHALL only be present in the first reply from the
+         target.  It is a choice from the mechanism(s) offered by the
+         initiator.
+
+   ResponseToken
+
+         The field, if present, contains tokens specific to the
+         mechanism selected.
+
+   mechlistMIC
+
+         This field, is present, contains a MIC token, which is computed
+         according to Section 5, for the mechanism list in the initial
+         negotiation message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 12]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+5.  Processing of mechListMIC
+
+   If the mechanism selected by the negotiation does not support
+   integrity protection, then no mechlistMIC token is used.  Otherwise
+   if the initiator's preferred mechanism is accepted and it is also the
+   most preferred mechanism available for the acceptor (there is no
+   mechanism which, had it been present in the mechanism list, the
+   acceptor would have preferred over the accepted mechanism), then the
+   MIC token exchange, as described later in this section, is OPTIONAL.
+   In all other cases, MIC tokens MUST be exchanged after the mechanism
+   context is fully established.
+
+   It is assumed that per-message integrity services are available on
+   the established mechanism context in the following procedure for
+   processing MIC tokens of the initiator's mechanism list.
+
+   a) The mechlistMIC token (or simply the MIC token) is computed
+      through invoking GSS_GetMIC(): the input context_handle is the
+      established mechanism context, the input qop_req is 0, and the
+      input message is the mechTypes field in the initial negotiation
+      message (only the "value" portion, omitting the tag and length, of
+      the ASN.1 encoding for that field is included).
+
+   b) If the selected mechanism uses an even number of mechanism tokens
+      (namely the acceptor sends the last mechanism token), the acceptor
+      does the following when emitting the negotiation message
+      containing the last mechanism token: if the MIC token exchange is
+      not required, GSS_Accept_sec_context() either indicates
+      GSS_S_COMPLETE and does not include a mechlistMIC token, or
+      indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token
+      and an accept_incomplete state; if the MIC token exchange is
+      required, GSS_Accept_sec_context() indicates
+      GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token.
+      Acceptors who wish to be compatible with legacy Windows SPNEGO
+      implementations as described in Appendix B shall not generate a
+      mechlistMIC token when the MIC token exchange is not required.
+      The initiator then processes the last mechanism token, and does
+      one of the following:
+
+      (I) If a mechlistMIC token was included, and is correctly
+         verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE.  The
+         output negotiation message contains a mechlistMIC token, and an
+         accept_complete state.  The acceptor MUST then verify this
+         mechlistMIC token.
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 13]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+      (II) If a mechlistMIC token was included but is incorrect, the
+         negotiation SHALL be terminated.  GSS_Accept_sec_context()
+         indicates GSS_S_DEFECTIVE_TOKEN.
+
+      (III) If no mechlistMIC token was included, and the MIC token
+         exchange is not required, GSS_Init_sec_context() indicates
+         GSS_S_COMPLETE with no output token.
+
+      (IV) If no mechlistMIC token was included, but the MIC token
+         exchange is required, the negotiation SHALL be terminated.
+         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
+
+   c) In the case that the chosen mechanism uses an odd number of
+      mechanism tokens (namely the initiator sends the last mechanism
+      token), the initiator does the following when emitting the
+      negotiation message containing the last mechanism token: if the
+      negResult state was request_mic in the first reply from the
+      target, a mechlistMIC token MUST be included, otherwise the
+      mechlistMIC token is OPTIONAL.  GSS_Init_sec_context() indicates
+      GSS_S_CONTINUE_NEEDED.  Initiators who wish to be compatible with
+      legacy Windows SPNEGO implementations as described in Appendix B
+      shall not generate a mechlistMIC token when the MIC token exchange
+      is not required.  The acceptor then processes the last mechanism
+      token, and does one of the following:
+
+      (I) If a mechlistMIC token was included, and is correctly
+         verified, GSS_Accept_sec_context() indicates GSS_S_COMPLETE.
+         The output negotiation message contains a mechlistMIC token,
+         and an accept_complete state.  The initiator MUST then verify
+         this mechlistMIC token.
+
+      (II) If a mechlistMIC token was included but is incorrect, the
+         negotiation SHALL be terminated.  GSS_Accept_sec_context()
+         indicates GSS_S_DEFECTIVE_TOKEN.
+
+      (III) If no mechlistMIC token was included and the mechlistMIC
+         token exchange is not required, GSS_Accept_sec_context()
+         indicates GSS_S_COMPLETE.  The output negotiation message
+         contains an accept_complete state.
+
+      (IV) If no mechlistMIC token was included and the acceptor sent a
+         request_mic state in the first reply message (the exchange of
+         MIC tokens is required), the negotiation SHALL be terminated.
+         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 14]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+6.  Extensibility
+
+   Two mechanisms are provided by extensibility.  First, the ASN.1
+   structures in this specification MAY be expanded by IETF standards
+   action.  Implementations receiving unknown fields MUST ignore these
+   fields.
+
+   Secondly, OIDs corresponding to a desired mechanism attribute may be
+   included in the set of preferred mechanisms by an initiator.  The
+   acceptor can choose to honor this request by preferring mechanisms
+   that have that attribute.  Future work within the Kitten working
+   group is expected to standardize common attributes that SPNEGO
+   mechanisms may wish to support.  At this time it is sufficient to say
+   that initiators MAY include OIDs that do not correspond to mechanisms
+   but instead correspond to desired mechanism attributes in their
+   requests.  Such OIDs MAY influence the acceptor's choice of
+   mechanism.  As discussed in Section 5, if there are mechanisms that
+   if present in the initiator's list of mechanisms might be preferred
+   by the acceptor to the initiator's preferred mechanism, the acceptor
+   MUST demand the MIC token exchange.  As a consequence, acceptors MUST
+   demand the MIC token exchange if they support negotiation of
+   attributes not available in the initiator's preferred mechanism
+   regardless of whether the initiator actually requested these
+   attributes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 15]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+7.  Security Considerations
+
+   In order to produce the MIC token for the mechanism list, the
+   mechanism must provide integrity protection.  When the selected
+   mechanism does not support integrity protection, then the negotiation
+   is vulnerable: an active attacker can force it to use a security
+   mechanism that is not mutually preferred but is acceptable anyway to
+   the target.
+
+   When per-message integrity services are available on the established
+   mechanism context, and there was an alteration of the mechanism list
+   by an adversary such that a common mechanism that is not mutually
+   preferred could be selected, this protocol provides the following
+   guarantees: if the last mechanism token is sent by the initiator,
+   both peers shall fail; if the last mechanism token is sent by the
+   acceptor, the acceptor shall not complete and the initiator at worst
+   shall complete with its preferred mechanism being selected.  The
+   negotiation may not be terminated if an alteration was made but it
+   had no material impact.
+
+   The protection of the negotiation depends on the strength of the
+   integrity protection.  In particular, the strength of SPNEGO is no
+   stronger than the integrity protection of the weakest mechanism
+   acceptable to GSS-API peers.
+
+   In all cases, the communicating peers are exposed to the denial of
+   service threat.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 16]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+8.  Acknowledgments
+
+   The authors wish to thank Nicolas Williams, Ken Raeburn, Jeff Altman,
+   Cristian Ilac and Martin Rex for their comments and suggestions on
+   earlier versions of this document.
+
+   Eric Baize and Denis Pinkas wrote the original SPNEGO specification
+   [RFC2478], of which some of the text has been retained in this
+   document.
+
+9  References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
+              Negotiation Mechanism", RFC 2478, December 1998.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding Rules 
+              (BER), Canonical Encoding Rules (CER) and Distinguished 
+              Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 
+              ISO/IEC International Standard 8825-1:1998.
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: paulle@microsoft.com
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 17]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: karthikj@microsoft.com
+
+
+   Sam Hartman
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA  02139
+   US
+
+   EMail: hartmans@mit.edu
+
+
+   Wyllys Ingersoll
+   Sun Microsystems
+   1775 Wiehle Avenue, 2nd Floor
+   Reston, VA  20190
+   US
+
+   EMail: wyllys.ingersoll@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 18]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+Appendix A.  GSS-API Negotiation Support API
+
+   In order to provide to a GSS-API caller (either the initiator or the
+   target or both) the ability to choose among the set of supported
+   mechanisms a reduced set of mechanisms for negotiation, two
+   additional APIs are defined:
+
+   o  GSS_Get_neg_mechs() indicates the set of security mechanisms
+      available on the local system to the caller for negotiation, based
+      on the credentials being used.
+   o  GSS_Set_neg_mechs() specifies the set of security mechanisms to be
+      used on the local system by the caller for negotiation, for the
+      given credentials.
+
+A.1  GSS_Set_neg_mechs call
+
+   Inputs:
+
+   o  cred_handle CREDENTIAL HANDLE, -- NULL specifies default
+      -- credentials
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the set of security mechanisms
+      available for negotiation has been set to mech_set.
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to specify the set of security mechanisms that may be
+   negotiated with the credential identified by cred_handle.  This call
+   is intended for support of specialized callers who need to restrict
+   the set of negotiable security mechanisms from the set of all
+   security mechanisms available to the caller (based on available
+   credentials).  Note that if more than one mechanism is specified in
+   mech_set, the order in which those mechanisms are specified implies a
+   relative preference.
+
+A.2  GSS_Get_neg_mechs call
+
+   Input:
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 19]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+   o  cred_handle CREDENTIAL HANDLE -- NULL specifies default
+      -- credentials
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the set of security mechanisms
+      available for negotiation has been returned in mech_set.
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to determine the set of security mechanisms available
+   for negotiation with the credential identified by cred_handle.  This
+   call is intended for support of specialized callers who need to
+   reduce the set of negotiable security mechanisms from the set of
+   supported security mechanisms available to the caller (based on
+   available credentials).
+
+   Note: The GSS_Indicate_mechs() function indicates the full set of
+   mechanism types available on the local system.  Since this call has
+   no input parameter, the returned set is not necessarily available for
+   all credentials.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 20]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+Appendix B.  Changes since RFC2478
+
+      SPNEGO implementations in Windows 2000/Windows XP/Windows Server
+      2003 have the following behavior: no mechlistMIC is produced, and
+      mechlistMIC is not processed if one is provided; if the initiator
+      sends the last mechanism token, the acceptor will send back a
+      negotiation token with an accept_complete state and no mechlistMIC
+      token.  In addition, the OID (1.2.840.48018.1.2.2) can be used to
+      identify the GSS-API Kerberos Version 5 mechanism.
+
+      The following changes have been made to be compatible with these
+      legacy implementations.
+
+      *  NegTokenTarg is changed to negTokenResp and it is the message
+         format for all subsequent negotiation tokens.
+      *  NegTokenInit is the message for the initial token and that
+         token only.
+      *  mechTypes in negTokenInit is not optional.
+      *  negResult is not optional in the negTokenResp token.
+      *  Two MIC tokens are exchanged, one in each direction.
+      *  If the selected mechanism is also the most preferred mechanism
+         for both peers, it is safe to omit the MIC tokens.
+
+      If at least one of the two peers implements the pseudo mechanism
+      in this document, the negotiation is protected.
+
+      The following changes are to address the problems in RFC 2478.
+
+      *  reqFlags is not protected therefore it should not impact the
+         negotiation.
+      *  DER encoding is required.
+      *  GSS_GetMIC() input is clarified.
+      *  Per-message integrity services are requested for the negotiated
+         mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 21]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 22]
+
+
diff --git a/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-02.txt b/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-02.txt
new file mode 100644
index 000000000..55cdf4c76
--- /dev/null
+++ b/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-02.txt
@@ -0,0 +1,562 @@
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                             K. Jaganathan
+Expires: May 21, 2005                              Microsoft Corporation
+                                                             N. Williams
+                                                        Sun Microsystems
+                                                       November 20, 2004
+
+
+                        OCSP Support for PKINIT
+                 draft-ietf-krb-wg-ocsp-for-pkinit-02
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on May 21, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document defines a mechanism to enable in-band transmission of
+   OCSP responses.  These responses are used to verify the validity of
+   the certificates used in PKINIT - the Kerberos Version 5 extension
+   that provides for the use of public key cryptography.
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 1]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.   Conventions Used in This Document  . . . . . . . . . . . . .   4
+   3.   Message Definition . . . . . . . . . . . . . . . . . . . . .   5
+   4.   Security Considerations  . . . . . . . . . . . . . . . . . .   6
+   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   7
+   6.   Acknowledgement  . . . . . . . . . . . . . . . . . . . . . .   8
+   7.   References . . . . . . . . . . . . . . . . . . . . . . . . .   8
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .   8
+        Intellectual Property and Copyright Statements . . . . . . .  10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 2]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+1.  Introduction
+
+   Online Certificate Status Protocol (OCSP) [RFC2560] enables
+   applications to obtain timely information regarding the revocation
+   status of a certificate.  Because OCSP responses are well-bounded and
+   small in size, constrained clients may wish to use OCSP to check the
+   validity of KDC certificates in order to avoid transmission of large
+   Certificate Revocation Lists (CRLs) and therefore save bandwidth on
+   constrained networks [OCSP-PROFILE].
+
+   This document defines a pre-authentication type [CLARIFICATIONS],
+   where the client and the KDC MAY piggyback OCSP responses for
+   certificates used in authentication exchanges, as defined in
+   [PKINIT].
+
+   By using this OPTIONAL extension, PKINIT clients and the KDC can
+   maximize the reuse of cached OCSP responses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 3]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 4]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+3.  Message Definition
+
+   A pre-authentication type identifier is defined for this mechanism:
+
+              PA-PK-OCSP-RESPONSE              16
+
+   The corresponding pre-authentication field contains OCSP data as
+   follows:
+
+          PA-PK-OCSP-DATA ::= SEQUENCE OF OcspResponse
+
+          OcspResponse ::= OCTET STRING
+                         -- contains a complete OCSP response,
+                         -- defined in [RFC2560]
+
+   The client MAY send OCSP responses for certificates used in
+   PA-PK-AS-REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
+
+   The KDC that receives a PA-PK-OCSP-RESPONSE the SHOULD send a
+   PA-PK-OCSP-RESPONSE in response.  The client can request a
+   PA-PK-OCSP-RESPONSE by using an empty sequence in its request.
+
+   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
+   PA-PK-OCSP-RESPONSE from the client.
+
+   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
+   certificates used in PA-PK-AS-REP [PKINIT].
+
+   Note the lack of integrity protection for the empty or missing OCSP
+   response; lack of an expected OCSP response from the KDC for the
+   KDC's certificates SHOULD be treated as an error by the client,
+   unless it is configured otherwise.
+
+   When using OCSP, the response is signed by the OCSP server, which is
+   trusted by the receiver.  Depending on local policy, further
+   verification of the validity of the OCSP servers MAY need to be done.
+
+   The client and the KDC SHOULD ignore invalid OCSP responses received
+   via this mechanism, and they MAY implement CRL processing logic as a
+   fall-back position, if the OCSP responses received via this mechanism
+   alone are not sufficient for the verification of certificate
+   validity.  The client and/or the KDC MAY ignore a valid OCSP response
+   and perform their own revocation status verification independently.
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 5]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+4.  Security Considerations
+
+   The pre-authentication data in this document do not actually
+   authenticate any principals, and MUST be used in conjunction with
+   PKINIT.
+
+   There is a downgrade attack against clients which want OCSP responses
+   from the KDC for the KDC's certificates.  The clients, however, can
+   treat the absence of valid OCSP responses as an error, based on their
+   local configuration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 6]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+5.  IANA Considerations
+
+   This document defines a new pre-authentication type for use with
+   PKINIT to encode OCSP responses.  The official value for this padata
+   identifier need to be acquired from IANA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 7]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+6.  Acknowledgements
+
+   This document was based on conversations among the authors, Jeffrey
+   Altman, Sam Hartman, Martin Rex and other members of the Kerberos
+   working group.
+
+7  References
+
+   [CLARIFICATIONS]
+              Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", 
+              draft-ietf-krb-wg-kerberos-clarifications, Work in 
+              progress.
+
+   [OCSP-PROFILE]
+              Deacon, A. and R. Hurst, "Lightweight OCSP Profile for
+              High Volume Environments", 
+              draft-ietf-pkix-lightweight-ocsp-profile, Work in
+              progress.
+
+   [PKINIT]   Tung, B., Neuman, B. and S. Medvinsky, "Public Key
+              Cryptography for Initial Authentication in Kerberos",
+              draft-ietf-cat-kerberos-pk-init, Work in progress.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
+              Adams, "X.509 Internet Public Key Infrastructure Online
+              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: karthikj@microsoft.com
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 8]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 9]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                 [Page 10]
+
+