Discussion:
2.4.2 and auth-token
(too old to reply)
Steven Haigh
2017-06-12 05:47:24 UTC
Permalink
Raw Message
Hi all,

I'm trying to get renegotiation working with openvpn 2.4.2 using a YubiKey.

I have had no issues creating a auth-user-pass-verify script to validate the
password provided by the Yubikey and this works well.

When renegotiation happens, I notice that the password line in the file
provided (as $ARGV[0]) is the original password and not the auth-token pushed
on the initial connect.

My script is then trying to revalidate an OTP - which of course fails and the
connection dies.

When an auth-token is pushed to the client, how do I get it back to the server
during the renegotiation?

Am I wrong in expecting the token to be in the $password field? Is this a bug?
Configuration issue?

Thanks.
--
Steven Haigh

📧 ***@crc.id.au 💻 http://www.crc.id.au
📞 +61 (3) 9001 6090 📱 0412 935 897
Steven Haigh
2017-06-12 06:13:14 UTC
Permalink
Raw Message
Post by Steven Haigh
Hi all,
I'm trying to get renegotiation working with openvpn 2.4.2 using a YubiKey.
I have had no issues creating a auth-user-pass-verify script to validate the
password provided by the Yubikey and this works well.
When renegotiation happens, I notice that the password line in the file
provided (as $ARGV[0]) is the original password and not the auth-token
pushed on the initial connect.
My script is then trying to revalidate an OTP - which of course fails and
the connection dies.
When an auth-token is pushed to the client, how do I get it back to the
server during the renegotiation?
Am I wrong in expecting the token to be in the $password field? Is this a
bug? Configuration issue?
Thanks.
Also, for what its worth, if I disable the 'client-connect' script and enable
the 'auth-gen-token' option on the server, I get the following error when
reneg-sec is hit:

TLS Auth Error: Auth-token verification failed for username '$username' [CN
SET]
--
Steven Haigh

📧 ***@crc.id.au 💻 http://www.crc.id.au
📞 +61 (3) 9001 6090 📱 0412 935 897
David Sommerseth
2017-06-12 08:47:33 UTC
Permalink
Raw Message
Post by Steven Haigh
Post by Steven Haigh
Hi all,
I'm trying to get renegotiation working with openvpn 2.4.2 using a YubiKey.
I have had no issues creating a auth-user-pass-verify script to validate the
password provided by the Yubikey and this works well.
When renegotiation happens, I notice that the password line in the file
provided (as $ARGV[0]) is the original password and not the auth-token
pushed on the initial connect.
My script is then trying to revalidate an OTP - which of course fails and
the connection dies.
When an auth-token is pushed to the client, how do I get it back to the
server during the renegotiation?
Am I wrong in expecting the token to be in the $password field? Is this a
bug? Configuration issue?
When the server pushes 'auth-token $VALUE' to the client, the client
will replace the locally cached password with the token. But beware,
there are currently some collision if the client uses --auth-nocache.
The --auth-nocache tells the client to never cache any passwords, which
also hits pushed auth-tokens. Patches are on the devel-ML for review,
so I hope we'll get this fixed in not too long.
Post by Steven Haigh
Also, for what its worth, if I disable the 'client-connect' script and enable
the 'auth-gen-token' option on the server, I get the following error when
TLS Auth Error: Auth-token verification failed for username '$username' [CN
SET]
I'm the one who implemented the auth-gen-token feature, so I have
interests in these issues :) But this sounds even more like a
--auth-nocache collision.
--
kind regards,

David Sommerseth
OpenVPN Technologies, Inc
Steven Haigh
2017-06-12 08:55:00 UTC
Permalink
Raw Message
Post by David Sommerseth
Post by Steven Haigh
Post by Steven Haigh
Hi all,
I'm trying to get renegotiation working with openvpn 2.4.2 using a YubiKey.
I have had no issues creating a auth-user-pass-verify script to validate
the password provided by the Yubikey and this works well.
When renegotiation happens, I notice that the password line in the file
provided (as $ARGV[0]) is the original password and not the auth-token
pushed on the initial connect.
My script is then trying to revalidate an OTP - which of course fails and
the connection dies.
When an auth-token is pushed to the client, how do I get it back to the
server during the renegotiation?
Am I wrong in expecting the token to be in the $password field? Is this a
bug? Configuration issue?
When the server pushes 'auth-token $VALUE' to the client, the client
will replace the locally cached password with the token. But beware,
there are currently some collision if the client uses --auth-nocache.
The --auth-nocache tells the client to never cache any passwords, which
also hits pushed auth-tokens. Patches are on the devel-ML for review,
so I hope we'll get this fixed in not too long.
Ok - this sounds promising. I'm currently using the stock epel packages on EL7
and Fedora packages.
Post by David Sommerseth
Post by Steven Haigh
Also, for what its worth, if I disable the 'client-connect' script and
enable the 'auth-gen-token' option on the server, I get the following
TLS Auth Error: Auth-token verification failed for username '$username' [CN
SET]
I'm the one who implemented the auth-gen-token feature, so I have
interests in these issues :) But this sounds even more like a
--auth-nocache collision.
I did trawl through *many* references with your name tagged, so kind of good
to know ;)

So the client config is generated via NetworkManager. To validate this, is
there a way to:
1) Verify it uses auth-nocache
2) Tell it not to?
--
Steven Haigh

📧 ***@crc.id.au 💻 http://www.crc.id.au
📞 +61 (3) 9001 6090 📱 0412 935 897
Loading...