Network Working Group A. Melnikov Internet-Draft Isode Ltd Intended status: Standards Track 31 July 2026 Expires: 1 February 2027 IMAP SASL2 Profile draft-melnikov-imap-sasl2-profile-00 Abstract This document specifies an IMAP extension for SASL2 authentication, which extends IMAP SASL (RFC 4422) Profile. Status of This Memo 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 Notice 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. Melnikov Expires 1 February 2027 [Page 1] Internet-Draft IMAP SASL2 Profile July 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Extended SASL Profile Definition . . . . . . . . . . . . . . 3 3.1. Service Name . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Mechanism negotiation . . . . . . . . . . . . . . . . . . 3 3.3. Message Definitions for authentication . . . . . . . . . 3 3.4. Aborting . . . . . . . . . . . . . . . . . . . . . . . . 4 3.5. Security Layer Effect . . . . . . . . . . . . . . . . . . 4 3.6. Security Layer Order . . . . . . . . . . . . . . . . . . 4 3.7. Multiple Authentications . . . . . . . . . . . . . . . . 4 3.8. Advertising list of Channel Bindings . . . . . . . . . . 4 3.9. Generating reauthentication tokens . . . . . . . . . . . 5 3.10. Task negotiation facility . . . . . . . . . . . . . . . . 5 3.11. Messages necessary for executing Tasks . . . . . . . . . 5 4. CONTINUE - task required to complete authentication . . . . . 6 5. TASK command . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction 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?]] Melnikov Expires 1 February 2027 [Page 2] Internet-Draft IMAP SASL2 Profile July 2026 2. Conventions Used in This Document 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. 3. Extended SASL Profile Definition This provides pointers in the order and manner defined in [RFC4422], section 4. 3.1. Service Name The service name SHALL be "imap", as defined in [RFC9051]. 3.2. Mechanism negotiation Servers list available mechanisms in the CAPABILITY response or response code. Each mechanism name is prefix with "AUTH=". See [RFC9051]. 3.3. Message Definitions for authentication 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]). Melnikov Expires 1 February 2027 [Page 3] Internet-Draft IMAP SASL2 Profile July 2026 3.4. Aborting 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. 3.5. Security Layer Effect 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). 3.6. Security Layer Order Option (a) is used - any SASL Security Layer is applied first to data being sent, and TLS applied last. 3.7. Multiple Authentications 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. 3.8. Advertising list of Channel Bindings 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. Melnikov Expires 1 February 2027 [Page 4] Internet-Draft IMAP SASL2 Profile July 2026 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 3.9. Generating reauthentication tokens 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=". 3.10. Task negotiation facility 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??]] 3.11. Messages necessary for executing Tasks 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. Melnikov Expires 1 February 2027 [Page 5] Internet-Draft IMAP SASL2 Profile July 2026 4. CONTINUE - task required to complete authentication 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 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 5. TASK command Arguments: Task mechanism name, OPTIONAL initial response Responses: continuation data can be requested Result: OK - task completed, now in authenticated state Melnikov Expires 1 February 2027 [Page 6] Internet-Draft IMAP SASL2 Profile July 2026 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. Melnikov Expires 1 February 2027 [Page 7] Internet-Draft IMAP SASL2 Profile July 2026 6. Formal Syntax 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" ;; 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]] 7. IANA Considerations TBD. Register the new IMAP capability and new response codes. 8. Security Considerations TBD. 9. References 9.1. Normative References [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008, . [IMAP-REMEMBERME] Melnikov, A., "IMAP REMEMBERME extension for quick reauthentication token generation", Work in Progress, Internet-Draft, draft-melnikov-imap-rememberme-01, 31 July 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Melnikov Expires 1 February 2027 [Page 8] Internet-Draft IMAP SASL2 Profile July 2026 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, . [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message Access Protocol (IMAP) - Version 4rev2", RFC 9051, DOI 10.17487/RFC9051, August 2021, . [SASL2] Cridland, D., Molitor, T., Wild, M., and A. Melnikov, "Extensible Simple Authentication and Security Layer (SASL)", Work in Progress, Internet-Draft, draft-melnikov- sasl2-03, 31 July 2026, . 9.2. Informative References [draft-ietf-kitten-sasl-ht] Schmaus, F., Molitor, T., and C. Egger, "The Hashed Token SASL Mechanism", Work in Progress, Internet-Draft, draft- ietf-kitten-sasl-ht-02, 22 June 2026, . [draft-ietf-kitten-sasl-rememberme] Bucksch, B. and S. Farrell, "SASL Remember Me", Work in Progress, Internet-Draft, draft-ietf-kitten-sasl- rememberme-00, 28 February 2025, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . Melnikov Expires 1 February 2027 [Page 9] Internet-Draft IMAP SASL2 Profile July 2026 Author's Address Alexey Melnikov Isode Ltd 14 Castle Mews Hampton TW12 2NP United Kingdom Email: alexey.melnikov@isode.com Melnikov Expires 1 February 2027 [Page 10]