IMAP SASL2 Profile

This document specifies an IMAP extension for Extensible Simple Authentication and Security Layer (also known as SASL2). SASL2 itself is based on Simple Authentication and Security Layer . 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 when, and only when, they appear in all capitals, as shown here.

This provides pointers in the order and manner defined in , section 4.

The service name SHALL be "imap", as defined in .

Servers list available mechanisms in the CAPABILITY response or response code. Each mechanism name is prefix with "AUTH=". See .

Clients initiate authentication by issuing the AUTHENTICATE command . Server Challenges and Client Responses are sent as described in . 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 ); 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 ).

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.

The REMEMBERME command 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 ) 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 . Task related data sent by clients and servers as described in . 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 ); 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 , as well as CBINDING command ), plus the TASK command . 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: 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 ]]>

Task mechanism name, OPTIONAL initial response continuation data can be requested 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 ") 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 productions not defined in this document are defined in IMAP4rev2 or . 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.

TBD.