Page History

Identity assurance

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 is protected. Institutions and Service Providers that offer online services also need to verify a users user's identity to make sure only the right users are accessing the right information. These are distinct 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).

In general there are three types of authentication factors:

• Something the user knows (password or PIN)
• Something the user has (mobile phone or token)
• Something the user is (fingerprint or other bio-metric data)

Strong Multi-factor authentication refers to the use of more than one of the these factors listed above. Generally , the use of multiple factors this results in a higher level of assurance (LoA) about the user. 

...

SURFsecureID levels of assurance

...

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

SURFsecureID expresses the strength of authentication and identity of the user in 4 levels of assurance. This is based on the assurance framework as described in ISO/IEC 29115 (similar to NIST Special Publication 800-63-1), but with a LoA 1.5 added.

Level of assurance	Authentication Assurance	Identity assurance	Characteristics
LoA 1	Username/password	No extra validation of the user's identity	For access to basic resources with little or no risk
LoA 1.5	Username/password + second factor	No extra validation of the user's identity	Protects the user and resources from compromised passwords
LoA 2	Username/password + tiqr, SMS or AzureMFA	The identity of the user is validated	For high level of confidence in the asserted identity. Often used for access to high risk resources
LoA 3	Username/password + YubiKey or FIDO2	The identity of the user is validated	Same as LoA2, but with more secure authentication methods.

A service or institution needs to choose which level of assurance is appropriate for protection. There are several ways a LoA can be requested for a specific service or part of a service.

Second Factor Only (SFO) authentication

With Second Factor Only (SFO) Authentication "Level" is used to indicate the authentication strength: LoA does not apply. There are three levels:

• Level 1.5: any SURFsecureID second factor, no extra validation of the user's identity
• Level 2: SMS, Tiqr or Azure MFA authentication AND the identity of the user is validated
• Level 3: YubiKey or FIDO2 token authentication AND the identity of the user is validated

Assurance level explained

There are several international standards for identity assurance, like NIST (US), eIDAS (Europe, previously STORK) and ISO29115. SURFsecureID is based on 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:

...

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 resulting assurance level is then determined through a depends on the combination of these aspects. The individual aspect with the lowest score will ultimately determine determines the applicable overall assurance level , on the principle that ‘the (a chain is only as strong as the its weakest link’link).

Image Modified

Level of assurance requirements: risk based

The required level of assurance level for a certain service can be estimated based on a number of criteria. These criteria all concern on:

• the importance of the data and
• the potential damages if these data were to be obtained or modified by

...

• unauthorized users

These risks must be assessed .Each service will need to assess risks to be able to decide what the level of assurance is needed . SURF has published guidelines on how to make such a risk assessment. These guidelines are published here.for your service (see also SURFnet guidelines).

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 taken 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 registered 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 taken 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 fulfill 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.SURFsecureID. 

Anchor
Attributes Attributes

Level of assurance vs attributes

Please note that SURFconext Strong Authentication solely SURFsecureID solely focuses on authentication LoA. No LoA is assigned to the individual attributes of the user's identity.

...

...

...

...

...

...

...

...

...

...

...