[kitten] Re: WG Last Call: draft-ietf-kitten-sasl-ht-02 (Ends 2026-07-10)

[Thilo Molitor <[e-mail]>]

Hi Alexey, hi Simon,

thanks for your detailed review and apologies for my late answer!
I discussed some of these with Florian and this is the outcome:

1.) We'll add support for authzid along the lines of Simon's third variant.
HT-tokens are meant to be used for quick re-authentication after previous 
strong authentication (SCRAM with channel-binding etc.). This can be used as 
building block for session resumption, but it doesn't need to. That means it 
can also be used as a means for quick re-authentication of the authcid user 
while also setting an authzid, subsequently resulting in new session as that 
authzid user.
This is especially useful if the previous strong authentication had something 
like 2FA in place and acting as the authzid user should not trigger the 2FA 
again. Of course the server has to check if the authcid is allowed to use the 
given authzid, just like Simon wrote.

2.) While strong channel-binding and security in general it a worthy goal, it 
doesn't make sense to mandate a strong channel-binding like tls-exporter with 
a MUST, if that means that some software and deployments not being able to 
support this will have to break the I-D/RFC (tls-termination/load-balancers in 
front of an imap/smtp/xmpp server etc. comes immediately to my mind, but there 
may well be others, too).
Therefore we decided to make tls-server-endpoint a MUST while suggesting 
support for tls-exporter using SHOULD and some wording explaining that tls-
exporter is way more secure than tls-server-endpoint and should be preferred 
whenever possible.

This is similar to a discussion we had on this list (thread starting at [1]) 
and the xmpp standards list ~half a year ago (see [2] and [3] for my 
explanation back then or the whole thread around those messages for some more 
context). On that occasion multiple people spoke out against using tls-
exporter as the mandatory-to-implement (and mandatory-to-deploy) minimal 
common channel-binding on this list, too.

3.) The key-value pairs of SCRAM are a very nice mechanism to extend the 
authentication mechanism with optional and mandatory properties needed for the 
authentication. Only that extensibility allowed us to write something like 
XEP-0474 [4] to harden the SASL flow in XMPP against downgrade attacks on the 
channel-binding and/or SASL mechanism (rather than relying on pinning and 
leaving the first authentication unprotected).
The key-value pairs in HT follow a similar pattern and in my discussion with 
Florian we decided to model them more after the SCRAM ones: adding a predefined 
key prefix (e.g. "mandatory-") that forces the client/server to abort 
authentication if present but not understood.
Of course these key-value pairs aren't meant to be used to transport arbitrary 
application data and should be tied to the authentication itself. We will add 
some wording to make that clearer.

-tmolitor

[1] https://mailarchive.ietf.org/arch/msg/kitten/zpesKSHsiuy1RvhPlbSUGajLbKQ/
[2] https://mail.jabber.org/hyperkitty/list/[e-mail]/message/
6RJMUORBJGS2ZNQNFMY44EWP5PJHPZCC/
[3] https://mail.jabber.org/hyperkitty/list/[e-mail]/message/
OTFEHOYYFWVPVPU4HAVNVH2H3KNY3U6K/
[4] https://xmpp.org/extensions/xep-0474.html


Am Freitag, 10. Juli 2026, 12:27:29 CEST schrieb Florian Schmaus:
> Hi Alexey,
> 
> Thanks for your feedback. Much appreciated.
> 
> On 26/06/2026 18.03, Alexey Melnikov wrote:
> 
> >> ISSUE: Key/value pairs
> >>
> >>
> >>
> >> What is the actual intended use of this mechanism?  How is support for a
> >> particular key type intended to be communicated?  Could a peer refuse
> >> authentication if it didn't understand a key/value pair?  Is it possible
> >> to express that a key/value pair is MANDATORY or OPTIONAL?  The entire
> >> method seems underspecified to me, compare what SCRAM says about its
> >> similar fields.
> > 
> > 
> > I am a bit concerned about this feature as well. SCRAM optional/ 
> > mandatory attributes were not supposed to be a mechanism for shuttling 
> > arbitrary extra application data in SASL exchange.
> > 
> > Also, if KITTEN WG decides that having such a facility is a good thing, 
> > we should have it as a generic SASL2 requirement, as otherwise we are 
> > breaking SASL interface isolation guarantees between application 
> > protocols and SASL mechanism. I.e., with the exception of legacy SASL 
> > mechanisms, most features should be available in most of them, not just 
> > in 1 of them.
> > 
> > I am not dead against this feature in HT2, but I think I need a bit of 
> > convincing. And as you say, tightening scope and applicability of this 
> > feature would be good.
> 
> I think there are two distinct aspects here: the scope of the key/value 
> data, and how it applies to SASL2.
> 
> Our motivation for this feature was strictly related to authentication 
> security, specifically SASL SCRAM downgrade protection (XEP-0474). 
> Because HT is a fast resumption mechanism, we needed a way for peers to 
> cryptographically verify the initially offered SASL mechanisms and 
> channel-binding types to ensure a MITM attacker didn't force a downgrade.
> 
> Since downgrade protection is a SASL security concern, placing it inside 
> the HT mechanism's envelope felt appropriate. That said, I hear your 
> point that framing this as "arbitrary key/value pairs" leaves the door 
> open too wide.
> 
> I completely understand the need to maintain SASL interface isolation, 
> but out of curiosity, and to help my understanding of the architecture, 
> could you elaborate a bit on the dangers of allowing arbitrary but 
> authenticated data to piggyback on the SASL exchange? My initial thought 
> was that since extension points, like the one we used for downgrade 
> protection, proved so valuable, leaving the field generic might be 
> beneficial for unforeseen future use cases. I would love to hear your 
> perspective on exactly where that boundary should be drawn between a 
> valid security extension and a layering violation.
> 
> Regardless of that theoretical boundary, I completely agree with your 
> second point: if we want a generic data facility, it belongs in SASL2, 
> not hidden inside a single mechanism.
> 
> Given that, how would you prefer to handle this in the current HT draft? 
> We could rename the "arbitrary key/value pairs" to something strictly 
> scoped, like "Authentication Security Extensions," and add normative 
> language explicitly forbidding application-layer data. Does that 
> sufficiently tighten the scope for you, or how would you prefer we proceed?
> 
> - Florian