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

Alexey Melnikov <> Wed, 25 March 2020 18:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B302E3A0CC1 for <>; Wed, 25 Mar 2020 11:05:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GLG-6jhgJTxx for <>; Wed, 25 Mar 2020 11:05:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7DCA03A0D13 for <>; Wed, 25 Mar 2020 11:05:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1585159531;; s=june2016;; bh=72vOAF0+drjQvc0W91Wgh9bAoIoCT3SFSGWhW5rwkSk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=GZTE90EtzhafXGqwmPpi+KUpOzwd4JoC/+1Y6uDmoy/QAk9fGjUgF3gAodJ1jvpO0IPT/o 4yjOGdVkVdtg+h0RPDs1etx/ibpS/sKzgju6Rw5DW/lvEXaxEyJlISnK6f177wAHN9uoxC i0EyceL3FRoL99zpUP5BT3SBY1c8JKY=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Wed, 25 Mar 2020 18:05:31 +0000
To: Greg Hudson <>,
References: <> <> <>
From: Alexey Melnikov <>
Message-ID: <>
Date: Wed, 25 Mar 2020 18:05:14 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [kitten] Fwd: I-D Action: draft-melnikov-scram-2fa-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Mar 2020 18:05:51 -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:

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 

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