Re: [kitten] Fwd: I-D Action: draft-melnikov-scram-2fa-00.txt

On Wed, 25 Mar 2020 at 18:06, Alexey Melnikov <alexey.melnikov@isode.com>
wrote:

> Hi Greg,
>
> I wasn't entirely sure whether you were asking about
> draft-melnikov-scram-2fa-00 or Dave's SASL2 proposal. I gave you both
> answers in some cases:
>
> On 20/03/2020 05:21, Greg Hudson wrote:
> > On 3/19/20 9:25 AM, Alexey Melnikov wrote:
> >> (If I remember correctly I also talked to Dave Cridland about doing a
> >> more generic extension to the SASL framework itself by allowing
> >> protocols to invoke multiple SASL mechanism in a sequence and achieving
> >> 2FA that way. I would be interested in developing this concept as well,
> >> but it would take longer than just extending some existing SASL
> mechanisms.)
> > Possible concerns:
> >
> > * If I attempt to authenticate with guessed credentials for each factor,
> > can I tell if one of the guesses was correct?  (Not everyone cares about
> > this property, but it's a legitimate concern if both factors are weak
> > enough to be guessable.)
>
> At the moment draft-melnikov-scram-2fa-00 allows to give a separate
> error code for "second factor authentication failed".
> draft-melnikov-scram-2fa-00.txt should talk about tradeoffs of returning
> this information in order to help debug issues versa helping attackers
> to guess.
>
> In Dave's SASL2 proposal, it is also clear whether a particular step has
> failed.
>
>
Indeed, but - exactly like 2FA is normally deployed - the factors are
required to be sequential, with the knowledge factor first and a hardware
factor (or software emulation of one) second.

> > * If I know one of the factors, can I MITM a connection between a client
> > and server and pass through the other-factor messages while retaining
> > control of the session?
> >
> > * How does the number of authentication round trips compare to a tight
> > coupling of the two factors into one mechanism?
>
> In draft-melnikov-scram-2fa-00.txt there are no extra roundtrips in
> comparison to standard SCRAM (which is 2 rout trips).
>
>
> In Dave's SASL2 proposal second factor authentication adds extra round
> trips, as it is executed sequentially after the main password based
> authentication mechanism.
>
>
Yes - this is in order to make it a conditional step; for example, some
mechanisms might be intended for per-device keys (see
draft-cridland-kitten-device-key for example, or something based around
provisioning TLS certs, which is probably preferable), and be considered
not to require 2FA, whereas SCRAM would be considered an interactive use
and therefore require 2FA.

> > * Does the combining framework work for out-of-band "factors" like SMS
> > or phone confirmation?
> I believe so. Basically the factors are like SASL mechanisms, but with
> slightly limited scope. They still need to be defined, but there is one
> example, see <https://xmpp.org/extensions/xep-0400.html>
>

Yes; originally I designed these so they were SASL mechanisms, but this
turned out to be very difficult in practise. Real SASL mechanisms don't
expect to start with a known authzid, for example, so while the protocol
interface is the same for "Tasks" as it is for "Mechanisms", the
programming interface is different.

> > * Is there a risk of mechanisms being used alone when they were only
> > designed to be secure in combination with other mechanisms?  Can that
> > risk be mitigated?  (Example: a simple OTP mechanism designed for use
> > with a verify-only back end might not be much more secure than PLAIN
> > unless combined with a more complicated mechanism using a different kind
> > of credential.)
>
> I think the way this works is that a SASL server wouldn't return "ok"
> for a SASL mechanism that needs a followup factor mechanism. It will
> return "continue" instead.
>
>
Right - for the TOTP typically used as a software second factor, that can't
be used as the sole mechanism because it's a Task and not a Mechanism, so
only would be offered (and required, indeed) after a more traditional
mechanism were used.

The extended profile introduces a "Continue" outcome instead of just a
Success or Failure, as Alexey says, in order to accomplish this.

> Best Regards,
>
> Alexey
>
>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>