Re: [kitten] U2F/FIDO/WebAuthn in draft-ietf-kitten-scram-2fa-01

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 10 February 2022 14:41 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 E71963A084D for <kitten@ietfa.amsl.com>; Thu, 10 Feb 2022 06:41:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.812
X-Spam-Level:
X-Spam-Status: No, score=-2.812 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, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, 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 007yx2tIfdXs for <kitten@ietfa.amsl.com>; Thu, 10 Feb 2022 06:41:42 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC4A3A0847 for <kitten@ietf.org>; Thu, 10 Feb 2022 06:41:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1644504100; d=isode.com; s=june2016; i=@isode.com; bh=234wld/YfDqPJu6vYTNHZywSZR7w9o/pht+rzQevt4s=; 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=PP2DfdYjzNTPbldM5ztYk+y3N8PXl3AKJZQ9rbq9fddb5AlLIH7hgM8Tf1y/ia0qouadyl QL47GHFwfMhe7+tEhqp1JVSX/yeTivj75Q7ENdG57tb9kEQJX9eIFvcPuZqCY8l9xOwxns 43M1RQmkSQgWqLQnOwpCspR4PEIYXik=;
Received: from [172.27.251.87] (connect.isode.net [172.20.0.43]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <YgUkJAAyESve@waldorf.isode.com>; Thu, 10 Feb 2022 14:41:40 +0000
Message-ID: <475273fb-10fc-d603-c915-fa170154b01f@isode.com>
Date: Thu, 10 Feb 2022 14:41:39 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
To: Simon Josefsson <simon=40josefsson.org@dmarc.ietf.org>, kitten@ietf.org
References: <164312561194.29378.12687557189314117323@ietfa.amsl.com> <87pmnx1v5z.fsf@latte.josefsson.org>
From: Alexey Melnikov <alexey.melnikov@isode.com>
In-Reply-To: <87pmnx1v5z.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/NlqKiEm4YvphD2NsM7ODBKRRx1o>
Subject: Re: [kitten] U2F/FIDO/WebAuthn in draft-ietf-kitten-scram-2fa-01
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: Thu, 10 Feb 2022 14:41:47 -0000

Hi Simon,

On 08/02/2022 10:59, Simon Josefsson wrote:
> I think the document should discuss how U2F/FIDO/WebAuthn would be
> supported, since that is (to my knowledge) the best recommended openly
> standardized 2fa protocol available.  What do you think?
>
> OATH HOTP/TOTP was superseded as the best recommended choice 5+ years
> ago when U2F became available.
Ok, let me study relevant documents and I will reply to your proposal at 
a later time.
> Alternatively, perhaps this document should specify a SCRAM-TOTP variant
> only, and not allow sub-protocol flexibility, to reduce the number of
> sub-negotitations we have in popular SASL mechanisms.  Sub-negotiation
> within a SASL mechanism seems to be one major reason why SASL mechanisms
> fail as far as I can judge.

I generally don't mind having a single recommended (or maybe 2) 2FA 
mechanisms, but I would like the design of SCRAM 2FA to be extensible in 
case we need to change the 2FA mechanism later on.

Best Regards,

Alexey