wdiff draft-zhu-spnego-2478bis-00.txt draft-zhu-spnego-2478bis-01.txt

NETWORK WORKING GROUP L. Zhu
Internet-Draft K. Jaganathan P. Leach
Obsoletes: 2478 (if approved) R. Ward K. Jaganathan
Expires: April 18, May 22, 2005 Microsoft Corporation
October 18,
S. Harman
MIT
W. Ingersoll
Sun Microsystems
November 21, 2004

The Simple and Protected GSS-API Negotiation Mechanism
draft-zhu-spnego-2478bis-00
draft-zhu-spnego-2478bis-01

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 18, May 22, 2005.

Abstract

This document specifies a security negotiation mechanism for the Generic
Security Service Application Program Interface (GSS-API) which is
described in RFC 2743.

This mechanism allows negotiating and choosing one security

GSS-API peers can use this negotiation mechanism to choose from a
common set of security mechanisms shared by GSS-API peers.

Once the common security mechanism is identified, the security
mechanism MAY also negotiate mechanism-specific options during its
context establishment, but that will be inside the mechanism tokens,
and invisible to this protocol. mechanisms.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 5
3. Negotiation Model . Protocol . . . . . . . . . . . . . . . . . . . . . 5 6
3.1 Negotiation Description . . . . . . . . . . . . . . . . . 5 6
3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 6 7
4. Data Elements Token Definitions . . . . . . . . . . . . . . . . . . . . . . . . 11 9
4.1 Mechanism Type . Types . . . . . . . . . . . . . . . . . . . . . 11 9
4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 11 9
4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 12 10
4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 13 11
5. Processing of mechListMIC . . . . . . . . . . . . . . . . . . 13
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
7. 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . 17 21
Intellectual Property and Copyright Statements . . . . . . . . 18 22

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 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 pseudo security mechanism, represented by the
object identifier
Object Identifier iso.org.dod.internet.security.mechanism.snego
(1.3.6.1.5.5.2)
(1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band
whether their credentials share common GSS-API security mechanism(s),
and if so, to invoke normal security context establishment for a
selected common security mechanism. This is most useful for
applications that are based on GSS-API implementations which support and multiple security mechanisms.
mechanisms are shared between the peers.

The simple and protected GSS-API SPNEGO mechanism negotiation is based on the following
negotiation model: the initiator proposes one security
mechanism or a list of security mechanisms
mechanism(s), in its preference order (favorite choice first), the
acceptor (the (also known as the target) either accepts the
proposed initiator's
preferred security mechanism, 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 initial first security token of
the preferred mechanism for the initiator SHOULD be embedded in the initial negotiation token
message (as defined in Section 4.2). This mechanism token is
referred to as the optimistic token in this document. If the target
preferred
selected mechanism matches the initiator's preferred mechanism, no
additional round trips may need to be incurred by using the negotiation this protocol.

The negotiation is protected and all the underlying mechanisms
offered
In addition, by using the optimistic token, the initiator MUST can recover
from a non-fatal error in producing the first token before a
mechanism can be capable selected. Implementations, however, MAY omit the
optimistic token, to avoid the cost of integrity protection.

The Simple and Protected GSS-API Negotiation Mechanism 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.

2. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

3. Negotiation Model 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

Each OID represents one GSS-API mechanism or one variant of it.

The first negotiation token sent by the initiator contains an ordered
list of mechanisms (in preference order, favorite choice first), and
OPTIONALLY
optionally the initial security token for the preferred mechanism of
the initiator (i.e. (i.e., the first of 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 three four possible states (as defined in Section 4.2.2):
accept_completed, accept_incomplete, reject, or reject. request_mic. A
reject state will terminate the negotiation. An 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 authentication; an accept_incomplete state indicates
that the target
has selected a different mechanism or the preferred mechanism further message exchange is
acceptable, needed but this mechanism requires at least one additional
message to complete the authentication. The target MAY produce a
context level MIC token for exchange as
described in Section 5 is OPITONAL; a reject state.

The first negotiation token sent by the acceptor contains the result
of the negotiation (accept_completed, accept_incomplete or reject)
and, request_mic state (this state
can only be present in case of accept, the agreed security mechanism. It MUST also
include the response mechanism token to the initial mechanism token first reply message from the initiator, when the first proposed mechanism of target)
indicates the
initiator has been selected and an initial mechanism MIC token was
provided by the initiator. However, exchange is REQUIRED if per-message integrity
services are available.

Unless the initiator's preferred
mechanism preference order is not possible, specified by the target will not emit a response
mechanism token in application (see
Appendix A), the first reply.

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 MUST SHALL choose
the first mechanism in the initiator proposed list for which it has
valid credentials are available.

The credentials.

In case of a successful negotiation, the security mechanism in the
first negotiation 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 negTokenInit message and all
subsequent negotiation tokens specific to the
selected mechanism are carried within the negTokenResp message, negotiation tokens.

Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the
mechanism list as
defined in Section 4.2.

The seen by the target.

To avoid conflicts with the use of MIC tokens by SPNEGO,
partially-established contexts (as indicated by are not used for per-message calls:
the prot_ready_state in [RFC2743]), either for this [RFC2743] will be false even if the underlying
mechanism or
mechanisms negotiated using this mechanism, is prohibited. would return true natively.

3.2 Negotiation Procedure

The negotiation 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 the this
negotiation mechanism) that the Simple and Protected GSS-API
Negotiation Mechanism SPNEGO is used; 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 optionally an initial security token for the
first mechanism from that list
(i.e. the preferred mechanism), and indicates
GSS_S_CONTINUE_NEEDED status; list.

(d)
application. The GSS-API target application deposits the token
through invoking GSS_Accept_sec_context. GSS_Accept_sec_context(). The target GSS-API application
will do one of the following:

(I) If the initiator's preferred mechanism is accepted by the
target, an initial token is included in the first token from
the initiator, no further mechanism token from the initiator is
needed for the chosen mechanism to establish the security
context, (e.g. when the authentication mechanism is unilateral
or mutual authentication has been performed and involves a
single token in either direction), and the initiator has not
sent a MIC token (the output token of the GSS_GetMIC() call
[RFC2743], the input to GSS_GetMIC() is the OTCET STRING field
representing the MechTypes in the initial NegTokenInit token),
of the mechanism list, the acceptor will do
one of the following:

1) If the initiator's preferred mechanism is accepted and there
is no policy on the target such that a different mechanism
other than the initiator's preferred mechanism could have
been selected given a different list of mechanisms,
GSS_Accept_sec_context() MUST indicate GSS_S_COMPLETE and it
MUST produce a negotiation token with the accept_completed
state, and with no MIC of the

(I) No proposed mechanism list. This is
referred in this document as acceptable, the Safe to Omit MIC (SOMIC)
rule number 1. The resulting negotiation token MUST include
the security token if one is returned by the selected
mechanism;

2) If the initiator's preferred mechanism is accepted and there
is policy exists on the target such that a different
mechanism other than the initiator's preferred mechanism
could have been selected given a different list of
mechanisms, GSS_Accept_sec_context() MUST indicate
GSS_S_CONTINUE_NEEDED with the accept_incomplete state, and
a MIC MUST be generated by the target. This MIC is to be
verified by the initiator and the result will SHALL be sent back
to the acceptor. This is referred in this document as the
Safe to Omit MIC (SOMIC) rule number 2.
terminated. GSS_Accept_sec_context indicates GSS_S_BAD_MECH.
The resulting
negotiation token MUST include the security token if one is
returned by the selected mechanism.

3) If there is a MIC token and it is correct,
GSS_Accept_sec_context() MUST indicate GSS_S_COMPLETE with
no acceptor MAY output token; If there is an incorrect MIC token,
GSS_Accept_sec_context() must indicate GSS_S_BAD_MIC status,
OPTIONALLY returning a negotiation token with the containing a reject
state.

