Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT)

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 15 Oct 2017 21:51:17 -0500

On Fri, Sep 29, 2017 at 11:08:10AM +0200, Florian Schmaus wrote:
> I would like to note the existence of draft-schmaus-kitten-sasl-ht-01:
> 
> https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-01

Thanks, I just got a chance to look it over.

[...]

> Thus we initially authenticate an XMPP session using a strong mechanism
> like SCRAM, but at resumption-time we want a single round trip
> mechanism. The basic idea of such a mechanism is that the client
> requests a short-lived, exclusively ephemeral token after being
> authenticated, which can be used to authenticate the resumption in an
> efficient manner.
[...]
> The SASL HT-* mechanism outlined is attempting to provide a reasonably
> secure authentication based around a token obtained over the application
> protocol, in a single round-trip. This single-round-trip is a key
> requirement. The proposal uses a single-use token as a shared secret,
> provides channel binding and mutual authentication.

There does seem to be some value in having a fast "session resumption"
SASL mechanism to avoid repeated reauthentication (though presumably there
should be some guidance to periodically require a full authentication;
various flows elsewhere do this on a month timescale, roughly).
It's a little unfortunate that this ends up requiring TLS for confidentiality
(as there is some desire to have standalone mechanisms), but that seems
to be an acceptable tradeoff for this sort of application.

Putting my kitten WG chair hat on for a moment, it does seem like this work
would be in scope with our current charter
(https://datatracker.ietf.org/doc/charter-ietf-kitten/), which gives us
a pretty wide berth for giving "guidance for any new SASL-related
submissions".  That said, it is not really appropriate for us to accept
new work without a critical mass of people willing to participate/review
that work.  This document seems simple and straightforward enough that
it would not take too much work to get it ready, but we would need
to find a couple more people who are willing to review it before we
could adopt it as a WG document.  (Noting the standards@xmpp cc, I'll
explictly state that since participation in IETF working groups is
entirely open, so there is no requirement of having previously been
a WG participant for this purpose.)

Without my chair hat, the document is a little rough in some places,
but it should be pretty straightforward to clean up.  I do appreciate
the reference to RFC 6919 in particular, but it should really only be
cited by other "April 1st" RFCs.

-Ben

---

From: Sam Whited <[email-masked]>
Date: Mon, 16 Oct 2017 10:21:30 -0500

On Sun, Oct 15, 2017, at 21:51, Benjamin Kaduk wrote:
> That said, it is not really appropriate for us to accept
> that work.

I have an interest in implementing this and can commit to reviewing this
document and providing feedback as new versions are released.

—Sam

---

From: Florian Schmaus <[email-masked]>
Date: Tue, 17 Oct 2017 10:19:00 +0200

> Thanks, I just got a chance to look it over.

Much appreciated, thank you. :)

> various flows elsewhere do this on a month timescale, roughly).

Good point. I'll write down some recommendations.

> to be an acceptable tradeoff for this sort of application.

Yes, I think TLS is a requirement to achieve what HT-* tries to achieve
in a secure fashion.

> cited by other "April 1st" RFCs.

I don't remember explicit putting it there, so it is likely a leftover
from the I-D template [1] I've used. Err, I mean it put it there to test
if someone actually reads it. You have passed. :) I've removed the
reference in 02-SNAPSHOT [2].

One important point regarding SASL HT-* I'd like to discuss and hope to
get some insights from such a discussion is, if (and how) we should
combine it with TLS 1.3 early data.

It would be theoretically possible to exploit TLS 1.3 early data for 1
round trip session resumption. The current version of the I-D stays
defensive and forbids the usage of TLS 1.3 early data. However if the
early data *only* contains the HT-* initiator-msg and potential SASL
profile framing of the application protocol, and nothing else, then it
should be safe as far as I can tell. If that is the case, then I really
feel tempted to make use of it.

I'm happy to hear everyone's thoughts on this.

- Florian

1:
https://github.com/miekg/mmark/blob/master/rfc/rfc7511.md#conventions-and-terminology
2:
http://geekplace.eu/xeps/draft-schmaus-kitten-sasl-ht/draft-schmaus-kitten-sasl-ht-02.html

---

From: Simo Sorce <[email-masked]>
Date: Tue, 17 Oct 2017 09:02:17 -0400

On Sun, 2017-10-15 at 21:51 -0500, Benjamin Kaduk wrote:
> There does seem to be some value in having a fast "session
> resumption" SASL mechanism to avoid repeated reauthentication (though
> presumably there should be some guidance to periodically require a
> full authentication; various flows elsewhere do this on a month
> timescale, roughly).
> It's a little unfortunate that this ends up requiring TLS for
> confidentiality (as there is some desire to have standalone
> mechanisms), but that seems to be an acceptable tradeoff for this
> sort of application.

