Multifactor authentication - Deployment guide

Document History

Version	Date	Author	Comment
1.5	Oct 2018	Olav Morken	Replace API for TOTP secrets with new API.
1.4	Feb 2017	Jaime Pérez	Fix a couple of typos in Appendix 1, norEduPersonServiceAuthnLevel examples.
1.3	Oct 2015	Jaime Pérez	Update for final settings in production.
1.2	Jul 2015	Hildegunn Vada	Removed URLs for Feide Authenticator API until further.
1.1	Jan 2015	Jaime Pérez	Update with new attributes and formats from norEduPerson
1.0	Dec 2014	Jaime Pérez	First version of this document.

Introduction

Feide, the Identity Federation of the Norwegian Agency for Shared Services in Education and Research (Sikt), is introducing the possibility to use a second factor of authentication as a requisite to complete the login process and minimise the possibility of identity theft, especially for those services that require higher guarantees on the security of the whole system.

This document describes the technical details and requisites involved in the deployment of a multifactor authentication solution in Feide, as well as the rationale behind them. Institutions willing to deploy this solution should follow this document as a technical guide for an interoperable and secure implementation. This guide, however, does not pretend to be exhaustive or to provide specific instructions for every possible setup, or to describe the administrative procedures that every institution should have in place for a successful and secure deployment.

Requirements notation

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

The use of SHOULD, SHOULD NOT, and RECOMMENDED reflects broad consensus on deployment practices intended to foster both interoperability and guarantees of security and confidentiality needed to satisfy the requirements of many organizations that engage in the use of federated identity. Deviating may limit a deployment’s ability to technically interoperate without additional negotiation, and should be undertaken with caution.

Motivation

The main purpose of a multifactor authentication solution is to verify the identity of the user by other means apart from the traditional username and password authentication. Second factors are usually something that the user physically has, commonly combined with something the user knows (like a token with a PIN code that generates one-time passwords).

In order to use most of the multifactor solutions available in the market, some information about the other factors needs to be stored. Since Feide does not store information about the end users in any way, the institutions need to store themselves the relevant information for their own users and the other factors they want to support. Feide has so far implemented support for two different multifactor authentication mechanisms: SMS-based and time-based one-time passwords. Here we discuss their basic characteristics as well as their main challenges.

SMS-based one-time password

Authentication based on text messages is probably one of the simplest and most widespread multifactor mechanisms. When a user has identified with a username and password, a random code is sent to the mobile phone number associated with that account, and the user needs to enter it to continue. That way we can verify that the user is in possession of a specific device he or she is supposed to own.

In the case of Feide, many institutions are already registering and storing the mobile phone numbers of their users. However, experience shows that those numbers are not strictly validated, and they may often contain errors, typos or simply be invalid, either due to automated provisioning or the users manually entering them. Besides, it is also desirable that the institutions are able to signal whether a phone number should be used or not for multifactor authentication. This means the phone numbers currently registered at every institution cannot be used right away, so they must be provisioned again, verifying their authenticity and format.

Time-based one-time password

Feide has implemented support for a time-based one-time password (TOTP) authentication method that is compatible with RFC 6238. It is more specific though, as it uses a subset of the mechanisms described in the standard and restricts how others are used. This authentication method (referred to as Authenticator from now on) can be used with hardware tokens, but also with any device capable of running software implementing this method, which is part of its success.

Most typically, the user configures a smartphone with an Authenticator application by manually entering a shared secret on the application or by scanning a QR code. Later on, the device can be used to generate the six-digit codes used for authentication. Note that even though this mechanism was originally implemented by Google in its Google Authenticator application, there is also a wide range of clients that support this mechanism.

The time-based one-time password authentication mechanism is based on a secret shared between a device owned by the end user (a mobile phone, a hardware token or some software running on a laptop) and the authenticating party. In this case the authenticating party is Feide, as multifactor authentication happens right after traditional username and password authentication, but Feide by design does not store any authentication data for the users. This means the secret shared between Feide and the user must be stored in the directory of the home institution of the user, the same way as passwords.

This shared secret is necessary to setup and use an Authenticator application to authenticate a user. In a way, it is equivalent to a password. This means we have to handle it with the same security considerations as we would handle a password. Particularly, if the shared secret is stored in plain in the user’s entry in the directory, anybody able to read the entries of other users would be able to setup an Authenticator instance identifying any particular user, completely defeating the purpose of multifactor authentication.

In order to avoid the Authenticator secrets being widely readable for anybody with access to the directory, they must be protected by some mechanism so that only the authenticating party (Feide in this case) can use them. This is achieved by using public key cryptography to encrypt the secrets, so that anybody can encrypt, but only Feide can decrypt them. This is different to usual password protection mechanisms, as passwords are commonly hashed with a one-way function instead of encrypted. This method cannot be used with the Authenticator secrets since Feide needs the original value to generate the one-time password, and the only place it can get that value from is the user directory.

For the technical specification see SAML2.0 Technical Requisites.

Testing

Multifactor authentication login

To test if your Feide user supports two-factor authentication, log into https://two-factor-test.feide.no. If successful, you should see your eduPersonPrincipalName and your eduPersonAssurance.

Successful login

Failed login

If not successful, check if your Feide user has the following configuration:

1. Check if the user has a norEduPersonAuthnMethod-attribute.

2. Check the format of norEduPersonAuthnMethod – It should have two or three fields.

3. Check the method (first field) of norEduPersonAuthnMethod – it should be either urn:mace:feide.no:auth:method:ga or urn:mace:feide.no:auth:method:sms.

4. If the method is urn:mace:feide.no:auth:method:ga, check if the other field has the form of ey[...]n0.Uy[...]UA.tq[...]Kg.ww[...]N5.LZ[...]9Q i.e. it should contain five elements with base64url-coded data, where each element are separated with ..

5. If the method is urn:mace:feide.no:auth:method:sms, check that the second field has the form +4712345678 i.e. it should start with a country code and not contain any space or other special characters.

For examples see the MFA Examples.