(II) If either the initiator's preferred mechanism is accepted, and an
initial token from not accepted
by the target, or this mechanism is sent by the initiator, accepted but
a failure it is returned by not the chosen mechanism,
GSS_Accept_sec_context() MUST report
most preferred mechanism available for the failure acceptor (see
Section 3.1 and the
mech_type output parameter Section 5), GSS_Accept_sec_context() indicates the selected mechanism.
GSS_S_CONTINUE_NEEDED. The target acceptor MUST produce output a negotiation
token with the reject
state if the selected mechanism returns a response token (e.g. containing a KRB_ERROR when the Kerberos Version 5 GSS-API mechanism is
chosen [GSSAPICFX]); request_mic state.

(III) If the initiator's preferred mechanism is accepted, and an
initial Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE
or GSS_S_CONTINUE_NEEDED, depending on if at least one
additional negotiation token from this mechanism is sent by the initiator, but
at last one more initiator token need to be transferred is needed to
establish the context, GSS_Accept_sec_context() MUST indicate
GSS_S_CONTINUE_NEEDED status, returning this context. The acceptor outputs a negotiation
token
with the containing an accept_complete or accept_incomplete state, the response mechanism token,
and no MIC token.

(IV)
respectively.

If the initiator's preferred mechanism is accepted, but no
initial and an
optimistic mechanism token from was included, this mechanism is sent by the initiator,
GSS_Accept_sec_context() MUST indicate GSS_S_CONTINUE_NEEDED
status, returning a negotiation token with the
accept_incomplete state, MUST
be deposited to the selected mechanism, no response mechanism token or MIC token.

