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

[Florian Schmaus <[e-mail]>]

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