Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses SASL. Authentication mechanisms can also support proxy authorization, a facility allowing one user to assume the identity of another. Authentication mechanisms can also provide a data security layer offering data integrity and data confidentiality services. DIGEST-MD5 is an example of mechanisms which can provide a data security layer. Application protocols that support SASL typically also support Transport Layer Security (TLS) to complement the services offered by SASL.
SASL was originally specified in RFC 2222, authored by John Meyers while at Carnegie Mellon University. That document was made obsolete by RFC 4422, edited by Alexey Melnikov and Kurt Zeilenga.
SASL Mechanisms
A SASL mechanism is modelled as a series of challenges and responses. Defined SASL mechanisms [1] include:
"EXTERNAL", where authentication is implicit in the context (e.g., for protocols already using IPsec or TLS)
"ANONYMOUS", for unauthenticated guest access
"PLAIN", a simple cleartext password mechanism. PLAIN obsoleted the LOGIN mechanism.
"OTP", a one-time password mechanism. OTP obsoleted the SKEY Mechanism.
"SKEY", an S/KEY mechanism.
"CRAM-MD5", a simple challenge-response scheme based on HMAC-MD5.
"DIGEST-MD5", HTTP Digest compatible challenge-response scheme based upon MD5. DIGEST-MD5 offers a data security layer.
"NTLM", an NT LAN Manager authentication mechanism.
"GSSAPI", for Kerberos V5 authentication via the GSSAPI. GSSAPI offers a data security layer.
A family of SASL mechanisms is planned to support arbitrary GSSAPI mechanisms.
SASL-aware Application Protocols
Application protocols define their representation of SASL exchanges with a profile. A protocol has a service name such as "ldap" in a registry shared with GSSAPI and Kerberos [2]. Protocols currently supporting SASL include BEEP, IMAP, LDAP, POP, SMTP, IMSP, ACAP. and XMPP.
SASL was originally specified in RFC 2222, authored by John Meyers while at Carnegie Mellon University. That document was made obsolete by RFC 4422, edited by Alexey Melnikov and Kurt Zeilenga.
SASL Mechanisms
A SASL mechanism is modelled as a series of challenges and responses. Defined SASL mechanisms [1] include:
"EXTERNAL", where authentication is implicit in the context (e.g., for protocols already using IPsec or TLS)
"ANONYMOUS", for unauthenticated guest access
"PLAIN", a simple cleartext password mechanism. PLAIN obsoleted the LOGIN mechanism.
"OTP", a one-time password mechanism. OTP obsoleted the SKEY Mechanism.
"SKEY", an S/KEY mechanism.
"CRAM-MD5", a simple challenge-response scheme based on HMAC-MD5.
"DIGEST-MD5", HTTP Digest compatible challenge-response scheme based upon MD5. DIGEST-MD5 offers a data security layer.
"NTLM", an NT LAN Manager authentication mechanism.
"GSSAPI", for Kerberos V5 authentication via the GSSAPI. GSSAPI offers a data security layer.
A family of SASL mechanisms is planned to support arbitrary GSSAPI mechanisms.
SASL-aware Application Protocols
Application protocols define their representation of SASL exchanges with a profile. A protocol has a service name such as "ldap" in a registry shared with GSSAPI and Kerberos [2]. Protocols currently supporting SASL include BEEP, IMAP, LDAP, POP, SMTP, IMSP, ACAP. and XMPP.