IMAP SASL2 Profile
draft-melnikov-imap-sasl2-profile-00

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
      <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

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"
                       ;; <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]]

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,
              <https://www.rfc-editor.org/info/rfc5234>.

   [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, <https://www.ietf.org/archive/id/draft-melnikov-
              imap-rememberme-01.txt>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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,
              <https://www.rfc-editor.org/info/rfc3501>.

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422,
              DOI 10.17487/RFC4422, June 2006,
              <https://www.rfc-editor.org/info/rfc4422>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9051]  Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
              Access Protocol (IMAP) - Version 4rev2", RFC 9051,
              DOI 10.17487/RFC9051, August 2021,
              <https://www.rfc-editor.org/info/rfc9051>.

   [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, <https://www.ietf.org/archive/id/
              draft-melnikov-sasl2-03.txt>.

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,
              <https://www.ietf.org/archive/id/draft-ietf-kitten-sasl-
              ht-02.txt>.

   [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,
              <https://www.ietf.org/archive/id/draft-ietf-kitten-sasl-
              rememberme-00.txt>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

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]