| Internet-Draft | sasl-passkey | January 2025 |
| Bucksch & Farrell | Expires 4 August 2025 | [Page] |
Introduces a SASL mechanism that allows the user to authenticate using a FIDO2 Passkey.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-bucksch-sasl-passkey/.¶
Discussion of this document takes place on the kitten Working Group mailing list (mailto:kitten@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/kitten/. Subscribe at https://www.ietf.org/mailman/listinfo/kitten/.¶
Source for this draft and an issue tracker can be found at https://github.com/benbucksch/sasl-passkey.¶
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 4 August 2025.¶
Copyright (c) 2025 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.¶
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.¶
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.¶
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.¶
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:¶
passkey-client-step1 = authentication_id authentication_id = 1*OCTET¶
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.¶
server-final-message = server-error "," server-error-message
; Only returned on error. Omitted on success.
server-error = "e=" server-error-value
server-error-value = "invalid-encoding" /
"unknown-user" /
"invalid-username-encoding" /
; invalid username encoding (invalid UTF-8 or
; SASLprep failed)
"other-error" /
server-error-value-ext
; Unrecognized errors should be treated as "other-error".
; In order to prevent information disclosure, the server
; may substitute the real reason with "other-error".
server-error-value-ext = value
; Additional error reasons added by extensions
; to this document.
server-error-message = "m=" server-error-message-value
server-error-message-value = 1*OCTET
; Human readable error message in UTF-8
¶
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.¶
In IMAP, the exchange would be:¶
S: * OK ACME IMAP Server v1.23 is ready C: 22 CAPABILITY S: 22 CAPABILITY IMAP4rev1 IMAP4rev2 AUTH=PASSKEY AUTH=REMEMBERME C: 23 AUTHENTICATE PASSKEY eW91QGV4YW1wbGUuY29tCg== S: AEC6576576557=== (passkey challenge) C: EAB675757GJvYgB== (passkey response) S: 23 OK AUTHENTICATE completed¶
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.¶
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.¶
It's all about security.¶
IANA is requested to add the following entry to the SASL Mechanism registry established by [RFC4422]:¶
To: iana@iana.org
Subject: Registration of a new SASL mechanism PASSKEY
SASL mechanism name (or prefix for the family): PASSKEY
Security considerations: Section YY of [RFCXXXX]
Published specification (optional, recommended): [RFCXXXX]
Person & email address to contact for further information:
IETF Kitten WG <kitten@ietf.org>
Intended usage: COMMON
Owner/Change controller: IESG <iesg@ietf.org>
Note:
¶
TODO acknowledge.¶