[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS gss/doc/specification
|
From: |
gss-commit |
|
Subject: |
CVS gss/doc/specification |
|
Date: |
Thu, 16 Dec 2004 00:13:30 +0100 |
Update of /home/cvs/gss/doc/specification
In directory dopio:/tmp/cvs-serv9868
Added Files:
draft-ietf-kitten-2478bis-03.txt
Log Message:
Add.
--- /home/cvs/gss/doc/specification/draft-ietf-kitten-2478bis-03.txt
2004/12/15 23:13:30 NONE
+++ /home/cvs/gss/doc/specification/draft-ietf-kitten-2478bis-03.txt
2004/12/15 23:13:30 1.1
NETWORK WORKING GROUP L. Zhu
Internet-Draft P. Leach
Obsoletes: 2478 (if approved) K. Jaganathan
Expires: June 14, 2005 Microsoft Corporation
W. Ingersoll
Sun Microsystems
December 14, 2004
The Simple and Protected GSS-API Negotiation Mechanism
draft-ietf-kitten-2478bis-03
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 June 14, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document specifies a negotiation mechanism for the Generic
Security Service Application Program Interface (GSS-API) which is
described in RFC 2743.
Zhu, et al. Expires June 14, 2005 [Page 1]
Internet-Draft GSS-API Negotiation Mechanism December 2004
GSS-API peers can use this negotiation mechanism to choose from a
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . 6
3.1 Negotiation Description . . . . . . . . . . . . . . . . . 6
3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 7
4. Token Definitions . . . . . . . . . . . . . . . . . . . . . . 10
4.1 Mechanism Types . . . . . . . . . . . . . . . . . . . . . 10
4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 10
4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 11
4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 12
5. Processing of mechListMIC . . . . . . . . . . . . . . . . . . 14
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 21
10.2 Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 23
A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 23
A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 23
B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 25
C. mechListMIC Computation Example . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 28
Zhu, et al. Expires June 14, 2005 [Page 2]
Internet-Draft GSS-API Negotiation Mechanism December 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 does not 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 support a common set of one or more GSS-API
security mechanisms, and if so, to invoke the normal security context
establishment for a selected common security mechanism. This is most
useful for applications which depend on GSS-API implementations and
share multiple mechanisms between the peers.
The SPNEGO mechanism negotiation is based on the following model: the
initiator proposes a list of security mechanism(s), in decreasing
preference order (favorite choice first), the acceptor (also known as
the target) either accepts the initiator's preferred security
mechanism (the first in the list), or chooses one that is available
from the offered list, or rejects the proposed value(s). The target
then informs the initiator of its choice.
Once a common security mechanism is chosen, mechanism-specific
options MAY be negotiated as part of the selected mechanism's context
establishment. These negotiations (if any) are internal to the
mechanism and opaque to the SPNEGO protocol. As such they are
outside the scope of this document.
If per-message integrity services are available on the established
mechanism security context, then the negotiation is protected to
ensure that the mechanism list has not been modified. In cases where
an attacker could have materially influenced the negotiation, peers
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 context
establishment token of the initiator's preferred mechanism SHOULD be
Zhu, et al. Expires June 14, 2005 [Page 3]
Internet-Draft GSS-API Negotiation Mechanism December 2004
embedded in the initial negotiation message (as defined in Section
4.2). (This mechanism token is referred to as the optimistic
mechanism token in this document.) In addition, using the optimistic
mechanism token allows the initiator to recover from non-fatal errors
encountered trying to produce the first mechanism token before a
mechanism can be selected. Implementations MAY omit the optimistic
mechanism token in cases where the likelihood of the initiator's
preferred mechanism not being selected by the acceptor is significant
given the cost of generating it.
SPNEGO relies on 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 June 14, 2005 [Page 4]
Internet-Draft GSS-API Negotiation Mechanism December 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 June 14, 2005 [Page 5]
Internet-Draft GSS-API Negotiation Mechanism December 2004
3. Negotiation Protocol
When the established mechanism context provides integrity protection,
the mechanism negotiation can be protected. When acquiring
negotiated security mechanism tokens, per-message integrity services
are always requested by the SPNEGO mechanism.
When the established mechanism context supports per-message integrity
services, SPNEGO guarantees that the selected mechanism is mutually
preferred.
This section describes the negotiation process of this protocol.
3.1 Negotiation Description
The first negotiation token sent by the initiator contains an ordered
list of mechanisms in decreasing preference order (favorite mechanism
first), and optionally the initial mechanism token for the preferred
mechanism of the initiator (i.e., the first in the list). (Note that
the list MUST NOT contain mechanisms for which the client does not
have appropriate credentials.)
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)
being returned in the reply message: accept_completed,
accept_incomplete, reject, or request_mic. A reject state will
terminate the negotiation; an accept_completed state indicates that
not only was the initiator-selected mechanism acceptable to the
target, but also that the optimistic mechanism token was sufficient
to complete the authentication; an accept_incomplete state indicates
that further message exchange is needed but the MIC token exchange as
described in Section 5 is OPTIONAL; a request_mic state (this state
can only be present in the first reply message from the target)
indicates the MIC token exchange is REQUIRED if per-message integrity
services are available.
Unless the preference order is specified by the application (see
Appendix A), the policy by which the target chooses a mechanism is an
implementation-specific local matter. In the absence of an
application specified preference order or other policy, the target
SHALL choose the first mechanism in the initiator proposed list for
which it has valid credentials.
In case of a successful negotiation, the security mechanism in the
first reply message represents the value suitable for the target,
chosen from the list offered by the initiator.
In case of an unsuccessful negotiation, the reject state is returned
Zhu, et al. Expires June 14, 2005 [Page 6]
Internet-Draft GSS-API Negotiation Mechanism December 2004
and it is OPTIONAL to emit a context level negotiation token.
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.
To avoid conflicts with the use of MIC tokens by SPNEGO,
partially-established contexts MUST NOT be used for per-message
calls. To guarantee this, the prot_ready_state [RFC2743] MUST be set
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
The basic form of the procedure assumes that per-message integrity
services are available on the established mechanism context, and it
is summarized as follows:
(a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
but requests that SPNEGO be used. SPNEGO can either be explicity
requested or accepted as the default mechanism.
(b) The initiator GSS-API implementation emits a negotiation token
containing a list of one or more security mechanisms that are
available based on the credentials used for this context
establishment, and optionally the initial mechanism token for the
first mechanism in the list.
(c) The GSS-API initiator application sends the token to the target
application. The GSS-API target application deposits the token by
invoking GSS_Accept_sec_context(). The acceptor will do one of
the following:
(I) If none of the proposed mechanisms are acceptable, the
negotiation SHALL be terminated. GSS_Accept_sec_context
indicates GSS_S_BAD_MECH. The acceptor MAY output a
negotiation token containing a reject state.
(II) If either the initiator's preferred mechanism is not
accepted by the target or this mechanism is accepted but it
is not the acceptor's most preferred mechanism (i.e., the
MIC token exchange as described in Section 5 is required),
GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED.
Zhu, et al. Expires June 14, 2005 [Page 7]
Internet-Draft GSS-API Negotiation Mechanism December 2004
The acceptor MUST output a negotiation token containing a
request_mic state.
(III) Otherwise if at least one additional negotiation token
from the initiator is needed to establish this context,
[1171 lines skipped]