Proper(!) authentication with a FIDO2/CTAP2 token
Hi, I have read a few articles here on Yubikey authentication, but they seem outdated in that they consider the FIDO2 tokens as an additional security measure, as opposed to using true passwordless authentication: https://devcentral.f5.com/articles/two-factor-authentication-using-yubikey-yubicloud-and-big-ip-ltm https://devcentral.f5.com/articles/two-factor-authentication-using-yubikey-yubicloud-and-apm What I want to achieve is granting a user VPN connection to a corporate network, requiring the user only to start the relevant F5 app on Windows, Mac, or Android and then touch her token to the back of her Android phone in order to connect. I can't see a reason why this should not be possible, and I would very much like help with setting it up. As far as I can tell, these are the prerequisites: A working APM for VPN access The user must have installed either BIG-IP Edge Client or the F5 Access Android app on the device which needs VPN, and the user must have completed an authentication using password + OTP earlier, in order for the client device to be remembered as a valid device. The user must have a FIDO2/CTAP2 token with NFC support, for example the Yubikey 5 NFC The admin must have a user database (e.g. Active Directory) which contains at least three attributes: user ID (sAMAccountName), Token public key (another string attribute), A third attribute to store client IDs/cookies is needed. It could be stored as an array in an AD attribute, or in a separate database. The public key of the token must have been recorded as an attribute of the user in the directory The security policies of the admin must allow a user to use VPN provided only that the connection is established from a device with a valid client ID for that user, and is authenticated by the users token. The F5 Access app on the Android phone must have functionality to let the user validate the token by touch, even if the VPN connection is being requested from another client. If the admin wants to prevent access by someone who has stolen both the users token and the users device, the access profile could additionally ask for the users password. The authentication could take place like this if the VPN is requested on an Android device: Before the user enters any credentials, the APM server sends a string (perhaps containing information about the time, session ID etc) to the client application and waiting for a signed version of that string to be returned. The client application will send the string to the token through NFC (or USB) using the CTAP2 protocol. The token then signs the string using its private key, which never leaves the chip in the token, and returns it to the client application. If the user requested VPN access on a device other than the Android, device, the user might have to start F5 Access on the Android device, the app The client application sends the signed version of the string back to the APM server. The APM server searches the user directory for the public key matching the public key returned as part of the signed string from the users token. APM verifies that the public key is indeed the one that has signed the string. Then, APM compares the client ID to the list of valid client IDs for the user to which the token is registered. If a valid client ID is found, the access policy can complete, the user gets a connectivity profile, and the VPN is connected. If the user requests VPN access on a device without NFC support, the user will have to enter his/her username and then start the F5 Access app on the phone so that the Android device can be used to communicate with the token. The client ID check serves as a secondary "ownership" authentication factor and this scenario uses no knowledge-based factors like a password, but they can easily be added if necessary.