OTP and 'extra' in message.Authenticate

[Yury Sobolev]

Hi,

I would like to authenticate users with multi factor authentication. In particular, I would like to use WAMPCRA and OTP. Now, each by itself works fine. However, I am not sure how to make them both be required. I was thinking of passing in the OTP code inside the 'extra' parameter inside message.Authenticate. However, at the moment this is impossible as onChallenge only returns a signature.

Am I missing something?

-Yury

[Yury Sobolev]

Alright, here is what I propose. Please let me know if this does not mesh well with Autobahn's philosophy.

diff --git a/autobahn/autobahn/wamp/protocol.py b/autobahn/autobahn/wamp/protoco

index d92f729..bd38a65 100644

--- a/autobahn/autobahn/wamp/protocol.py

+++ b/autobahn/autobahn/wamp/protocol.py

@@ -414,7 +414,10 @@ class ApplicationSession(BaseSession):

             d = self._as_future(self.onChallenge, challenge)

 

             def success(signature):

-               reply = message.Authenticate(signature)

+               if isinstance(signature, message.Authenticate):

+                  reply = signature

+               else:

+                  reply = message.Authenticate(signature)

                self._transport.send(reply)

 

             def error(err):

Something similar can be cooked up for JS. There one can test for the return value being an Array. This is backwards compatible, yet allows onChallange to return a full Authenticate message. The benefit is being able to specify the 'extra' parameter. Please let me know what you think.

-Yury

[Tobias Oberstein]

Hi Yury,

sorry, this got lost on me. Catching up now.

We want to support what I think is your actual goal: https://github.com/tavendo/WAMP/issues/143

Maybe we should first discuss the details there, as code-wise, this will have multiple implications (incl. router).

Cheers,
/Tobias

[Yury Sobolev]

Hi Tobias,

No problem. Thanks for getting to this. In the meantime, I have been
experimenting with how to add OTP functionality in the minimally
invasive way. Here are my ideas so far:

1. By agreement, both the server and the client use
pbkdf2(original_hash, otp) as the new password hash. This is a
horrible hack, however it requires no changes to the current
infrastructure.

2. Piggyback the OTP inside the WAMP-CRA authentication using the
'extra' field. This is not very elegant, but would be the easiest to
implement router side. It would require the client to return something
like types.Signature(signature, otp) from onChallange. This would be
serialized to message.Authenticate(signature, otp), sent across the
wire, and made available to the authenticator. This would be backwards
compatible with the current onChallenge API provided the return type
is checked.

3. Allow several authentication-challenge steps. I think this is the
ideal solution, but it is more difficult to implement. When the router
receives HELLO, it sends out several challenges. It would send out a
WAMP-CRA challenge, and an OTP challenge, for example. These can be
distinguished by having an 'authmethod' field set inside 'extra'. The
client would respond to both challenges preserving the 'authmethod'
part of 'extra'. The router would then collect the responses, decide
on an authrole and authid, and welcome or deny the client. You can
even allow elaborate chains (sort of like PAM) where one
authentication method may be sufficient (cookie or ticket), or another
may be required (IP filter).

Looking forward to hearing from you.

-Yury

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Autobahn" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/autobahnws/R2ZL3sIlQ0Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> autobahnws+...@googlegroups.com.
> To post to this group, send email to autob...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/autobahnws/fbd0e5c9-966e-43f7-a2c0-80df98a49206%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Tobias Oberstein]

Hi Yury,

Am 15.03.2015 um 18:49 schrieb Yury Sobolev:
> Hi Tobias,
>
> No problem. Thanks for getting to this. In the meantime, I have been
> experimenting with how to add OTP functionality in the minimally
> invasive way. Here are my ideas so far:
>
> 1. By agreement, both the server and the client use
> pbkdf2(original_hash, otp) as the new password hash. This is a
> horrible hack, however it requires no changes to the current
> infrastructure.

Yeah, hack;)

>
> 2. Piggyback the OTP inside the WAMP-CRA authentication using the
> 'extra' field. This is not very elegant, but would be the easiest to
> implement router side. It would require the client to return something
> like types.Signature(signature, otp) from onChallange. This would be
> serialized to message.Authenticate(signature, otp), sent across the
> wire, and made available to the authenticator. This would be backwards
> compatible with the current onChallenge API provided the return type
> is checked.

Yes, this isn't that bad. It's a pragmatic approach that does the job
and is minimally invasive.

>
> 3. Allow several authentication-challenge steps. I think this is the
> ideal solution, but it is more difficult to implement. When the router
> receives HELLO, it sends out several challenges. It would send out a
> WAMP-CRA challenge, and an OTP challenge, for example. These can be
> distinguished by having an 'authmethod' field set inside 'extra'. The
> client would respond to both challenges preserving the 'authmethod'
> part of 'extra'. The router would then collect the responses, decide
> on an authrole and authid, and welcome or deny the client. You can
> even allow elaborate chains (sort of like PAM) where one
> authentication method may be sufficient (cookie or ticket), or another
> may be required (IP filter).

Having the analog of PAM chains mapped to WAMP using multiple
CHALLENGE/AUTHENTICATE message exchanges sounds very powerful.

But the design might be tricky (thoug we can steal from PAM), and it is
intrusive for implementations (their protocol state machines).

I don't have a final opinion yet .. 2) or 3). Not 1).

I think we should give this more thought first:

https://github.com/tavendo/WAMP/issues/143

and collect community opinion.

In any case, I support the goal of having state-of-the-art
authentication for WAMP.

"SCRAM + TOTP + Cookies" is my current candidate ...

Cheers,
/Tobias