KITTEN online Interim - 17 January 2023

Meetecho (online video): https://meetings.conf.meetecho.com/interim/?short=6011e6f6-2503-40db-b99b-68f88c85a0e9

Proposed agenda: https://datatracker.ietf.org/doc/agenda-interim-2023-kitten-01-kitten-01/

Scribe: Nadja & Rick

Agenda Tops

• SASL2
• SCRAM 2FA
• SASL-HT
• SASL-OPAQUE

SASL2

• Not a meeting for making decisions, mostly informing everybody about progress, making sure people are on the same page & gathering levels of interest

XSF is the main driver of SASL2 so far, related XEPs: XEP-0388 (Extensible SASL profile), XEP-0440 (SASL Channel-Binding Type Capability), XEP-scram-upgrade (not yet published w/ XSF)

XSF SASL2 presentation

Presentator: Matthew Wild

Originally started around 2016-2017, earlier drive by Dave Cridland

XMPP sees primarily deployment of SCRAM-SHA-1, with a few PLAIN.

SASL2 XEP serves as foundation for further extensions e.g. "FAST" and "Bind 2"

Primary changes:
- Allow secondary tasks after authentication using mechanisms, but before auth is "completed" in the wrapping protocol
- Helps negotiating channel binding mechanisms

SASL2 adds a third answer next to auth success and failure: "continue", a.k.a. "do further tasks please"

e.g. MFA could be implemented using a task to transmit an OTP after primary authentication, or do a password update task (e.g. from SCRAM-SHA-1 to SCRAM-SHA-256).

=> TOTP proposed in XEP-0400
=> also implemented at mechanism level (e.g. SCRAM-2FA)

Latest changes change typical challenge-response structure into a bidirection dataflow.
Current draft also uses structured data in the form of XML instead of plain byte arrays, as XML is a good fit for XMPP.

Client Identifiers that are stable for returning clients, usable for diagnostics (which clients are using outdated mechanisms), helps server narrow down what to compare to for e.g. hashed tokens (SASL-HT).

Upgrade tasks: XMPP is stuck with SCRAM-SHA-1, upgrading is difficult. Looking for user-supported ways that are not as brutal as a full password reset for each account. Cooperation of the client is required, i.e. user control/consent is retained.

Channel binding negotiation: XMPP mostly standardized on tls-unique which is not available for TLS-1.3, but since mechanisms do not tell which channel binding mechanisms are available, authentication will fail. XMPP additionally doesn't properly return the SCRAM error message in that case (=> noted by Thilo)

XEP-0474 is an attempt to prevent downgrade attack on channel binding (esp. relevant given negotiation ability above).

Ben Kaduk: Q: Client decides which cb type to use, why is that not enough? A: Client support is spotty, tls-exporter technically works on TLS-1.2, but support is not widespread. Some setups can only provide tls-server-endpoint, which is better than nothing.

Dave Cridland: tls-exporter is appreciated in the XMPP community.
Setups exist in which only tls-server-endpoint is possible (for example if web frontend is used), or none at all, so assumptions like that tend to break often enough.

Dave Cridland: Drafted an idea of taking most of SASL2, and transporting it 'within' the already existing SASL framework. I.e. as custom SASL "meta" mechanism.

Key Derivation in SASL

Presentator: Rick van Rein

SASL usually runs over TLS, which usually uses ECDH(E) which is not quantum hard.

High level idea: use shared secrets that are generated during SASL authentication to harden TLS

Structure in Realm Crossover with SXOVER-PLUS; key establishment with a local domain using a remote (home) domain

Similar system for e.g. VPN, use the SASL shared secret to generate a transport key

Q: Will this not also be solved by TLS becoming quantum-hard? A: Yes, but there's applicability outside of TLS-protected channels

Alexey: I also have another use case: if modern SASL mechanisms such as SCRAM and OPAQUE have key derivation specified, then they can be automatically used with fast reauthentication provided by HT-* mechanisms.

SCRAM-2FA status update

2 mechanisms: TOTP (taken from SASL2), FIDO CTAP1 including support for USB/NFC/BLE tokens

FIDO part specifically could use peer review.

The document also includes a separate extension: reauthentication token, can be used instead of SASL2 for reauthentication tokens for e.g. SASL-HT (should be compatible)

Why do we need SASL Fast Reauthentication?

Reauthentication is a common requirement, especially in mobile context, but also because applications use multiple connections in parallel.

Instead of doing full reauth, use a very fast single round-trip authentication using a safe shared secret.

Rick van Rein: Reauthentication is hard to do well, but HTTP-SASL could benefit immensely from this.

Dave Cridland: The token is high-risk, if attacker gets access to this token they can authenticate freely. It's very important that the token issuing is also combined with a token listing / management available to the user. IIRC ISR in XMPP also allowed tracking which devices are logged in / have session for an user, which is also an advantage for device identifiers as implemented in SASL2.

SASL-HT (Hashed Token) - Fast Reauthentication mechanism

Presentator: Florian Schmaus

Note on Dave's above comment: ISR does not have that but would be very nice

XMPP has very long reconnect delay => extensions like ISR proposed to make connection setup faster

SASL-HT started as part of ISR specification, has now been split out as a separate spec to send to KITTEN WG.

SASL-HT adds simple bearer token, meant to be only a "little bit" better than PLAIN.
It uses HMAC over the bearer token and channel binding data (if any)

ISR (thus design of HT) was written befor TLS-1.3 was standardized. Back then TLS early data looked like a very good use for SASL-HT but since early data requires TLS-PSK you potentially gain little compared to SASL EXTERNAL. But TLS-PSK / early data may not be available all the time, allows fallback on SASL-HT in that case. Benjamin Kaduk adds that TLS-PSK can use newly added keys and keys set on TLS layer by session resumption, it does not have to be static/pre-arranged via sideband mechanism. Early data in TLS is considered part of the application, so it cannot easily be used in a mere authentication mechanism.

XEP ISR did not catch on, new ideas in XEP FAST, which also uses SASL HT.

Next steps

Is there enough interest in the WG for starting a generalized SASL2 draft?

Is there enough interest in the WG for putting SCRAM-2FA on standards track?

• Matthew Wild: 2FA for only SCRAM does not solve the problem for setup that do not / can not use SCRAM.
  => A: Alexey: Work isn't doubled, SASL2 will take quite some time.

• Benjamin Kaduk: SCRAM-2FA is definitely useful, but would like a general 2FA system.

General support for additional interim regarding also OPAQUE, which was dropped due to time constraints.

Some further discussion on SASL-HT was moved to external venue