PVE 7.1 - U2F broken, confused about WebAuthn

[David Herselman]

U2F mult-factor authentication is unfortunately broken after upgrading to PVE 7.1:



We had previously set the U2F AppID to point at a JSON document on a redundant web hosting service 'https://u2f.company.co.za/kvm1-appid', where this file contained a list of the possible facets that it would be allowed to interact with:

{
  "trustedFacets" : [{
    "version": { "major": 1, "minor" : 0 },
    "ids": [
      "https://kvm1.company.co.za:8006",
      "https://kvm1a.company.co.za:8006",
      "https://kvm1b.company.co.za:8006",
      "https://kvm1c.company.co.za:8006",
      "https://kvm1d.company.co.za:8006",
      "https://kvm1e.company.co.za:8006",
      "https://kvm1f.company.co.za:8006",
    ]
  }]
}

The following article details that this behaviour is not available with WebAuthn, you have to use a sub domain for multiple hosts:
https://www.stackallocated.com/blog/2019/u2f-to-webauthn/



We are lucky enough to have all our Staff Yubico public portion identifiers on record and could subsequently depreciate U2F as a 2nd authentication factor and switch over to Yubikey OTP integration. We can subsequently start with WebAuthn fresh without locking our staff out of the PVE hosts. Anyone interested in also switching over in a pinch can review this forum post: https://forum.proxmox.com/threads/webauthn-registration-failed.99861/post-431848


Right, so my understanding is that U2F is legacy and that we should be transitioning over to WebAuthn. We have several clusters that we wish to provide WebAuthn on, where these have a common TLD domain (company.co.za) in the following example.

The U2F method of defining the AppID, to be an URL that points at a JSON file containing all allowed facets (listing all URLs on the cluster member nodes) appears to be depreciated in WebAuthn so we need to set the Relying Party ID as the common TLD.

I'm aware of some things unfortunately temporarily being broken with this integration, as PVE 7.1 was released. I am however wanting to clarify what the Relying Party, Origin and ID should be setup to allow WebAuthn to work on any of the cluster nodes, part of separate clusters.


WebAuthn - PVE generated (non cluster aware):
Relying Party : kvm1a.company.co.za
Origin : https://kvm1a.company.co.za:8006
ID : kvm1a.company.co.za

If this cluster comprises of nodes kvm1a - kvm1f and I have other clusters such as kvm2a-kvm2i, kvm3a-kvm3h and so on should I structure each cluster's configuration as such:
WebAuthn - kvm1x.company.co.za (cluster aware):
Relying Party : company.co.za
Origin : https://u2f.company.co.za/kvm1-appid
ID : kvm1x.company.co.za


Pretty sure that whatever I've cooked together is wrong but also not sure what is currently broken with the WebAuthn integration in PVE 7.1 so would really appreciate some clarity on how we should set this up to allow WebAuthn to work on any node and allow our staff to register their tokens on any of the separate clusters that would ultimately all share a common Relying Party name...

 

[wbumiller]

Multi-facet U2F verification had indeed a bug, verifying the appid vs the origin which of course cannot work in this case.
As for webauthn with subdomains, this should work with the upcoming updates by setting the rp and id to the common tld, leaving out the origin (so each node fills it out for itself, as this is in the cluster-wide datacenter.cfg file).

Could you by any chance test u2f (and possibly webauthn) with libpve-access-control 7.1-4 and libpve-rs-perl 0.4.4 from the pvetest repository?

 

[David Herselman]

Hi Wolfgang,

I installed the two packages and can confirm that I can now use WebAuthn to login to any cluster member server, as long as I remove the 'origin' line from the datacenter.cfg file:

webauthn: id=company.co.za,rp=company.co.za

I'm unfortunately not able to test legacy U2F until this weekend, when we plan on upgrading our last cluster to PVE 7.1. This is quite simply due to me having not recorded the U2F details when I replaced it with Yubico OTP public prefixes. With U2F deprecated I don't appear to be able to register this anymore on upgraded nodes.


Some comments and feedback to make the multi-function validation feature more user friendly:

• Please filter the list of available multi-factor options at login to those that are setup, perhaps simply show enabled options first, if you want to use this as a way of showing users what options are available. Herewith a snippet when I login, when I only had 'Yubico OTP' and 'WebAuthn' enabled. It would be pretty hard for a user to know that 'hn' is 'WebAuthn':

