FIDO Credential Lifecycle Guide: Difference between revisions

From NIEF Wiki
Jump to navigation Jump to search
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Introduction==
==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.
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.


FIDO has two primary standards/use cases known as U2F (universal second factor) and UAF (universal authentication framework).  While some of the topics contained here can apply to both U2F and UAF, the focus is on UAF.  Additionally, there is a FIDO2 standard that was handed over to W3C and renamed [https://www.w3.org/TR/webauthn/ webAuthn].  This standard is still very new, but rapid adoption by browsers hints at longterm viability.  This standard consolidates UAF and U2F functionality and supports both use cases.
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==
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 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===
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 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===
===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 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===
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.
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===
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 was the device stolen or not 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, 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===
===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.
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===
===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.
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===
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.
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.

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.