WireGuard itself doesn't even handle its existing authentication fully -- you are expected to exchange peer public keys out of band. There are several projects that try to tackle this public key exchange. I think what you're asking for, indirectly, is support for certificate authority style authentication similar to how SSH CAs work, so that wireguard could authenticate tunnels using certificates with signed pubkeys instead of statically configured pubkeys themselves for each peer.

If the wireguard core included any kind of timed partial delegation of authority through key signatures (similar to what SSH allows now with cert-authority/CertificateFile), that'd be enough to build SMS/HOTP/TOTP 2FA, security keys, and much more on top of it.

Think of wireguard as the plumbing. There will be a plethora of things available on top of wireguard that will enable all sorts of easy authentication options. (For example, TailScale.)

How this plumbing is expected to be implemented? For example Cloudflare Warp uses Wireguard for its VPN solution, but all key exchanges and other stuff happens via HTTPS REST calls. Is it expected for any non-trivial implementation to build a different "control" protocol? For me it sounds like a dangerous approach. While wireguard protocol will be safe and audited, those additional proprietary protocols will hinder cross-platform usage (for example you had to use reverse-engineered Cloudflare Warp implementation for Linux until recently and I guess that BSDs will use it forever) and might expose security vulnerabilities on their own.

Yes, you are exactly right. Wireguard is a typical example of a thing I'd call myopic-cryptographer-protocol. Solve one problem in the minimal fashion that can be called proof-of-concept, do it in a maybe-more-secure way and call it done. Everything else, like proper key distribution and user management, which you need for a real-world deployment that isn't just a personal toy, is left as an exercise to the reader. All the readers will screw up in different ways, after which the myopic cryptographer will explain that his protocol was of course perfect and there is nothing wrong with it, you are just holding it wrong...

That's one way to look at it.

Another would be "Do one thing and do it well", which is Unix philosophy.

https://en.m.wikipedia.org/wiki/Unix_philosophy

Another might be that existing VPN solutions will gut the bottom of their stack and use WireGuard for that, thereby reducing complexity and increasing performance.

I think there's already some that do that iirc.

I think this was the point of WG. OpenVPN/IPSec/etc are beasts since they include all of the above. OpenVPN is TLS based! That makes adding it into the kernel difficult, and you need kernel access or exotic stuff like VPP/DPDK for speed.

I do agree with your overall sentiment, though. The next step is to make a higher level protocol on top.

Not all parts of a system are going to age equally well.

You are going to want to try to avoid that problem, while making your tool still useful. Wireguard hits the sweet spot particularly well.

If people want Wireguard to be a complete multiplatform audited free enterprise VPN solution they need to donate more. A lot more.

Nobody really needs enterprise VPN crap, that stuff does far too much weird stuff that is totally unrelated to what a VPN should do, like patch management, malware scanning, firewalling, and other useless box-ticking.

What we do need is a proper replacement for roughly the things OpenVPN plus PAM can do. A VPN plus some user and key management.

It is a completely reasonable requirement of a large organization to ensure an endpoint meets certain criteria before being allowed access to an internal network.

I'm not arguing that Wireguard has an obligation to tackle that problem themselves. I'm arguing against your assertion that VPN access should be completely decoupled from ensuring endpoint security.

Lets be honest, any malicious endpoint can easily bypass those 'endpoint security' checks.

All they're good for is checking that unpatched (but not yet exploited/evil) endpoints can't connect to the network, which is of marginal benefit compared to allowing them to connect but requiring they patch before accessing risky resources (like the internet or email).

Not all compromised machines are the same. Is the user of the machine an insider threat or not? Does the login user have admin rights to the machine or not? And what you said in the last sentence is exactly how some VPN solutions can be configured: Limited access to network resources for updates and management, and only when fully matching version/anti-malware/etc. requirements can you connect to all resources.

Anyway. Like I said, I think Wireguard is amazing - I used PiVPN (which can be installed on any .deb distro) to set up a simple gateway for my laptop and phone to be always connected for DNS and local-network access. I'm very grateful for its architecture and simplicity in that regard.

I think there's an external issue here though. There might be regulation or some sort of liability concern regarding known unpatched clients connecting to the network. In that context simple checks make a lot of sense.

Even if they donate more that won't happen. It's antithetical to the premise of the whole project. WireGuard is fine where it is, it's amazing.

Related: Does anyone know of a PKI-on-WireGuard implementation? Specifically I'm looking for a system that lets clients join the WireGuard network by presenting a CA-signed certificate.

