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

[Alexey Melnikov <[e-mail]>]

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.

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

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

Best Regards,

Alexey