Simple Authentication and Security Layer (SASL)
RFC 2222
Document | Type |
RFC - Proposed Standard
(October 1997; No errata)
Updated by RFC 2444
Was draft-myers-auth-sasl (individual)
|
|
---|---|---|---|
Author | John Myers | ||
Last updated | 2020-07-29 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 2222 (Proposed Standard) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group J. Myers Request for Comments: 2222 Netscape Communications Category: Standards Track October 1997 Simple Authentication and Security Layer (SASL) 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 (1997). All Rights Reserved. Table of Contents 1. Abstract .............................................. 2 2. Organization of this Document ......................... 2 2.1. How to Read This Document ............................. 2 2.2. Conventions Used in this Document ..................... 2 2.3. Examples .............................................. 3 3. Introduction and Overview ............................. 3 4. Profiling requirements ................................ 4 5. Specific issues ....................................... 5 5.1. Client sends data first ............................... 5 5.2. Server returns success with additional data ........... 5 5.3. Multiple authentications .............................. 5 6. Registration procedures ............................... 6 6.1. Comments on SASL mechanism registrations .............. 6 6.2. Location of Registered SASL Mechanism List ............ 6 6.3. Change Control ........................................ 7 6.4. Registration Template ................................. 7 7. Mechanism definitions ................................. 8 7.1. Kerberos version 4 mechanism .......................... 8 7.2. GSSAPI mechanism ...................................... 9 7.2.1 Client side of authentication protocol exchange ....... 9 7.2.2 Server side of authentication protocol exchange ....... 10 7.2.3 Security layer ........................................ 11 7.3. S/Key mechanism ....................................... 11 7.4. External mechanism .................................... 12 8. References ............................................ 13 9. Security Considerations ............................... 13 10. Author's Address ...................................... 14 Myers Standards Track [Page 1] RFC 2222 SASL October 1997 Appendix A. Relation of SASL to Transport Security .......... 15 Full Copyright Statement .................................... 16 1. Abstract This document describes a method for adding authentication support to connection-based protocols. To use this specification, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection. This document describes how a protocol specifies such a command, defines several mechanisms for use by the command, and defines the protocol used for carrying a negotiated security layer over the connection. 2. Organization of this Document 2.1. How to Read This Document This document is written to serve two different audiences, protocol designers using this specification to support authentication in their protocol, and implementors of clients or servers for those protocols using this specification. The sections "Introduction and Overview", "Profiling requirements", and "Security Considerations" cover issues that protocol designers need to understand and address in profiling this specification for use in a specific protocol. Implementors of a protocol using this specification need the protocol-specific profiling information in addition to the information in this document. 2.2. Conventions Used in this Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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" [RFC 2119]. Myers Standards Track [Page 2] RFC 2222 SASL October 1997 2.3. Examples Examples in this document are for the IMAP profile [RFC 2060] of this specification. The base64 encoding of challenges and responses, as well as the "+ " preceding the responses are part of the IMAP4Show full document text