mirror of
https://github.com/samba-team/samba.git
synced 2024-12-23 17:34:34 +03:00
7055827b8f
This makes it clearer that we always want to do heimdal changes via the lorikeet-heimdal repository. Signed-off-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz> Autobuild-User(master): Joseph Sutton <jsutton@samba.org> Autobuild-Date(master): Wed Jan 19 21:41:59 UTC 2022 on sn-devel-184
1155 lines
32 KiB
Plaintext
1155 lines
32 KiB
Plaintext
NETWORK WORKING GROUP L. Zhu
|
|
Internet-Draft K. Jaganathan
|
|
Obsoletes: 2478 (if approved) R. Ward
|
|
Expires: April 18, 2005 Microsoft Corporation
|
|
October 18, 2004
|
|
|
|
|
|
|
|
The Simple and Protected GSS-API Negotiation Mechanism
|
|
draft-zhu-spnego-2478bis-00
|
|
|
|
|
|
Status of this Memo
|
|
|
|
|
|
This document is an Internet-Draft and is subject to all provisions
|
|
of section 3 of RFC 3667. By submitting this Internet-Draft, each
|
|
author represents that any applicable patent or other IPR claims of
|
|
which he or she is aware have been or will be disclosed, and any of
|
|
which he or she become aware will be disclosed, in accordance with
|
|
RFC 3668.
|
|
|
|
|
|
Internet-Drafts are working documents of the Internet Engineering
|
|
Task Force (IETF), its areas, and its working groups. Note that
|
|
other groups may also distribute working documents as
|
|
Internet-Drafts.
|
|
|
|
|
|
Internet-Drafts are draft documents valid for a maximum of six months
|
|
and may be updated, replaced, or obsoleted by other documents at any
|
|
time. It is inappropriate to use Internet-Drafts as reference
|
|
material or to cite them other than as "work in progress."
|
|
|
|
|
|
The list of current Internet-Drafts can be accessed at
|
|
http://www.ietf.org/ietf/1id-abstracts.txt.
|
|
|
|
|
|
The list of Internet-Draft Shadow Directories can be accessed at
|
|
http://www.ietf.org/shadow.html.
|
|
|
|
|
|
This Internet-Draft will expire on April 18, 2005.
|
|
|
|
|
|
Copyright Notice
|
|
|
|
|
|
Copyright (C) The Internet Society (2004).
|
|
|
|
|
|
Abstract
|
|
|
|
|
|
This document specifies a security negotiation mechanism for the
|
|
Generic Security Service Application Program Interface (GSS-API)
|
|
which is described in RFC 2743.
|
|
|
|
|
|
This mechanism allows negotiating and choosing one security mechanism
|
|
from a common set of security mechanisms shared by GSS-API peers.
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 1]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
Once the common security mechanism is identified, the security
|
|
mechanism MAY also negotiate mechanism-specific options during its
|
|
context establishment, but that will be inside the mechanism tokens,
|
|
and invisible to this protocol.
|
|
|
|
|
|
Table of Contents
|
|
|
|
|
|
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
|
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
|
|
3. Negotiation Model . . . . . . . . . . . . . . . . . . . . . . 5
|
|
3.1 Negotiation Description . . . . . . . . . . . . . . . . . 5
|
|
3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 6
|
|
4. Data Elements . . . . . . . . . . . . . . . . . . . . . . . . 11
|
|
4.1 Mechanism Type . . . . . . . . . . . . . . . . . . . . . . 11
|
|
4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 11
|
|
4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 12
|
|
4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 13
|
|
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
|
|
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
|
|
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
|
|
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
|
|
A. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 17
|
|
Intellectual Property and Copyright Statements . . . . . . . . 18
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 2]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
1. Introduction
|
|
|
|
|
|
The GSS-API [RFC2743] provides a generic interface which can be
|
|
layered atop different security mechanisms such that if communicating
|
|
peers acquire GSS-API credentials for the same security mechanism,
|
|
then a security context MAY be established between them (subject to
|
|
policy). However, GSS-API doesn't prescribe the method by which
|
|
GSS-API peers can establish whether they have a common security
|
|
mechanism.
|
|
|
|
|
|
The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
|
|
defined here is a pseudo-security mechanism, represented by the
|
|
object identifier iso.org.dod.internet.security.mechanism.snego
|
|
(1.3.6.1.5.5.2) which enables GSS-API peers to determine in-band
|
|
whether their credentials share common GSS-API security mechanism(s),
|
|
and if so, to invoke normal security context establishment for a
|
|
selected common security mechanism. This is most useful for
|
|
applications that are based on GSS-API implementations which support
|
|
multiple security mechanisms.
|
|
|
|
|
|
The simple and protected GSS-API mechanism negotiation is based on
|
|
the following negotiation model: the initiator proposes one security
|
|
mechanism or a list of security mechanisms in its preference order
|
|
(favorite choice first), the acceptor (the target) either accepts the
|
|
proposed security mechanism, or chooses one from the offered list, or
|
|
rejects the proposed value(s). The target then informs the initiator
|
|
of its choice.
|
|
|
|
|
|
In order to avoid an extra round trip, the initial security token of
|
|
the preferred mechanism for the initiator SHOULD be embedded in the
|
|
initial negotiation token (as defined in Section 4.2). If the target
|
|
preferred mechanism matches the initiator's preferred mechanism, no
|
|
additional round trips may be incurred by using the negotiation
|
|
protocol.
|
|
|
|
|
|
The negotiation is protected and all the underlying mechanisms
|
|
offered by the initiator MUST be capable of integrity protection.
|
|
|
|
|
|
The Simple and Protected GSS-API Negotiation Mechanism uses the
|
|
concepts developed in the GSS-API specification [RFC2743]. The
|
|
negotiation data is encapsulated in context-level tokens. Therefore,
|
|
callers of the GSS-API do not need to be aware of the existence of
|
|
the negotiation tokens but only of the new pseudo-security mechanism.
|
|
A failure in the negotiation phase causes a major status code to be
|
|
returned: GSS_S_BAD_MECH.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 3]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
2. Conventions Used in This Document
|
|
|
|
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
document are to be interpreted as described in [RFC2119].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 4]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
3. Negotiation Model
|
|
|
|
|
|
3.1 Negotiation Description
|
|
|
|
|
|
Each OID represents one GSS-API mechanism or one variant of it.
|
|
|
|
|
|
The first negotiation token sent by the initiator contains an ordered
|
|
list of mechanisms (in preference order, favorite choice first), and
|
|
OPTIONALLY the initial security token for the preferred mechanism of
|
|
the initiator (i.e. the first of the list).
|
|
|
|
|
|
The target then processes the token from the initiator. This will
|
|
result in one of three possible states (as defined in Section 4.2.2):
|
|
accept_completed, accept_incomplete, or reject. A reject state will
|
|
terminate the negotiation. An accept_completed state indicates that
|
|
not only was the initiator-selected mechanism acceptable to the
|
|
target, but that the initial token was sufficient to complete the
|
|
authentication. An accept_incomplete state indicates that the target
|
|
has selected a different mechanism or the preferred mechanism is
|
|
acceptable, but this mechanism requires at least one additional
|
|
message to complete the authentication. The target MAY produce a
|
|
context level token for a reject state.
|
|
|
|
|
|
The first negotiation token sent by the acceptor contains the result
|
|
of the negotiation (accept_completed, accept_incomplete or reject)
|
|
and, in case of accept, the agreed security mechanism. It MUST also
|
|
include the response mechanism token to the initial mechanism token
|
|
from the initiator, when the first proposed mechanism of the
|
|
initiator has been selected and an initial mechanism token was
|
|
provided by the initiator. However, if the initiator's preferred
|
|
mechanism is not possible, the target will not emit a response
|
|
mechanism token in the first reply.
|
|
|
|
|
|
The policy by which the target chooses a mechanism is an
|
|
implementation-specific local matter. In the absence of other
|
|
policy, the target MUST choose the first mechanism in the list for
|
|
which valid credentials are available.
|
|
|
|
|
|
The first negotiation token is the negTokenInit message and all
|
|
subsequent negotiation tokens are the negTokenResp message, as
|
|
defined in Section 4.2.
|
|
|
|
|
|
The use of partially-established contexts (as indicated by the
|
|
prot_ready_state in [RFC2743]), either for this mechanism or
|
|
mechanisms negotiated using this mechanism, is prohibited.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 5]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
3.2 Negotiation Procedure
|
|
|
|
|
|
The negotiation procedure is summarized as follows:
|
|
|
|
|
|
(a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
|
|
but requests (either explicitly, with the negotiation mechanism,
|
|
or through accepting a default, when the default is the
|
|
negotiation mechanism) that the Simple and Protected GSS-API
|
|
Negotiation Mechanism is used;
|
|
|
|
|
|
(b) The initiator GSS-API implementation emits a negotiation token
|
|
containing a list of supported security mechanisms for the
|
|
credentials used for this context establishment, and OPTIONALLY an
|
|
initial security token for the first mechanism from that list
|
|
(i.e. the preferred mechanism), and indicates
|
|
GSS_S_CONTINUE_NEEDED status;
|
|
|
|
|
|
(c) The GSS-API initiator application sends the token to the target
|
|
application;
|
|
|
|
|
|
(d) The GSS-API target application deposits the token through
|
|
invoking GSS_Accept_sec_context. The target GSS-API application
|
|
will do one of the following:
|
|
|
|
|
|
(I) If the initiator's preferred mechanism is accepted by the
|
|
target, an initial token is included in the first token from
|
|
the initiator, no further mechanism token from the initiator is
|
|
needed for the chosen mechanism to establish the security
|
|
context, (e.g. when the authentication mechanism is unilateral
|
|
or mutual authentication has been performed and involves a
|
|
single token in either direction), and the initiator has not
|
|
sent a MIC token (the output token of the GSS_GetMIC() call
|
|
[RFC2743], the input to GSS_GetMIC() is the OTCET STRING field
|
|
representing the MechTypes in the initial NegTokenInit token),
|
|
of the mechanism list, the acceptor will do one of the
|
|
following:
|
|
|
|
|
|
1) If the initiator's preferred mechanism is accepted and there
|
|
is no policy on the target such that a different mechanism
|
|
other than the initiator's preferred mechanism could have
|
|
been selected given a different list of mechanisms,
|
|
GSS_Accept_sec_context() MUST indicate GSS_S_COMPLETE and it
|
|
MUST produce a negotiation token with the accept_completed
|
|
state, and with no MIC of the mechanism list. This is
|
|
referred in this document as the Safe to Omit MIC (SOMIC)
|
|
rule number 1. The resulting negotiation token MUST include
|
|
the security token if one is returned by the selected
|
|
mechanism;
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 6]
|
|
|
|
|
|
2) If the initiator's preferred mechanism is accepted and there
|
|
is policy exists on the target such that a different
|
|
mechanism other than the initiator's preferred mechanism
|
|
could have been selected given a different list of
|
|
mechanisms, GSS_Accept_sec_context() MUST indicate
|
|
GSS_S_CONTINUE_NEEDED with the accept_incomplete state, and
|
|
a MIC MUST be generated by the target. This MIC is to be
|
|
verified by the initiator and the result will be sent back
|
|
to the acceptor. This is referred in this document as the
|
|
Safe to Omit MIC (SOMIC) rule number 2. The resulting
|
|
negotiation token MUST include the security token if one is
|
|
returned by the selected mechanism.
|
|
|
|
|
|
3) If there is a MIC token and it is correct,
|
|
GSS_Accept_sec_context() MUST indicate GSS_S_COMPLETE with
|
|
no output token; If there is an incorrect MIC token,
|
|
GSS_Accept_sec_context() must indicate GSS_S_BAD_MIC status,
|
|
OPTIONALLY returning a negotiation token with the reject
|
|
state.
|
|
|
|
|
|
(II) If the initiator's preferred mechanism is accepted, and an
|
|
initial token from this mechanism is sent by the initiator, but
|
|
a failure is returned by the chosen mechanism,
|
|
GSS_Accept_sec_context() MUST report the failure and the
|
|
mech_type output parameter indicates the selected mechanism.
|
|
The target MUST produce a negotiation token with the reject
|
|
state if the selected mechanism returns a response token (e.g.
|
|
a KRB_ERROR when the Kerberos Version 5 GSS-API mechanism is
|
|
chosen [GSSAPICFX]);
|
|
|
|
|
|
(III) If the initiator's preferred mechanism is accepted, and an
|
|
initial token from this mechanism is sent by the initiator, but
|
|
at last one more initiator token need to be transferred to
|
|
establish the context, GSS_Accept_sec_context() MUST indicate
|
|
GSS_S_CONTINUE_NEEDED status, returning a negotiation token
|
|
with the accept_incomplete state, the response mechanism token,
|
|
and no MIC token.
|
|
|
|
|
|
(IV) If the initiator's preferred mechanism is accepted, but no
|
|
initial token from this mechanism is sent by the initiator,
|
|
GSS_Accept_sec_context() MUST indicate GSS_S_CONTINUE_NEEDED
|
|
status, returning a negotiation token with the
|
|
accept_incomplete state, the selected mechanism, no response
|
|
mechanism token or MIC token.
|
|
|
|
|
|
(V) If a proposed mechanism is accepted, and it is not the
|
|
initiator's preferred mechanism, GSS_Accept_sec_context() MUST
|
|
indicate GSS_S_CONTINUE_NEEDED status, returning a negotiation
|
|
token with the accept_incomplete state, the selected mechanism,
|
|
no response mechanism token or MIC token. The negotiation will
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 7]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
be the agreed security mechanism if the negotiation is
|
|
successful.
|
|
|
|
|
|
(e) The GSS-API target application returns the negotiation token to
|
|
the initiator application;
|
|
|
|
|
|
(f) The GSS-API initiator application deposits the token through
|
|
invoking GSS_Init_sec_context(). The initiator will do one of the
|
|
following:
|
|
|
|
|
|
(I) When the negotiation token carries an accept_completed result,
|
|
the initiator MUST do one of the following:
|
|
|
|
|
|
1) If the selected mechanism is the initiator's preferred
|
|
mechanism, the initiator SHALL NOT reject the negotiation if
|
|
no MIC token is present. This is referred in this document
|
|
as the Safe to Omit MIC ("SOMIC") rule number 3. The
|
|
initiator MUST deposit the security token if one is
|
|
included, GSS_Init_sec_context() MUST indicate
|
|
GSS_S_BAD_MECH status if the context is not established
|
|
after this GSS_Init_sec_context() call. If a MIC token is
|
|
present, the initiator MUST verify it and a GSS_S_BAD_MIC
|
|
must be returned if the MIC is incorrect;
|
|
|
|
|
|
2) If the selected mechanism is not the initiator's preferred
|
|
mechanism, and there is no or an incorrect MIC token,
|
|
GSS_Init_sec_context() MUST indicate GSS_S_BAD_MIC status.
|
|
This is referred in this document as the Safe to Omit MIC
|
|
("SOMIC") rule number 4.
|
|
|
|
|
|
(II) When the negotiation token carries a reject result without a
|
|
response security token, GSS_Init_sec_context() MUST indicate
|
|
GSS_S_BAD_MECH status;
|
|
|
|
|
|
(III) When the negotiation token carries a reject result with a
|
|
response security token, the initiator MUST deposit the
|
|
security token, and GSS_Init_sec_context() MUST indicate a
|
|
failure status reported by the underlying mechanism, and the
|
|
output mech_type indicates the selected mechanism;
|
|
|
|
|
|
(IV) When the negotiation token carries an accept_incomplete
|
|
result and further mechanism tokens from the acceptor must be
|
|
transferred in order to complete context establishment,
|
|
GSS_Init_sec_context() MUST indicate GSS_S_CONTINUE_NEEDED
|
|
status, returning an output token with the accept_incomplete,
|
|
and the selected mechanism's context level token;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 8]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
(V) When the negotiation token carries an accept_incomplete
|
|
result, no further mechanism token need to be transferred from
|
|
the acceptor to complete the context establishment, the
|
|
initiator MUST do one of the following:
|
|
|
|
|
|
1) If a MIC token was included, the initiator MUST verify it
|
|
and GSS_Init_sec_context() MUST indicate GSS_S_BAD_MIC if
|
|
the MIC is incorrect; GSS_Init_sec_context() MUST indicate
|
|
GSS_S_COMPLETE and produce a negotiation with the
|
|
accept_completed state if the MIC is correct. This is
|
|
referred in this document as the Safe to Omit MIC ("SOMIC")
|
|
rule number 5;
|
|
|
|
|
|
2) If no MIC token was present, GSS_Init_sec_context() MUST
|
|
indicate GSS_S_BAD_MIC statue, This is referred in this
|
|
document as the Safe to Omit MIC ("SOMIC") rule number 6.
|
|
|
|
|
|
(g) The initiator application then sends the output_token to the
|
|
target if one is returned. The security context initialization is
|
|
then continued according to the standard GSS-API conventions for
|
|
the selected mechanism, where the tokens of the selected mechanism
|
|
are encapsulated until the GSS_S_COMPLETE is returned for both the
|
|
initiator and the target. When no further mechanism token is
|
|
needed to be transferred and the context for the chosen mechanism
|
|
is established, the initiator and the acceptor will need to either
|
|
apply the "SOMIC" rules above and skip MIC generation and
|
|
verification, or generate and verify the MIC token to protect the
|
|
negotiation.
|
|
|
|
|
|
(h) When GSS_S_CONTINUE_NEEDED is returned, the mech_type output
|
|
parameter is not yet valid. When GSS_S_COMPLETE is returned, the
|
|
mech_type output parameter indicates the selected mechanism.
|
|
|
|
|
|
Note that the *_req_flag input parameters for context establishment
|
|
are relative to the selected mechanism, as are the *_state output
|
|
parameters. i.e., these parameters are not applicable to the
|
|
negotiation process per se.
|
|
|
|
|
|
On receipt of a negotiation token on the target side, a GSS-API
|
|
implementation that does not support negotiation would indicate the
|
|
GSS_S_BAD_MECH status as if a particular basic security mechanism had
|
|
been requested but was not supported.
|
|
|
|
|
|
When GSS_Acquire_cred is invoked with the negotiation mechanism as
|
|
desired_mechs, an implementation-specific default credential is used
|
|
to carry on the negotiation. A set of mechanisms as specified
|
|
locally by the system administrator is then available for
|
|
negotiation. If there is a desire for the caller to make its own
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 9]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
choice, then an additional API has to be used as defined in [PRTSTK].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 10]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
4. Data Elements
|
|
|
|
|
|
The type definitions in this section assume an ASN.1 module
|
|
definition of the following form:
|
|
|
|
|
|
SPNEGOASNOneSpec {
|
|
iso(1) identified-organization(3) dod(6) internet(1)
|
|
security(5) mechanism(5) snego (2)
|
|
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
|
|
|
|
|
|
-- rest of definitions here
|
|
|
|
|
|
END
|
|
|
|
|
|
This specifies that the tagging context for the module will be
|
|
explicit and non-automatic.
|
|
|
|
|
|
The encoding of SPNEGO protocol messages shall obey the Distinguished
|
|
Encoding Rules (DER) of ASN.1 as described in [X690].
|
|
|
|
|
|
4.1 Mechanism Type
|
|
|
|
|
|
MechType ::= OBJECT IDENTIFIER
|
|
-- OID represents each security mechanism as suggested by
|
|
-- [RFC2743]
|
|
|
|
|
|
|
|
4.2 Negotiation Tokens
|
|
|
|
|
|
The syntax of the initial negotiation tokens follows the
|
|
InitialContextToken syntax defined in [RFC2743]. The security
|
|
mechanism of the initial negotiation token is identified by the
|
|
Object Identifier in Section 1. All subsequent tokens are not
|
|
encapsulated in the above generic token framing.
|
|
|
|
|
|
This section specifies the syntax of initial and subsequent context
|
|
level tokens.
|
|
|
|
|
|
NegotiationToken ::= CHOICE {
|
|
negTokenInit [0] NegTokenInit,
|
|
negTokenResp [1] negTokenResp
|
|
}
|
|
|
|
|
|
MechTypeList ::= SEQUENCE OF MechType
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 11]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
4.2.1 negTokenInit
|
|
|
|
|
|
NegTokenInit ::= SEQUENCE {
|
|
mechTypes [0] MechTypeList,
|
|
reqFlags [1] ContextFlags OPTIONAL,
|
|
mechToken [2] OCTET STRING OPTIONAL,
|
|
mechListMIC [3] OCTET STRING OPTIONAL,
|
|
...
|
|
}
|
|
|
|
|
|
ContextFlags ::= BIT STRING {
|
|
delegFlag (0),
|
|
mutualFlag (1),
|
|
replayFlag (2),
|
|
sequenceFlag (3),
|
|
anonFlag (4),
|
|
confFlag (5),
|
|
integFlag (6)
|
|
}
|
|
|
|
|
|
This is the message for the initial negotiation token.
|
|
|
|
|
|
mechTypes
|
|
|
|
|
|
This field contains one or more security mechanisms in the
|
|
preference order (favorite choice first) supported by the
|
|
initiator (as indicated in the field mechTypes).
|
|
|
|
|
|
reqFlags
|
|
|
|
|
|
This field, if present, contains the service options that are
|
|
requested to establish the context. The context flags SHOULD
|
|
be filled in from the req_flags parameter of
|
|
GSS_Init_sec_context(). This field SHALL NOT influence the
|
|
outcome of the negotiation.
|
|
|
|
|
|
mechToken
|
|
|
|
|
|
This field, is present, contains an optimistic negotiation
|
|
response.
|
|
|
|
|
|
mechListMIC
|
|
|
|
|
|
This field, if present, contains the result of a GSS_GetMIC()
|
|
[RFC2743] of the MechTypes field in the initial NegTokenInit
|
|
token. It allows verifying that the list initially sent by the
|
|
initiator has been received unmodified by the target.
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 12]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
4.2.2 negTokenResp
|
|
|
|
|
|
NegTokenResp ::= SEQUENCE {
|
|
negResult [0] ENUMERATED {
|
|
accept_completed (0),
|
|
accept_incomplete (1),
|
|
reject (2)
|
|
},
|
|
supportedMech [1] MechType OPTIONAL,
|
|
responseToken [2] OCTET STRING OPTIONAL,
|
|
mechListMIC [3] OCTET STRING OPTIONAL,
|
|
-- used only by the acceptor
|
|
...
|
|
}
|
|
|
|
|
|
This is the message for all the subsequent tokens.
|
|
|
|
|
|
negResult
|
|
|
|
|
|
Result of the negotiation exchange, specified by the target.
|
|
This can be:
|
|
|
|
|
|
accept_completed
|
|
A security mechanism is selected, and the context is
|
|
established for the sender;
|
|
|
|
|
|
accept_incomplete
|
|
Further exchanges are necessary;
|
|
|
|
|
|
reject
|
|
The sender reject the proposed security mechanism(s).
|
|
|
|
|
|
accept_completed indicates that a context has been successfully
|
|
established, while the result accept_incomplete indicates that
|
|
additional token exchanges are needed.
|
|
|
|
|
|
For those targets that support piggybacking the initial
|
|
mechToken, an optimistic negotiation response is possible and
|
|
includes in that case a responseToken which MAY continue the
|
|
authentication exchange (e.g. when mutual authentication has
|
|
been requested or when unilateral authentication requires
|
|
several round trips). Otherwise the responseToken is used to
|
|
carry the tokens specific to the mechanism selected.
|
|
|
|
|
|
The mechListMIC, when present, is a MIC computed over the
|
|
MechTypes using the mechanism list field in the initial token
|
|
(encoded in DER).
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 13]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
supportedMech
|
|
|
|
|
|
This field is present and only present in the first
|
|
negTokenResp token. It is a choice from the mechanisms offered
|
|
by the initiator.
|
|
|
|
|
|
responseToken
|
|
|
|
|
|
This field, if present, contains the security token of the
|
|
selected mechanism.
|
|
|
|
|
|
mechListMIC
|
|
|
|
|
|
This field, if present, contains the result of a GSS_GetMIC()
|
|
[RFC2743] of the MechTypes field in the initial NegTokenInit
|
|
token. It allows verifying that the list initially sent by the
|
|
initiator has been received unmodified by the target.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 14]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
5. Security Considerations
|
|
|
|
|
|
In order to produce the MIC for the mechanism list, the mechanism
|
|
MUST provide integirty protection. When one of the mechanisms
|
|
proposed by the initiator does not support integrity protection, then
|
|
the negotiation is exposed to all threats a non secured service is
|
|
exposed. In particular, an active attacker can force to use a
|
|
security mechanism which is not the common preferred one (when
|
|
multiple security mechanisms are shared between peers) but which is
|
|
acceptable anyway to the target, thus this mechanism does not support
|
|
selecting a mechanism that does not support integrity protection.
|
|
|
|
|
|
In any case, the communicating peers MAY be exposed to the denial of
|
|
service threat.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 15]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
6. Acknowledgments
|
|
|
|
|
|
The authors wish to thank Paul Leach and Todd Stecher for theirs
|
|
comments and suggestions on earlier versions of this document.
|
|
|
|
|
|
Eric Baize and Denis Pinkas wrote the original SPNEGO specification
|
|
[RFC2478], of which some of the text has been retained in this
|
|
document.
|
|
|
|
|
|
7 References
|
|
|
|
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
|
|
|
|
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
|
|
Negotiation Mechanism", RFC 2478, December 1998.
|
|
|
|
|
|
[RFC2743] Linn, J., "Generic Security Service Application Program
|
|
Interface Version 2, Update 1", RFC 2743, January 2000.
|
|
|
|
|
|
[PRTSTK] RFC-Editor: To be replaced by RFC number for draft-williams
|
|
-gssapi-stackable-pseudo-mechs. Work in progress.
|
|
|
|
[X690] ASN.1 encoding rules: Specification of Basic Encoding Rules
|
|
(BER), Canonical Encoding Rules (CER) and Distinguished
|
|
Encoding Rules (DER), ITU-T Recommendation X.690 (1997) |
|
|
ISO/IEC International Standard 8825-1:1998.
|
|
|
|
|
|
Authors' Addresses
|
|
|
|
|
|
Larry Zhu
|
|
Microsoft Corporation
|
|
One Microsoft Way
|
|
Redmond, WA 98052
|
|
US
|
|
|
|
|
|
EMail: lzhu@microsoft.com
|
|
|
|
|
|
|
|
Karthik Jaganathan
|
|
Microsoft Corporation
|
|
One Microsoft Way
|
|
Redmond, WA 98052
|
|
US
|
|
|
|
|
|
EMail: karthikj@microsoft.com
|
|
|
|
|
|
|
|
Richard B. Ward
|
|
Microsoft Corporation
|
|
One Microsoft Way
|
|
Redmond, WA 98052
|
|
US
|
|
|
|
|
|
EMail: richardw@microsoft.com
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 16]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
Appendix A. Changes since RFC2478
|
|
|
|
|
|
The following changes are designed to be compatible with an
|
|
incorrect implementation of RFC 2478 shipped in Windows 2000. A
|
|
correct implementation of this protocol that negotiates the 2 leg
|
|
Kerberos GSS-API mechanism as the only available security
|
|
mechanism should be ale to interoperate with the implementation of
|
|
Windows 2000 when the mangled OID (1.2.840.48018.1.2.2) can be
|
|
used to identify Kerberos.
|
|
|
|
|
|
* The negTokenTarg is changed to negTokenResp and it is now the
|
|
format for all subsequent negotiation messages.
|
|
* negTokenInit is the message for the initial token and that
|
|
token only.
|
|
* mechTypes in negTokenInit is no longer optional.
|
|
* negResult is no longer optional in the negTokenResp token.
|
|
* The initiator does not send the MIC token.
|
|
* Add rules when it is safe to omit the MIC token. Search for
|
|
SOMIC.
|
|
|
|
|
|
The following changes are to address the problems in RFC 2478.
|
|
|
|
|
|
* reqFlags is not protected therefore it should not impact the
|
|
negotiation.
|
|
* BER encoding is required.
|
|
* GSS_GetMIC() input is clarified.
|
|
* Nico's stackable pseudo mechanism draft is used to replace the
|
|
support APIs.
|
|
* We no longer support negotiating mechanisms that do not provide
|
|
for integrity. That support does not add security values but
|
|
blows up the interoperability test matrix.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 17]
|
|
Internet-Draft GSS-API Negotiation Mechanism October 2004
|
|
|
|
|
|
|
|
Intellectual Property Statement
|
|
|
|
|
|
The IETF takes no position regarding the validity or scope of any
|
|
Intellectual Property Rights or other rights that might be claimed to
|
|
pertain to the implementation or use of the technology described in
|
|
this document or the extent to which any license under such rights
|
|
might or might not be available; nor does it represent that it has
|
|
made any independent effort to identify any such rights. Information
|
|
on the procedures with respect to rights in RFC documents can be
|
|
found in BCP 78 and BCP 79.
|
|
|
|
|
|
Copies of IPR disclosures made to the IETF Secretariat and any
|
|
assurances of licenses to be made available, or the result of an
|
|
attempt made to obtain a general license or permission for the use of
|
|
such proprietary rights by implementers or users of this
|
|
specification can be obtained from the IETF on-line IPR repository at
|
|
http://www.ietf.org/ipr.
|
|
|
|
|
|
The IETF invites any interested party to bring to its attention any
|
|
copyrights, patents or patent applications, or other proprietary
|
|
rights that may cover technology that may be required to implement
|
|
this standard. Please address the information to the IETF at
|
|
ietf-ipr@ietf.org.
|
|
|
|
|
|
|
|
Disclaimer of Validity
|
|
|
|
|
|
This document and the information contained herein are provided on an
|
|
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
|
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
|
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
|
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
|
|
|
|
Copyright Statement
|
|
|
|
|
|
Copyright (C) The Internet Society (2004). This document is subject
|
|
to the rights, licenses and restrictions contained in BCP 78, and
|
|
except as set forth therein, the authors retain all their rights.
|
|
|
|
|
|
|
|
Acknowledgment
|
|
|
|
|
|
Funding for the RFC Editor function is currently provided by the
|
|
Internet Society.
|
|
|
|
|
|
|
|
|
|
|
|
Zhu, et al. Expires April 18, 2005 [Page 18] |