draft-ietf-kitten-2478bis-02.txt   draft-ietf-kitten-2478bis-03.txt 
NETWORK WORKING GROUP L. Zhu NETWORK WORKING GROUP L. Zhu
Internet-Draft P. Leach Internet-Draft P. Leach
Obsoletes: 2478 (if approved) K. Jaganathan Obsoletes: 2478 (if approved) K. Jaganathan
Expires: June 1, 2005 Microsoft Corporation Expires: June 14, 2005 Microsoft Corporation
W. Ingersoll W. Ingersoll
Sun Microsystems Sun Microsystems
December 1, 2004 December 14, 2004
The Simple and Protected GSS-API Negotiation Mechanism The Simple and Protected GSS-API Negotiation Mechanism
draft-ietf-kitten-2478bis-02 draft-ietf-kitten-2478bis-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 38 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 1, 2005. This Internet-Draft will expire on June 14, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
This document specifies a negotiation mechanism for the Generic This document specifies a negotiation mechanism for the Generic
Security Service Application Program Interface (GSS-API) which is Security Service Application Program Interface (GSS-API) which is
described in RFC 2743. described in RFC 2743.
GSS-API peers can use this negotiation mechanism to choose from a GSS-API peers can use this negotiation mechanism to choose from a
common set of security mechanisms. common set of security mechanisms.
If per-message integrity services are available on the established
mechanism context, then the negotiation is protected against an
attacker forcing the selection of a mechanism not desired by the
peers.
This mechanism replaces RFC 2478 in order to fix defects in that
specification and to describe how to interoperate with
implementations of that specification commonly deployed on the
Internet.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . 6 3. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . 6
3.1 Negotiation Description . . . . . . . . . . . . . . . . . 6 3.1 Negotiation Description . . . . . . . . . . . . . . . . . 6
3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 7 3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 7
4. Token Definitions . . . . . . . . . . . . . . . . . . . . . . 9 4. Token Definitions . . . . . . . . . . . . . . . . . . . . . . 10
4.1 Mechanism Types . . . . . . . . . . . . . . . . . . . . . 9 4.1 Mechanism Types . . . . . . . . . . . . . . . . . . . . . 10
4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 9 4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 10
4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 10 4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 11
4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 11 4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 12
5. Processing of mechListMIC . . . . . . . . . . . . . . . . . . 13 5. Processing of mechListMIC . . . . . . . . . . . . . . . . . . 14
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. Normative References . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 21
A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 21 10.2 Informative References . . . . . . . . . . . . . . . . . . . 21
A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 21 A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 23
B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 23 A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 25 A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 23
B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 25
C. mechListMIC Computation Example . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 28
1. Introduction 1. Introduction
The GSS-API [RFC2743] provides a generic interface which can be The GSS-API [RFC2743] provides a generic interface which can be
layered atop different security mechanisms such that if communicating layered atop different security mechanisms such that if communicating
peers acquire GSS-API credentials for the same security mechanism, peers acquire GSS-API credentials for the same security mechanism,
then a security context may be established between them (subject to then a security context may be established between them (subject to
policy). However, GSS-API does not prescribe the method by which policy). However, GSS-API does not prescribe the method by which
GSS-API peers can establish whether they have a common security GSS-API peers can establish whether they have a common security
mechanism. mechanism.
The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
defined here is a pseudo security mechanism, represented by the defined here is a pseudo security mechanism, represented by the
Object Identifier iso.org.dod.internet.security.mechanism.snego 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 (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), whether their credentials support a common set of one or more GSS-API
and if so, to invoke normal security context establishment for a security mechanisms, and if so, to invoke the normal security context
selected common security mechanism. This is most useful for establishment for a selected common security mechanism. This is most
applications which are based on GSS-API implementations and share useful for applications which depend on GSS-API implementations and
multiple mechanisms between the peers. share multiple mechanisms between the peers.
The SPNEGO mechanism negotiation is based on the following The SPNEGO mechanism negotiation is based on the following model: the
negotiation model: the initiator proposes a list of security initiator proposes a list of security mechanism(s), in decreasing
mechanism(s), in decreasing preference order (favorite choice first), preference order (favorite choice first), the acceptor (also known as
the acceptor (also known as the target) either accepts the the target) either accepts the initiator's preferred security
initiator's preferred security mechanism (the first in the list), or mechanism (the first in the list), or chooses one that is available
chooses one that is available from the offered list, or rejects the from the offered list, or rejects the proposed value(s). The target
proposed value(s). The target then informs the initiator of its then informs the initiator of its choice.
choice.
Once a common security mechanism is chosen, mechanism-specific Once a common security mechanism is chosen, mechanism-specific
options MAY be negotiated as part of the selected mechanism's context options MAY be negotiated as part of the selected mechanism's context
establishment. These negotiations (if any) are internal to the establishment. These negotiations (if any) are internal to the
mechanism and opaque to the SPNEGO protocol. As such they are mechanism and opaque to the SPNEGO protocol. As such they are
outside the scope of this document. outside the scope of this document.
If per-message integrity services are available on the established If per-message integrity services are available on the established
mechanism security context, then the peers can exchange MIC tokens to mechanism security context, then the negotiation is protected to
ensure that the mechanism list was not tampered with. This MIC token ensure that the mechanism list has not been modified. In cases where
exchange is OPTIONAL if the selected mechanism is the most preferred an attacker could have materially influenced the negotiation, peers
choice of both peers (see Section 5). exchange message integrity code (MIC) tokens to confirm the mechanism
list has not been modified. If no action of an attacker could have
materially modified the outcome of the negotiation, the exchange of
MIC tokens is optional (see Section 5). Allowing MIC tokens to be
optional in this case provides interoperability with existing
implementations while still protecting the negotiation. This
interoperability comes at the cost of increased complexity.
In order to avoid an extra round trip, the first security token of In order to avoid an extra round trip, the first context
the initiator's preferred mechanism SHOULD be embedded in the initial establishment token of the initiator's preferred mechanism SHOULD be
negotiation message (as defined in Section 4.2). This mechanism embedded in the initial negotiation message (as defined in Section
token is referred to as the optimistic mechanism token in this 4.2). (This mechanism token is referred to as the optimistic
document. If the selected mechanism matches the initiator's mechanism token in this document.) In addition, using the optimistic
preferred mechanism, no additional round trips need be incurred by mechanism token allows the initiator to recover from non-fatal errors
using this protocol. In addition, using the optimistic mechanism encountered trying to produce the first mechanism token before a
token allows the initiator to recover from non-fatal errors while mechanism can be selected. Implementations MAY omit the optimistic
producing the first mechanism token before a mechanism can be mechanism token in cases where the likelihood of the initiator's
selected. Implementations MAY omit the optimistic mechanism token to preferred mechanism not being selected by the acceptor is significant
avoid the cost of generating it in cases where the initiator's given the cost of generating it.
preferred mechanism is not selected by the acceptor.
SPNEGO relies the concepts developed in the GSS-API specification SPNEGO relies on the concepts developed in the GSS-API specification
[RFC2743]. The negotiation data is encapsulated in context-level [RFC2743]. The negotiation data is encapsulated in context-level
tokens. Therefore, callers of the GSS-API do not need to be aware of 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 the existence of the negotiation tokens but only of the new
pseudo-security mechanism. A failure in the negotiation phase causes pseudo-security mechanism. A failure in the negotiation phase causes
a major status code to be returned: GSS_S_BAD_MECH. a major status code to be returned: GSS_S_BAD_MECH.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 6, line 21 skipping to change at page 6, line 21
When the established mechanism context supports per-message integrity When the established mechanism context supports per-message integrity
services, SPNEGO guarantees that the selected mechanism is mutually services, SPNEGO guarantees that the selected mechanism is mutually
preferred. preferred.
This section describes the negotiation process of this protocol. This section describes the negotiation process of this protocol.
3.1 Negotiation Description 3.1 Negotiation Description
The first negotiation token sent by the initiator contains an ordered The first negotiation token sent by the initiator contains an ordered
list of mechanisms (in decreasing preference order, favorite list of mechanisms in decreasing preference order (favorite mechanism
mechanism first), and optionally the initial mechanism token for the first), and optionally the initial mechanism token for the preferred
preferred mechanism of the initiator (i.e., the first in the list). mechanism of the initiator (i.e., the first in the list). (Note that
The list of security mechanisms available for negotiation is based on the list MUST NOT contain mechanisms for which the client does not
the credentials being used. have appropriate credentials.)
The target then processes the token from the initiator. This will 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): result in one of four possible states (as defined in Section 4.2.2)
accept_completed, accept_incomplete, reject, or request_mic. A being returned in the reply message: accept_completed,
reject state will terminate the negotiation; an accept_completed accept_incomplete, reject, or request_mic. A reject state will
state indicates that not only was the initiator-selected mechanism terminate the negotiation; an accept_completed state indicates that
acceptable to the target, but also that the initial mechanism token not only was the initiator-selected mechanism acceptable to the
was sufficient to complete the authentication; an accept_incomplete target, but also that the optimistic mechanism token was sufficient
state indicates that further message exchange is needed but the MIC to complete the authentication; an accept_incomplete state indicates
token exchange as described in Section 5 is OPTIONAL; a request_mic that further message exchange is needed but the MIC token exchange as
state (this state can only be present in the first reply message from described in Section 5 is OPTIONAL; a request_mic state (this state
the target) indicates the MIC token exchange is REQUIRED if can only be present in the first reply message from the target)
per-message integrity services are available. indicates the MIC token exchange is REQUIRED if per-message integrity
services are available.
Unless the preference order is specified by the application (see Unless the preference order is specified by the application (see
Appendix A), the policy by which the target chooses a mechanism is an Appendix A), the policy by which the target chooses a mechanism is an
implementation-specific local matter. In the absence of an implementation-specific local matter. In the absence of an
application specified preference order or other policy, the target application specified preference order or other policy, the target
SHALL choose the first mechanism in the initiator proposed list for SHALL choose the first mechanism in the initiator proposed list for
which it has valid credentials. which it has valid credentials.
In case of a successful negotiation, the security mechanism in the In case of a successful negotiation, the security mechanism in the
first reply message represents the value suitable for the target, first reply message represents the value suitable for the target,
picked up from the list offered by the initiator. A context level chosen from the list offered by the initiator.
token for a reject state is OPTIONAL.
Once a mechanism has been selected, the tokens specific to the In case of an unsuccessful negotiation, the reject state is returned
selected mechanism are carried within the negotiation tokens. and it is OPTIONAL to emit a context level negotiation token.
Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the Once a mechanism has been selected, context establishment tokens
specific to the selected mechanism are carried within the negotiation
tokens.
Lastly, MIC tokens may be exchanged to ensure the authenticity of the
mechanism list received by the target. mechanism list received by the target.
To avoid conflicts with the use of MIC tokens by SPNEGO, To avoid conflicts with the use of MIC tokens by SPNEGO,
partially-established contexts are not used for per-message calls: partially-established contexts MUST NOT be used for per-message
the prot_ready_state [RFC2743] will be false even if the underlying calls. To guarantee this, the prot_ready_state [RFC2743] MUST be set
mechanism would return true natively. to false on return from GSS_Init_sec_context() and
GSS_Accept_sec_context() even if the underlying mechanism returned
true.
3.2 Negotiation Procedure 3.2 Negotiation Procedure
The basic form of the procedure assumes that per-message integrity The basic form of the procedure assumes that per-message integrity
services are available on the established mechanism context, and it services are available on the established mechanism context, and it
is summarized as follows: is summarized as follows:
(a) The GSS-API initiator invokes GSS_Init_sec_context() as normal, (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
but requests that SPNEGO be used. SPNEGO can either be explicity but requests that SPNEGO be used. SPNEGO can either be explicity
requested or accepted as the default mechanism. requested or accepted as the default mechanism.
skipping to change at page 7, line 40 skipping to change at page 7, line 46
(c) The GSS-API initiator application sends the token to the target (c) The GSS-API initiator application sends the token to the target
application. The GSS-API target application deposits the token by application. The GSS-API target application deposits the token by
invoking GSS_Accept_sec_context(). The acceptor will do one of invoking GSS_Accept_sec_context(). The acceptor will do one of
the following: the following:
(I) If none of the proposed mechanisms are acceptable, the (I) If none of the proposed mechanisms are acceptable, the
negotiation SHALL be terminated. GSS_Accept_sec_context negotiation SHALL be terminated. GSS_Accept_sec_context
indicates GSS_S_BAD_MECH. The acceptor MAY output a indicates GSS_S_BAD_MECH. The acceptor MAY output a
negotiation token containing a reject state. negotiation token containing a reject state.
(II) If either the initiator's preferred mechanism is not accepted (II) If either the initiator's preferred mechanism is not
by the target or this mechanism is accepted but it is not the accepted by the target or this mechanism is accepted but it
acceptor's most preferred mechanism (see Section 3.1 and is not the acceptor's most preferred mechanism (i.e., the
Section 5), GSS_Accept_sec_context() indicates MIC token exchange as described in Section 5 is required),
GSS_S_CONTINUE_NEEDED. The acceptor MUST output a negotiation GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED.
token containing a request_mic state.
(III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE The acceptor MUST output a negotiation token containing a
or GSS_S_CONTINUE_NEEDED depending on if at least one request_mic state.
additional negotiation token from the initiator is needed to
establish this context. The acceptor outputs a negotiation (III) Otherwise if at least one additional negotiation token
token containing an accept_complete or accept_incomplete state, from the initiator is needed to establish this context,
respectively. GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and
outputs a negotiation token containing an accept_incomplete
state.
(IV) Otherwise no additional negotiation token from the
initiator is needed to establish this context,
GSS_Accept_sec_context() indicates GSS_S_COMPLETE and
outputs a negotiation token containing an accept_complete
state.
If the initiator's preferred mechanism is accepted, and an If the initiator's preferred mechanism is accepted, and an
optimistic mechanism token was included, this mechanism token MUST optimistic mechanism token was included, this mechanism token MUST
be deposited to the selected mechanism by invoking be deposited to the selected mechanism by invoking
GSS_Accept_sec_context() and if a response mechanism token is GSS_Accept_sec_context() and if a response mechanism token is
emitted, it MUST be included in the response negotiation token. emitted, it MUST be included in the response negotiation token.
Otherwise, the target will not emit a response mechanism token in Otherwise, the target will not emit a response mechanism token in
the first reply. the first reply.
(d) The GSS-API target application returns the negotiation token to (d) The GSS-API target application returns the negotiation token to
skipping to change at page 11, line 14 skipping to change at page 12, line 14
mechlistMIC mechlistMIC
This field, if present, contains a MIC token for the mechanism This field, if present, contains a MIC token for the mechanism
list in the initial negotiation message. This MIC token is list in the initial negotiation message. This MIC token is
computed according to Section 5. computed according to Section 5.
4.2.2 negTokenResp 4.2.2 negTokenResp
NegTokenResp ::= SEQUENCE { NegTokenResp ::= SEQUENCE {
negResult [0] ENUMERATED { negState [0] ENUMERATED {
accept_completed (0), accept_completed (0),
accept_incomplete (1), accept_incomplete (1),
reject (2), reject (2),
request_mic (3) request_mic (3)
} OPTIONAL, } OPTIONAL,
-- REQUIRED in the first reply from the target -- REQUIRED in the first reply from the target
supportedMech [1] MechType OPTIONAL, supportedMech [1] MechType OPTIONAL,
-- present only in the first reply from the target -- present only in the first reply from the target
responseToken [2] OCTET STRING OPTIONAL, responseToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL, mechListMIC [3] OCTET STRING OPTIONAL,
... ...
} }
This is the syntax for all subsequent negotiation messages. This is the syntax for all subsequent negotiation messages.
negResult negState
This field, if present, contains the state of the negotiation. This field, if present, contains the state of the negotiation.
This can be: This can be:
accept_completed accept_completed
No further negotiation message from the peer is expected, No further negotiation message from the peer is expected,
and the security context is established for the sender. and the security context is established for the sender.
accept_incomplete accept_incomplete
skipping to change at page 13, line 10 skipping to change at page 14, line 10
This field, if present, contains a MIC token for the mechanism This field, if present, contains a MIC token for the mechanism
list in the initial negotiation message. This MIC token is list in the initial negotiation message. This MIC token is
computed according to Section 5. computed according to Section 5.
5. Processing of mechListMIC 5. Processing of mechListMIC
If the mechanism selected by the negotiation does not support If the mechanism selected by the negotiation does not support
integrity protection, then no mechlistMIC token is used. integrity protection, then no mechlistMIC token is used.
Otherwise if the accepted mechanism is the most preferred mechanism Otherwise, if the accepted mechanism is the most preferred mechanism
of both the initiator and the acceptor, then the MIC token exchange, of both the initiator and the acceptor, then the MIC token exchange,
as described later in this section, is OPTIONAL. A mechanism is the as described later in this section, is OPTIONAL. A mechanism is the
acceptor's most preferred mechanism if there is no other mechanism acceptor's most preferred mechanism if there is no other mechanism
which would have been preferred over the accepted mechanism if it had which, had it been present in the mechanism list, the acceptor would
been present in the received mechanism list. have preferred over the accepted mechanism.
In all other cases, MIC tokens MUST be exchanged after the mechanism In all other cases, MIC tokens MUST be exchanged after the mechanism
context is fully established. context is fully established.
It is assumed that per-message integrity services are available on a) The mechlistMIC token (or simply the MIC token) is computed over
the established mechanism context in the following procedure for the mechanism list in the initial negotiation message by invoking
processing MIC tokens of the initiator's mechanism list. GSS_GetMIC() as follows: the input context_handle is the
established mechanism context, the input qop_req is 0, and the
a) The mechlistMIC token (or simply the MIC token) is computed by input message is the DER encoding of the value of type
invoking GSS_GetMIC(): the input context_handle is the established MechTypeList which is contained in the "mechTypes" field of the
mechanism context, the input qop_req is 0, and the input message NegTokenInit. The input message is NOT the DER encoding of the
is the mechTypes field in the initial negotiation message (only type "[0] MechTypeList".
the DER encoding of the type MechTypeList is included).
b) If the selected mechanism uses an even number of mechanism tokens b) If the selected mechanism exchanges an even number of mechanism
(namely the acceptor sends the last mechanism token), the acceptor tokens (i.e., the acceptor sends the last mechanism token), the
does the following when emitting the negotiation message acceptor does the following when emitting the negotiation message
containing the last mechanism token: if the MIC token exchange is containing the last mechanism token: if the MIC token exchange is
not required, GSS_Accept_sec_context() either indicates optional, GSS_Accept_sec_context() either indicates GSS_S_COMPLETE
GSS_S_COMPLETE and does not include a mechlistMIC token, or and does not include a mechlistMIC token, or indicates
indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token and an
and an accept_incomplete state; if the MIC token exchange is accept_incomplete state; if the MIC token exchange is required,
required, GSS_Accept_sec_context() indicates GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED, and
GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token. includes a mechlistMIC token. Acceptors that wish to be
Acceptors that wish to be compatible with legacy Windows SPNEGO compatible with legacy Windows SPNEGO implementations as described
implementations as described in Appendix B shall not generate a in Appendix B should not generate a mechlistMIC token when the MIC
mechlistMIC token when the MIC token exchange is not required. token exchange is not required. The initiator then processes the
The initiator then processes the last mechanism token, and does last mechanism token, and does one of the following:
one of the following:
(I) If a mechlistMIC token was included, and is correctly (I) If a mechlistMIC token was included, and is correctly
verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The
output negotiation message contains a mechlistMIC token, and an output negotiation message contains a mechlistMIC token, and an
accept_complete state. The acceptor MUST then verify this accept_complete state. The acceptor MUST then verify this
mechlistMIC token. mechlistMIC token.
(II) If a mechlistMIC token was included but is incorrect, the (II) If a mechlistMIC token was included but is incorrect, the
negotiation SHALL be terminated. GSS_Accept_sec_context() negotiation SHALL be terminated. GSS_Init_sec_context()
indicates GSS_S_DEFECTIVE_TOKEN. indicates GSS_S_DEFECTIVE_TOKEN.
(III) If no mechlistMIC token was included, and the MIC token (III) If no mechlistMIC token was included, and the MIC token
exchange is not required, GSS_Init_sec_context() indicates exchange is not required, GSS_Init_sec_context() indicates
GSS_S_COMPLETE with no output token. GSS_S_COMPLETE with no output token.
(IV) If no mechlistMIC token was included, but the MIC token (IV) If no mechlistMIC token was included, but the MIC token
exchange is required, the negotiation SHALL be terminated. exchange is required, the negotiation SHALL be terminated.
GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
c) In the case that the chosen mechanism uses an odd number of c) In the case that the chosen mechanism exchanges an odd number of
mechanism tokens (namely the initiator sends the last mechanism mechanism tokens (i.e., the initiator sends the last mechanism
token), the initiator does the following when emitting the token), the initiator does the following when emitting the
negotiation message containing the last mechanism token: if the negotiation message containing the last mechanism token: if the
negResult state was request_mic in the first reply from the negState was request_mic in the first reply from the target, a
target, a mechlistMIC token MUST be included, otherwise the mechlistMIC token MUST be included, otherwise the mechlistMIC
mechlistMIC token is OPTIONAL. In the case that the optimistic token is OPTIONAL. (Note that the MIC token exchange is required
mechanism token is the only mechanism token for the initiator's if a mechanism other than the initiator's first choice is chosen.)
preferred mechanism, the mechlistMIC token is OPTIONAL. In the case that the optimistic mechanism token is the only
GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED. mechanism token for the initiator's preferred mechanism, the
Initiators that wish to be compatible with legacy Windows SPNEGO mechlistMIC token is OPTIONAL. Whether or not the mechlistMIC
implementations as described in Appendix B shall not generate a token is included, GSS_Init_sec_context() indicates
mechlistMIC token when the MIC token exchange is not required. GSS_S_CONTINUE_NEEDED. Initiators that wish to be compatible with
The acceptor then processes the last mechanism token and does one legacy Windows SPNEGO implementations as described in Appendix B
of the following: should not generate a mechlistMIC token when the MIC token
exchange is not required. The acceptor then processes the last
mechanism token and does one of the following:
(I) If a mechlistMIC token was included and is correctly verified, (I) If a mechlistMIC token was included and is correctly verified,
GSS_Accept_sec_context() indicates GSS_S_COMPLETE. The output GSS_Accept_sec_context() indicates GSS_S_COMPLETE. The output
negotiation message contains a mechlistMIC token and an negotiation message contains a mechlistMIC token and an
accept_complete state. The initiator MUST then verify this accept_complete state. The initiator MUST then verify this
mechlistMIC token. mechlistMIC token.
(II) If a mechlistMIC token was included but is incorrect, the (II) If a mechlistMIC token was included but is incorrect, the
negotiation SHALL be terminated. GSS_Accept_sec_context() negotiation SHALL be terminated. GSS_Accept_sec_context()
indicates GSS_S_DEFECTIVE_TOKEN. indicates GSS_S_DEFECTIVE_TOKEN.
skipping to change at page 16, line 12 skipping to change at page 17, line 12
MIC tokens is required), the negotiation SHALL be terminated. MIC tokens is required), the negotiation SHALL be terminated.
GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
6. Extensibility 6. Extensibility
Two mechanisms are provided for extensibility. First, the ASN.1 Two mechanisms are provided for extensibility. First, the ASN.1
structures in this specification MAY be expanded by IETF standards structures in this specification MAY be expanded by IETF standards
action. Implementations receiving unknown fields MUST ignore these action. Implementations receiving unknown fields MUST ignore these
fields. fields.
Secondly, OIDs corresponding to a desired mechanism attribute may be Secondly, OIDs corresponding to a desired mechanism attribute (i.e.,
included in the set of preferred mechanisms by an initiator. The mechanism variants) may be included in the set of preferred
acceptor can choose to honor this request by preferring mechanisms mechanisms by an initiator. The acceptor can choose to honor this
that have the included attributes. Future work within the Kitten request by preferring mechanisms that have the included attributes.
working group is expected to standardize common attributes that Future work within the Kitten working group is expected to
SPNEGO mechanisms may wish to support. At this time it is sufficient standardize common attributes that SPNEGO mechanisms may wish to
to say that initiators MAY include OIDs that do not correspond to support. At this time it is sufficient to say that initiators MAY
mechanisms but instead correspond to desired mechanism attributes in include OIDs that do not correspond to mechanisms but instead
their requests. Such OIDs MAY influence the acceptor's choice of correspond to desired mechanism attributes in their requests. Such
mechanism. As discussed in Section 5, if there are mechanisms that OIDs MAY influence the acceptor's choice of mechanism. As discussed
if present in the initiator's list of mechanisms might be preferred in Section 5, if there are mechanisms that if present in the
by the acceptor to the initiator's preferred mechanism, the acceptor initiator's list of mechanisms might be preferred by the acceptor to
MUST demand the MIC token exchange. As a consequence, acceptors MUST the initiator's preferred mechanism, the acceptor MUST demand the MIC
demand the MIC token exchange if they support negotiation of token exchange. As a consequence, acceptors MUST demand the MIC
attributes not available in the initiator's preferred mechanism token exchange if they support negotiation of attributes not
regardless of whether the initiator actually requested these available in the initiator's preferred mechanism regardless of
attributes. whether the initiator actually requested these attributes.
7. Security Considerations 7. Security Considerations
In order to produce the MIC token for the mechanism list, the In order to produce the MIC token for the mechanism list, the
mechanism must provide integrity protection. When the selected mechanism must provide integrity protection. When the selected
mechanism does not support integrity protection, the negotiation is mechanism does not support integrity protection, the negotiation is
vulnerable: an active attacker can force it to use a security vulnerable: an active attacker can force it to use a security
mechanism that is not mutually preferred but is acceptable to the mechanism that is not mutually preferred but is acceptable to the
target. target.
This protocol provides the following guarantees when per-message This protocol provides the following guarantees when per-message
integrity services are available on the established mechanism context integrity services are available on the established mechanism context
and the mechanism list was altered by an adversary such that a and the mechanism list was altered by an adversary such that a
mechanism which is not mutually preferred could be selected: mechanism which is not mutually preferred could be selected:
o if the last mechanism token is sent by the initiator, both peers a) If the last mechanism token is sent by the initiator, both peers
shall fail; shall fail;
o if the last mechanism token is sent by the acceptor, the acceptor b) If the last mechanism token is sent by the acceptor, the acceptor
shall not complete and the initiator at worst shall complete with shall not complete and the initiator at worst shall complete with
its preferred mechanism being selected. its preferred mechanism being selected.
The negotiation may not be terminated if an alteration was made but The negotiation may not be terminated if an alteration was made but
it had no material impact. it had no material impact.
The protection of the negotiation depends on the strength of the The protection of the negotiation depends on the strength of the
integrity protection. In particular, the strength of SPNEGO is no integrity protection. In particular, the strength of SPNEGO is no
stronger than the integrity protection of the weakest mechanism stronger than the integrity protection of the weakest mechanism
acceptable to GSS-API peers. acceptable to GSS-API peers.
skipping to change at page 19, line 18 skipping to change at page 21, line 5
Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments
and suggestions during development of this document. and suggestions during development of this document.
Luke Howard provided a prototype of this protocol in Heimdal and Luke Howard provided a prototype of this protocol in Heimdal and
resolved several issues in the initial draft. resolved several issues in the initial draft.
Eric Baize and Denis Pinkas wrote the original SPNEGO specification Eric Baize and Denis Pinkas wrote the original SPNEGO specification
[RFC2478] of which some of the text has been retained in this [RFC2478] of which some of the text has been retained in this
document. document.
10 Normative References 10. References
10.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[X690] ASN.1 encoding rules: Specification of Basic Encoding [X690] ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), ITU-T Recommendation Distinguished Encoding Rules (DER), ITU-T Recommendation
X.690 (1997) | ISO/IEC International Standard 8825-1:1998. X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
10.2 Informative References
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998.
Authors' Addresses Authors' Addresses
Larry Zhu Larry Zhu
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
US US
EMail: lzhu@microsoft.com EMail: lzhu@microsoft.com
skipping to change at page 21, line 13 skipping to change at page 23, line 13
EMail: wyllys.ingersoll@sun.com EMail: wyllys.ingersoll@sun.com
Appendix A. GSS-API Negotiation Support API Appendix A. GSS-API Negotiation Support API
In order to provide to a GSS-API caller (either the initiator or the 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 target or both) the ability to choose among the set of supported
mechanisms a reduced set of mechanisms for negotiation, two mechanisms a reduced set of mechanisms for negotiation, two
additional APIs are defined: additional APIs are defined:
o GSS_Get_neg_mechs() indicates the set of security mechanisms o GSS_Get_neg_mechs() indicates the set of security mechanisms
available on the local system to the caller for negotiation, based available on the local system to the caller for negotiation, for
on the credentials being used. which appropriate credentials are available.
o GSS_Set_neg_mechs() specifies the set of security mechanisms to be 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 used on the local system by the caller for negotiation, for the
given credentials. given credentials.
A.1 GSS_Set_neg_mechs call A.1 GSS_Set_neg_mechs call
Inputs: Inputs:
o cred_handle CREDENTIAL HANDLE, -- NULL specifies default o cred_handle CREDENTIAL HANDLE, -- NULL specifies default
-- credentials -- credentials
skipping to change at page 23, line 12 skipping to change at page 25, line 12
no input parameter, the returned set is not necessarily available for no input parameter, the returned set is not necessarily available for
all credentials. all credentials.
Appendix B. Changes since RFC2478 Appendix B. Changes since RFC2478
SPNEGO implementations in Windows 2000/Windows XP/Windows Server SPNEGO implementations in Windows 2000/Windows XP/Windows Server
2003 have the following behavior: no mechlistMIC is produced and 2003 have the following behavior: no mechlistMIC is produced and
mechlistMIC is not processed if one is provided; if the initiator mechlistMIC is not processed if one is provided; if the initiator
sends the last mechanism token, the acceptor will send back a sends the last mechanism token, the acceptor will send back a
negotiation token with an accept_complete state and no mechlistMIC 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 token. In addition, an incorrect OID (1.2.840.48018.1.2.2) can be
identify the GSS-API Kerberos Version 5 mechanism. used to identify the GSS-API Kerberos Version 5 mechanism.
The following changes have been made to be compatible with these The following changes have been made to be compatible with these
legacy implementations. legacy implementations.
* NegTokenTarg is changed to negTokenResp and it is the message * NegTokenTarg is changed to negTokenResp and it is the message
format for all subsequent negotiation tokens. format for all subsequent negotiation tokens.
* NegTokenInit is the message for the initial negotiation message * NegTokenInit is the message for the initial negotiation message
and that message only. and that message only.
* mechTypes in negTokenInit is not optional. * mechTypes in negTokenInit is not optional.
* Two MIC tokens are exchanged, one in each direction.
* If the selected mechanism is also the most preferred mechanism * If the selected mechanism is also the most preferred mechanism
for both peers, it is safe to omit the MIC tokens. for both peers, it is safe to omit the MIC tokens.
If at least one of the two peers implements the pseudo mechanism If at least one of the two peers implements the updated pseudo
in this document, the negotiation is protected. mechanism in this document, the negotiation is protected.
The following changes are to address the problems in RFC 2478. The following changes are to address the problems in RFC 2478.
* reqFlags is not protected therefore it should not impact the * reqFlags is not protected therefore it should not impact the
negotiation. negotiation.
* DER encoding is required. * DER encoding is required.
* GSS_GetMIC() input is clarified. * GSS_GetMIC() input is clarified.
* Per-message integrity services are requested for the negotiated * Per-message integrity services are requested for the negotiated
mechanism. mechanism.
* Two MIC tokens are exchanged, one in each direction.
An implementation that conforms to this specification will not An implementation that conforms to this specification will not
interoperate with a strict 2748 implementation. Even if the new interoperate with a strict 2748 implementation. Even if the new
implementation always sends a mechlistMIC token, it will still fail implementation always sends a mechlistMIC token, it will still fail
to interoperate. If it is a server, it will fail because it requests to interoperate. If it is a server, it will fail because it requests
a mechlistMIC token using an option that older implementations simply a mechlistMIC token using an option that older implementations simply
do not support. Clients will tend to fail as well. do not support. Clients will tend to fail as well.
As an alternative to the approach chosen in this specification, we As an alternative to the approach chosen in this specification, we
could have documented a correct behavior that is fully backward could have documented a correct behavior that is fully backward
compatible with RFC 2478 and included an appendix on how to compatible with RFC 2478 and included an appendix on how to
interoperate with existing incorrect implementations of RFC 2478. interoperate with existing incorrect implementations of RFC 2478.
As a practical matter, the SPNEGO implementers within the IETF have As a practical matter, the SPNEGO implementers within the IETF have
valued interoperability with the Microsoft implementations. We were valued interoperability with the Microsoft implementations. We were
unable to choose to maintain reasonable security guarantees, maintain unable to choose to maintain reasonable security guarantees, maintain
interoperability with the Microsoft implementations and maintain interoperability with the Microsoft implementations and maintain
interoperability with correct implementations of RFC 2478. The interoperability with correct implementations of RFC 2478. The
working group was not aware of any RFC 2478 implementations. Even if working group was not aware of any RFC 2478 implementations deployed
there are RFC 2478 implementations, it is unlikely that they will on the Internet. Even if there are such implementations, it is
interoperate because of a critical flaw in the description of the unlikely that they will interoperate because of a critical flaw in
encoding of the mechanism list in RFC 2478. the description of the encoding of the mechanism list in RFC 2478.
With the approach taken in this specification, we get security With the approach taken in this specification, security is ensured
between new implementations all the time while maintaining between new implementations all the time while maintaining
interoperability with the implementations we have within the IETF interoperability with the implementations deployed within the IETF
community. The working group believes that this justifies breaking community. The working group believes that this justifies breaking
compatibility with a correct implementation of RFC 2478. compatibility with a correct implementation of RFC 2478.
Appendix C. mechListMIC Computation Example
The following is an example to illustrate how the mechListMIC field
would be computed.
The initial part of the DER encoding of NegTokenInit is constructed
as follows (the "nn" are length encodings, possibly longer than one
octet):
30 -- identifier octet for constructed SEQUENCE (NegTokenInit)
nn -- length
-- contents octets of the SEQUENCE begin with
-- DER encoding of "[0] MechTypeList":
A0 -- identifier octet for constructed [0]
nn -- length
-- contents of the constructed [0] are DER encoding
-- of MechTypeList (which is a SEQUENCE):
30 -- identifier octet for constructed SEQUENCE
nn -- length
-- contents octets of the SEQUENCE begin with
-- DER encoding of OBJECT IDENTIFIER:
06 -- identifier octet for primitive OBJECT IDENTIFIER
09 -- length
2A 86 48 86 F7 12 01 02 02 -- Kerberos V5
-- {1 2 840 113554 1 2 2}
If a mechlistMIC needs to be generated (according to the rules in
Section 5), it is computed by using the DER encoding of the type
MechTypeList data from the initiator's NegTokenInit token as input to
the GSS_GetMIC() function. In this case, the MIC would be computed
over the following octets:
DER encoding of MechTypeList:
30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...
Note that the identifier octet and lengh octet(s) for constructed [0]
(A0 nn) are not included in the MIC computation.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/