2-factor auth options

2-factor auth options

[Konstantin Ryabitsev]

[-- 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 --]

Re: 2-factor auth options

[David Woodhouse]

[-- 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 --]

Re: 2-factor auth options

[Jason A. Donenfeld]

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

Re: 2-factor auth options

[Joe Doss]

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

Re: 2-factor auth options

[Konstantin Ryabitsev]

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

Re: 2-factor auth options

[Jason A. Donenfeld]

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