8: Referenced Documents
[ISO-7498-2] International Standard ISO 7498-2-1988(E), Security
[ISOIEC-8824] ISO/IEC 8824, "Specification of Abstract Syntax
Notation One (ASN.1)".
[ISOIEC-8825] ISO/IEC 8825, "Specification of Basic Encoding Rules
for Abstract Syntax Notation One (ASN.1)".)
[RFC-1507]: Kaufman, C., "DASS: Distributed Authentication Security
Service", RFC 1507, September 1993.
[RFC-1508]: Linn, J., "Generic Security Service Application Program
Interface", RFC 1508, September 1993.
[RFC-1509]: Wray, J., "Generic Security Service API: C-bindings",
RFC 1509, September 1993.
[RFC-1964]: Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC-2025]: Adams, C., "The Simple Public-Key GSS-API Mechanism
(SPKM)", RFC 2025, October 1996.
[RFC-2078]: Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997.
[RFC-2203]: Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[RFC-2744]: Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
APPENDIX A - MECHANISM DESIGN CONSTRAINTS
The following constraints on GSS-API mechanism designs are adopted in
response to observed caller protocol requirements, and adherence
thereto is anticipated in subsequent descriptions of GSS-API
mechanisms to be documented in standards-track Internet
It is strongly recommended that mechanisms offering per-message
protection services also offer at least one of the replay detection
and sequencing services, as mechanisms offering neither of the latter
will fail to satisfy recognized requirements of certain candidate
APPENDIX B - COMPATIBILITY WITH GSS-V1
It is the intent of this document to define an interface and
procedures which preserve compatibility between GSS-V1 [RFC-1508]
callers and GSS-V2 providers. All calls defined in GSS-V1 are
preserved, and it has been a goal that GSS-V1 callers should be able
to operate atop GSS-V2 provider implementations. Certain detailed
changes, summarized in this section, have been made in order to
resolve omissions identified in GSS-V1.
The following GSS-V1 constructs, while supported within GSS-V2, are
Names for per-message processing routines: GSS_Seal() deprecated
in favor of GSS_Wrap(); GSS_Sign() deprecated in favor of
GSS_GetMIC(); GSS_Unseal() deprecated in favor of GSS_Unwrap();
GSS_Verify() deprecated in favor of GSS_VerifyMIC().
GSS_Delete_sec_context() facility for context_token usage,
allowing mechanisms to signal context deletion, is retained for
compatibility with GSS-V1. For current usage, it is recommended
that both peers to a context invoke GSS_Delete_sec_context()
independently, passing a null output_context_token buffer to
indicate that no context_token is required. Implementations of
GSS_Delete_sec_context() should delete relevant locally-stored
This GSS-V2 specification adds the following calls which are not
present in GSS-V1:
Credential management calls: GSS_Add_cred(),
Context-level calls: GSS_Inquire_context(), GSS_Wrap_size_limit(),
Per-message calls: No new calls. Existing calls have been
Support calls: GSS_Create_empty_OID_set(),
GSS_Canonicalize_name(), GSS_Export_name(), GSS_Duplicate_name().
This GSS-V2 specification introduces three new facilities applicable
to security contexts, indicated using the following context state
values which are not present in GSS-V1:
anon_state, set TRUE to indicate that a context's initiator is
anonymous from the viewpoint of the target; Section 1.2.5 of this
specification provides a summary description of the GSS-V2
anonymity support facility, support and use of which is optional.
prot_ready_state, set TRUE to indicate that a context may be used
for per-message protection before final completion of context
establishment; Section 1.2.7 of this specification provides a
summary description of the GSS-V2 facility enabling mechanisms to
selectively permit per-message protection during context
establishment, support and use of which is optional.
trans_state, set TRUE to indicate that a context is transferable
to another process using the GSS-V2 GSS_Export_sec_context()
These state values are represented (at the C bindings level) in
positions within a bit vector which are unused in GSS-V1, and may be
safely ignored by GSS-V1 callers.
New conf_req_flag and integ_req_flag inputs are defined for
GSS_Init_sec_context(), primarily to provide information to
negotiating mechanisms. This introduces a compatibility issue with
GSS-V1 callers, discussed in section 2.2.1 of this specification.
Relative to GSS-V1, GSS-V2 provides additional guidance to GSS-API
implementors in the following areas: implementation robustness,
credential management, behavior in multi-mechanism configurations,
naming support, and inclusion of optional sequencing services. The
token tagging facility as defined in GSS-V2, Section 3.1, is now
described directly in terms of octets to facilitate interoperable
implementation without general ASN.1 processing code; the
corresponding ASN.1 syntax, included for descriptive purposes, is
unchanged from that in GSS-V1. For use in conjunction with added
naming support facilities, a new Exported Name Object construct is
added. Additional name types are introduced in Section 4.
This GSS-V2 specification adds the following major_status values
which are not defined in GSS-V1:
GSS_S_BAD_QOP unsupported QOP value
GSS_S_UNAUTHORIZED operation unauthorized
GSS_S_UNAVAILABLE operation unavailable
GSS_S_DUPLICATE_ELEMENT duplicate credential element
GSS_S_NAME_NOT_MN name contains multi-mechanism
GSS_S_GAP_TOKEN skipped predecessor token(s)
Of these added status codes, only two values are defined to be
returnable by calls existing in GSS-V1: GSS_S_BAD_QOP (returnable by
GSS_GetMIC() and GSS_Wrap()), and GSS_S_GAP_TOKEN (returnable by
GSS_VerifyMIC() and GSS_Unwrap()).
Additionally, GSS-V2 descriptions of certain calls present in GSS-V1
have been updated to allow return of additional major_status values
from the set as defined in GSS-V1: GSS_Inquire_cred() has
GSS_S_DEFECTIVE_CREDENTIAL and GSS_S_CREDENTIALS_EXPIRED defined as
returnable, GSS_Init_sec_context() has GSS_S_OLD_TOKEN,
GSS_S_DUPLICATE_TOKEN, and GSS_S_BAD_MECH defined as returnable, and
GSS_Accept_sec_context() has GSS_S_BAD_MECH defined as returnable.
APPENDIX C - CHANGES RELATIVE TO RFC-2078
This document incorporates a number of changes relative to RFC-2078,
made primarily in response to implementation experience, for purposes
of alignment with the GSS-V2 C language bindings document, and to add
informative clarification. This section summarizes technical changes
Clarified usage of object release routines, and incorporated
statement that some may be omitted within certain operating
Removed GSS_Release_OID, GSS_OID_to_str(), and GSS_Str_to_OID()
Clarified circumstances under which zero-length tokens may validly
exist as inputs and outputs to/from GSS-API calls.
Added GSS_S_BAD_MIC status code as alias for GSS_S_BAD_SIG.
For GSS_Display_status(), deferred to language bindings the choice
of whether to return multiple status values in parallel or via
iteration, and added commentary deprecating return of
Adapted and incorporated clarifying material on optional service
support, delegation, and interprocess context transfer from C
Added and updated references to related documents, and to current
status of cited Kerberos mechanism OID.
Added general statement about GSS-API calls having no side effects
visible at the GSS-API level.
Context-related (including per-message protection issues):
Clarified GSS_Delete_sec_context() usage for partially-established
Added clarification on GSS_Export_sec_context() and
GSS_Import_sec_context() behavior and context usage following an
Added informatory conf_req_flag, integ_req_flag inputs to
GSS_Init_sec_context(). (Note: this facility introduces a
backward incompatibility with GSS-V1 callers, discussed in Section
2.2.1; this implication was recognized and accepted in working
Stated that GSS_S_FAILURE is to be returned if
GSS_Init_sec_context() or GSS_Accept_sec_context() is passed the
handle of a context which is already fully established.
Re GSS_Inquire_sec_context(), stated that src_name and targ_name
are not returned until GSS_S_COMPLETE status is reached; removed
use of GSS_S_CONTEXT_EXPIRED status code (replacing with EXPIRED
lifetime return value); stated requirement to retain inquirable
data until context released by caller; added result value
indicating whether or not context is fully open.
Added discussion of interoperability conditions for mechanisms
permitting optional support of QOPs. Removed reference to
structured QOP elements in GSS_Verify_MIC().
Added discussion of use of GSS_S_DUPLICATE_TOKEN status to
indicate reflected per-message tokens.
Clarified use of informational sequencing codes from per-message
protection calls in conjunction with GSS_S_COMPLETE and
GSS_S_FAILURE major_status returns, adjusting status code
Added specific statements about impact of GSS_GetMIC() and
GSS_Wrap() failures on context state information, and generalized
existing statements about impact of processing failures on
received per-message tokens.
For GSS_Init_sec_context() and GSS_Accept_sec_context(), permitted
returned mech_type to be valid before GSS_S_COMPLETE, recognizing
that the value may change on successive continuation calls in the
negotiated mechanism case.
Deleted GSS_S_CONTEXT_EXPIRED status from
Added conf_req_flag input to GSS_Wrap_size_limit().
Stated requirement for mechanisms' support of per-message
protection services to be usable concurrently in both directions
on a context.
For GSS_Acquire_cred() and GSS_Add_cred(), aligned with C bindings
statement of likely non-support for INITIATE or BOTH credentials
if input name is neither empty nor a name resulting from applying
GSS_Inquire_cred() against the default credential. Further,
stated that an explicit name returned by GSS_Inquire_context()
should also be accepted. Added commentary about potentially
time-variant results of default resolution and attendant
implications. Aligned with C bindings re behavior when
GSS_C_NO_NAME provided for desired_name. In GSS_Acquire_cred(),
stated that NULL, rather than empty OID set, should be used for
desired_mechs in order to request default mechanism set.
Added GSS_S_CREDENTIALS_EXPIRED as returnable major_status for
GSS_Acquire_cred(), GSS_Add_cred(), also specifying GSS_S_NO_CRED
as appropriate return for temporary, user-fixable credential
unavailability. GSS_Acquire_cred() and GSS_Add_cred() are also to
return GSS_S_NO_CRED if an authorization failure is encountered
upon credential acquisition.
Removed GSS_S_CREDENTIALS_EXPIRED status return from per-message
protection, GSS_Context_time(), and GSS_Inquire_context() calls.
For GSS_Add_cred(), aligned with C bindings' description of
behavior when addition of elements to the default credential is
Upgraded recommended default credential resolution algorithm to
status of requirement for initiator credentials.
For GSS_Release_cred(), GSS_Inquire_cred(), and
GSS_Inquire_cred_by_mech(), clarified behavior for input
Aligned GSS_Inquire_mechs_for_name() description with C bindings.
Removed GSS_S_BAD_NAMETYPE status return from
GSS_Duplicate_name(), GSS_Display_name(); constrained its
applicability for GSS_Compare_name().
Aligned with C bindings statement re GSS_Import_name() behavior
with GSS_C_NO_OID input name type, and stated that GSS-V2
mechanism specifications are to define processing procedures
applicable to their mechanisms. Also clarified GSS_C_NO_OID usage
Downgraded reference to name canonicalization via DNS lookup to an
For GSS_Canonicalize_name(), stated that neither negotiated
mechanisms nor the default mechanism are supported input
mech_types for this operation, and specified GSS_S_BAD_MECH status
to be returned in this case. Clarified that the
GSS_Canonicalize_name() operation is non-destructive to its input
Clarified semantics of GSS_C_NT_USER_NAME name type.
Added descriptions of additional name types. Also added
discussion of GSS_C_NO_NAME and its constrained usage with
specific GSS calls.
Adapted and incorporated C bindings discussion about name
comparisons with exported name objects.
Added recommendation to mechanism designers for support of host-
based service name type, deferring any requirement statement to
individual mechanism specifications. Added discussion of host-
based service's service name element and proposed approach for
IANA registration policy therefor.
Clarified byte ordering within exported name object. Stated that
GSS_S_BAD_MECH is to be returned if, in the course of attempted
import of an exported name object, the name object's enclosed
mechanism type is unrecognized or unsupported.
Stated that mechanisms may optionally accept GSS_C_NO_NAME as an
input target name to GSS_Init_sec_context(), with comment that
such support is unlikely within mechanisms predating GSS-V2,
20 Crosby Drive
Bedford, MA 01730 USA
Phone: +1 781.687.7817
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Funding for the RFC Editor function is currently provided by the