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

From: Florian Schmaus <[email-masked]>
Date: Sun, 5 Nov 2017 16:32:24 +0100

On 17.10.2017 15:02, Simo Sorce wrote:
> 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 ...).

I had a look at ldapssotoken. Although I have worked with LDAP in the
past, I wouldn't consider myself an expert. What follows is a short
summary of how I understand ldapssotoken and the differences between
sasl-ht.

The ldapssotoken I-D allows the creation of tokens for different
services which can be relayed by middleware. This enables a SSO
experience without the need of Kerberos. It also specifies a SASL
mechanism which transports the token to the LDAP server for
verification/authentication. Tokens can also be revoked at the LDAP server.

The major difference between ldapssotoken and sasl-ht is that the latter
uses short lived exclusively ephemeral tokens. That is, the token is
immediately revoked after it has been used. IMHO this is a necessary
requirement: For increased security the lifetime of the token should be
as short as possible.

Furthermore SASL HT-* enables mutual authentication of initiator and
responder using channel binding, and therefore it is required that SASL
HT-* is performed over TLS. Mutual authentication is a very desirable
property of an SASL mechanism, especially for one using short lived
tokens for authentication.

Also sasl-ht specifies a SASL mechanism and nothing more. But it can
only be used with an application protocol specific extension like [1]. I
think it is advantageous that those two parts are kept separate.

In summary, while both I-D use tokens, I think they do not try to
achieve the exact same goals.

Therefore I am not sure if it is sensible to merge those two I-Ds into one.

Some unrelated remarks and possibly nits about
draft-wibrown-ldapssotoken-02:
- It talks about authid when it should possibly be authcid?
- Security Strength Factor seems to be nowhere defined in a RFC?

- Florian

1: http://geekplace.eu/xeps/xep-isr-sasl2/xep-isr-sasl2.html

---

From: Florian Schmaus <[email-masked]>
Date: Sun, 12 Nov 2017 10:29:49 +0100

I have just published -03 of draft-schmaus-kitten-sasl-ht, which is now
available online at

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

Besides some minor changes the major ones are:

The incorporation of the requirements of the application specific
extension protocol, which where already stated in the ProtoXEP [1], but
really belong (also) in he HT SASL mechanism.

Describe how (I believe) the Hashed Token SASL mechanism could be used
with TLS 1.3 early data safely.

An attempt to clarify that the used tokens are one time tokens.

The I-D is now in a state where its authors need a mentor or guide on
how we continue from here on. That is obviously why I put PSA into the
cc, but help from other people is, of course, also appreciated. :)

- Florian