5 ms·

No, I don't think it does. The thing about simple, key-based authentication is that it's very extensible, without changing the actual protocol. What? Well, w

No, I don't think it does. The thing about simple, key-based authentication is that it's very extensible, without changing the actual protocol. What? Well, what Wireguard's auth actually means is that you can use whatever authentication you want to communicate a shared secret to both ends. Want to authenticate with, say, SSH keys? Sure- SSH into a server, run a command that generates a new Wireguard key, connect in with that key. LDAP? Same situation. Whatever SSO you want- as long as you can stick up authentication in front of a service that's able to pull bits from /dev/urandom. Multifactor? Sure. Wireguard does one thing well. What's missing is not features in Wireguard- it's the ecosystem around it to actually handle key management. For enterprises, Hashicorp Vault or something should probably look into supporting Wireguard; for smaller situations, some SSH-based key exchange, like the way Mosh handles things, seems reasonable. Complex, pluggable authentication is sometimes necessary...but you want as few implementations of it as possible, and you sure don't want it in the kernel if you can help it.

yardstick 7y ago
The problem is lots of organisations in the financial and medical worlds need 2FA. WireGuard needs a 2FA solution - It doesn’t have to be kernel based - but it does need to protect against someone grabbing a copy of the single factor auth in WireGuard (keypair). A solution that rotates/manages/provisions/etc these keypairs is still fundamentally single factor auth of the tunnel.
- tptacek 7y ago
  Nobody is arguing that there shouldn't be IdP-based WireGuard management systems. The point is that they are out of scope for the WireGuard project itself. WireGuard has an extremely straightforward configuration interface; if Okta wanted to manage WireGuard, they'd likely have no problem doing it.
  - yardstick 7y ago
    Is there any decent open source 2FA / IdP management systems at the moment that work with WireGuard?
    - ficklepickle 7y ago
      It has just landed in one distro. If there isn't yet, there certainly will be.
      - yardstick 7y ago
        You don’t need a distro for this, and WireGuard has been available and in use for several years. So in that time has anyone developed a practical 2FA solution that is compatible with it?
        tptacek 7y ago
        People have. I'm unaware of any published. It's not hard. Implementing a new IdP-integrated WireGuard authorizer is probably easier than understanding IPSEC or OpenVPN in sufficient detail to secure it.
    - marsokod 7y ago
      There are some attempts like subspace: https://github.com/subspacecloud/subspace https://github.com/subspacecloud/subspace but I have not found anything stable yet.
- XMPPwocky 7y ago
  > WireGuard needs a 2FA solution - It doesn’t have to be kernel based - but it does need to protect against someone grabbing a copy of the single factor auth in WireGuard (keypair). By this standard, no website supports 2FA- ultimately it's just a cookie that's used to authenticate requests, even though to get that cookie you may have to go through 2FA. Nothing prevents an attacker from just grabbing the session cookies. In fact, I doubt any VPN supports 2FA by this definition- it would mean requiring authentication on every packet. Instead, of course, what you do is do authentication once, when setting up a tunnel, and then use bearer tokens from then on.
  - yardstick 7y ago
    The session info in a browser is not persisted on disk as a long term config file that’s easy to copy and duplicate. Having a session key only ever exist in memory is completely different to storing WireGuard keys on a filesystem. Edit: Also OpenVPN, which is the tool I’m comparing it with, only ever has session keys in memory. The 2FA part (password+OTP) isn’t saved by OpenVPN.
  - labawi 7y ago
    Typical session tokens shouldn't be valid for days, months or even years, unlike a straightforward wireguard setup.
Spivak 7y ago
The problem is that a Wireguard key isn't a session token -- it isn't revoked when the connection ends or goes idle. It's more like an authorized SSH key which in most environments meets the bar for 1FA even if it requires 2FA to set up the key. WG has the concept of sessions already, the only change would be allowing a process in userspace to instrument the sessions directly without going through the key system. The the default key-routing system would be just one method of issuing and managing sessions making the core protocol even simpler!
- labawi 7y ago
  By sessions, do you mean the key agreement/initiation protocol, that is re-run every 2 or so minutes (with the keys having moderately overlapping validity)?

yardstick 7y ago

The problem is lots of organisations in the financial and medical worlds need 2FA. WireGuard needs a 2FA solution - It doesn’t have to be kernel based - but it does need to protect against someone grabbing a copy of the single factor auth in WireGuard (keypair). A solution that rotates/manages/provisions/etc these keypairs is still fundamentally single factor auth of the tunnel.

tptacek 7y ago
Nobody is arguing that there shouldn't be IdP-based WireGuard management systems. The point is that they are out of scope for the WireGuard project itself. WireGuard has an extremely straightforward configuration interface; if Okta wanted to manage WireGuard, they'd likely have no problem doing it.
- yardstick 7y ago
  Is there any decent open source 2FA / IdP management systems at the moment that work with WireGuard?
  - ficklepickle 7y ago
    It has just landed in one distro. If there isn't yet, there certainly will be.
    - yardstick 7y ago
      You don’t need a distro for this, and WireGuard has been available and in use for several years. So in that time has anyone developed a practical 2FA solution that is compatible with it?
      - tptacek 7y ago
        People have. I'm unaware of any published. It's not hard. Implementing a new IdP-integrated WireGuard authorizer is probably easier than understanding IPSEC or OpenVPN in sufficient detail to secure it.
  - marsokod 7y ago
    There are some attempts like subspace: https://github.com/subspacecloud/subspace https://github.com/subspacecloud/subspace but I have not found anything stable yet.
XMPPwocky 7y ago
> WireGuard needs a 2FA solution - It doesn’t have to be kernel based - but it does need to protect against someone grabbing a copy of the single factor auth in WireGuard (keypair). By this standard, no website supports 2FA- ultimately it's just a cookie that's used to authenticate requests, even though to get that cookie you may have to go through 2FA. Nothing prevents an attacker from just grabbing the session cookies. In fact, I doubt any VPN supports 2FA by this definition- it would mean requiring authentication on every packet. Instead, of course, what you do is do authentication once, when setting up a tunnel, and then use bearer tokens from then on.
- yardstick 7y ago
  The session info in a browser is not persisted on disk as a long term config file that’s easy to copy and duplicate. Having a session key only ever exist in memory is completely different to storing WireGuard keys on a filesystem. Edit: Also OpenVPN, which is the tool I’m comparing it with, only ever has session keys in memory. The 2FA part (password+OTP) isn’t saved by OpenVPN.
- labawi 7y ago
  Typical session tokens shouldn't be valid for days, months or even years, unlike a straightforward wireguard setup.

Spivak 7y ago

The problem is that a Wireguard key isn't a session token -- it isn't revoked when the connection ends or goes idle. It's more like an authorized SSH key which in most environments meets the bar for 1FA even if it requires 2FA to set up the key. WG has the concept of sessions already, the only change would be allowing a process in userspace to instrument the sessions directly without going through the key system. The the default key-routing system would be just one method of issuing and managing sessions making the core protocol even simpler!

labawi 7y ago
By sessions, do you mean the key agreement/initiation protocol, that is re-run every 2 or so minutes (with the keys having moderately overlapping validity)?