(V) If through invoking
GSS_Accept_sec_context() and if a proposed response mechanism token is accepted, and
emitted, it is not the
initiator's preferred mechanism, GSS_Accept_sec_context() MUST
indicate GSS_S_CONTINUE_NEEDED status, returning a negotiation
token with the accept_incomplete state, be included in the selected mechanism,
no response mechanism token or MIC token. The negotiation will
be token.
Otherwise, the agreed security target will not emit a response mechanism if token in
the negotiation is
successful.

(e) first reply.

(d) The GSS-API target application returns the negotiation token to
the initiator application;

(f) application. The GSS-API initiator application
deposits the token through invoking GSS_Init_sec_context(). The initiator will do one of the
following:

(I) When the negotiation token carries an accept_completed result,
the initiator MUST do one of the following:

1) If the selected mechanism is the initiator's preferred
mechanism, the initiator SHALL NOT reject the negotiation if
no MIC token is present. This is referred in this document
as the Safe to Omit MIC ("SOMIC") rule number 3. The
initiator MUST deposit the security token if one is
included, GSS_Init_sec_context() MUST indicate
GSS_S_BAD_MECH status if the context is not established
after this GSS_Init_sec_context() call. If a MIC token is
present, the initiator MUST verify it and a GSS_S_BAD_MIC
must be returned if the MIC is incorrect;

2) If the selected mechanism is not the initiator's preferred
mechanism, and there is no or an incorrect MIC token,
GSS_Init_sec_context() MUST indicate GSS_S_BAD_MIC status.
This is referred in this document as the Safe to Omit MIC
("SOMIC") rule number 4.

(II) When the negotiation token carries a reject result without a
response security token, GSS_Init_sec_context() MUST indicate
GSS_S_BAD_MECH status;

(III) When the negotiation token carries a reject result with a
response security token, the initiator MUST deposit the
security token, and GSS_Init_sec_context() MUST indicate a
failure status reported by the underlying mechanism, and the
output mech_type indicates the selected mechanism;

(IV) When the negotiation token carries an accept_incomplete
result and further mechanism tokens from the acceptor must be
transferred in order to complete context establishment,
GSS_Init_sec_context() MUST indicate GSS_S_CONTINUE_NEEDED
status, returning an output token with the accept_incomplete,
and the selected mechanism's context level token;

(V) When the negotiation token carries an accept_incomplete
result, no further mechanism token need to be transferred from
the acceptor to complete the context establishment, the
initiator MUST do one of the following:

1) If a MIC token was included, the initiator MUST verify it
and GSS_Init_sec_context() MUST indicate GSS_S_BAD_MIC if
the MIC is incorrect; GSS_Init_sec_context() MUST indicate
GSS_S_COMPLETE and produce a negotiation with the
accept_completed state if the MIC is correct. This is
referred in this document as the Safe to Omit MIC ("SOMIC")
rule number 5;

2) If no MIC token was present, GSS_Init_sec_context() MUST
indicate GSS_S_BAD_MIC statue, This is referred in this
document as the Safe to Omit MIC ("SOMIC") rule number 6.

(g) The initiator application then sends the output_token to the
target if one is returned. The
security context initialization is then continued according to the
standard GSS-API conventions for the selected mechanism, where the
tokens of the selected mechanism are encapsulated until the
GSS_S_COMPLETE is returned for both the initiator and the target. When no further mechanism token is
needed to be transferred and the context for the chosen mechanism
is established, the initiator and the acceptor will need to either
apply target
by the "SOMIC" rules above and skip selected security mechanism.

