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

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 25 March 2020 18:05 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B302E3A0CC1 for <kitten@ietfa.amsl.com>; Wed, 25 Mar 2020 11:05:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLG-6jhgJTxx for <kitten@ietfa.amsl.com>; Wed, 25 Mar 2020 11:05:38 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCA03A0D13 for <kitten@ietf.org>; Wed, 25 Mar 2020 11:05:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1585159531; d=isode.com; s=june2016; i=@isode.com; 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 [172.27.250.93] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <XnudawBvRCwX@waldorf.isode.com>; Wed, 25 Mar 2020 18:05:31 +0000
To: Greg Hudson <ghudson@mit.edu>, kitten@ietf.org
References: <158462386052.13384.7911173297625270492@ietfa.amsl.com> <1330abb0-f0ae-3399-0486-4d7f7ff63267@isode.com> <0c3f5196-a067-6e87-9dc1-567e8e26e3f2@mit.edu>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <886d63d6-d8dc-97b7-3bfc-ba5ada78106a@isode.com>
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: <0c3f5196-a067-6e87-9dc1-567e8e26e3f2@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/5DRQ0c3xpr57CAx-DFbDKyoUZb4>
Subject: Re: [kitten] Fwd: I-D Action: draft-melnikov-scram-2fa-00.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=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 
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