FIDO Authentication Methods

The standards issued by the Fast Identity Online (FIDO) Alliance represent the next generation in authentication technologies. FIDO addresses the general need for stronger authentication that mitigates issues connected with legacy authentication methods and can withstand contemporary cyber threats. FIDO shifts away from a traditional password-based authentication to an easy-to-use multi-factor authentication.

FIDO standards focus on improving in the major aspects of a mature security-related solution: strong security, improved user experience, and reduced costs.

Supported Standards

The implementation of FIDO standards enriches the already wide variety of authentication methods in DirX Access. FIDO methods can be used either during an initial authentication or within step-up authentication mechanisms. DirX Access supports the following FIDO-based specifications:

Universal Authentication Framework (UAF) – a mechanism that enables a passwordless authentication user experience. See FIDO UAF Protocol Specification .
Universal Second Factor (U2F) – a mechanism that enables a strong cryptographic second factor option for end user security. See Universal Second Factor.
Web Authentication – a mechanism that enables strong authentication specifically in the environment of web applications. See Web Authentication: An API for accessing Public Key Credentials .

Design

In DirX Access, authentication methods are typically made accessible through the Authentication Application. This Web application provides a frontend to FIDO operations and workflows: it enables the authentication process but can also act as a self-service credential-management portal providing self-registration/deregistration of FIDO authenticators. The Authentication Application transmits requests to and responses from the FIDO service running in the Services container.

FIDO Protocols

FIDO protocols are based on a public key cryptography and follow a challenge-response model.

The DirX Access FIDO infrastructure is formed by:

A FIDO authenticator connected to/built into a client device possessed by the user.
An Authentication Application providing a FIDO frontend and delegating the authentication to the FIDO service.

DirX Access supports the following FIDO actions:

Registration – Allows the user to enroll new a FIDO credential (public and private key) forming a bond between authenticator in use and the user’s account at the server side.
Authentication – Provides a simple and transparent user authentication via the FIDO protocol.
Deregistration – Provides the user with the complete set credential management functions, including deregistration protocol flow.

These operations can be enabled for any FIDO authentication method via the support for the selected operation in the configuration section.

The Figure 1 illustrates authentication operation in the FIDO protocol:

attachments/att++_++14++_++for++_++110526498

Figure 1. DirX Access FIDO Protocol Flow

As shown in the Figure 1:

The user accesses a protected resource (Web page).
The third-party application detects that the user is not signed in and redirects her to the Authentication Application.
The Authentication Application offers a selection of authentication methods to the user.
The user selects the FIDO authentication method option. The Authentication Application initiates FIDO authentication.
The DirX Access server generates a challenge and wraps it into a FIDO request message.
The Authentication Application forwards the FIDO request to the user’s device.
The user’s device submits the FIDO request to the authenticator either by calling Javascript APIs in the browser (U2F, Windows Hello, Web Authentication) or with Android/iOS API calls (UAF).
The authenticator locally verifies the user’s identity based on either something the user has (a device), something the user is (biometrics, such as fingerprint, iris scan or voice pattern), or something the user knows (a PIN).
After successful user verification, the authenticator signs the server-issued challenge with a private key that is relevant to the given server and user account and returns the signed FIDO response to the device.
The device forwards the FIDO response to the Authentication Application.
The Authentication Application forwards the FIDO response to the DirX Access server.
The DirX Access server verifies the signed response using the corresponding public key and also verifies the authenticator’s metadata against a configured set of policies. (see the section “Authentication Method Configuration”).
If successful, the DirX Access server returns the user’s authenticated state to the Authentication Application.
Once authenticated, the Authentication Application redirects the user to the requested resource.
The authenticated user can access the resource.

Configuration

DirX Access Manager allows for a high FIDO configurability. First, you must configure a trust between DirX Access and FIDO authenticators in at least one of the ways described in the sections “FIDO Metadata Service Configuration” and “Custom Authenticator Support Configuration”. Next, set up the respective FIDO authentication methods.

Trust

Trust between a FIDO authenticator and DirX Access server is based on an attestation mechanism. Each authenticator has an attestation private key shared among a vast number of authenticators. During the registration process, the authenticator signs the FIDO registration message using the attestation private key. The fact that the private key is shared (typically by a single model of authenticators) causes the attestation to verify only the model in use, not the exact authenticator communicating with the DirX Access server. The DirX Access server verifies the signature using the public key from the attestation certificate bound to the metadata obtained either from FIDO metadata statements or from the DirX Access truststore.

