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

Dave Cridland <> Wed, 25 March 2020 23:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 312693A03F2 for <>; Wed, 25 Mar 2020 16:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3qg2fTPdtPXl for <>; Wed, 25 Mar 2020 16:12:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8226A3A0123 for <>; Wed, 25 Mar 2020 16:12:36 -0700 (PDT)
Received: by 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;; 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;; 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: <> <> <> <>
In-Reply-To: <>
From: Dave Cridland <>
Date: Wed, 25 Mar 2020 23:12:22 +0000
Message-ID: <>
To: Alexey Melnikov <>
Cc: Greg Hudson <>,
Content-Type: multipart/alternative; boundary="000000000000dac4db05a1b60056"
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 23:12:47 -0000

On Wed, 25 Mar 2020 at 18:06, Alexey Melnikov <>

> 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