]> Beonex

ben.bucksch@beonex.com

Trinity College Dublin

stephen.farrell@cs.tcd.ie

AREA kitten sasl passkey login authentication Introduces a SASL mechanism that allows the user to authenticate using a FIDO2 Passkey. About This Document The latest revision of this draft can be found at . 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 Introduces a SASL mechanism that allows the user to authenticate using a FIDO2 Passkey. The client/server exchange is a simple challenge-response mechanism, using the same mechanism that browsers use when they authenticate using Passkeys to a website.

Creation of the Passkey The Passkey has to be created on the user's device via other means. Signup and passkey creation happens, for example, at the normal web frontend of the site. We assume that the browser will use the same authenticator (OS functions) as the authenticating application. The authenticator is responsible for creating and storing the Passkey. The authenticator may also sync the Passkey between the user's devices. The Passkey is never seen by either browser nor the authenticating application, but managed entirely by the Passkey manager.

Initial Auth using Passkey

1. The authenticating application has the target server hostname and authentication identity (e.g. username or email address) configured. If the target server is an IMAP server, the username is the email address. If the target server is an XMPP server, the username is the XMPP address of the user.
2. The authenticating application opens (or reuses existing) connection to the target server and starts authentication using the SASL PASSKEY mechanism. PASSKEY mechanism starts with the client sending the initial client response, which has the following format defined using ABNF:

3. a. The server generates a Passkey challenge, based on the target server hostname, authentication identity, and Passkey of the user, and sends the server challenge with to the client. b. If login for that user is forbidden, the server will return a SASL error. A human-readable error message for end users must be included, with a detailed and helpful description of why login is forbidden for that user, and instructions for the user how the situation can be remedied. 4. The authenticating application takes the challenge and passes it on as-is to the OS authenticator API, which returns the response. The OS calls are the same that the web browser would do. As part of this process, the OS authenticator API may require the end user to complete additional authentication, for example entering a device unlock code, providing a fingerprint, face recognition, or similar. This is the responsibility of the OS authenticator and outside the scope of this protocol. The authenticating application then passes on the response as-is to the server. 5. a. If the server accepts the response as valid and allows login, it responds with a SASL success response. The user is logged in. b. If the response is invalid, the server responds with a SASL error and a human-readable error message for the end user. This SASL mechanims will typically be combined with SASL chain or SASL2, to allow re-opening a new connection without requiring the user to go through Passkey authentication again.

IMAP Example In IMAP, the exchange would be: Where "eW91QGV4YW1wbGUuY29tCg==" is base64-encoded authentication identity ("you@example.com"), "AEC6576576557===" is base64-encoded passkey challenge, "EAB675757GJvYgB==" is base64-encoded passkey response. All challenge and responses values are base64-encoded according to the IMAP SASL protocol profile.

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 It's all about security.

IANA Considerations IANA is requested to add the following entry 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.