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

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Mar 2020 13:25:58 +0000

Hi all,

As I had various conversations with people saying that SASL doesn't 
support 2 factor authentication, I posted a short draft which shows how 
to add 2 factor authentication to SCRAM. This is mostly a proof of 
concept and I am planning to work on another draft explaining how to do 
the same for SASL OAUTH.

(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.)

If people can have a look and provide feedback, that would be much 
appreciated.

Best Regards,
Alexey
-------- Forwarded Message --------
Subject: 	I-D Action: draft-melnikov-scram-2fa-00.txt
Date: 	Thu, 19 Mar 2020 06:17:40 -0700
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

Title : Extensions to Salted Challenge Response (SCRAM) for 2 factor 
authentication
Author : Alexey Melnikov
Filename : draft-melnikov-scram-2fa-00.txt
Pages : 5
Date : 2020-03-19

Abstract:
This specification describes an extension to family of Simple
Authentication and Security Layer (SASL; RFC 4422) authentication
mechanisms called the Salted Challenge Response Authentication
Mechanism (SCRAM), which provides support for 2 factor
authentication.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-melnikov-scram-2fa/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-melnikov-scram-2fa-00
https://datatracker.ietf.org/doc/html/draft-melnikov-scram-2fa-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Florian Schmaus <[email-masked]>
Date: Thu, 19 Mar 2020 14:53:01 +0100

> If people can have a look and provide feedback, that would be much

How does the client discover that the SCRAM 2FA extension is required?
Is it encoded in the SASL mechanism name, akin to SCRAM -PLUS?

- Florian

---

From: Dave Cridland <[email-masked]>
Date: Thu, 19 Mar 2020 14:12:27 +0000

In XMPP-land, we did this by having an extended SASL profile that could ask
explicitly for TOTP (and password changes, and other things of that ilk).

https://xmpp.org/extensions/xep-0388.html (Extensible SASL Profile)
https://xmpp.org/extensions/xep-0400.html (TOTP 2FA for the above)

This detaches the choice of authentication mechanism from the choice of
second factor, as well as allowing other exciting options for all your
authentication needs.

I've personally implemented these in servers and clients, and they appear
to work well.

On Thu, 19 Mar 2020 at 13:26, Alexey Melnikov <[email-masked]>
wrote:

> support 2 factor authentication, I posted a short draft which shows how to
> add 2 factor authentication to SCRAM. This is mostly a proof of concept and
> I am planning to work on another draft explaining how to do the same for
> SASL OAUTH.
>
> (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.)
>
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Mar 2020 16:24:17 +0000

Hi Florian,

> Is it encoded in the SASL mechanism name, akin to SCRAM -PLUS?

It could be done this way.

I was also thinking about not introducing new SASL mechanism names and 
just add a mandatory attribute in the first message from the server to 
the client.

If you have an opinion on these options, please let me know.

Best Regards,

Alexey

---

From: Greg Hudson <[email-masked]>
Date: Fri, 20 Mar 2020 01:21:00 -0400

> 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.)

* 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?

* Does the combining framework work for out-of-band "factors" like SMS
or phone confirmation?

* 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.)

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 25 Mar 2020 18:05:14 +0000

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:

> this property, but it's a legitimate concern if both factors are weak

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.

> 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.

> * Does the combining framework work for out-of-band "factors" like SMS
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>
> unless combined with a more complicated mechanism using a different kind

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.

Best Regards,

Alexey

---

From: Dave Cridland <[email-masked]>
Date: Wed, 25 Mar 2020 23:12:22 +0000

> In Dave's SASL2 proposal, it is also clear whether a particular step has
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.

> 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.

> 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.

> 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.