From nobody Thu Mar 19 01:49:17 2020 Return-Path: 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 92E953A2517 for ; Thu, 19 Mar 2020 01:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=openfortress.nl 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 6HUQSl3Xf5p1 for ; Thu, 19 Mar 2020 01:49:13 -0700 (PDT) Received: from lb2-smtp-cloud9.xs4all.net (lb2-smtp-cloud9.xs4all.net [194.109.24.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BAA3A2515 for ; Thu, 19 Mar 2020 01:49:12 -0700 (PDT) Received: from popmini.vanrein.org ([IPv6:2001:980:93a5:1::7]) by smtp-cloud9.xs4all.net with ESMTP id EqrUjrgEXfHuvEqrVjdBI3; Thu, 19 Mar 2020 09:49:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1584607748; h=message-id : date : from : mime-version : to : subject : content-type : content-transfer-encoding : date : from : subject; bh=U9Q7eQyzFxnU4n3VIMtUP3jsfo84lOw4mwJEezmwVgk=; b=b581tgzjZRPW7z/velSz/qIOEqRP/vg2N3uIyFoALPSvnifH2bfBseTu B0uAIyJ2N1v83xs/RVFKOP2APrcyZ16gdYSAtrOxEmWm9fd1Zc2qik4j1s BpUGfb3CsIrEKSIsQ1LrOSHrQZF5QO1I0Aa1c4dY3Y4/yleJCXWNB2VYQ= Received: by fame.vanrein.org (Postfix, from userid 1006) id 765A437EE2; Thu, 19 Mar 2020 08:49:08 +0000 (UTC) X-Original-To: kitten@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id E65B137B27; Thu, 19 Mar 2020 08:49:04 +0000 (UTC) Message-ID: <5E7331FF.9000500@openfortress.nl> Date: Thu, 19 Mar 2020 09:49:03 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "kitten@ietf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfC767V+pLsnT6DBZhdUKIxAzVsyBCAjIeVJk/8xM4QMr/b+V7FVIwD50vWTFCD16CT5NrD/DacAhKWDZKGYc+6TyRYrZgLK5CYeavz97wnqz+ZG9JoAG pFn1k6MVyZUqTQ4+6RI2xSkVCyP/eqPPMeeZ1ZNrQJLvCVihYu/rMYypjh6OMjkBRWBhnawcxk5JyQ== Archived-At: Subject: [kitten] SASL's idea of "additional data" in a protocol X-BeenThere: kitten@ietf.org 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: Thu, 19 Mar 2020 08:49:16 -0000 Hello, RFC 4422 states that there may be additional data with a success. I don't think I have ever seen this in any protocol or mechanism. Am I correct that there is no reason in practice to add it to a protocol embedding of SASL? The text is, Some mechanisms specify that the server is to send additional data to the client when indicating a successful outcome. Protocols may provide an optional additional data field in the outcome message to carry this data. Where the mechanism specifies that the server is to return additional data with the successful outcome, the protocol provides an optional additional data field in the outcome message, and the server uses this field, the exchange is shortened by one round-trip: Thanks, -Rick From nobody Thu Mar 19 06:26:15 2020 Return-Path: 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 214AA3A296A for ; Thu, 19 Mar 2020 06:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, HTML_MESSAGE=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, 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 6rmFbUioQR0Z for ; Thu, 19 Mar 2020 06:26:01 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 6833B3A294D for ; Thu, 19 Mar 2020 06:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1584624360; d=isode.com; s=june2016; i=@isode.com; bh=9cJKzr70INMq3MiyrRIlbcVJ5ONIGVw6xiGI7f6T75A=; 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=SA4YCqdq4s08ho9/ICtJAf0h4XCbeHtxW9Lx7QrmLN73pLFz23D2VjLXqpSxaU5EglWxTI JcjXrm1xLhu4XJzlrRvO9zXV+j5Jj3J/sU9E6ncD9sgdW5GoqAdPRCc1pTlBrLJuP1rkdR lCd0AV6Llkws76wKH3gY/OWKACNnqkg=; Received: from [192.168.1.216] (host81-154-46-147.range81-154.btcentralplus.com [81.154.46.147]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 19 Mar 2020 13:26:00 +0000 References: <158462386052.13384.7911173297625270492@ietfa.amsl.com> To: kitten@ietf.org From: Alexey Melnikov X-Forwarded-Message-Id: <158462386052.13384.7911173297625270492@ietfa.amsl.com> Message-ID: <1330abb0-f0ae-3399-0486-4d7f7ff63267@isode.com> Date: Thu, 19 Mar 2020 13:25:58 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 In-Reply-To: <158462386052.13384.7911173297625270492@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A7B8FD3CFFB25C81ED9C08FE" Content-Language: en-GB Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 13:26:14 -0000 This is a multi-part message in MIME format. --------------A7B8FD3CFFB25C81ED9C08FE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org 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 I-D-Announce@ietf.org 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 --------------A7B8FD3CFFB25C81ED9C08FE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

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: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org



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
I-D-Announce@ietf.org
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
--------------A7B8FD3CFFB25C81ED9C08FE-- From nobody Thu Mar 19 06:31:04 2020 Return-Path: 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 918D53A2981 for ; Thu, 19 Mar 2020 06:31:02 -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 E40woC1Y_aX7 for ; Thu, 19 Mar 2020 06:31:00 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 96EFE3A297F for ; Thu, 19 Mar 2020 06:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1584624654; d=isode.com; s=june2016; i=@isode.com; bh=bgXbiBuXR1d8opwq3/YlXFj+LTqb0U7KznblK8zdXkw=; 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=h15Z9s8tevrmWhpGZj9iM7W22m2d3YDRqaNCjyJPy+aFrrLKGqxRAFE8u4HO7Rn/D7VVrI 3rM/vkdVm8Gg/3n6IK1fQcLX2za62HwOmEjSo+u+hFx5VyndyEtEVdB8jY12av3A1RhMsw MguJ58f41AGG9tOvkCUm1+qMHj6kXa4=; Received: from [192.168.1.216] (host81-154-46-147.range81-154.btcentralplus.com [81.154.46.147]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 19 Mar 2020 13:30:54 +0000 To: Rick van Rein , "kitten@ietf.org" References: <5E7331FF.9000500@openfortress.nl> From: Alexey Melnikov Message-ID: <889abf71-b8c9-5bb8-5376-02047054296b@isode.com> Date: Thu, 19 Mar 2020 13:30:52 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 In-Reply-To: <5E7331FF.9000500@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [kitten] SASL's idea of "additional data" in a protocol X-BeenThere: kitten@ietf.org 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: Thu, 19 Mar 2020 13:31:03 -0000 Hi Rick, On 19/03/2020 08:49, Rick van Rein wrote: > Hello, > > RFC 4422 states that there may be additional data with a success. I > don't think I have ever seen this in any protocol or mechanism. Am I > correct that there is no reason in practice to add it to a protocol > embedding of SASL? Actually, this is being used. Look for example at SCRAM (RFC 5802), the last message from the server (containing the v= attribute) can be sent as "additional data with success". It is always better to allow for this in a SASL protocol profile in order to save an extra round trip. I.e. if this feature is not supported by a protocol, the server will have to send it as a regular SASL response, to which the client will have to respond with an empty challenge, which will then be responded to by the server with just successful outcome (with no data). Best Regards, Alexey > The text is, > > Some mechanisms specify that the server is to send additional data to > the client when indicating a successful outcome. Protocols may > provide an optional additional data field in the outcome message to > carry this data. Where the mechanism specifies that the server is to > return additional data with the successful outcome, the protocol > provides an optional additional data field in the outcome message, > and the server uses this field, the exchange is shortened by one > round-trip: > > Thanks, > -Rick > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Thu Mar 19 06:53:09 2020 Return-Path: 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 F254B3A29C5 for ; Thu, 19 Mar 2020 06:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.111 X-Spam-Level: X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 RJ_fdqtaZnbo for ; Thu, 19 Mar 2020 06:53:05 -0700 (PDT) Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858C53A29C3 for ; Thu, 19 Mar 2020 06:53:05 -0700 (PDT) Received: by mail-wr1-f41.google.com with SMTP id i9so3058934wrx.12 for ; Thu, 19 Mar 2020 06:53:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wQttBIceW1TqK6grImC5290YZxfP5fX2AA39/ZiUYQ4=; b=kgx75uaD0EXw6F48pjXkrU/ZjR2I52x4HOLqWIyRcWybPHLLpZdlPNfzqqIegzphQV o+qXc77820xp3+Q/6km0JYdwJUtD+a0MYfWko8p1EdyzdmYnC7PkMc7DxlcekTgunoSs nyeKPdWpdVPq9sEecXtRpRpWsDgNdiLF44YN5jxTr726FTkR8Boz1zojpoLkUwMop3Ux A7SX7qzLqhSn6tc/R97FGexBIpQKEPj5VNzO503PWAba3/FQcqcbZ4sIHLKWmWLPBRiS x5+NPlVsE519TRUQgaBAQKeOhuh/syCYpRrHOGaueMFVeRO2twA2e40zj0bdV0CY11Rv GXnQ== X-Gm-Message-State: ANhLgQ2WB1NQsghDemtrrCCMq9Va6sHhrarkYuyAux3ShEvb718edBFT vq3M8tS6+zfDjAG1OZVBoCGNqilpc50= X-Google-Smtp-Source: ADFU+vsYzy6v75PVQhwVcTp8ROhDsBoSPBg0HlQ0bNGhVWKjd3MGANyCMCPBWhrn7B1yCOeGr0pyNg== X-Received: by 2002:a5d:56cd:: with SMTP id m13mr4349066wrw.236.1584625983506; Thu, 19 Mar 2020 06:53:03 -0700 (PDT) Received: from neo-pc.sch (55d4389f.access.ecotel.net. [85.212.56.159]) by smtp.gmail.com with ESMTPSA id n63sm15385wmf.6.2020.03.19.06.53.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Mar 2020 06:53:02 -0700 (PDT) To: kitten@ietf.org References: <158462386052.13384.7911173297625270492@ietfa.amsl.com> <1330abb0-f0ae-3399-0486-4d7f7ff63267@isode.com> From: Florian Schmaus Message-ID: <7b8fc0af-a0e4-6c13-8bcd-da6be3b70cc6@geekplace.eu> Date: Thu, 19 Mar 2020 14:53:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <1330abb0-f0ae-3399-0486-4d7f7ff63267@isode.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 13:53:08 -0000 On 3/19/20 2:25 PM, Alexey Melnikov wrote: > 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.) > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-melnikov-scram-2fa/ > > If people can have a look and provide feedback, that would be much > appreciated. 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 nobody Thu Mar 19 07:12:44 2020 Return-Path: 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 A7BB93A15BD for ; Thu, 19 Mar 2020 07:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=cridland.net 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 Xb030JMZ3iBY for ; Thu, 19 Mar 2020 07:12:41 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55393A15BB for ; Thu, 19 Mar 2020 07:12:40 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id v11so3170074wrm.9 for ; Thu, 19 Mar 2020 07:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6XsJic+W1VYO6kg/s2z/Td1IMSV2EEFuJQAy5/pUqKA=; b=UzuHRwrx3lhfEwd/GoXXGp/ECwUz+qo40nEVqNHqIs7roB4Pghw/+6CN+PzIqw6R54 G2mPk4u9fy6WavdUh6j69/W1vxVQccX48ECwL3bEwRSOtJxY5RWdxdkGMo4KHgL0Gici mCHtLCl6mAGm1xB51Y2al+amrd+NTSxbghCSY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6XsJic+W1VYO6kg/s2z/Td1IMSV2EEFuJQAy5/pUqKA=; b=Qw8Yv4kRVatVxs5OBFT+11MgAKkdfsdUP/Y26yC1oOjKtVlIbW+BwPoWgA/4NCyHiV kLVlQV+hsoB1YxPjBUeRrRIMSZNP21D5pa0Ng9dRzGlrlMFgPkdE3IMKofrGuGrmZQZo UDZp19U23dqZ772JkyuwHKWhs4Qrba2I6Bnmado9knLAzpki2dW4cMv/MaOwynHfM2tP BG+iZR7ViVUtTJeTKFXb8/hX+V8SieHwn56AQSfp1Ws21aHQ2Q5Y4/sZXMB5u6jxTs5H iDyizwhnfnm8batPfZBRQnZsF5BqdB8z37ChiaAUVwLkzfRszbv2LaHS2nAOxz5qskpo mPwg== X-Gm-Message-State: ANhLgQ1q5TYrpOPWvC3Rmc5tN4oO4Ea1h/YrmEU0R8Bk9muZ81CRK+Du Snv/3qpM39UEejjHPB8ZfntlxF5O1nO0JKNZ+CpE7YXDqD2RFA== X-Google-Smtp-Source: ADFU+vsKONO+Z1QW5NfIp1TbpQ7sJZjlPZGSIECzcDqWxoEQn3+QrMjnvoGKqkPi9mgwH8kUKgbnS8ZPw4t4844pYXI= X-Received: by 2002:adf:fe8d:: with SMTP id l13mr4498532wrr.248.1584627158648; Thu, 19 Mar 2020 07:12:38 -0700 (PDT) MIME-Version: 1.0 References: <158462386052.13384.7911173297625270492@ietfa.amsl.com> <1330abb0-f0ae-3399-0486-4d7f7ff63267@isode.com> In-Reply-To: <1330abb0-f0ae-3399-0486-4d7f7ff63267@isode.com> From: Dave Cridland Date: Thu, 19 Mar 2020 14:12:27 +0000 Message-ID: To: Alexey Melnikov Cc: kitten@ietf.org Content-Type: multipart/alternative; boundary="000000000000e4a11c05a135c206" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 14:12:43 -0000 --000000000000e4a11c05a135c206 Content-Type: text/plain; charset="UTF-8" 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 wrote: > 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: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > 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 > I-D-Announce@ietf.org > 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 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > --000000000000e4a11c05a135c206 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In XMPP-land, we did this by having an extended SASL profi= le that could ask explicitly for TOTP (and password changes, and other thin= gs of that ilk).

https://xmpp.org/extensions/xep-0388.html (Extensible SASL Profile)<= br>https://xmpp.org/e= xtensions/xep-0400.html (TOTP 2FA for the above)

This detaches t= he choice of authentication mechanism from the choice of second factor, as = well as allowing other exciting options for all your authentication needs.<= br>
I've personally implemented these in servers and clients, and th= ey appear to work well.

On Thu, 19 Mar 2020 at 13:26, Alexey Melnikov &l= t;alexey.melnikov@isode.com> wrote:
=20 =20 =20

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: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: = i-d-announce@ietf.org



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-2= fa/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-melnikov-scram-2fa-00
https://datatracker.ietf.org/doc/html/draft-meln= ikov-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
I-D-Announ= ce@ietf.org
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
_______________________________________________
Kitten mailing list
Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten
--000000000000e4a11c05a135c206-- From nobody Thu Mar 19 08:54:26 2020 Return-Path: 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 A4DF23A07FE for ; Thu, 19 Mar 2020 08:54:24 -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=openfortress.nl 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 A8XzHIX6bEZK for ; Thu, 19 Mar 2020 08:54:21 -0700 (PDT) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6601E3A07FD for ; Thu, 19 Mar 2020 08:54:20 -0700 (PDT) Received: from popmini.vanrein.org ([IPv6:2001:980:93a5:1::7]) by smtp-cloud7.xs4all.net with ESMTP id ExUrjompRLu1fExUsjjyqB; Thu, 19 Mar 2020 16:54:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1584633253; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=OB+odT0jNTvQM5s5RcgF+takqkdHAWYrzeMlxwTe2NY=; b=gh3c/1c7wEhSYgwL5HUe6QJpKvDnnYBMqPMRCR8vGRr5+HD9gnk1TcY6 8tVbBwy8lfpQFPU+m2KACS0ugAFak3UVwjUYPKpJKat7CycIygXmc2c7Wm RlYddW9ZOp7YlBZbDcYYAcYIKi400RsQvPmFvTrDatE4tDuJYgsNiXgjQ= Received: by fame.vanrein.org (Postfix, from userid 1006) id 48E2937F20; Thu, 19 Mar 2020 15:54:11 +0000 (UTC) X-Original-To: kitten@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id BB79B37F1C; Thu, 19 Mar 2020 15:54:03 +0000 (UTC) Message-ID: <5E739599.5010605@openfortress.nl> Date: Thu, 19 Mar 2020 16:54:01 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Alexey Melnikov , dave@cridland.net CC: "kitten@ietf.org" References: <5E7331FF.9000500@openfortress.nl> <889abf71-b8c9-5bb8-5376-02047054296b@isode.com> In-Reply-To: <889abf71-b8c9-5bb8-5376-02047054296b@isode.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfN1IAcSsaEZcxG6QY/BdoeCV5a5tbbXmV2s5FQIZCK5qcdJCEyDC2XdcCf7JPWsjvPGtWfmaNb/LGbuqv0y5WikEpNm67kUKeKBksQbyR97XReGtr5ef +DQa3rr1fIE2c7juUzqhZW4bmyntHXwq+E8mPL8hUgDmKdRUDeo/DXliDLDYyalN3j+Vecyhvwx5XA== Archived-At: Subject: Re: [kitten] SASL's idea of "additional data" in a protocol X-BeenThere: kitten@ietf.org 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: Thu, 19 Mar 2020 15:54:25 -0000 Hello Dave and Alexey, > SCRAM does this, and it can be seen in profiles that support it like XMPP. > Actually, this is being used. Look for example at SCRAM (RFC 5802), > the last message from the server (containing the v= attribute) can be > sent as "additional data with success". Thanks, my feeling that this was not used at else has been falsified. I was beginning to wonder if I was being overzealously spec-compliant. Apparently not :) -Rick From nobody Thu Mar 19 09:24:29 2020 Return-Path: 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 DCD743A08B8 for ; Thu, 19 Mar 2020 09:24:26 -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 dDtnpGBvZAs6 for ; Thu, 19 Mar 2020 09:24:25 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF533A08B2 for ; Thu, 19 Mar 2020 09:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1584635059; d=isode.com; s=june2016; i=@isode.com; bh=6Ofug0pk0VQ+iuwI856gCCt7oWabJ+nr8Zfj0q/q7qQ=; 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=eJSFRE2+CGOZNAUtjO47baNEV9ezI9j40vmzVL5as398yaJufowYg0TPDBCq9Pev5R9jeM cL0pzDe9FW4g5XwDuNjzcyi9z3OM5Nf8kGPn8EHPGOOI36bPZzkhjjchxXPmWAFGAfGYqa RqEGtfwZn31mjiFmDhYYFFEHFIUkD2g=; Received: from [192.168.1.216] (host81-154-46-147.range81-154.btcentralplus.com [81.154.46.147]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 19 Mar 2020 16:24:19 +0000 To: Florian Schmaus , kitten@ietf.org References: <158462386052.13384.7911173297625270492@ietfa.amsl.com> <1330abb0-f0ae-3399-0486-4d7f7ff63267@isode.com> <7b8fc0af-a0e4-6c13-8bcd-da6be3b70cc6@geekplace.eu> From: Alexey Melnikov Message-ID: <2a4d603c-7538-01e5-9e65-58ae6052b9ef@isode.com> Date: Thu, 19 Mar 2020 16:24:17 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 In-Reply-To: <7b8fc0af-a0e4-6c13-8bcd-da6be3b70cc6@geekplace.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 16:24:27 -0000 Hi Florian, On 19/03/2020 13:53, Florian Schmaus wrote: > On 3/19/20 2:25 PM, Alexey Melnikov wrote: >> 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.) >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-melnikov-scram-2fa/ >> >> If people can have a look and provide feedback, that would be much >> appreciated. > How does the client discover that the SCRAM 2FA extension is required? > 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 nobody Thu Mar 19 22:21:06 2020 Return-Path: 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 ED7543A15CB for ; Thu, 19 Mar 2020 22:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 DVzyW27yvFQz for ; Thu, 19 Mar 2020 22:21:03 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3143D3A15C3 for ; Thu, 19 Mar 2020 22:21:02 -0700 (PDT) Received: from [18.28.11.154] ([18.28.11.154]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02K5L00j019678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Mar 2020 01:21:01 -0400 To: Alexey Melnikov , kitten@ietf.org References: <158462386052.13384.7911173297625270492@ietfa.amsl.com> <1330abb0-f0ae-3399-0486-4d7f7ff63267@isode.com> From: Greg Hudson Openpgp: preference=signencrypt Autocrypt: addr=ghudson@mit.edu; keydata= xsFNBFLMQYIBEADZLNv8Jpeo2d4XSLE+k6m1VD2iOyX66wErZKaQpYrGB/leWKfz8l6c3pWd iVUnCoyxKlhRuGVArszdh2wUSRgHnMl86JC/vIdawdOdbnlTVfOJTiP3EfycsMUUDG6GckLY e+xxo7sM/bpXpGkbIWc0Ec/vbQt67eeW2En1AqL+ezJdVN9XL8icH2Hu6HlqxGgleC5H0yAi kM4yvNjo5z2M/Dr/x63bLcIdKkSRPzd0OaBg2g0Yh651eYpPu0e1Gi6785ZBjV4bnv3K5oLo 5XsiHIZ60maHWTEyMO/byw4aS2cCWIovXurvz699KSF83B296+xhsFhhz4+kbQgXvJt4kIoI pdpX6xbIkeVlc+FuUbyE8MUGveA3TFHXZ4+0f2tvTekey/62FOeXnrqc4NsBViir3zGTXAqC 7PQTNnX/86jyW+9SnJo9XbSBB3NV0K5I2o1cDzqRPqy/4fsoq8SxQwRga0CSId1PzE9PUEUY V0FCldo9LvPsUK9YE7AuwC+bcQiVLah5TF+5Kk7yLSaRxzQ3fI5lcqk5UPUqMLa87cRBdnal niuHVg0u3W22RMPkWe2iPIYYdr4TQDzCkD2JXpXNaZ3KipVT5aqowwfPEt7b6ti0vjrOInij YzFmVNMGKYabwh2zxKWQQ8GO5mUVu09CSe33H4EW7pDP+zHr2wARAQABzR1HcmVnIEh1ZHNv biA8Z2h1ZHNvbkBtaXQuZWR1PsLBeAQTAQIAIgUCUsxBggIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AACgkQDLoIV1+Dct8dZBAA1Mtoq1RPuUQg6hL2qFjwTEXeonWq8czkQ1fNNzO9 x8I3VLn5L6CmWeAmxRU1DD0qZ5HL24+Mwnvy/eazp4/CSgiPC52KfbNsnQtg/E+8ruFQVHA/ 3HZXuCT/Nz4s06N3fMZrJLCGNEHRD0S43kb2GGboVY3ykO3FbPJB/DxDqtIMqt6B1SZ87UAR CVsRc296X3TsF9BgoQ/n54XfYAzrACkuIH9biHmH6wB1eykCeuhkCsu5Zf/tlSXJCFiuhvS+ CX2EbNKF+0MLcGAavSzbjTnQw3kv8unSgecbEQ7A8ibGx6Jwgnvy0gzu6w4prhR40pVYDcL+ sKsmQg6jo/uPvGdEqHISFSK8FxGGAonaAwg0014bXLaPo2MckcZ+szcHA/z4vpTdB1vChexL omM5ZTeSJaFfeYsspv8sq6EL1x21c7A+ngCmB70/OZR6dcgf9/ILmcjBiYfJHYukXTIvGT6y QJbok19So8RJKUYjzzHDKBweg8x6HdIrdy7HTcLzsqY9PFGg7/YlbLlGQwYXhK1b4uBmWyE7 I/402+57I1YpMYND7vsTmJuE13Gv5ZGhYn5pSzX9ZTWY13LgGymkWBXPxfefkHKTV9ROCGEL t7SV3Nf7ZsCGLRGmDT6oqLz75/IrhKEcHIfD4ct+QvIm6pvPNvikQMwPWSd52GazILLOwU0E UsxBggEQAKaz/wX8nsSUaivmwW4NVlbmTsErHUt9iNHm9CmieuoDv1o8qUqEV6RiONIs0q5Y +dcooazhHRNpjAST2rbQFBZebfpVRKYAGzHoZEQ6OV8Eao+NjAGazS8RuwIxpeZ36r3AyVhe TAIvIzwpQFDNKTIUNbXctHrZ157TlxDuKwZ3+Yw/bhQE5YGrSLm17wIMcY3UHiE1mO5X0ohR dDeTf93PignUUvWvRRQLyxRGsBLz/CCwmCJZeu/FjnDk8HkEbAlmFAJ+YZu9rQ40vU6Z40KY L5U9PIn0FdSxviK7mys+VbFYV6mXWXZN8dOkHuG6zSdmobE90G6ZzAPcI4cyql63N+kUOb3b hGI/Wvn6tUbWeIc8UvQGpYb0+eOKHQBNKUOq5RV98hZorZRCu2W2RzZSxiufyONvtonbUtYs BMdw+gqUpK0ir782lc3cKbj+X5iiyg3ZGvBmTU6FN/MiX6MnTyEwOScFboKe6vB8ZgwII85K n9qlSI3xH56JBXamMP0yqJf57q0WfP8V7lFtm8SmhU2NQyP3wRYDm2+bLTNCmRPJN2ZUgkTx c/Qjov8TeeiTfX9S3ea/GJOdgA1mQfSkmUoOWROnwDBbKGBXNzkkoJna8j/zWgo/mQ5gNdIu HXcIdDKbyyhVH3+DwxXYWyYP/pnIk3AVCss75dXcdStfABEBAAHCwV8EGAECAAkFAlLMQYIC GwwACgkQDLoIV1+Dct+oSA/9HyTkr+UQbaucXE9pP87yasObKCBxYhoeRjzBhgtYUtSDuH2o xl5M3wmTNOooQSa8R1ljhax9v02pqspIA9hyGjGjvZ6jPydDsANNcohdbMjCzXNdrCF5149w gbGQ07rkc5JNyajzxH4GE/BXclTzwTYAaHvYM5PEQLDhmubK3M/kBvjWpZxLAJAobMi/jVwQ cmai+N56X9Ht/FVIQlmCuXoMAE9ScVWFaq8JnCo9VZ0G045NcxdEoQXVUXb3E5cmZ0Ld9sUm SKSJKjYWjfE4c/8oylZuo9LDTwozBEp/jsASjL0g8F3QJsQUkFkKROd45xHcIkFulshS3xkG gMu6UduV2ypPz987f+0wdVwx+KYnmnUB83gxqVucFRxfZZXiUHUml4rJ7Ww2+//H9FFPfw9f aPMg7nLFm2T0to3pwgyisLH/aThzW3TY7CZ7gkvMDtbo9EHrN4Nl3onuOtOKQpIMbFVqX4YZ m6znSLuUiWDUd8rvQfz+4ndZKIFOG1YIKwQBV8tN1RYBGY9bhv2Wtt5X6SKIzkUhDdgeyzci MC1M3N0Pqoqrms7FdBKAd0BE7puhQ24U42APss+Ur6WyRZMQTKc41SZWfrWV30agytUVdtRu gxERw74qeGAz6o3if42vI6u30SR6OCLMMSobqKc7HQvJ2qv3Z6j9kt1zXiE= Message-ID: <0c3f5196-a067-6e87-9dc1-567e8e26e3f2@mit.edu> Date: Fri, 20 Mar 2020 01:21:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1330abb0-f0ae-3399-0486-4d7f7ff63267@isode.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 05:21:05 -0000 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.) * 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 nobody Wed Mar 25 11:06:16 2020 Return-Path: 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 ; 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 ; 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 ; 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 ; Wed, 25 Mar 2020 18:05:31 +0000 To: Greg Hudson , 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 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: 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 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 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 > * 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 From nobody Wed Mar 25 16:12:50 2020 Return-Path: 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 312693A03F2 for ; Wed, 25 Mar 2020 16:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=cridland.net 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 3qg2fTPdtPXl for ; Wed, 25 Mar 2020 16:12:36 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8226A3A0123 for ; Wed, 25 Mar 2020 16:12:36 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id p10so5628651wrt.6 for ; Wed, 25 Mar 2020 16:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2u9zH6Czgg6/TZUY/+XiAPA9q7ncZYfbSnvhhwGnz5A=; b=KtpmW61M+nMD6bs8imU7UgEKcoFyCukMxPBr8P7ySf0Th+4fPivbs38pI6pXSzxPjp 8ydKnmkEve6JbLwRkMmLGn+hSLJ0n4vY+p/228E1EXXBEdF5S7GWeSXZYEhjV33gqdIM uTBd7sBp2zp/JdBRTFYxmWCcXm+yw4ApOJoPU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2u9zH6Czgg6/TZUY/+XiAPA9q7ncZYfbSnvhhwGnz5A=; b=HJT1uiXjlU5zzV3Qh9kaiZwhvEwcvm20hmmKY0YLe4JHtAhbmsIgWPbW7vu6Wj4U/u 2kKUvFnHLBw1Dbo0Fq2maHedgqbEm24yqmLZaNjfqtcKD3GEcMBiLIpFO7qacjcjYLap PEu0Z2/ESm9UXm39py/bGxNXxHbgYItqegfHarxf2y5sr5Pi3LDyomKKbokgn25jWfpq FOk7HbTI99TMl2+niRUynyfl296pClWO2byJP3kylK/d7oQDgMcWdSjqte5W31tsEgu9 E+K1H4p2yhULHy2gJRspF3YwoAWcgES6ojXo+HHTUFaYl6Eg1Vp4GBjed1YWyxeLAVTI 4Pzw== X-Gm-Message-State: ANhLgQ1DO962eAHwWm88Co0tBOZhA8BdodHG+o/NR8urw/KQ8fGZ8D8i ZnyejlATd2zoRiwDnJeHIyiIhyDV8VMeyF/vAwZKpN2nbNKytg== X-Google-Smtp-Source: ADFU+vsrpLEnvZrTrdaDK6CFNMYdMigpfBDJGHRzQPz+fefa4Bf0ZtFUGqwGhuY4zTSOPOm41IxdiGm1fng79iBU/Lw= X-Received: by 2002:adf:a21a:: with SMTP id p26mr5904899wra.102.1585177954004; Wed, 25 Mar 2020 16:12:34 -0700 (PDT) MIME-Version: 1.0 References: <158462386052.13384.7911173297625270492@ietfa.amsl.com> <1330abb0-f0ae-3399-0486-4d7f7ff63267@isode.com> <0c3f5196-a067-6e87-9dc1-567e8e26e3f2@mit.edu> <886d63d6-d8dc-97b7-3bfc-ba5ada78106a@isode.com> In-Reply-To: <886d63d6-d8dc-97b7-3bfc-ba5ada78106a@isode.com> From: Dave Cridland Date: Wed, 25 Mar 2020 23:12:22 +0000 Message-ID: To: Alexey Melnikov Cc: Greg Hudson , kitten@ietf.org Content-Type: multipart/alternative; boundary="000000000000dac4db05a1b60056" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 23:12:47 -0000 --000000000000dac4db05a1b60056 Content-Type: text/plain; charset="UTF-8" On Wed, 25 Mar 2020 at 18:06, Alexey Melnikov wrote: > 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. > > 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. > > * 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. > > 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. > > * 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 > 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. > > * 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. > > 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. > Best Regards, > > Alexey > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > --000000000000dac4db05a1b60056 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 25 Mar 2020 at 18:06, Alexey = Melnikov <alexey.melnikov@i= sode.com> wrote:
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 <= br> 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 doin= g a
>> more generic extension to the SASL framework itself by allowing >> protocols to invoke multiple SASL mechanism in a sequence and achi= eving
>> 2FA that way. I would be interested in developing this concept as = well,
>> but it would take longer than just extending some existing SASL me= chanisms.)
> Possible concerns:
>
> * If I attempt to authenticate with guessed credentials for each facto= r,
> can I tell if one of the guesses was correct?=C2=A0 (Not everyone care= s about
> this property, but it's a legitimate concern if both factors are w= eak
> 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 ha= s
failed.


Indeed, but - exactly like 2FA is norm= ally deployed - the factors are required to be sequential, with the knowled= ge factor first and a hardware factor (or software emulation of one) second= .
=C2=A0
> * If I know one of the factors, can I MITM a connection between a clie= nt
> and server and pass through the other-factor messages while retaining<= br> > 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.


Yes - this is in order to make it a co= nditional step; for example, some mechanisms might be intended for per-devi= ce keys (see draft-cridland-kitten-device-key for example, or something bas= ed around provisioning TLS certs, which is probably preferable), and be con= sidered not to require 2FA, whereas SCRAM would be considered an interactiv= e=C2=A0use and therefore require 2FA.
=C2=A0
> * 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= >

Yes; originally I designed the= se so they were SASL mechanisms, but this turned out to be very difficult i= n practise. Real SASL mechanisms don't expect to start with a known aut= hzid, for example, so while the protocol interface is the same for "Ta= sks" as it is for "Mechanisms", the programming interface is= different.
=C2=A0
> * Is there a risk of mechanisms being used alone when they were only > designed to be secure in combination with other mechanisms?=C2=A0 Can = that
> risk be mitigated?=C2=A0 (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 ki= nd
> 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.


Right - for the TOTP typically used as= a software second factor, that can't be used as the sole mechanism bec= ause it's a Task and not a Mechanism, so only would be offered (and req= uired, indeed) after a more traditional mechanism were used.

=
The extended profile introduces a "Continue" outcome i= nstead of just a Success or Failure, as Alexey says, in order to accomplish= this.
=C2=A0
Best Regards,

Alexey


_______________________________________________
Kitten mailing list
Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten
--000000000000dac4db05a1b60056-- From nobody Mon Mar 30 19:28:42 2020 Return-Path: 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 C03A73A1866 for ; Mon, 30 Mar 2020 19:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.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 cm-xsD9gQw2i for ; Mon, 30 Mar 2020 19:28:39 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8713A1865 for ; Mon, 30 Mar 2020 19:28:38 -0700 (PDT) Received: by us.padl.com with ESMTP id 02V2SUv2004235; Tue, 31 Mar 2020 02:28:34 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 02V2SUv2004235 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1585621715; bh=5Jg48eLPKgIEsB1efPS5um31I9YBQzhsNJ+ohgyDgzQ=; h=From:Subject:References:To:Date:From; b=Rzc9Is/bi0PPYWU5m9pS6jxpBAXmZOjyKs4XmwrTphIlsAEfLwSoy3aT5ICZmC8gC 0jTzHoUQnG3/V51OFv3GSarztpIpKIO2uNd7duxgVXjUk+tj9KpzmrdIgI44zy3dLi LLjRyhiKM6Ct8NkAPvvr4U4rpcEKuEQ4UOjKSnRITubP44Duq2NkH+/IxI9nUXDEnG OQvpX9scjQV0TSVS/5gzmQ4jIdMcspDs/NKQUydKfklf62WJEH8V2+1b2kmS+5JAaf 3JQeF/48I16TahL+SqlI5cuCusoKrj9kXWRu/lTbcx2hX3KylJcnUSlzlKsjWj7WpG DGKvirP+CpDeA== From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_1E1E0E1F-304E-4523-857E-9BD289A2117C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <03F73286-C983-44C6-B10D-7E826AE2C609@padl.com> References: <158562149038.11496.7234948048087895644@ietfa.amsl.com> To: "kitten@ietf.org" Date: Tue, 31 Mar 2020 13:28:11 +1100 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [kitten] Fwd: New Version Notification for draft-howard-gss-sanon-00.txt X-BeenThere: kitten@ietf.org 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: Tue, 31 Mar 2020 02:28:41 -0000 --Apple-Mail=_1E1E0E1F-304E-4523-857E-9BD289A2117C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi everybody, Below is a specification for a simple anonymous mechanism based on = curve25519 that does not authenticate either initiator or acceptor. An implementation can be found at: = https://github.com/PADL/heimdal/tree/lukeh/sanon/lib/gssapi/sanon = Cheers, Luke > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-howard-gss-sanon-00.txt > Date: 31 March 2020 at 1:24:50 pm AEDT > To: "Luke Howard" >=20 >=20 > A new version of I-D, draft-howard-gss-sanon-00.txt > has been successfully submitted by Luke Howard and posted to the > IETF repository. >=20 > Name: draft-howard-gss-sanon > Revision: 00 > Title: A Simple Anonymous SASL and GSS-API Mechanism > Document date: 2020-03-30 > Group: Individual Submission > Pages: 12 > URL: = https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-00.txt > Status: = https://datatracker.ietf.org/doc/draft-howard-gss-sanon/ > Htmlized: https://tools.ietf.org/html/draft-howard-gss-sanon-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon >=20 >=20 > Abstract: > This document defines protocols, procedures and conventions for a > Generic Security Service Application Program Interface (GSS-API) > security mechanism that provides key agreement without = authentication > of either party. Through the GS2 family of mechanisms defined in = RFC > 5801, these protocols also define how Simple Authentication and > Security Layer (SASL, RFC 4422) applications may use this mechanism. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_1E1E0E1F-304E-4523-857E-9BD289A2117C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = everybody,

Below is a specification for a simple anonymous mechanism = based on curve25519 that does not authenticate either initiator or = acceptor.

An = implementation can be found at: https://github.com/PADL/heimdal/tree/lukeh/sanon/lib/gssapi/san= on

Cheers,
Luke

Begin= forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-howard-gss-sanon-00.txt
Date: = 31 March 2020 at 1:24:50 pm = AEDT
To: = "Luke Howard" <lukeh@padl.com>

A new version of I-D, draft-howard-gss-sanon-00.txt
has been successfully submitted by Luke Howard and posted to = the
IETF repository.

Name: = draft-howard-gss-sanon
Revision: 00
Title:= = A Simple Anonymous SASL and GSS-API Mechanism
Document date: 2020-03-30
Group:= = Individual Submission
Pages: 12
URL: =            https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-00.= txt
Status: =         https://datatracker.ietf.org/doc/draft-howard-gss-sanon/Htmlized:       https://tools.ietf.org/html/draft-howard-gss-sanon-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon


Abstract:
=   This document defines protocols, procedures and conventions = for a
  Generic Security Service Application = Program Interface (GSS-API)
  security = mechanism that provides key agreement without authentication
  of either party.  Through the GS2 family of = mechanisms defined in RFC
  5801, these = protocols also define how Simple Authentication and
=   Security Layer (SASL, RFC 4422) applications may use this = mechanism.




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.

The IETF = Secretariat



= --Apple-Mail=_1E1E0E1F-304E-4523-857E-9BD289A2117C-- From nobody Tue Mar 31 16:37:07 2020 Return-Path: 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 77F803A0D23 for ; Tue, 31 Mar 2020 16:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.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 RypwU-LrHfYY for ; Tue, 31 Mar 2020 16:37:04 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B4A3A0D97 for ; Tue, 31 Mar 2020 16:36:57 -0700 (PDT) Received: by us.padl.com with ESMTP id 02VNan2b030342; Tue, 31 Mar 2020 23:36:55 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 02VNan2b030342 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1585697815; bh=GpFxU3IdpatI5wWzvjBpUItyQqHpc6spfG5UUG7zdHk=; h=From:Subject:Date:References:To:In-Reply-To:From; b=nqjf4RVzNiouB3T0i+ElrbllgJyHspLxMYg/FhlFV5M/XlrCyTwZ2ijgg7wEqwu4m QIxuE9q1zCmUHqYIwSePUMiCCh6/6YPO73q5NTMxPT5djD3KnBzMR5ZEtqEXcmUIhe 46F/jt2jx0ozYiHb7GIvnBsDeigdSKDAVGhMWCIcGjJZBWcguK2B8mLCWHFYgk18ID NHNFQ4DS9fpX2GAsswaN83a2TfVmfCoejbN0w9sIqW9/Cs2JyQ7LTJDJH4rsXmDmFS vnzYyA0tJPAcOVIaRQveqUSzOQSbAmCeVnKZbwAaS1Ge3ZhgYk//zUVtAhj7q2hl/T EBt6X9NNGlBRw== From: Luke Howard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 1 Apr 2020 10:36:32 +1100 References: <158562149038.11496.7234948048087895644@ietfa.amsl.com> <03F73286-C983-44C6-B10D-7E826AE2C609@padl.com> To: "kitten@ietf.org" In-Reply-To: <03F73286-C983-44C6-B10D-7E826AE2C609@padl.com> Message-Id: <135C8753-9355-41F8-9A46-9D25502AA070@padl.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-00.txt X-BeenThere: kitten@ietf.org 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: Tue, 31 Mar 2020 23:37:06 -0000 A couple of things I=E2=80=99ll fix in the next draft: 3. Discovery and Negotiation =E2=80=A6 The selection of SAnon is subject to local policy. If anonymity is not desired, mechanisms that provide authentication SHOULD be preferred. Initiators use GSS_C_ANON_FLAG to indicate that anonymous authentication is desired; either parties can test this flag to check if it was performed. and 4.1.2. GSS_C_NT_HOSTBASED_SERVICE This name type is typically used by acceptors to identify a host- based service. To allow existing applications to work unmodified with SAnon, it is useful to allow anonymous acceptor credentials to be acquired regardless of the service name. (Because SAnon does not set GSS_C_MUTUAL_FLAG, the acceptor identity may be safely ignored.) When importing a name of this type the name string SHOULD be ignored. Thoughts on how to support RFC 5801 without setting GSS_C_MUTUAL_FLAG = are welcome. =E2=80=94 Luke=