FIDO Credential Lifecycle Guide: Difference between revisions

From NIEF Wiki
Jump to navigation Jump to search
(Created page with "==Introduction== * Lifecycle management for authenticators. * FIDO specifics as appropriate. ==Issuance== Address initial issuance. ===Enrollment=== * Credential issuance h...")
 
No edit summary
 
(18 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==Introduction==
==Introduction==
* Lifecycle management for authenticators.   
All authenticators (i.e., mechanisms by which a user is authenticated) require some degree of lifecycle management.  The technical details of an authenticator impact its lifecycle in many ways.  For example, passwords tend to expire, must satisfy minimum complexity requirements, and typically have automated recovery processes for when they are forgotten.  Physical authenticators may have longer expiration times, but they also have more complex requirements for replacement (i.e., appear in person before the issuing official, fill out some paperwork, verify your identity, have a new credential issued, etc.) The credential lifecycle also necessarily includes the initial provisioning of the credential.  For lower-assurance credentials, this is often a simple online sign-up process with an email address verification and nothing moreBut for higher-assurance credentials, it is often an in-person process with biometric capture and verification, such as a fingerprint scan and/or photograph of the user.
* FIDO specifics as appropriate.
 
The Fast Identity Online (FIDO) 1.0 specification has two primary standards: Universal 2nd Factor (U2F) and Universal Authentication Framework (UAF).  While some of the topics contained here apply to both U2F and UAF, this document's focus is UAF.  Note also that a "FIDO2" standard has been 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 up to this point hints at its long-term viability.  The FIDO2 standard consolidates UAF and U2F functionality and supports both use cases.


==Issuance==
==Issuance==
Address initial 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 in accordance with [https://pages.nist.gov/800-63-3/sp800-63b.html NIST SP 800-63B], it must be issued through a high-assurance identity proofing process, e.g., in accordance with [https://pages.nist.gov/800-63-3/sp800-63a.html NIST SP 800-63A] IAL2 or IAL3, respectively.
 
===Enrollment===
===Enrollment===
* Credential issuance happens as final part of identity proofing process.
The most direct method for establishing a high-assurance FIDO credential on a user's mobile device is for the user to have the device present at the time when the user finishes going through the identity proofing process, so that the authenticator can be issued and bound to the device during this in-person event. This requires the user to use their phone during this process and 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 is somewhat costly, inconvenient, and unscalable. It also lacks resiliency due to the potential loss or replacement of the mobile device.
* Authenticator is bound at this time.
 
===Redundancy===
===Redundancy===
* Should issue multiple and back-up credentials.
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 subsequent credential management issues that may arise.  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-scale providers and moderate-scale providers hoping to reduce their scaling costs.
 
===Add-on===
===Add-on===
* Allow user to add new authenticators of equal or lesser strength than the authenticator used for current session; useful for generating back-up credentials.
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 to access resources despite having a lower assurance level.  An add-on authenticator with a low assurance authenticator can be elevated through external processes. 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==
==Use Cases==
===Lost Authenticator===
===Lost Authenticator===
* Reporting loss.
A common occurrence for any authenticator is the possibility of loss, 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 contact and notify an administrator.  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 (e.g, due to theft, loss or device replacement/upgrade).  In such case, the provider can revoke the credential on the FIDO server, thereby assuring that the credential can never be used to authenticate. But this may not be necessary; it depends 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 as to whether to revoke a credential on a lost, stolen, or replaced device.
** CSP must have clear and readily available instructions for users that lose their authenticators.
** CSP may revoke existing authenticator
** Initiate reissuance via backup authenticator (if possible).


===Reissuance===
===Reissuance===
* Replace credential
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 deviceNote that this is not a typical use case for small providers, as supporting many different authenticators can be cost-prohibitive.
** Near expiration time, may reissue (for example password changes).
** For FIDO reissuing is likely not an issue, credentials would not have expiration times and backup authenticators likely not strong enough to allow direct enrollment.
* In-person
** Depending on availability of multiple authenticators, reissuance may require in-person processes.
* Necessitate new enrollment?
** Without multiple authenticators, may necessitate a new enrollment (new online identity / account).   
* Viable via redundant credentials.
** In some cases (and particularly for lower strength authenticators), you can reissue an authenticator via a channel established with another authenticator.


===Expiration===
===Expiration===
* Trigger reissuance before expiration
There are two aspects to expiration. One is authenticator expiration (such as a password expiring or a certificate expiring) and the other is online account expiration, which is a common occurrence due to lack of use.  FIDO UAF credentials generally have no expiration issues, as FIDO uses strong public key cryptography for the keys with expected lifetime of the device being shorter than the expected lifetime 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 accountAs with reissuance, this reactivation would need to happen at an appropriate assurance level process to ensure the FIDO UAF credential maintained AAL2.
* Credential no longer valid
* FIDO likely not configured to have expiration.
** The underlying account (online identity) may have expiration rules independent of the authenticator's expiration rules though.
** Does DI3 have expiration rules? Inactivity leading to automatically disabled accounts?


===Revocation===
===Revocation===
* Mark credential as no longer valid.
Revocation is a mechanism whereby the credential possessed (or lost) by the a user is disallowed for future use by the authentication server. For FIDO UAF, 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.
* For FIDO/ThumbSignIn this is done within the ThumbSignIn control panel.

Latest revision as of 21:06, 24 April 2019

Introduction

All authenticators (i.e., mechanisms by which a user is authenticated) require some degree of lifecycle management. The technical details of an authenticator impact its lifecycle in many ways. For example, passwords tend to expire, must satisfy minimum complexity requirements, and typically have automated recovery processes for when they are forgotten. Physical authenticators may have longer expiration times, but they also have more complex requirements for replacement (i.e., appear in person before the issuing official, fill out some paperwork, verify your identity, have a new credential issued, etc.) The credential lifecycle also necessarily includes the initial provisioning of the credential. For lower-assurance credentials, this is often a simple online sign-up process with an email address verification and nothing more. But for higher-assurance credentials, it is often an in-person process with biometric capture and verification, such as a fingerprint scan and/or photograph of the user.

The Fast Identity Online (FIDO) 1.0 specification has two primary standards: Universal 2nd Factor (U2F) and Universal Authentication Framework (UAF). While some of the topics contained here apply to both U2F and UAF, this document's focus is UAF. Note also that a "FIDO2" standard has been developed through W3C, and is named webAuthn. This standard is still very new as of Spring 2019, but rapid adoption by browsers up to this point hints at its long-term viability. The FIDO2 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 in accordance with NIST SP 800-63B, it must be issued through a high-assurance identity proofing process, e.g., in accordance with NIST SP 800-63A IAL2 or IAL3, respectively.

Enrollment

The most direct method for establishing a high-assurance FIDO credential on a user's mobile device is for the user to have the device present at the time when the user finishes going through the identity proofing process, so that the authenticator can be issued and bound to the device during this in-person event. This requires the user to use their phone during this process and 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 is somewhat costly, inconvenient, and unscalable. It also lacks resiliency due 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 subsequent credential management issues that may arise. 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-scale providers and moderate-scale providers hoping to reduce their scaling costs.

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 to access resources despite having a lower assurance level. An add-on authenticator with a low assurance authenticator can be elevated through external processes. 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, 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 contact and notify an administrator. 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 (e.g, due to theft, loss or device replacement/upgrade). In such case, the provider can revoke the credential on the FIDO server, thereby assuring that the credential can never be used to authenticate. But this may not be necessary; it depends 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 as to whether to revoke a credential on a lost, stolen, or replaced 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. Note that 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 authenticator expiration (such as a password expiring or a certificate expiring) and the other is online account expiration, which is a common occurrence due to lack of use. FIDO UAF credentials generally have no expiration issues, as FIDO uses strong public key cryptography for the keys with expected lifetime of the device being shorter than the expected lifetime 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 whereby the credential possessed (or lost) by the a user is disallowed for future use by the authentication server. For FIDO UAF, 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.