(e) MIC generation and
verification, tokens are then either skipped or generate and verify the MIC token exchanged according to protect the
negotiation.

(h) When GSS_S_CONTINUE_NEEDED is returned, the mech_type output
parameter is not yet valid. When GSS_S_COMPLETE is returned, the
mech_type output parameter indicates the selected mechanism.
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 the negotiation 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 as defined in [PRTSTK]. (see Appendix A).

4. Data Elements 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 Type 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
initialContextToken syntax defined in Section 3.1 of [RFC2743]. The security
SPNEGO pseudo mechanism of the initial negotiation token is identified by the Object Identifier
specified in Section 1. All subsequent Subsequent tokens are not encapsulated in the above
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
level establishment tokens.

NegotiationToken ::= CHOICE {
negTokenInit [0] NegTokenInit,
negTokenResp [1] negTokenResp
}

MechTypeList ::= SEQUENCE OF MechType

4.2.1 negTokenInit

NegTokenInit ::= SEQUENCE {
mechTypes [0] MechTypeList,
reqFlags [1] ContextFlags OPTIONAL,
mechToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL,
...
}
ContextFlags ::= BIT STRING {
delegFlag (0),
mutualFlag (1),
replayFlag (2),
sequenceFlag (3),
anonFlag (4),
confFlag (5),
integFlag (6)
}

This is the message syntax for the inner token of the initial negotiation token.
message.

mechTypes

This field contains one or more security mechanisms in available
for the initiator in preference order (favorite choice first) supported by the
initiator (as indicated in the field mechTypes). 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 influence the
outcome of have impact on
the negotiation.

mechToken

This field, is present, contains an the optimistic negotiation
response.

mechListMIC security
mechanism token.

mechlistMIC

This field, if is present, contains the result of a GSS_GetMIC()
[RFC2743] of MIC token, which is computed
according to Section 5, for the MechTypes field mechanism list in the initial NegTokenInit
token. It allows verifying that the list initially sent by the
initiator has been received unmodified by the target.
negotiation message.

4.2.2 negTokenResp

NegTokenResp ::= SEQUENCE {
negResult [0] ENUMERATED {
accept_completed (0),
accept_incomplete (1),
reject (2) (2),
request_mic (3)
},
supportedMech [1] MechType OPTIONAL,
responseToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL,
-- used only by the acceptor
...
}

This is the message syntax for all the subsequent tokens. negotiation messages.

negResult

Result of

This field contains the negotiation exchange, specified by state of the target. negotiation. This can be:

accept_completed
A security mechanism
No further negotiation message from the peer is selected, expected,
and the security context is established for the sender; sender.

accept_incomplete
Further exchanges are necessary;
At least one more negotiation message from the peer is
needed to establish the security context.

reject
The sender reject terminates the proposed security mechanism(s).

accept_completed negotiation.

request_mic
The sender indicates that a context has been successfully
established, while the result accept_incomplete indicates that
additional token exchanges exchange of MIC tokens, as
described in Section 5, will be REQUIRED if per-message
integrity services are needed.

For those targets that support piggybacking available on the initial
mechToken, an optimistic negotiation response is possible and
includes mechanism context to
be established. This value SHALL only be present in that case a responseToken which MAY continue the
authentication exchange (e.g. when mutual authentication has
been requested or when unilateral authentication requires
several round trips). Otherwise
first reply from the responseToken target.

supportedMech

This field SHALL only be present in the first reply from the
target. It is used to
carry a choice from the mechanism(s) offered by the
initiator.

ResponseToken

The field, if present, contains tokens specific to the
mechanism selected.

The mechListMIC, when present,

mechlistMIC

This field, is present, contains a MIC token, which is computed over the
MechTypes using
according to Section 5, for the mechanism list field in the initial
negotiation message.

5. Processing of mechListMIC

If the mechanism selected by the negotiation does not support
integrity protection, then no mechlistMIC token
(encoded in DER).

supportedMech

