FIDO Credential Lifecycle Guide: Difference between revisions
mNo edit summary |
mNo edit summary |
||
| Line 2: | Line 2: | ||
All authenticators (mechanism by which a user is authenticated) require some degree of lifecycle management. The technical details of an authenticator impacts the lifecycle in many ways. For example passwords tend to expire and have to adhere to complexity requirements and typically have automated recovery processes for when they are forgotten. Physical authenticators may have longer expiration times but more complex requirements for replacing (ie. show up at the badge office, fill out some paperwork, verify your identity, have a new credential issued, etc.). The lifecycle also necessarily includes the very initial provisioning of the credential. For low assurance level services, this is often a simple online sign-up process with an email address verification and nothing more. For more secure credentialing it is often an in-person process with biometric capture and verification, like a fingerprint scan and photo taken for a driver's license. | All authenticators (mechanism by which a user is authenticated) require some degree of lifecycle management. The technical details of an authenticator impacts the lifecycle in many ways. For example passwords tend to expire and have to adhere to complexity requirements and typically have automated recovery processes for when they are forgotten. Physical authenticators may have longer expiration times but more complex requirements for replacing (ie. show up at the badge office, fill out some paperwork, verify your identity, have a new credential issued, etc.). The lifecycle also necessarily includes the very initial provisioning of the credential. For low assurance level services, this is often a simple online sign-up process with an email address verification and nothing more. For more secure credentialing it is often an in-person process with biometric capture and verification, like a fingerprint scan and photo taken for a driver's license. | ||
FIDO has two primary standards | FIDO has two primary standards: Universal 2nd Factor (U2F) and Universal Authentication Framework (UAF). While some of the topics contained here can apply to both U2F and UAF, this document's focus is UAF. Additionally, there is a FIDO2 standard that was developed through W3C and is named [https://www.w3.org/TR/webauthn/ webAuthn]. This standard is still very new as of Spring 2019, but rapid adoption by browsers so far hints at its long-term viability. This standard consolidates UAF and U2F functionality and supports both use cases. | ||
==Issuance== | ==Issuance== | ||
FIDO UAF authenticators can be used for both high assurance and low assurance, depending on the process used to issue the credential. For a FIDO UAF mobile credential to be considered an AAL2 or AAL3 credential, it must be issued as part of a high assurance identity proofing process, IAL2 or IAL3 respectively. | FIDO UAF authenticators can be used for both high assurance and low assurance, depending on the process used to issue the credential. For a FIDO UAF mobile credential to be considered an AAL2 or AAL3 credential, it must be issued as part of a high assurance identity proofing process, IAL2 or IAL3 respectively. | ||
===Enrollment=== | ===Enrollment=== | ||
The most direct method for establishing a higher assurance level FIDO credential on a user's mobile device is for them to have the device on them when they finish going through the identity proofing process, and the authenticator is bound during this process. This would require the user to use their phone during this process to generate a FIDO credential that is bound to the online identity created during the enrollment. While this process is effective at establishing a strong credential, it may lack resiliency do to the potential loss or replacement of the mobile device. | The most direct method for establishing a higher assurance level FIDO credential on a user's mobile device is for them to have the device on them when they finish going through the identity proofing process, and the authenticator is bound during this process. This would require the user to use their phone during this process to generate a FIDO credential that is bound to the online identity created during the enrollment. While this process is effective at establishing a strong credential, it may lack resiliency do to the potential loss or replacement of the mobile device. | ||
===Redundancy=== | ===Redundancy=== | ||
Redundant authenticators can be issued during enrollment, such as a username and password for low assurance operations, or physical tokens for higher assurance interactions. Redundancy can be costly to implement and can yield even more potential failure points if there are insufficient self-service capabilities to remedy issues. For larger systems with significant self-service capabilities, redundancy can become critically important for using those self-service capabilities. Supporting multiple authentication methods and multiple authenticators can be costly, but it can be beneficial for large providers and moderate providers hoping to reduce the cost to scale up. | Redundant authenticators can be issued during enrollment, such as a username and password for low assurance operations, or physical tokens for higher assurance interactions. Redundancy can be costly to implement and can yield even more potential failure points if there are insufficient self-service capabilities to remedy issues. For larger systems with significant self-service capabilities, redundancy can become critically important for using those self-service capabilities. Supporting multiple authentication methods and multiple authenticators can be costly, but it can be beneficial for large providers and moderate providers hoping to reduce the cost to scale up. | ||
| Line 15: | Line 17: | ||
==Use Cases== | ==Use Cases== | ||
===Lost Authenticator=== | ===Lost Authenticator=== | ||
A common occurrence for any authenticator is the possibility of loss, and so it is critical for a provider to have clear and readily available instructions for their users on what to do in the case of their authenticator being lost. This may typically include a phone number or email address for the user to make contact. They may also report a high assurance level credential as being lost over a lower assurance level channel. In the case of a FIDO UAF credential on a mobile device, loss would include any situation where the user no longer possesses the device (stolen, lost, replaced, etc). In the case of FIDO UAF credentials, the provider may revoke the credential on the FIDO server, but this may not be necessary depending on various factors, such as whether the the device was stolen and what mechanism was used to protect the key material on the device (if a sufficiently strong biometric was used, the key may not be recoverable). The provider must make a risk-based decision whether to revoke the credential of a lost device. | A common occurrence for any authenticator is the possibility of loss, and so it is critical for a provider to have clear and readily available instructions for their users on what to do in the case of their authenticator being lost. This may typically include a phone number or email address for the user to make contact. They may also report a high assurance level credential as being lost over a lower assurance level channel. In the case of a FIDO UAF credential on a mobile device, loss would include any situation where the user no longer possesses the device (stolen, lost, replaced, etc). In the case of FIDO UAF credentials, the provider may revoke the credential on the FIDO server, but this may not be necessary depending on various factors, such as whether the the device was stolen and what mechanism was used to protect the key material on the device (if a sufficiently strong biometric was used, the key may not be recoverable). The provider must make a risk-based decision whether to revoke the credential of a lost device. | ||
Revision as of 20:43, 24 April 2019
Introduction
All authenticators (mechanism by which a user is authenticated) require some degree of lifecycle management. The technical details of an authenticator impacts the lifecycle in many ways. For example passwords tend to expire and have to adhere to complexity requirements and typically have automated recovery processes for when they are forgotten. Physical authenticators may have longer expiration times but more complex requirements for replacing (ie. show up at the badge office, fill out some paperwork, verify your identity, have a new credential issued, etc.). The lifecycle also necessarily includes the very initial provisioning of the credential. For low assurance level services, this is often a simple online sign-up process with an email address verification and nothing more. For more secure credentialing it is often an in-person process with biometric capture and verification, like a fingerprint scan and photo taken for a driver's license.
FIDO has two primary standards: Universal 2nd Factor (U2F) and Universal Authentication Framework (UAF). While some of the topics contained here can apply to both U2F and UAF, this document's focus is UAF. Additionally, there is a FIDO2 standard that was developed through W3C and is named webAuthn. This standard is still very new as of Spring 2019, but rapid adoption by browsers so far hints at its long-term viability. This standard consolidates UAF and U2F functionality and supports both use cases.
Issuance
FIDO UAF authenticators can be used for both high assurance and low assurance, depending on the process used to issue the credential. For a FIDO UAF mobile credential to be considered an AAL2 or AAL3 credential, it must be issued as part of a high assurance identity proofing process, IAL2 or IAL3 respectively.
Enrollment
The most direct method for establishing a higher assurance level FIDO credential on a user's mobile device is for them to have the device on them when they finish going through the identity proofing process, and the authenticator is bound during this process. This would require the user to use their phone during this process to generate a FIDO credential that is bound to the online identity created during the enrollment. While this process is effective at establishing a strong credential, it may lack resiliency do to the potential loss or replacement of the mobile device.
Redundancy
Redundant authenticators can be issued during enrollment, such as a username and password for low assurance operations, or physical tokens for higher assurance interactions. Redundancy can be costly to implement and can yield even more potential failure points if there are insufficient self-service capabilities to remedy issues. For larger systems with significant self-service capabilities, redundancy can become critically important for using those self-service capabilities. Supporting multiple authentication methods and multiple authenticators can be costly, but it can be beneficial for large providers and moderate providers hoping to reduce the cost to scale up.
Add-on
It can be useful to have processes where a user can add an additional authenticator to their user account. Add-on authenticators are constrained by the assurance level of the authenticator used to add the authenticator. When adding a FIDO UAF credential to an existing account, it would be considered AAL1 if it is added to an account via an existing username/password. This may still be a useful use case if the FIDO UAF credential can be still be used even when it's assurance level is low. An authenticator that has been added on with a low assurance authenticator can still be elevated using external processes, so for example a FIDO UAF authenticator could be added to a username/password account, and then that authenticator could be further bound at a higher AAL via an out of band verification and approval process.
Use Cases
Lost Authenticator
A common occurrence for any authenticator is the possibility of loss, and so it is critical for a provider to have clear and readily available instructions for their users on what to do in the case of their authenticator being lost. This may typically include a phone number or email address for the user to make contact. They may also report a high assurance level credential as being lost over a lower assurance level channel. In the case of a FIDO UAF credential on a mobile device, loss would include any situation where the user no longer possesses the device (stolen, lost, replaced, etc). In the case of FIDO UAF credentials, the provider may revoke the credential on the FIDO server, but this may not be necessary depending on various factors, such as whether the the device was stolen and what mechanism was used to protect the key material on the device (if a sufficiently strong biometric was used, the key may not be recoverable). The provider must make a risk-based decision whether to revoke the credential of a lost device.
Reissuance
For FIDO UAF to be used at higher assurance levels, reissuance may be handled by having the user go through the initial issuance process again. If a provider issues multiple strong credentials to users, this may enable a user to use a strong back-up credential to self enroll a new FIDO device. This is not a typical use case for small providers as supporting many different authenticators can be cost prohibitive.
Expiration
There are two aspects to expiration, one is the authenticator expiring (such as a password expiring or a certificate expiring) and an online account expiring, a common occurrence do to lack of use. FIDO UAF credentials generally have no expiration issues, as it uses strong public key cryptography for the keys with expected lifetimes of the devices being shorter than the strength window of the key material. In the case of an expired account rendering a FIDO UAF credential inoperative, the user would need to go through the issuance process again to enable a new account or to re-enable their existing account. As with reissuance, this reactivation would need to happen at an appropriate assurance level process to ensure the FIDO UAF credential maintained AAL2.
Revocation
Revocation is a mechanism by where the credential possessed (or lost) by the a user is disallowed for future use by the authentication server. This would be akin to a temporary one time password replacing a user's existing password (so the old password is no longer accepted). For FIDO UAF the public and private key system does not involve certificates issued by an authority so revocation does not use typical X.509 mechanics. With FIDO every public/private keypair is unique to a single credential, so revocation is handled within the FIDO UAF Server simply by deleting the credential for the user, thus forcing them to go through the registration process again thus generating a new credential at that time.