| Internet-Draft | IMAP SASL2 Profile | July 2026 |
| Melnikov | Expires 1 February 2027 | [Page] |
This document specifies an IMAP extension for SASL2 authentication, which extends IMAP SASL (RFC 4422) Profile.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document specifies an IMAP [RFC9051] extension for Extensible Simple Authentication and Security Layer [SASL2] (also known as SASL2). SASL2 itself is based on Simple Authentication and Security Layer [RFC4422]. This document specified SASL2 protocol profile, i.e. it specifies how different SASL2 commands, responses and capabilities are expressed as an IMAP extension.¶
The IMAP CAPABILITY name for this extension is "SASL2". The extension includes CBINDING command and response, TASK command, REMEMBERME command, TOKEN response code, CONTINUE response code.¶
[[Do we need to enable SASL2 with "ENABLE SASL2", so that the server can return CONTINUE response code and know that the client can handle it correctly?]]¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This provides pointers in the order and manner defined in [RFC4422], section 4.¶
Servers list available mechanisms in the CAPABILITY response or response code. Each mechanism name is prefix with "AUTH=". See [RFC9051].¶
Clients initiate authentication by issuing the AUTHENTICATE command [RFC9051].¶
Server Challenges and Client Responses are sent as described in [RFC9051].¶
Authentication may complete in one of three ways. It may fail by server returning tagged NO or BAD response, in which case the client is not authenticated and the session state remain entirely unchanged. It may complete successfully by returning a tagged OK response that either doesn't include any response code or includes a response code different from the CONTINUE response code (see Section 4); in which case the client is authenticated. Finally, it may have completed successfully, but further interaction is required - for example, a password change or second-factor authentication. In the latter case the server returns tagged OK response with CONTINUE response code. (Note that the CONTINUE response code is a new feature in this document, but otherwise the behaviour of AUTHENTICATE command is unchanged from [RFC9051]).¶
Clients MAY abort unilaterally at any time before the authentication completed by sending an a line containing a single * character (i.e. * CR LF).¶
Servers MAY abort uniliterally by sending tagged NO or BAD response to AUTHENTICATE command.¶
Security Layers take effect after the SASL mechanism itself (ie, the first negotiation) has completed successfully, after the final octet of the server's tagged OK response (with or without the CONTINUE response code).¶
Option (a) is used - any SASL Security Layer is applied first to data being sent, and TLS applied last.¶
Unless changed by another IMAP extension, IMAP profile of SASL2 doesn't allow multiple authentications on the same TCP connection. Once a client is successfully authenticated on a connection (by server returning tagged OK response to AUTHENTICATE with or without CONTINUE response code), all subsequent authentication attempts MUST fail.¶
Although the CONTINUE concept does use tasks analogous to multiple SASL authentication sequences, only the first SASL mechanism used is considered an authentication, and only the first can negotiate a security layer.¶
List of channel bindings supported by the server can be retrieved by issuing CBINDING command. Available channel bindings are returned in the CBINDING response.¶
The CBINDING command is available in all states.¶
S: * OK ACME IMAP Server v1.23 is ready C: 22 CAPABILITY S: * CAPABILITY IMAP4rev1 IMAP4rev2 STARTTLS AUTH=REMEMBERME AUTH=SCRAM-SHA-256 TOKEN=JWT S: 22 CAPABILITY completed C: 23 STARTTLS S: 23 OK Completed C: 24 CBINDING S: * CBINDING tls-exporter tls-server-end-point S: 24 OK Completed¶
The REMEMBERME command [IMAP-REMEMBERME] is used for generating/retrieving quick reauthentication tokens. List of available tokens in returned in the CAPABILITY response/response code, prefixed with "TOKEN=".¶
Available Tasks are listed in CONTINUE response code (see Section 4) in an OK response of an AUTHENTICATE or TASK command. It is not currently possible to list all available tasks before starting authentication. [[Do we need a mechanism similar to CAPABILITY response to allow for this??]]¶
Clients initiate execution of a task by issuing the TASK command Section 5.¶
Task related data sent by clients and servers as described in Section 5.¶
Task may complete in one of three ways. It may fail by server returning tagged NO or BAD response, in which case the client is not authenticated and the session state remain entirely unchanged (i.e. in half-authenticated state). It may complete successfully by returning a tagged OK response that either doesn't include any response code or includes a response code different from the CONTINUE response code (see Section 4); in which case the client is authenticated. Finally, it may have completed successfully, but further interaction is required - for example, a password change or second-factor authentication. In the latter case the server returns tagged OK response with CONTINUE response code.¶
If the server returns tagged OK with CONTINUE response code, this means that the user is in half-authenticated IMAP state. In this state the only allowed commands are commands allowed in all IMAP states (see Section 6.1 of [RFC9051], as well as CBINDING command Section 3.8), plus the TASK command Section 5.¶
The most recent CONTINUE response code value lists possible choices for available tasks to complete. Once a task is completed successfully, it might advertise further possible tasks in the subsequent CONTINUE response code.¶
Once there are no more tasks to complete, the server returns tagged OK response without a CONTINUE response code. The server MAY include a CAPABILITY response code in the tagged OK response of a successful TASK command in order to send capabilities automatically. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities. The server MAY advertise different capabilities after a successful TASK command.¶
S: * OK ACME IMAP Server v1.23 is ready C: 22 CAPABILITY S: * CAPABILITY IMAP4rev1 IMAP4rev2 STARTTLS SASL2 AUTH=REMEMBERME AUTH=SCRAM-SHA-256 TOKEN=JWT S: 22 CAPABILITY completed C: 23 STARTTLS S: 23 OK Completed C: 24 AUTHENTICATE SCRAM-SHA-256 <SCRAM-SHA-256 SASL exchange...> S: 24 OK [CONTINUE TOTP-EXAMPLE HOTP-EXAMPLE] Please complete an extra 2FA task C: 25 TASK TOTP-EXAMPLE SSd2ZSBydW4gb3V0IG9mIGlkZWFzIGhlcmUu S: + 94d27acffa2e99a42ba7786162a9e73e7ab17b9d C: OTRkMjdhY2ZmYTJlOTlhNDJiYTc3ODYxNjJhOWU3M2U3YWIxN2I5ZAo= S: SGFkIHlvdSBnb2luZywgdGhlcmUsIGRpZG4ndCBJPw== S: 25 OK [CAPABILITY IMAP4rev1 IMAP4rev2 CONDSTORE] Finally Authenticated¶
OK - task completed, now in authenticated state¶
NO - task failure: unsupported task mechanism, credentials rejected¶
BAD - command unknown or arguments invalid,¶
invalid state, task exchange canceled¶
This command is only valid in half-authenticated state.¶
The TASK command indicates a task mechanism to the server. If the server supports the requested task mechanism, it performs a task protocol exchange to authenticate and identify the client. If the requested task mechanism is not supported, the server SHOULD reject the TASK command by sending a tagged NO response.¶
The TASK command supports the optional "initial response" feature. The client MUST use it if the client sends data first for the specified task.¶
The task protocol exchange consists of a series of task server challenges and task client responses that are specific to the task mechanism. A server challenge consists of a command continuation request response with the "+" token followed by a base64-encoded (see Section 4 of [RFC4648]") string. The client response consists of a single line consisting of a base64-encoded string. If the client wishes to cancel a task exchange, it issues a line consisting of a single "*". If the server receives such a response, or if it receives an invalid base64 string (e.g., characters outside the base64 alphabet or non-terminal "="), it MUST reject the TASK command by sending a tagged BAD response.¶
As with any other client response, the initial response MUST be encoded as base64. It also MUST be transmitted outside of a quoted string or literal. To send a zero-length initial response, the client MUST send a single pad character ("="). This indicates that the response is present, but it is a zero-length string.¶
When decoding the base64 data in the initial response, decoding errors MUST be treated as in any normal TASK client response, i.e., with a tagged BAD response. In particular, the server should check for any characters not explicitly allowed by the base64 alphabet, as well as any sequence of base64 characters that contains the pad character ('=') anywhere other than the end of the string (e.g., "=AAA" and "AAA=BBB" are not allowed).¶
If the client uses an initial response with a task mechanism that does not support an initial response, the server MUST reject the command with a tagged BAD response.¶
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. ABNF productions not defined in this document are defined in IMAP4rev2 or [IMAP-REMEMBERME].¶
capability =/ "SASL2"
;; <capability> from [RFC9051]
resp-text-code =/ "CONTINUE" SP list-of-tasks
list-of-tasks = task-name *(SP task-name)
task-name = atom
; Precise syntax specified in SASL2
c-binding-name = atom
¶
[[TBD: add ABNF for TASK and channel-binding advertisement]]¶
TBD. Register the new IMAP capability and new response codes.¶