The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism
RFC 4178
Document | Type |
RFC - Proposed Standard
(October 2005; No errata)
Obsoletes RFC 2478
|
|
---|---|---|---|
Authors | Paul Leach , Karthik Jaganathan , Larry Zhu , Wyllys Ingersoll | ||
Last updated | 2018-12-20 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4178 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Sam Hartman | ||
Send notices to | jaltman@columbia.edu |
Network Working Group L. Zhu Request for Comments: 4178 P. Leach Obsoletes: 2478 K. Jaganathan Category: Standards Track Microsoft Corporation W. Ingersoll Sun Microsystems October 2005 The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API), which is described in RFC 2743. 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 that forces 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 inter-operate with implementations of that specification that are commonly deployed on the Internet. Zhu, et al. Standards Track [Page 1] RFC 4178 The GSS-API Negotiation Mechanism October 2005 Table of Contents 1. Introduction ....................................................2 2. Conventions Used in This Document ...............................3 3. Negotiation Protocol ............................................3 3.1. Negotiation Description ....................................4 3.2. Negotiation Procedure ......................................5 4. Token Definitions ...............................................7 4.1. Mechanism Types ............................................7 4.2. Negotiation Tokens .........................................7 4.2.1. negTokenInit ........................................8 4.2.2. negTokenResp ........................................9 5. Processing of mechListMIC ......................................10 6. Extensibility ..................................................13 7. Security Considerations ........................................13 8. Acknowledgments ................................................14 9. References .....................................................14 9.1. Normative References ......................................14 9.2. Informative References ....................................15 Appendix A. SPNEGO ASN.1 Module ..................................16 Appendix B. GSS-API Negotiation Support API ......................17 B.1. GSS_Set_neg_mechs Call ...................................17 B.2. GSS_Get_neg_mechs Call ...................................18 Appendix C. Changes since RFC 2478 ...............................18 Appendix D. mechListMIC Computation Example ......................20 1. Introduction The GSS-API [RFC2743] provides a generic interface that 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 that enables GSS-API peers to determine in-band whether their credentials support a common set of one or more GSS-API security mechanisms; if so, it invokes the normal security context establishment for a selected common security mechanism. This is most useful for applications that 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 Zhu, et al. Standards Track [Page 2]Show full document text