]> Beonex

ben.bucksch@beonex.com

Trinity College Dublin

stephen.farrell@cs.tcd.ie

AREA kitten sasl rememberme login authentication Introduces a SASL mechanism that allows the application to stay logged in and re-login without user interaction, after completing a time-consuming SASL login mechanism that involves the user. About This Document Status information for this document may be found at . Discussion of this document takes place on the kitten Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction A client application might at first log in to a server using Passkey or multi-factor authentication. However, these mechanisms require complicated user interaction. These are too costly to perform at every login. They can realistically only be completed once during setup. To stay logged in, this SASL mechanism allows the server to create a client-specific token that the client application can then use to log in to the same account, without further user interaction. The token is opaque to the client and the server can choose how to implement it. It may be a custom random string that the server stores, or an application-specific password generated for this client together with the username, or a JWT token, or a refresh token which does not expire.

Creation of the token The client requests the token from the server using either 1. application-specific commands, like IMAP REMEMBERME, which are to be defined in other standards. 2. the success response of another SASL mechanism. The client stores the token, instead of a password, in a client-specific storage that is as secure as a password storage.

Login using the token If the client needs to log in and has a token for this user and host, uses the SASL REMEMBERME mechanism to log in. REMEMBERME mechanism starts with the client sending the initial client response, which has the following format defined using ABNF: If the server accepts the response as valid and allows login, it responds with a SASL success response. The user is logged in. (ALTERNATIVE EXPIRY: .... it responds with a SASL success response, a new token, and the expiry time of the new token. The user is logged in. To avoid race conditions in clients that open multiple connections at the same time, the previously used token MUST be valid for at least 30 more seconds. Likewise, if the server returned a new token, then it must return the same new token in response to the same old token for the next 1 hour. Reason: If the client opens 5 connections at the same time, using the same token, but the server were to respond with 5 different new tokens, and it were to allow only 1 of them, then the client would not know which one to store, due to race conditions in the network response.) If the response is invalid, the server responds with a SASL error and a human-readable error message for the end user.

IMAP Example In IMAP, the exchange would be: In the above example the token is "AEC6576576557" which is base64-encoded according to IMAP SASL profile.

Requirements on the token

1. The token MUST also allow the server to infer the authentication identity (e.g. username or email address). The token alone must be sufficient to log in. This SASL mechanism doesn't support separate authorization identities.
2. The token MUST NOT expire. (ALTERNATIVE EXPIRY: The token MUST be valid for at least 30 days.)
3. The server SHOULD be able to revoke the tokens, in case this specific user account or device was compromised. In this case, the authentication MUST fail and the SASL error message MUST explain the situation to the user and give instructions how to remedy the situation.

Conventions and Definitions 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.

Security Considerations Clients should treat the token like a password and store it securely. TODO Security

IANA Considerations IANA is requested to add the following entries to the SASL Mechanism registry established by : Intended usage: COMMON Owner/Change controller: IESG Note: ]]>

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism. This document obsoletes RFC 2222. [STANDARDS-TRACK]

Acknowledgments TODO acknowledge.