During the certification, vendors of FIDO authenticators can allow their authenticator models to certify by FIDO Alliance. The vendor submits the authenticator metadata statement to the FIDO Alliance, which distributes it to the relying parties via the FIDO Alliance’s metadata service. Metadata statements contain relevant root attestation certificates and also other important characteristics of the authenticator. These characteristics are then validated against a properly configured set of policies (see the section “Authentication Method Configuration”).

For the Web Authentication protocol, DirX Access administrators can further specify how the attestation of the authenticator is obtained using Attestation Conveyance Preference. For a detailed description, see the Administrative Tasks.

FIDO Metadata Service Configuration

DirX Access Manager’s FIDO metadata service configuration page allows you to set up a DirX Access FIDO metadata service consumer. This consumer automatically downloads metadata statements distributed via the public metadata service managed by the FIDO Alliance itself. Trust of the authenticator used in the protocol run is verified against the corresponding metadata statement using the public key infrastructure. This configuration represents the main mechanism for establishing trust between an authenticator and DirX Access.

To be able to communicate with the FIDO metadata service in a secure way, you must upload the certificate of the FIDO metadata service. This certificate is available at: FIDO Alliance Metadata Service. You can configure the Update interval that specifies the time period during which the DirX Access server attempts to download the metadata statements from the FIDO metadata service. If the metadata are not accessible at the time of the update, the server attempts to update them on the next pass.

The metadata document obtained from the FIDO Alliance metadata service contains the nextUpdate element, which provides the latest date at which this document will be replaced with a fresh one. This element is displayed in the Metadata TOC value field in the FIDO metadata service settings tab of DirX Access Manager. The actual refresh rate (typically the difference between the time of issuance and the nextUpdate element) of new metadata document should give you a hint about how to set up the Update interval parameter in the FIDO metadata service settings tab. An inconsistency interval in the publicly-issued metadata and their local copy on the DirX Access side may occur and take at most as much time as the Update interval. It is up to you to set the appropriate interval; the shorter the interval, the more system resources are consumed, the longer the interval, the longer the interval of inconsistency.

Example 1: The refresh rate of the public metadata is in an order of days. The main reason for these refresh is to add new authenticators and revoke the ones that have been unexpectedly compromised. The administrator is typically ok with having the support of new authenticators added not immediately. Also, we can expect that discovery of a compromised authenticator is not typically instantaneous but instead takes a longer period of time (days, weeks). In this case, the Update interval can be set up in an order of days.

Example 2: A service employing a DirX Access FIDO server must use the freshest FIDO authenticators and provide the highest level of security. In this case, the Update interval should be set up in an order of minutes.

Custom Authenticators Support Configuration

If the authenticator’s metadata statement is not published via the FIDO alliance metadata service, you - the DirX Access administrator - can use the custom authenticators support configuration to establish trust between a given type of authenticator and DirX Access. First, obtain authenticator’s attestation root certificate from the authenticator’s vendor. Next, include this certificate in a DirX Access truststore that is assigned to a given FIDO authentication method.

If you use the custom authenticators support configuration, the DirX Access server internally constructs a custom metadata statement. This statement is used in the policy evaluation process in the same way that the certified metadata statement is used.

Use the autogenerated metadata statement structure to set up the FIDO policies accordingly. Here is the constructed metadata statement for UAF:

{
    aaid: [authenticator id],
    authenticatorVersion: [version of the authenticator],
    publicKeyAlgAndEncoding: [public key format used by the authenticator during registration operation],
    authenticationAlgorithm: [authentication algorithm supported by the authenticator],
    attestationTypes: [attestation type used for the relevant FIDO protocol run],
    attestationRootCertificates: [attestation certificates from configured truststore]
}

Here is the constructed metadata statement for Web Authentication:

{
    aaguid: [authenticator id],
    userVerificationDetails: [list of alternative verification methods],
    attestationRootCertificates: [attestation certificates from configured truststore],
    attestationTypes: [attestation type used for the relevant FIDO protocol run]
}

For a detailed description of the selected keys, see: FIDO Metadata Statement Specification .

DirX Access does not process the policy evaluation for U2F authenticators trusted via the custom authenticators support configuration.

attachments/att++_++10++_++for++_++110526498

Figure 2. Custom Authenticators Support Configuration

Authentication Method Configuration

