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