I mean, re-inventing IPsec is probably inevitable anyway.

Sadly I haven’t found anything. All there is are those curv25519 key pairs last i looked which is a real pain to manage at any scale, can’t be setup with a ttl etc. That’s probably main value proposition of products like Tailscale tbh

And will, themselves, lead to a new kind of incompatibility mess...

"Oh, I'm afraid the EasySecureAuth wireguard server doesn't support the AndroidWireClient client when using a Yubikey version 1. Either use version 2 or switch to iOS."

Tailscale solves all these problems, including SSO.

Can you tell I’m a very happy customer?

Do you have any Windows systems in your network? I am looking to restrict RDP sessions to a closed Wireguard network.

We did for a couple new people and then replaced them with Macs (for irrelevant reasons).

But while they were on Windows, Tailscale worked perfectly on their machines too.

Adding features like this that should be implemented on a different layer is the perfect way to turn it to the OpenVPN mess

Isn’t that just a roundabout way of asking for PSK support (which it already has)?

I think you'll have to use other options for that. I don't see them ever implementing 2FA as that is outside the goals of the project. They want to keep it has slim, performant, and on target as possible.

WireGuard is not MFA, but the user's private key could probably be stored in a smart-card instead of on disk. Software changes would need to be made so the key is read from the card instead of specified in the wgx.conf file.

To achieve true MFA, it would need either a password, TOTP, or SMS in addition to the stored keys.

Nope, can't. Storing a Wireguard key on a Smartcard isn't possible, because current cards do not support the key format and algorithms Wireguard uses. Only RSA and ECDSA on NIST curves are available on Smartcards. And "reading" the key from the card would make the card useless, the important feature of a smartcard is that it doesn't ever make the key available for reading. Instead, the key is used for signing or decrypting _on the card_ only. If you can really read a key off of a smartcard, sue the manufacturer and never use the key or card again.

Wireguard uses perfect forward secrecy, so wouldn't signing the ephemeral session once with the hardware key do the job? Or do they need some more advanced operations that the devices don't expose?

No, you just need a signature. But an Ed25519 signature, which current commercially available smartcards just cannot do.

You could be hacking something together with a Nitrokey or maybe Yubikey, those can do Ed25519 signatures. But generally, you would need to fiddle a lot with the implementation, because currently signatures are done in the kernel module, and you'd need to get that into the USB-device for signing and back again. Not impossible, but not implemented yet.

Another way would (theoretically) be to implement different signature algorithms for the wireguard key exchange, ideally some that common smartcards do support. But wireguards author left out cryptographic agility on purpose, so any work in that direction will be incompatible with the original implementation, or at least a very ugly kludge.

WireGuard does not use Ed25519. Indeed, it does not use any public-key signature algorithms at all. The long-lived static key (the peer's public key, their identity) is a Curve25519 ECDH key.

Of course, there are smartcards that could do this, you're just not allowed to have them. Plenty of smartcards nowadays are just flash and an ARM core which theoretically could be programmed arbitrarily. These tend to be used for credit cards, etc. Of course they might have acceleration units for specific algorithms like NIST ECDSA but I'd be surprised if Ed25519 couldn't be accommodated.

Unfortunately they're all NDAware, so they may as well not exist. ...But of course I've written about my extensive issues with the smartcard industry before.

You'll have to write some glue code, but if all you need is standard Ed25519 signatures, current-gen Yubikeys can do this. Somebody's implemented a python library that does that here https://github.com/tschudin/sc25519

> Storing a Wireguard key on a Smartcard isn't possible, because current cards do not support the key format and algorithms Wireguard uses. Only RSA and ECDSA on NIST curves are available on Smartcards.

There are programmable smartcards on which you can implement your own algorithm. ZeitControl sells cards you can program in a BASIC dialect: https://www.zeitcontrol.de/de/produkte/basiccard/basiccard-p...

Technically if the card could sign fast enough, you could sign packets on the card.

WireGuard seems to use symmetric key crypto for packet encdec. The card would need to sign only the handshake, which occurs "every few minutes"[1] and "is done based on time, and not based on the contents of prior packets"[1].

1: https://www.wireguard.com/protocol/

You only need to sign the packets in the key exchange on the card. The normal payload packets are protected by symmetric algorithms based on the ephemeral symmetric key generated in the key exchange, no need (and no use) to involve the smartcard there.

Pritunl has wireguard support and works well for this