When users access online services, they want to be confident that nobody else can log in pretending to be them, access their sensitive personal data or use their identity to make fraudulent claims. They want to be confident that their data and services are secure and their privacy protected. Institutions and Service Providers that offer online services also need to verify a users identity to make sure only the right users are accessing the right information. That is why identity assurance is needed.
The classic paradigm for authentication systems identifies three factors as the cornerstones of authentication:
- Something you know (for example, a password or a PIN);
- Something you have (for example, a mobile phone or a token);
- Something you are (for example, a fingerprint or other biometric data).
Strong authentication or multi-factor authentication refers to the use of more than one of the factors listed above. Generally, the use of multiple factors results in a higher level of assurance (LoA) about the user. The Level of Assurance concept is explained further on this page:
How identity assurance works
SURFconext Strong Authentication is designed to establish that a user is who he says he is, and that the authentication token he wishes to use for future strong authentication is indeed in possession of the user. It is the role of the institution (Identity Providers) to make sure the registration is valid and genuine.
One of the benefits of SURFconext Strong Authentication is that most users will be able to complete the registration process online. After completion of the registration process the user has to visit a Service Desk or IT Helpdesk once to have its token activated. Once the identity provider has verified the user's identity, the registered token of the user will be activated. The user can then use his token as a secure secure means of signing in.
Assurance level standards
NIST (US), STORK (Europe) and ISO29115 are all international standards for identity assurance. SURFconext Strong Authetnication is based on the concepts as defined in ISO29115. The four levels of identity assurance for electronic transactions requiring authentication commonly used are:
| LoA 1 | Little or no confidence in the asserted identity |
| LoA 2 | Some confidence in the asserted identity |
| LoA 3 | High confidence in the asserted identity |
| LoA 4 | Very high confidence in the asserted identity |
The different specifications elaborate on the meaning of these labels by specifying requirements for:
- the registration phase
- the authentication token management phase
- and the online authentication phase
The eventual assurance level is then determined through a combination of these aspects. The individual aspect with the lowest score will ultimately determine the applicable assurance level, on the principle that 'the chain is only as strong as the weakest link'.
Level of assurance requirements: risk based
The required assurance level for a certain service can be estimated based on a number of criteria. These criteria all concern the importance of the data and the potential damages if these were to be obtained or modified by unauthorised users. Each service will need to assess risks to be able to decide what level of assurance is needed. SURF has published guidelines on how to make such a risk assessment. These guidelines are published here.
Level of assurance vs robustness of infrastructure
The LoAs described by NIST and STORK primarily focus on the robustness of the authentication. The robustness of the technical infrastructure is mostly beyond their scope.
It is assumed that proper measures are in place to prevent potential authentication protocol threats such as eavesdropping, man-in-the-middle, replaying, and hijacking. Attacks are not limited to the authentication protocol itself. Other attacks include the use of malicious code to compromise authentication tokens, insider threats to compromise authentication tokens, social engineering to get a subscriber to reveal his password to the attacker, "shoulder-surfing", fooling claimants into using an insecure protocol, when they think that they are using a secure protocol, or intentionally denying ever having registerd by subscribers who deliberately compromise their tokens.
Other types of threats are (SAML) assertion related such as modification, disclosure, repudiation, reuse, or redirect. Countermeasures should be in place to prevent these attacks as well. It goes too far to describe for each LoA the amount and strength of the required countermeasures. Most of these countermeasures are addressed in the information security policy of the stakeholders. NIST 800-63-1 also gives some guidelines. The most important ones are the use of digital signatures to sign assertions with and the use of SSL/TLS to secure the communication channel.
Both control measures are required to fulfil the requirements for LoA2 and LoA3 and are already in place in SURFconext Strong Authentication. NIST SP 800-63-1 recommends the CSP (i.e. SURFconext Strong Authentication) for LoA2 to "employ appropriately tailored security controls from the low baseline of security controls defined in [NIST SP 800-53 ] and to ensure that the minimum assurance requirements associated with the low baseline are satisfied". For LoA3 security controls from the moderate baseline of security controls are required.
Level of assurance vs attributes
Please note that SURFconext Strong Authentication solely focuses on authentication LoA. No LoA is assigned to the individual attributes of the user's identity.
Several attributes provided by the IdP of the institution will be validated during registration and identification. These attributes include first and last name and e-mail address. In theory a LoA could be assigned to these attributes. In attribute-based access control scenario's, information about the reliability of these attributes could be beneficial for SPs to make their authorisation more reliable. There are, however, a number of arguments against doing this:
- Mixing attributes with different LoA's is complex;
- There is no suitable way to express differing LoA's for attributes in SAML assertions;
- The registration process will become more complex as attribute validation will need to be explicitly included.
Because the benefits do not outweigh the added complexity, SURFconext Strong Authentication solely focuses on authentication LoA.