kitten B. Bucksch Internet-Draft Beonex Intended status: Informational S. Farrell Expires: 4 August 2025 Trinity College Dublin 31 January 2025 SASL Passkey draft-bucksch-sasl-passkey-00 Abstract Introduces a SASL mechanism that allows the user to authenticate using a FIDO2 Passkey. About This Document 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. 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 4 August 2025. Bucksch & Farrell Expires 4 August 2025 [Page 1] Internet-Draft sasl-passkey January 2025 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Creation of the Passkey . . . . . . . . . . . . . . . . . . . 2 2.1. Initial Auth using Passkey . . . . . . . . . . . . . . . 3 3. IMAP Example . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. 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. 2. 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. Bucksch & Farrell Expires 4 August 2025 [Page 2] Internet-Draft sasl-passkey January 2025 2.1. 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: 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. Bucksch & Farrell Expires 4 August 2025 [Page 3] Internet-Draft sasl-passkey January 2025 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. 3. IMAP Example 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. Bucksch & Farrell Expires 4 August 2025 [Page 4] Internet-Draft sasl-passkey January 2025 4. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 5. Security Considerations It's all about security. 6. IANA Considerations 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 Intended usage: COMMON Owner/Change controller: IESG Note: 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Bucksch & Farrell Expires 4 August 2025 [Page 5] Internet-Draft sasl-passkey January 2025 Acknowledgments TODO acknowledge. Authors' Addresses Ben Bucksch Beonex Email: ben.bucksch@beonex.com Stephen Farrell Trinity College Dublin Email: stephen.farrell@cs.tcd.ie Bucksch & Farrell Expires 4 August 2025 [Page 6]