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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Alexey Melnikov

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: [hidden email]
Reply-To: [hidden email]
To: [hidden email]



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
[hidden email]
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
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Florian Schmaus
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Dave Cridland
In reply to this post by Alexey Melnikov
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 <[hidden email]> 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: [hidden email]
Reply-To: [hidden email]
To: [hidden email]



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
[hidden email]
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
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Alexey Melnikov
In reply to this post by Florian Schmaus
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
In reply to this post by Alexey Melnikov
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.)

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

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.

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


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Dave Cridland


On Wed, 25 Mar 2020 at 18:06, Alexey Melnikov <[hidden email]> 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 <https://xmpp.org/extensions/xep-0400.html>

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
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Simon Josefsson-2
In reply to this post by Alexey Melnikov
Thanks for working on this.  What we discovered with the OpenID/SAML
SASL mechanisms was that a major challenge was to resolve how to resume
sessions in a SASLy way.  To be more specific, the challenge is that a
lot of client applications (IMAP in particlar) expect to be able to open
several sessions to the server.  Having a user perform manual steps per
session won't work, and from a quick look at your document, it looks
like this problem isn't resolve here either.  What is needed is some way
to perform the 2FA authentication once, and then be able to refer to
that authentication in a new SASL authentication step.  With re-newed
energy and interest in this, I beliece we can do better now though.
Some ideas:

1) Specify how TLS resumption of a SASL authenticated session should
assume the same SASL authentication/authorization identity.

2) Specify how EXTERNAL (or some new mechanism) is to be used to
"resume" an earlier 2FA authenticated SASL session.

3) Describe how OAUTH could be used to achieve this.

4) Extend your proposal to generate a magic cookie after successful
authentication that can be provided instead of the 2FA code next time.

The problem is not exactly how to do it: it is to describe one
well-agreed on method that all application implementers can follow, to
get interoperability.

I believe it is a bad idea to implement a generic 2FA mechanism on top
of SCRAM, it will be too flexible with bad interop as a result.
Instead, implement specific 2FA methods so things become easily
implementable.  Your document could be a SCRAM-OATH-TOTP rather than
SCRAM-2FA.  OATH-HOTP/TOTP, U2F, FIDO2, etc each have different
behaviours that make it difficult to support in a generic protocol.

/Simon

Alexey Melnikov <[hidden email]> writes:

> 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: [hidden email]
> Reply-To: [hidden email]
> To: [hidden email]
>
>
>
>
> 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
> [hidden email]
> 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
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten
>

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Alexey Melnikov
Hi Simon,

On 03/04/2020 17:29, Simon Josefsson wrote:

> Thanks for working on this.  What we discovered with the OpenID/SAML
> SASL mechanisms was that a major challenge was to resolve how to resume
> sessions in a SASLy way.  To be more specific, the challenge is that a
> lot of client applications (IMAP in particlar) expect to be able to open
> several sessions to the server.  Having a user perform manual steps per
> session won't work, and from a quick look at your document, it looks
> like this problem isn't resolve here either.  What is needed is some way
> to perform the 2FA authentication once, and then be able to refer to
> that authentication in a new SASL authentication step.  With re-newed
> energy and interest in this, I beliece we can do better now though.
> Some ideas:
>
> 1) Specify how TLS resumption of a SASL authenticated session should
> assume the same SASL authentication/authorization identity.
I don't think this will fly, as TLS resumption is usually unaware of
SASL state. At least this is how it is commonly implemented in Email
clients or servers.
> 2) Specify how EXTERNAL (or some new mechanism) is to be used to
> "resume" an earlier 2FA authenticated SASL session.
I don't think SASL EXTERNAL is a good fit here. I think David Cridland's
CLIENTKEY
<https://tools.ietf.org/id/draft-cridland-kitten-clientkey-00.txt> is
what you describe and I agree that we should pursue standardizing it.
> 3) Describe how OAUTH could be used to achieve this.
Right, on my to do list. If somebody would like to volunteer to co-edit
with me, that would speed things up.
> 4) Extend your proposal to generate a magic cookie after successful
> authentication that can be provided instead of the 2FA code next time.
Sure, I can add this.

> The problem is not exactly how to do it: it is to describe one
> well-agreed on method that all application implementers can follow, to
> get interoperability.
>
> I believe it is a bad idea to implement a generic 2FA mechanism on top
> of SCRAM, it will be too flexible with bad interop as a result.
> Instead, implement specific 2FA methods so things become easily
> implementable.  Your document could be a SCRAM-OATH-TOTP rather than
> SCRAM-2FA.  OATH-HOTP/TOTP, U2F, FIDO2, etc each have different
> behaviours that make it difficult to support in a generic protocol.

With addition of SCRAM-SHA-256, SCRAM-SHA-512 and possibly SCRAM-SHA-3,
I am worried about combinatorial explosion of names of SCRAM variants,
that need to accommodate both new hash algorithms and 2FA methods. Maybe
we should just settle on a small (or just 1) 2FA for now, but make it
swappable for  something better in the future?


Best Regards,

Alexey


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten