Roaming Authenticator vs Bound authenticator
Fatma AL Moqbali
Hodges, Jeff
What is the difference between Roaming Authenticator vs Bound authenticator ?
Fatma AL Moqbali
Hodges, Jeff
Thanks Jeff.But where did you find the definition ? I was looking for the specifications but I could not find the definition. There is small intro in the FIDO Technical Glossary but not as clear as you define it.
FIDO UAF Authenticator Commands v1.0
There are four types of authenticators defined in this document. These definitions are not normative (unless otherwise stated) and are provided merely for simplifying some of the descriptions.
The following is the rationale for considering only these 4 types of authenticators:
- Bound authenticators are typically embedded into a user's computing device and thus can utilize the host's storage for their needs. It makes more sense from an economic perspective to utilize the host's storage rather than have embedded storage. Trusted Execution Environments (TEE), Secure Elements and Trusted Platform Modules (TPM) are typically designed in this manner.
- First-factor roaming authenticators must have an internal storage for key handles.
- Second-factor roaming authenticators can store their key handles on an associated server, in order to avoid the need for internal storage.
- Defining such constraints makes the specification simpler and clearer for defining the mainstream use-cases.
Vendors, however, are not limited to these constraints. For example a bound authenticator which has internal storage for storing key handles is possible. Vendors are free to design and implement such authenticators as long as their design follows the normative requirements described in this document.
- First-factor Bound Authenticator
-
- These authenticators have an internal matcher. The matcher is able to verify an already enrolled user. If there is more than one user enrolled - the matcher can also identify a user.
- There is a logical binding between this authenticator and the device it is attached to (the binding is expressed through a concept called KeyHandleAccessToken). This authenticator cannot be bound with more than one device.
- These authenticators do not store key handles in their own internal storage. They always return the key handle to the ASM and the latter stores it in its local database.
- Authenticators of this type may also work as a second factor.
- Examples
-
- A fingerprint sensor built into a laptop, phone or tablet
- Embedded secure element in a mobile device
- Voice verification built into a device
- Second-factor (2ndF) Bound Authenticator
-
- This type of authenticator is similar to first-factor bound authenticators, except that it can operate only as the second-factor in a multi-factor authentication
- Examples
-
- USB dongle with a built-in capacitive touch device for verifying user presence
- A "Trustlet" application running on the trusted execution environment of a mobile phone, and leveraging a secure keyboard to verify user presence
- First Factor (1stF) Roaming Authenticator
-
- These authenticators are not bound to any device. User can use them with any number of devices.
- It is assumed that these authenticators have an internal matcher. The matcher is able to verify an already enrolled user. If there is more than one user enrolled - the matcher can also identify a user.
- It is assumed that these authenticators are designed to store key handles in their own internal secure storage and not expose externally.
- These authenticators may also work as a second factor.
- Examples
-
- A Bluetooth LE based hardware token with built-in fingerprint sensor
- PIN protected USB hardware token
- A first-factor bound authenticator acting as a roaming authenticator for a different device on the user's behalf
- Second-factor Roaming Authenticator
-
- These authenticators are not bound to any device. A user may use them with any number of devices.
- These authenticators may have an internal matcher. The matcher is able to verify an already enrolled user. If there is more than one user enrolled then the matcher can also identify a particular specific user.
- It is assumed that these authenticators do not store key handles in their own internal storage. Instead they push key handles to the FIDO Server and receive them back during the authentication operation.
- These authenticators can only work as second factors.
- Examples
-
- USB dongle with a built-in capacitive touch device for verifying user presence
- A "Trustlet" application running on the trusted execution environment of a mobile phone, and leveraging a secure keyboard to verify user presence
Throughout the document there will be special conditions applying to these types of authenticators.
In some deployments, the combination of ASM and a bound authenticator can act as a roaming authenticator (for example when an ASM with an embedded authenticator on a mobile device acts as a roaming authenticator for another device). When this happens such an authenticator MUST follow the requirements applying to bound authenticators within the boundary of the system the authenticator is bound to, and follow the requirements that apply to roaming authenticators in any other system it connects to externally.
As stated above, the bound authenticator does not store key handles and roaming authenticators to store them. In the example above the ASM would store the key handles of the bound authenticator and hence meets this assumptions.