The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism
RFC 4752
Document | Type |
RFC - Proposed Standard
(November 2006; Errata)
Obsoletes RFC 2222
|
|
---|---|---|---|
Author | Alexey Melnikov | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4752 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Sam Hartman | ||
Send notices to | (None) |
Network Working Group A. Melnikov, Ed. Request for Comments: 4752 Isode Obsoletes: 2222 November 2006 Category: Standards Track The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) 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 IETF Trust (2006). Abstract The Simple Authentication and Security Layer (SASL) is a framework for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface (GSS-API) Kerberos V5 in the SASL. This document replaces Section 7.2 of RFC 2222, the definition of the "GSSAPI" SASL mechanism. This document, together with RFC 4422, obsoletes RFC 2222. Melnikov Standards Track [Page 1] RFC 4752 SASL GSSAPI Mechanism November 2006 Table of Contents 1. Introduction ....................................................2 1.1. Relationship to Other Documents ............................2 2. Conventions Used in This Document ...............................2 3. Kerberos V5 GSS-API Mechanism ...................................2 3.1. Client Side of Authentication Protocol Exchange ............3 3.2. Server Side of Authentication Protocol Exchange ............4 3.3. Security Layer .............................................6 4. IANA Considerations .............................................7 5. Security Considerations .........................................7 6. Acknowledgements ................................................8 7. Changes since RFC 2222 ..........................................8 8. References ......................................................8 8.1. Normative References .......................................8 8.2. Informative References .....................................9 1. Introduction This specification documents currently deployed Simple Authentication and Security Layer (SASL [SASL]) mechanism supporting the Kerberos V5 [KERBEROS] Generic Security Service Application Program Interface ([GSS-API]) mechanism [RFC4121]. The authentication sequence is described in Section 3. Note that the described authentication sequence has known limitations, in particular, it lacks channel bindings and the number of round-trips required to complete authentication exchange is not minimal. SASL WG is working on a separate document that should address these limitations. 1.1. Relationship to Other Documents This document, together with RFC 4422, obsoletes RFC 2222 in its entirety. This document replaces Section 7.2 of RFC 2222. The remainder is obsoleted as detailed in Section 1.2 of RFC 4422. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 3. Kerberos V5 GSS-API Mechanism The SASL mechanism name for the Kerberos V5 GSS-API mechanism [RFC4121] is "GSSAPI". Though known as the SASL GSSAPI mechanism, the mechanism is specifically tied to Kerberos V5 and GSS-API's Kerberos V5 mechanism. Melnikov Standards Track [Page 2] RFC 4752 SASL GSSAPI Mechanism November 2006 The GSSAPI SASL mechanism is a "client goes first" SASL mechanism; i.e., it starts with the client sending a "response" created as described in the following section. The implementation MAY set any GSS-API flags or arguments not mentioned in this specification as is necessary for the implementation to enforce its security policy. Note that major status codes returned by GSS_Init_sec_context() or GSS_Accept_sec_context() other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED cause authentication failure. Major status codes returned by GSS_Unwrap() other than GSS_S_COMPLETE (without any additional supplementary status codes) cause authentication and/or security layer failure. 3.1. Client Side of Authentication Protocol Exchange The client calls GSS_Init_sec_context, passing in input_context_handle of 0 (initially), mech_type of the Kerberos V5 GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name equal to output_name from GSS_Import_Name called with input_name_typeShow full document text