* 2-factor auth options @ 2017-09-21 19:21 Konstantin Ryabitsev 2017-09-21 22:18 ` David Woodhouse ` (2 more replies) 0 siblings, 3 replies; 6+ messages in thread From: Konstantin Ryabitsev @ 2017-09-21 19:21 UTC (permalink / raw) To: wireguard [-- Attachment #1: Type: text/plain, Size: 433 bytes --] 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2-factor auth options 2017-09-21 19:21 2-factor auth options Konstantin Ryabitsev @ 2017-09-21 22:18 ` David Woodhouse 2017-09-21 22:52 ` Jason A. Donenfeld 2017-09-22 14:39 ` Joe Doss 2 siblings, 0 replies; 6+ messages in thread From: David Woodhouse @ 2017-09-21 22:18 UTC (permalink / raw) To: Konstantin Ryabitsev, wireguard [-- Attachment #1: Type: text/plain, Size: 690 bytes --] On Thu, 2017-09-21 at 15:21 -0400, Konstantin Ryabitsev wrote: > 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. > 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. > c. (some other means) [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 4938 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2-factor auth options 2017-09-21 19:21 2-factor auth options Konstantin Ryabitsev 2017-09-21 22:18 ` David Woodhouse @ 2017-09-21 22:52 ` Jason A. Donenfeld 2017-09-22 14:45 ` Konstantin Ryabitsev 2017-09-22 14:39 ` Joe Doss 2 siblings, 1 reply; 6+ messages in thread From: Jason A. Donenfeld @ 2017-09-21 22:52 UTC (permalink / raw) To: Konstantin Ryabitsev; +Cc: WireGuard mailing list 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2-factor auth options 2017-09-21 22:52 ` Jason A. Donenfeld @ 2017-09-22 14:45 ` Konstantin Ryabitsev 2017-09-22 23:19 ` Jason A. Donenfeld 0 siblings, 1 reply; 6+ messages in thread From: Konstantin Ryabitsev @ 2017-09-22 14:45 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list On Fri, Sep 22, 2017 at 12:52:43AM +0200, Jason A. Donenfeld wrote: >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. >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). >(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. >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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2-factor auth options 2017-09-22 14:45 ` Konstantin Ryabitsev @ 2017-09-22 23:19 ` Jason A. Donenfeld 0 siblings, 0 replies; 6+ messages in thread From: Jason A. Donenfeld @ 2017-09-22 23:19 UTC (permalink / raw) To: Konstantin Ryabitsev; +Cc: WireGuard mailing list On Fri, Sep 22, 2017 at 4:45 PM, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote: > 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... > On Fri, Sep 22, 2017 at 12:52:43AM +0200, Jason A. Donenfeld wrote: > 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? > 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. > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2-factor auth options 2017-09-21 19:21 2-factor auth options Konstantin Ryabitsev 2017-09-21 22:18 ` David Woodhouse 2017-09-21 22:52 ` Jason A. Donenfeld @ 2017-09-22 14:39 ` Joe Doss 2 siblings, 0 replies; 6+ messages in thread From: Joe Doss @ 2017-09-22 14:39 UTC (permalink / raw) To: wireguard On 09/21/2017 02:21 PM, Konstantin Ryabitsev wrote: > 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 joe@solidadmin.com ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-09-22 22:51 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-09-21 19:21 2-factor auth options Konstantin Ryabitsev 2017-09-21 22:18 ` David Woodhouse 2017-09-21 22:52 ` Jason A. Donenfeld 2017-09-22 14:45 ` Konstantin Ryabitsev 2017-09-22 23:19 ` Jason A. Donenfeld 2017-09-22 14:39 ` Joe Doss
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).