8: Referenced Documents
[ISO-7498-2] International Standard ISO 7498-2-1988(E), Security Architecture. [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 specifications. 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 caller protocols.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 deprecated: 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 context information. This GSS-V2 specification adds the following calls which are not present in GSS-V1:
Credential management calls: GSS_Add_cred(), GSS_Inquire_cred_by_mech(). Context-level calls: GSS_Inquire_context(), GSS_Wrap_size_limit(), GSS_Export_sec_context(), GSS_Import_sec_context(). Per-message calls: No new calls. Existing calls have been renamed. Support calls: GSS_Create_empty_OID_set(), GSS_Add_OID_set_member(), GSS_Test_OID_set_member(), GSS_Inquire_names_for_mech(), GSS_Inquire_mechs_for_name(), 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() facility. 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 requested GSS_S_NAME_NOT_MN name contains multi-mechanism elements GSS_S_GAP_TOKEN skipped predecessor token(s) detected 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 incorporated.
General: Clarified usage of object release routines, and incorporated statement that some may be omitted within certain operating environments. Removed GSS_Release_OID, GSS_OID_to_str(), and GSS_Str_to_OID() routines. 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 GSS_S_CONTINUE_NEEDED. Adapted and incorporated clarifying material on optional service support, delegation, and interprocess context transfer from C bindings document. 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 contexts. Added clarification on GSS_Export_sec_context() and GSS_Import_sec_context() behavior and context usage following an export-import sequence. 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 group discussion.) 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 descriptions accordingly. 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 GSS_Import_sec_context(). 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. Credential-related: 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 requested. 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 GSS_C_NO_CREDENTIAL. Name-related: 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 with GSS_Display_name(). Downgraded reference to name canonicalization via DNS lookup to an example. 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 name.
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, Update 1.AUTHOR'S ADDRESS
John Linn RSA Laboratories 20 Crosby Drive Bedford, MA 01730 USA Phone: +1 781.687.7817 EMail: jlinn@rsasecurity.com
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 English. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.