Re: [OATH-Toolkit-help] dynalogin, HOTP and SASL

[Simon Josefsson]

Daniel Pocock <address@hidden> writes:

> I've just been contemplating how to make dynalogin more useful
>
> The current implementation only includes the test binary and an adapted
> version of phpMyId (an OpenID provider)
>
> One idea that comes to mind: SASL.  Should HOTP be provided through the
> PLAIN mechanism, or through some new mechanism (similar to the SECURID
> mechanism)?
>
> My understanding of PLAIN is that it is only intended for credentials
> with a long lifespan, although if HOTP was supported with it's own
> mechanism, then apps that only know PLAIN would not work at all.
>
> I believe that if it works with SASL, then it will also become usable
> from LDAP, and then it will work for anything that does LDAP (including
> various OpenID providers, Apache basic auth, etc)

Hi Daniel!

I believe adding SASL support would be a great improvement.  Two factor
authentication is important for sending/receiving email and also for
Jabber.  Today the alternatives to get two factor via SASL are Kerberos
or OpenID/SAML but both are complex and all involved protocols required
for two-factor authentication are not widely implemented.

Using PLAIN requires no changes on the wire, but I think it will work
fairly poorly in practice: most clients cache the password and some even
open multiple connections, all based on that cached password.  It is
likely to lead to many authentication failure problems.  A separate SASL
mechanism for OTP is likely to lead to better user interfaces in client
applications.  I actually worked on a specifcation for this a year ago:

https://tools.ietf.org/html/draft-josefsson-kitten-crotp-00

This has the advantage that it also supports two-factor authentication
via a password, and does it in a way compatible with the
state-of-the-art SASL password authentication mechanism SCRAM.

The disadvantage is that it is more complex than sending both password
and OTP in clear text to the server.  I have contemplated a PLAINOTP
mechanism that would be like PLAIN but have another field for the OTP.
This may be easier to implement and deploy for some.

What do you think?  My lack of further work in this area has mostly been
because of limited feedback and deployment opportunitites.  If you have
have some users that could beta test something like this, that would
help.

/Simon