• Whilst I like the feature of forcing MFA logins by associating it with the realm, it would be better to allow users to login with any of their registered second factors; but force users to register required factors at login. This would hopefully allow us to set eg 'Yubico OTP' and 'WebAuthn' as required registrations whilst enabling eg 'Recovery Key' but not forcing users to register for that method.
  Just to clarify, I want to require MFA, but not only one specific method. I essentially want users to be forced to register multiple methods where I can control which are optional and which are required.

Just a general shout out that I really appreciate the effort, dedication and attention to detail that makes Proxmox what it is!

 

[David Herselman]

We upgraded our last PVE 7.0 cluster to 7.1 this weekend. Didn't need to download the packages from testing as there were already superceding ones available via the enterprise repo:

[admin@kvm5b ~]# dpkg -l | grep -e libpve-access-control -e libpve-rs-perl
ii  libpve-access-control                7.1-5                          all          Proxmox VE access control library
ii  libpve-rs-perl                       0.4.4                          amd64        PVE parts which have been ported to Rust - Rust source code

U2F authentication unfortunately did not work. WebAuthn works perfectly with the following in /etc/pve/datacenter.cfg:

webauthn: id=company.co.za,rp=company.co.za

Is there an example on how to transfer oath 2nd factor authentication details to tfa.cfg?


The following is a working example of TOPT:

"admin1@pve":{"totp":[{"id":"09727a41-1b97-4b58-9115-e9cfdcc32eca","description":"key1","created":1638040785,"entry":"otpauth://totp/Proxmox%20VE%20%2D%20kvm1:admin%40pve?secret=UNVJCJ8S8XS214H76WZSOP2PUSJQY2EU&digits=6&algorithm=SHA1&period=30&issuer=Proxmox%20VE%20%2D%20kvm1"}]},

The following is an example of one user with a single and another with dual yubico OTPs:

"admin2@pve":{"yubico":[{"id":"a89f36bc-b16c-4290-8ec4-ac2cd87f520b","description":"key1","created":1638041705,"entry":"ccccccttttt1"}]},
"admin3@pve":{"yubico":[{"id":"b39b614d-b836-4de7-9774-32aaf0b39d10","description":"key1","created":1638041705,"entry":"ccccccttttt2"},{"id":"eed67df1-096d-4178-b2c2-be004738cafe","description":"key2","created":1638041705,"entry":"ccccccttttt3"}]},

The following is an example of WebAuthn:

"admin4@pve":{"webauthn":[{"id":"6ff83177-f541-4e22-ba99-48a2c2063190","description":"key1","created":1638043116,"entry":{"cred_id":[83,168,39,180,40,246,16,146,109,19,20,28,120,33,253,204,32,232,12,234,92,36,82,40,241,129,237,103,109,49,250,162,151,233,228,157,87,134,62,233,177,25,52,117,180,82,127,58,91,154,212,138,144,145,78,219,61,166,157,152,179,199,47,216],"cred":{"type_":"ES256","key":{"EC_EC2":{"curve":"SECP256R1","x":[43,139,136,200,38,9,55,161,9,25,234,221,116,80,237,220,62,66,130,202,133,168,244,94,188,54,102,183,75,38,205,212],"y":[51,61,57,112,231,128,194,167,53,236,252,195,89,12,34,107,66,70,40,100,223,158,113,44,110,248,54,55,51,206,220,76]}}},"counter":2}}],

Looking for help to structure a PVE 7.1 compatible OATH TFA entry in /etc/pve/priv/tfa.cfg. The following is as far as I've gotten but looking for the data prefix structures for the 'entry' field:

"admin5@pve":{"oath":[{"id":"6c645fd9-18ff-43da-a331-ff436c8a9bf0","description":"key1","created":1638041705,"entry":"LpZSNqjDudkveibbjIsxTwDcTNYV6vLftgdv666onElTfbNs81OXzFJLYaGHMY53P0a0zL3TTPzGNt2yZJ9fECyd60CVv4lduBqD4GN5ajpWLF=="}]},

PS: All uuids, passwords, hashes sanitised or deleted.