This field is present used. Otherwise
if the initiator's preferred mechanism is accepted and only it is also the
most preferred mechanism available for the acceptor (there is no
mechanism which, had it been present in the first
negTokenResp token. 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 a choice from assumed that per-message integrity services are available on
the mechanisms offered
by established mechanism context in the initiator.

responseToken

This field, 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 present, 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.

(II) If a mechlistMIC token was included but is incorrect, the security
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
selected mechanism.

mechListMIC

This field, initiator sends the last mechanism
token), the initiator does the following when emitting the
negotiation message containing the last mechanism token: if present, 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 result
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.

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 GSS_GetMIC()
[RFC2743] 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 MechTypes field 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 initial NegTokenInit
token. It allows verifying acceptor's choice of
mechanism. As discussed in Section 5, if there are mechanisms that
if present in the initiator's list initially sent of mechanisms might be preferred
by the
initiator has been received unmodified by acceptor to the target.

5. 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.

7. Security Considerations

In order to produce the MIC token for the mechanism list, the
mechanism
MUST must provide integirty integrity protection. When one of the mechanisms
proposed by the initiator selected
mechanism does not support integrity protection, then the negotiation
is exposed to all threats a non secured service is
exposed. In particular, vulnerable: an active attacker can force it to use a security
mechanism which that is not the common mutually preferred one (when
multiple security mechanisms are shared between peers) but which is acceptable anyway to
the target, thus this target.

When per-message integrity services are available on the established
mechanism does not support
selecting context, and there was an alteration of the mechanism list
by an adversary such that a common mechanism that does is not support 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 any case, 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 MAY be are exposed to the denial of
service threat.

8. Acknowledgments

The authors wish to thank Paul Leach Nicolas Williams, Ken Raeburn, Jeff Altman,
Cristian Ilac and Todd Stecher Martin Rex for theirs 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.

[PRTSTK] RFC-Editor: To be replaced by RFC number for draft-williams
-gssapi-stackable-pseudo-mechs. Work in progress.

[X690] ASN.1 encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER), ITU-T Recommendation X.690 (1997) |
ISO/IEC International Standard 8825-1:1998.

Authors' Addresses

Larry Zhu
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US

EMail: lzhu@microsoft.com

Karthik Jaganathan

Paul Leach
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US

EMail: karthikj@microsoft.com

Richard B. Ward paulle@microsoft.com
Karthik Jaganathan
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US

EMail: richardw@microsoft.com 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

Appendix A. Changes since RFC2478

The following changes 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 designed 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 compatible
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 an
incorrect implementation the credential identified by cred_handle. This call
is intended for support of RFC 2478 shipped 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 Windows 2000. A
correct implementation
mech_set, the order in which those mechanisms are specified implies a
relative preference.

A.2 GSS_Get_neg_mechs call

Input:

o cred_handle CREDENTIAL HANDLE -- NULL specifies default
-- credentials

Outputs:

o major_status INTEGER,
o minor_status INTEGER,
o mech_set SET OF OBJECT IDENTIFIER

Return major_status codes:

o GSS_S_COMPLETE indicates that the set of this protocol security mechanisms
available for negotiation has been returned in mech_set.
o GSS_S_FAILURE indicates that negotiates the 2 leg
Kerberos requested operation could not be
performed for reasons unspecified at the GSS-API mechanism as level.

Allows callers to determine the only 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
mechanism should be ale mechanisms from the set of
supported security mechanisms available to interoperate with the implementation caller (based on
available credentials).

Note: The GSS_Indicate_mechs() function indicates the full set of
mechanism types available on the local system. Since this call has
no input parameter, the returned set is not necessarily available for
all credentials.

Appendix B. Changes since RFC2478

SPNEGO implementations in Windows 2000 when 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 mangled OID (1.2.840.48018.1.2.2) can be used to
identify Kerberos.

* the GSS-API Kerberos Version 5 mechanism.

The negTokenTarg following changes have been made to be compatible with these
legacy implementations.

* NegTokenTarg is changed to negTokenResp and it is now the message
format for all subsequent negotiation messages. tokens.
* negTokenInit NegTokenInit is the message for the initial token and that
token only.
* mechTypes in negTokenInit is no longer not optional.
* negResult is no longer not optional in the negTokenResp token.
* The initiator does not send the Two MIC token. tokens are exchanged, one in each direction.
* Add rules when If the selected mechanism is also the most preferred mechanism
for both peers, it is safe to omit the MIC token. Search for
SOMIC. 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.
* BER DER encoding is required.
* GSS_GetMIC() input is clarified.
* Nico's stackable pseudo mechanism draft is used to replace the
support APIs.
* We no longer support negotiating mechanisms that do not provide Per-message integrity services are requested for integrity. That support does not add security values but
blows up the interoperability test matrix. negotiated
mechanism.

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 (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.