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