<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc ipr="trust200902" category="std" docName='draft-melnikov-imap-rememberme-00'>
  <front>
    <title abbrev="IMAP REMEMBERME">
      IMAP REMEMBERME extension for quick reauthentication token generation
    </title>
<!--
    <author initials="I." surname="Somebody" fullname="Someone Somebody">
      <organization></organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
        </postal>
        <email></email>
      </address>
    </author>
-->
    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
      <organization>Isode Ltd</organization>
      <address>
        <postal>
          <street>14 Castle Mews</street>
          <city>Hampton</city>
          <region>Middlesex</region>
          <code>TW12 2NP</code>
          <country>UK</country>
        </postal>
        <email>alexey.melnikov@isode.com</email>
      </address>
    </author>
    <date year="2025"/>
    
    <!--One or more extra keywords which don't appear in the title-->
    <keyword></keyword>
      
    <abstract>

    <t>
      This document specifies an IMAP extension for generating quick
      reauthentication tokens that allow clients to re-login without
      user interaction, once authentication using a strong SASL mechanism
      is completed.
    </t>
	
    </abstract>
    
  </front>
  <middle>

    <section title="Introduction">

        <t>
          This document specifies an IMAP <xref target="RFC9051"/> extension
          which is a protocol specific extension to
          Simple Authentication and Security Layer (SASL) <xref target="RFC4422"/>
          framework for generation of proof-of-posession reauthentication tokens.
          Such tokens can be used for subsequent 1 roundtrip reauthentication
          <!--///Add Informative References-->
          using SASL mechanisms such as REMEMBERME and HT-*.
        </t>

        <t>
        The typical sequence of events is going to be like this:

        <list style='numbers'>

          <t>
          Client establishes IMAP connection protected by TLS on Connection 1.
          </t>
          
          <t>
          On Connection 1 the client authenticates using a strong SASL mechanism, which might be CPU intensive,
          <!--///Add Informative References-->          
          and most likely requires user interaction, e.g., SCRAM with 2FA extension, PASSKEY.
          </t>
          
          <t>
          On Connection 1 the client requests reauthentication token using REMEMBERME command.
          </t>
          
          <t>
          &lt;Connection gets interrupted or closed due to inactivity&gt;
          </t>

          <t>
          Client establishes another IMAP connection protected by TLS on Connection N.
          The client then uses a previous issues quick reauthentication token
          with one of 1 round trip SASL mechanisms such as REMEMBERME and HT-*.
          The same token is reusable on other IMAP connections until it is replaced or revoked.
          </t>

        </list>
      </t>

      <t>
      IMAP servers advertise support for this extension by returning one or more TOKEN=&lt;token-type&gt; capabilities
      in the CAPABILITY response.
      </t>
      
      <!--
      <t>
      ///Add Informative References
      This extension will become a part of IMAP-specific extension for SASL2.
      </t>
      -->
      
    </section>
    
    <section title="Conventions Used in This Document">
      
      <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/>
      when, and only when, they appear in all capitals, as shown here.
      </t>


    </section>

    <section title="REMEMBERME command">

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>Token type</t>

   <t hangText='Responses:'>REQUIRED TOKEN response code</t>

   <t hangText='Result:'>OK - new token successfully issued<vspace/>
               NO - authentication mechanism too week, unrecognized token type<vspace/>
               BAD - command unknown or arguments invalid,<vspace/>
                    invalid state</t>
   </list>
   </t>
            
      <t>
      This command is only allowed in authenticated state.
      </t>

      <t>
      Upon receipt of REMEMBERME command the IMAP server checks that the specified token type
      is recognized and supported. If it is, it generates a new token of the requested type
      and returns it in the TOKEN response code in the tagged OK response.
      </t>

      <artwork name="" type="" align="left" alt="">
        <![CDATA[
  S: * OK ACME IMAP Server v1.23 is ready
  C: 22 CAPABILITY
  S: * CAPABILITY IMAP4rev1 IMAP4rev2 STARTTLS AUTH=PASSKEY AUTH=REMEMBERME AUTH=SCRAM-SHA-256 TOKEN=JWT TOKEN=RANDOM
  S: 22 CAPABILITY completed
  C: 23 STARTTLS
  S: 23 OK Completed
  C: 24 AUTHENTICATE ...
   <SASL exchange>
  S: 24 OK Completed
  C: 25 REMEMBERME JWT
  S: 26 OK [TOKEN <base64-encoded token>] Completed
]]>

      </artwork>

    </section>

    <section title="Formal Syntax">

      <sourcecode type="abnf">
        <![CDATA[
capability     =/ "TOKEN=" token-type
                    ;; <capability> from [RFC3501]

token-type     = atom
                    ;; SHOULD be registered with IANA

resp-text-code      =/ "TOKEN" SP base64-token

base64-token        = base64]]>
      </sourcecode>

    </section>
    
    
    <section title="IANA Considerations">

      <t>TBD. Regeister the IMAP capabilities and create a separate registry of token types.</t>

    </section>

    <section title="Security Considerations" anchor="seccons">

      <t>TBD.</t>

    </section>
    
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?> <!-- Keywords, part 1 -->
      <?rfc include="reference.RFC.8174"?> <!-- Keywords, part 2 -->

      <reference anchor="ABNF">
        <front>
          <title>Augmented BNF for Syntax Specifications: ABNF</title>
          <author initials="D" surname="Crocker" fullname="Dave Crocker" role="editor">
            <organization />
          </author>
          <author initials="P" surname="Overell" fullname="Paul Overell" role="editor">
            <organization />
          </author>
          <date year="2008" month="January"/>
        </front>
        <seriesInfo name="RFC" value="5234" />
        <format type="TXT" target="https://www.rfc-editor.org/info/rfc5234" />
      </reference>

      <?rfc include="reference.RFC.3501"?> <!-- IMAP4rev1 -->
      <?rfc include="reference.RFC.9051"?> <!-- IMAP4rev2 -->
      <?rfc include="reference.RFC.4422"?> <!-- SASL -->

    </references>

<!--    
    <references title="Informative References">
    </references>
-->

<!--
    <section title="Acknowledgements">
	
      <t>Thank you to Steve Kille and David Wilson for suggestions, comments and corrections on this document.</t>

      <t>David Wilson came up with the idea of defining a new Content-Type header field parameter to distinguish
      forwarded messages from inner header field protection constructs.</t>
      
    </section>
-->    
    
  </back>
</rfc>