I think this draft has many goals in common with this one:
https://tools.ietf.org/html/draft-wibrown-ldapssotoken-02

I wonder if we can end up having a solution that will work well to
cover it all ?

The main issue here would be the requirement to bind it to TLS as LDAP
(as well as other connection-oriented protocols) can use other means to
encrypt the channel (namely GSSAPI, although GSSAPI doe not have a
session resumption mechanism ...).

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

---

From: Sam Whited <[email-masked]>
Date: Tue, 17 Oct 2017 09:08:51 -0500

> https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-01

After a quick read through of the latest draft, the only thing I found
which I wasn't sure about was the following:

> Before sending the authentication identity string the initiator SHOULD
> prepare the data with the UsernameCaseMapped profile of [RFC7613].

This limits the SASL mechanisms usefulness to Unicode encodings. I'd
suggest that normalizing the username is something the application
protocol should do, it should not be required by the authentication
framework (as far as SASL is concerned these should just be bytes).

—Sam

P.S. Also note that 7613 was recently replaced by RFC 8265, if this
reference is kept it may be good to update it.

---

From: Florian Schmaus <[email-masked]>
Date: Tue, 17 Oct 2017 18:20:39 +0200

> framework (as far as SASL is concerned these should just be bytes).

I am not sure about that. SCRAM has the same requirement.

> reference is kept it may be good to update it.

Thanks. Updated in 02-SNAPSHOT. I also note that
https://tools.ietf.org/html/rfc7613 does not show a sign that the RFC
has been obsoleted. Maybe someone should ping Peter. :)

- Florian

---

From: Florian Schmaus <[email-masked]>
Date: Tue, 17 Oct 2017 18:23:26 +0200

> I wonder if we can end up having a solution that will work well to

Thanks for point this out. I'll have a look at
draft-wibrown-ldapssotoken-02 and get back to you.

- Florian

---

From: Sam Whited <[email-masked]>
Date: Tue, 17 Oct 2017 11:28:13 -0500

> I am not sure about that. SCRAM has the same requirement.

I'd forgotten that. That doesn't seem like a good reason to do it here
though. I ignore this requirement in my SCRAM implementation as well.

What if I have an application protocol that does its normalization using
a different system that's incompatible with PRECIS, or doesn't use
Unicode (in China I've been told that there's another system that's
widely used)? Or what if the username in a particular system is
something like an email or JID that may already apply multiple profiles
(usernamecasemapped to the localpart, IDNA2008 style normalization to
the domainpart), do we really want to apply usernamecasemapped again on
top of the existing application applied profiles?

—Sam

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 17 Oct 2017 17:57:00 +0100

Hi Sam,

On 17/10/2017 15:08, Sam Whited wrote:

> This limits the SASL mechanisms usefulness to Unicode encodings.
I think use of Unicode, in particular UTF-8 is the right thing. Other 
character sets can be mapped to UTF-8.

Normalization to disallow problematic characters is a good thing, so I 
think a SHOULD level requirement is appropriate. But I am not sure that 
case-mapped version of UserName profile is the right thing here.
>   I'd
+1.

---

From: Sam Whited <[email-masked]>
Date: Tue, 17 Oct 2017 12:01:25 -0500

> case-mapped version of UserName profile is the right thing here.

I agree, I just don't think this needs to be part of the authentication
framework. It should already be handled by the application level
protocol. Ex. RFC 7622 already defines how XMPP normalizes usernames, so
why should this mandate that we run that step again?

Also, what if a system wants to use UsernameCasePreserved but this
mechanism uses UsernameCaseMapped (or visa versa), the SASL mechanism
would be breaking that profile. Even if we change to username case
preserved (which I think is more correct than case mapped in this case,
FWIW) what if the application using this profile specifically allows
characters in usernames that aren't allowed by the identifier class of
PRECIS? We shouldn't be making that decision for people.

—Sam

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Oct 2017 17:20:21 -0500

> has been obsoleted. Maybe someone should ping Peter. :)

More likely a matter for [email-masked], with a cached copy
of the old document not getting regenerated after its status changed.

-Ben

---

From: Florian Schmaus <[email-masked]>
Date: Wed, 18 Oct 2017 08:54:50 +0200

> case-mapped version of UserName profile is the right thing here.

Good point. Since SASLprep also preserves the case, I switched to
UsernameCasePreserved in 02-SNAPSHOT.

- Florian

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Oct 2017 11:13:40 +0100

> of the old document not getting regenerated after its status changed.
You should email Henrik Levkowetz <[email-masked]>, as 
tools.ietf.org is the server he maintains.