DirX Access Manager’s Configuration | Authentication | Authentication methods page allows you to configure FIDO authentication methods for the selected Authentication Application. The FIDO-specific configuration section of the authentication methods administrative page allows you to select one of the supported FIDO specifications and align the configuration for it. For a detailed description of FIDO authentication method administrative fields and controls, see the section Authentication Methods

Policy - FIDO UAF defines a vocabulary of FIDO policies which helps to determine which authenticators are supported. DirX Access extends the use of this standardized mechanism to all FIDO standards to employ a unified way of fine-grained policy configuration that satisfies specific company security policies. Policies are evaluated against the corresponding authenticator’s FIDO metadata statement. The policies basically enable setting up different sets of authenticators to different authentication methods. Combining these policies with the assurance level parameter enables DirX Access to express “how much” it trusts different FIDO-based authentication methods. For example, the iris scan grants a higher assurance level than the fingerprint.

Imprint trusted facets to AppId – If there are multiple client applications that want to share the same FIDO authentication method, you can add all these applications to the Allowed Origins attributes. The identifiers of the applications are then published in the trusted facets document via the Authentication Application at: {location}/facets?authnMethodId={authentication method identifier}. The FIDO authenticator attempts to look up its identifier in this published document; if successful, the authentication is allowed. To enable this functionality, the field Imprint trusted facets to AppId must be enabled. This is relevant only to UAF and U2F specifications.

FIDO Credentials

FIDO credentials are stored in DirX Access’s Application repository. For each authenticator registered with DirX Access, a FIDO credential is created and assigned to the relevant user. A user can own multiple authenticators and thus can register multiple FIDO credentials. The stored credential contains a public key that binds the credential to a corresponding registered authenticator and other mandatory parameters required by the FIDO protocol (relying party identifier, signature counter, username, authenticator alias and authenticator id), but it typically does not contain any private data of the user. Depending on its format, the username can contain private data. It is then mandatory to treat the Application Repository as a repository containing private data, thus imposing further security requirements on it.

FIDO credentials registered via one FIDO authentication method can be used with other FIDO authentication methods of the same standard. This enables a configuration in which one method is used for the registration process only, while another is configured for the authentication.

Registration Process Considerations

DirX Access enables FIDO registration via its Authentication Application, which can be used as a self-service credential management portal allowing for a self-registration of an already authenticated user.

For the registration process, the user must be present, as the authenticator will require user verification (for example, biometrics, pin) to complete the registration process. This represents a different approach compared to a typical registration of strong authentication credentials (such as PKI cards) where a system or a system administrator assigns the credentials to the user.

For the FIDO registration process, it is important to configure the assurance levels for the authentication methods properly. In a typical scenario, there are three main authentication methods:

Initial authentication method (IA) – the method used for the initial authentication (protecting registration process) to register the FIDO credential.
FIDO authentication method used for registration (FR) – the method used for the registration of the FIDO credential.
FIDO authentication method used for authentication (FA) – the method used for the FIDO authentication using registered FIDO credential.

There are two typical setups:

IA must grant a higher assurance level than the Minimum registration assurance level configured in FR than FA grants; otherwise, users can gain an assurance level just by registering their FIDO credential and then authenticating with them while the registration is only protected by IA.
Strengthened assurance during the registration process is provided by other means than a high assurance level for IA; for example, registration could be protected by employing an IP address condition so that the registration process is possible only from a selected device in a location where a security officer can oversee the registration process.

To enable FIDO authentication with high assurance levels, the IA should be represented by a strong authentication method such as OTPs, PKI smart cards or multi-factor authentication methods.

Deregistration Process

The DirX Access Authentication Application allows users to deregister their FIDO credentials. To deregister, the user must be allowed to access the FIDO authentication method that has the support deregistration configured. Upon accessing this authentication method, the user is presented with a list of registered authenticators with the option to delete a selected authenticator. This deregistration action represents a deletion of the FIDO credential from the DirX Access Application Repository.

The deregistration action is also standardized in the UAF protocol itself. Upon deletion of the FIDO credential via the Authentication Application, the DirX Access server creates a deregistration message that is transmitted via the Authentication Application to the user’s device. The device then performs local deregistration of the credentials.

Server Challenge Length Considerations

Server challenge is a server-provided random challenge. The challenge is used by the FIDO server to verify whether an incoming response is new or has already been processed. The minimum challenge length must be 8 bytes. For more information, see FIDO UAF Protocol Specification. .