2-factor auth options
Hello, all:
Is there any mechanism to add some kind of 2-factor authentication mechanism either via:
a. additional prompting for a HOTP/TOTP key sequence similar to how openvpn allows doing auth-user-pass in addition to certificate-based authentication
b. some way to use PGP Auth keys with wireguard so that keys stored on GnuPG-capable smartcards can be used for establishing a VPN connection.
c. (some other means)
Best,
-K
Quoted 8 lines · Konstantin Ryabitsev
Hello, all:
Is there any mechanism to add some kind of 2-factor authentication mechanism either via:
a. additional prompting for a HOTP/TOTP key sequence similar to how openvpn allows doing auth-user-pass in addition to certificate-based authentication
Remember things like Yubikeys can do [HT]OTP in hardware. Not as HID but actually generating the OTP on demand via PCSC.
Quoted 2 lines
b. some way to use PGP Auth keys with wireguard so that keys stored on GnuPG-capable smartcards can be used for establishing a VPN connection.
PKCS#11 might be a better choice than PGP.
Quoted 1 line
c. (some other means)
Hi Konstantin,
The easiest way would be to add OTP to the part of your infra that does the key exchange. That is, if you have some kind of HTTPS REST-based API or an SSH-based API, you can have the server not accept a new public key until the OTP challenge is satisfied.
Alternatively, you could do OTP in-band, in order to authorize that public key for a certain window of time before inactivity. In this scheme, you'd disallow access to the network segment based on firewall rules until a certain in-band challenge is made -- perhaps by contacting a certain sandboxed server and answering an OTP challenge there
(At some point it is planned for WireGuard to have an API for sending control messages directly to a public key, not via an IP address, which will provide another option for in-band challenges (in addition to dynamic configuration of IPs), but it's not immediately obvious that this actually simplifies things, which is why I haven't yet implemented the plan.)
What kind of infrastructure are you imagining? Is this for kernel.org?
Jason
Quoted 4 lines · Jason A. Donenfeld
The easiest way would be to add OTP to the part of your infra that does the key exchange. That is, if you have some kind of HTTPS REST-based API or an SSH-based API, you can have the server not accept a new public key until the OTP challenge is satisfied.
It may be the easiest and, with a web frontend, would allow doing something like U2F (bonus!), but it'll probably be fairly
unpopular because it would require a wholly disconnected step before establishing a connection. It's similar to what we do with gitolite and IP whitelisting -- you must run a command using your 2-factor auth token before your git push would succeed. It's seen lukewarm adoption and grumbling due to people's git pushes suddenly failing if their whitelisting expires.
Quoted 6 lines
Alternatively, you could do OTP in-band, in order to authorize that public key for a certain window of time before inactivity. In this scheme, you'd disallow access to the network segment based on firewall rules until a certain in-band challenge is made -- perhaps by contacting a certain sandboxed server and answering an OTP challenge there
That's very similar to the above. The upside is that it would make sure we don't have 2-factor stuff happening via a separate (potentially weaker) crypto channel than the rest of the session, but the downside is that it would complicate firewall management (e.g. reloading firewalls for some reason would require people to re-auth in order to regain access).
Quoted 6 lines
(At some point it is planned for WireGuard to have an API for sending control messages directly to a public key, not via an IP address, which will provide another option for in-band challenges (in addition to dynamic configuration of IPs), but it's not immediately obvious that this actually simplifies things, which is why I haven't yet implemented the plan.)
Yeah, having an in-band solution would be best. Maybe even something like what you suggested above, but implemented internally. For example, establishing an initial connection would satisfy one set of permitted IP routing, but performing some API action would apply additional rules. It would be hard to do this in a non-kludgy way, though.
Quoted 1 line
What kind of infrastructure are you imagining? Is this for kernel.org?
I don't have concrete plans at this time, but we do use openvpn for admin-level access (that requires 2-factor auth), and I was looking for feature parity to see if we should eventually plan to switch.
Best,
-K
Quoted 3 lines · Konstantin Ryabitsev
The upside is that it would make sure we
don't have 2-factor stuff happening via a separate (potentially weaker) crypto channel than the rest of the session,
That's not actually the case. If a normal IP packet goes through wireguard, if it a) comes from a wireguard interface (wg0), and b) is from a particular IP address, then it will be unforgeably bound to the peer public key that has that IP listed in his allowed-ips. There's a strong binding here, in otherwords, between src IPs of packets within a wireguard interface and the actual identity.
This means...
Quoted 5 lines · Jason A. Donenfeld
It may be the easiest and, with a web frontend, would allow doing something like U2F (bonus!), but it'll probably be fairly
unpopular because it would require a wholly disconnected step before establishing a connection.
This means that you actually wouldn't even need to do it with a webpage. You could add this as a step that just uses tcp via ncat in a simple script to send the challenge. That's the kind of thing you could even add as a PostUp section in a wg-quick(8) configuration, so that immediately after starting up the tunnel, the OTP script runs that prompts the user for their 2FA, ncats it to a trivial little daemon on the server, that then validates the pin and adjusts the firewall (or more trivially, adds an entry to an ipset object).
There are a lot of very easy ways to structure this. I think next week I'll try to put together a little OTP example for the contrib/ directory. Do you have a favorite OTP command line challenge response tool I should use for this?
Quoted 4 lines
For example,
establishing an initial connection would satisfy one set of permitted IP routing, but performing some API action would apply additional rules. It would be hard to do this in a non-kludgy way, though.
I actually think this wouldn't be too difficult to accomplish. Live-changing IP address ACLs usually isn't too difficult. If you're really into it, you can even do this all with ip-rule instead of iptables/ipset.
Quoted 3 lines
I don't have concrete plans at this time, but we do use openvpn for admin-level access (that requires 2-factor auth), and I was looking for feature parity to see if we should eventually plan to switch.
Cool. You should certainly plan to switch. We'll make this happen.
Jason
Quoted 4 lines · Konstantin Ryabitsev
Hello, all:
Is there any mechanism to add some kind of 2-factor authentication mechanism either via
Throwing my hat into this feature/idea. My company heavily uses Duo for 2FA and having support for it like we do with OpenVPN would allow us to move over to WireGuard easier. Duo uses a plugin to manage the 2FA workflow within OpenVPN. I am not sure if WireGuard could use something similar.
https://github.com/duosecurity/duo_openvpn/
Joe
--
Joe Doss
[email protected]