Inventory of strong identity assurance solutions and how they compare to a web of trust approach

Transcription

1 Milestone M3.1: Inventory of strong identity assurance solutions and how they compare to a web of trust approach Milestone M3.1 Contractual Date: Actual Date: Grant Agreement No.: Work Package/Activity: JRA0 Task Item: WoT4LoA Lead Partner: InnoValor Document Code: MS3.1

2 Authors: Bob Hulsebosch & Martijn Oostdijk (InnoValor) Remco Poortinga-Van Wijnen & Joost van Dijk (SURFnet) DANTE on behalf of the GN3plus project. The research leading to these results has received funding from the European Community s Seventh Framework Programme (FP ) under Grant Agreement No (GN3plus). Abstract This deliverable provides an overview of various registration methods and authentication solutions and evaluates them based on a number of common criteria (costs, user, assurance, etc.). An innovative registration method that is researched in the Wot4LoA project is the use of web of trust. Existing registration practices are compared to the web of trust method. Several authentication solutions are selected that may benefit from a web of trust registration phase and are suitable for use in identity federations for higher education and research. Document Code: MS3.1

3 Document Revision History <This section to be deleted or hidden before publication of deliverable> Version Date Description of change Person First draft issued Bob Hulsebosch Overview of registration methods Bob Hulsebosch Review of registration methods Remco Poortinga-Van Wijnen Overview of authentication solutions added Martijn Oostdijk Review Maarten Wegdam Approved Bob Hulsebosch (PM) Document Code: MS3.1

4 Table of Contents Executive Summary 1 1 Introduction Authentication Strong authentication Objectives and goals Approach and reading guide 5 2 Authentication basics Background LoA 7 3 Registration LoA solutions Physical presence with identity credentials Use of physical address and snail mail Use of or (mobile) phone Use of bank account Copy of official identity credentials Use of official electronic identity credentials Use of video Identity verification services Account linking or federation Web of trust Summary 25 4 Authentication LoA solutions Classification Overview Knowledge based solutions Solutions based on possession Solutions based on out-of-band communications Solutions based on biometrics Other solution directions Summary overview 49 Document Code: MS3.1 iv

5 5 Conclusions 50 6 Error! Bookmark not defined. Table of Figures Figure 1: Identity assurance. 4 Figure 2: Overall authentication LoA components. 9 Figure 4: Paypal s account linking feature. 17 Figure 5: Paypal s two deposit-based verification. 18 Figure 8: Different life-cycle events of an authentication solution. From left to right: new technologies cycle, enrolment cycle, session cycle. 29 Figure 9: Taxonomy of authentication solutions. 30 Document Code: MS3.1 v

6 Table of Tables Table 1: High-level identity registration and proofing and authentication requirements per LoA. 11 Table 2: LoA overview and corresponding methods for identity registration and proofing. 26 Document Code: MS3.1 vi

7 Executive Summary Strong authentication is becoming more popular. In the old days this was mostly something for enterprises and online banking, and bothering users with stronger authentication solutions than username/password combinations for other services was rarely done. But now more services provide access to privacy-sensitive information and/or become more important or even critical. In addition, cybercrime is increasing and gets more attention in the press. Therefore service providers increasingly want to know if a person that is authenticating is indeed the person they think he/she is. Strong authentication implies more assurance in the user s identity. The strength of the authentication process is defined by the strength of the authentication solution used and the degree of confidence that the entity using the credential is indeed the entity that the credential was issued to, i.e. the quality of the registration process. The latter is often neglected, but is not only very important but in most cases also very expensive and annoying for the users. Doing this right typically means doing a face-2-face check as part of the registration and identity proofing process, which is expensive (skilled professional, an office, etc.) and requires the user to go somewhere with an identity document (annoying). Remote identity registration solutions are available and provide varying levels of assurance. For instance, the use of snail mail comes at the cost of user convenience as it breaks the user s authentication session. Utilizing the and especially the mobile channel provide a more real-time user experience, i.e., activation codes can be entered on the fly, but are less secure than face-2-face checks. A generic feature of remote registration approaches is that almost none of them directly verify the identity of the user based on a government-issued ID document. Instead they merely validate access to some resource, e.g., the banking information provided is capable of routing an electronic deposit to an account or that the mobile phone or account is capable of receiving challenges. So while validating multiple paths are leading to the same user, it does not necessarily establish the identity of that user as trustworthy as a face-2-face registration process would. An exception is the use of videoconferencing tools. In this case the user identifies him/herself via the videoconference and shows his/her passport or other valid photo-id to the registrar. The use of video conferencing tools for identification, however, has several drawbacks: it introduces scheduling overhead and it makes it harder to detect a forged ID. Other remote registration approaches rely on the availability of trusted sources to cross-reference and validate the provided assertions such as name, home address, age, social security number, and photo. Examples of such sources are an employer s HR system or the government/municipal administration(s). Consultation of the latter source is often restricted by legislation and therefore not available for enhancing authentication in most cases; the HR system on the other hand could be used as an alternative source if the registration is done by or on behalf of the employer. Document Code: MS3.1 1

8 Executive Summary To increase the trustworthiness of a remote registration a typical approach is to combine multiple methods to create a stronger binding with an identity. Possible combinations are mobile phone and , or bank account and physical address. What should be avoided in relying on so-called static knowledge as part of the registration, e.g., birthdate or place of birth, since this data can too easily be known by a possible identity thief. Account linking provides an interesting method to enhance the assurance of the user s identity. The identity attributes associated to the account can be compared and verified. Matching attributes not only provide assurance that both accounts belong to the same user but also help to uniquely identify that user. For instance, the set of attributes that consists of name, surname, date of birth, and place of birth almost uniquely identify a user. In a web of trust approach, other users vouch for someone s identity. The web of trust approach combines the best of remote and physical registration practices. There is no need for a physical registration desk as other users in the web of trust take over the identification task. s in the web of trust use physical presence, phone or practices for this purpose. The strength of this model is that during the communication between the user and the helpers in the web of trust, the helpers implicitly authenticate the user by verifying his identity. Basically they do the work (for free) that otherwise the (costly) registration authority does. Somehow, the attestations from the web of trust need to be related to the user s digital identity. This needs to be catered for by some kind of federated attestation service that enhances the assurance in the claimant s federated identity with attestations from the web of trust. How this can be done will be described in deliverable D2.1 of WoT4LoA. Linking social network accounts such as LinkedIn or Facebook to the federated account can help for determining the web of trust and the selection of candidate helpers therein that can vouch for a user s identity. The strength of the authentication solution itself constitutes the second part of the overall identity assurance level. A wide range of authentication solutions with varying strengths exist. The easiest way to enhance the strength of the authentication is to introduce a second factor. Particularly the one-time password (OTP) method is broadly used. Numerous OTP implementations exist but there is a shift in preference from traditional hardware tokens to phone-based authentication methods. This is mainly driven by cost and convenience considerations, but also because a mobile phone is a connected device. Other popular solutions are knowledge-based authentication or X.509 hardware tokens such as smart cards. Knowledge-based solutions are relatively weak but cost efficient; X.509 tokens provide strong security but expensive and often too complex for the user. Context-based authentication uses contextual information (e.g., location) to ascertain whether a user s identity is authentic or not, and is recommended as a complement to other strong authentication technologies. Levels of Assurance are a way to indicate the trustworthiness of an identity in, typically, four discrete levels starting at level 1 (username-password and no registration process) to 4 (smartcard and a strict face-2-face process). Well-known standards are STORK and ISO The OTP-based solutions provide authentication assurance at level 2, 3 and 4. Particularly the solutions for the medium trust levels 2 and 3 are interesting for combination with a web of trust registration process. They cater for a scenario in which a user purchases an OTP token or installs an app on his mobile and enhances the binding of it with his (federated) identity via a web of trust based identity registration and proofing process. Specifically for SMS-authentication the web of trust approach could be useful to validate the user s telephone number by other users from the web of trust. Level 4 authentication assurance requires physical registration and proofing. We expect that the web of trust approach will not reach this level. Document Code: MS3.1 2

9 1 Introduction 1.1 Authentication Authentication refers to the process where an entity's identity is authenticated, typically by providing evidence that it holds a specific digital identity such as an identifier and the corresponding credentials. Service providers traditionally use the familiar username and password combination to authenticate users on their websites. Unfortunately, this approach provides a relatively low level of security for users: passwords can be easy to guess, are often re-used, can be phished and are difficult to manage. Adding a second factor, e.g., combining what a user knows with something he has, to the authentication process can help to address these issues. Such stronger authentication solutions increase the assurance that the user really is who he claims to be and raise the level of trust from the service provider to the user. More and more service providers are beginning to rely on strong(er) authentication solutions to stop escalating online fraud, identity theft and to comply with regulations. Many financial organisations such as banks and insurance companies have been using text message- or token-based authentication solutions for transaction verification for years, but recently major websites and businesses not in regulated industries are recognizing the need for stronger online authentication. Not so long ago, Google, Facebook and LinkedIn made two-factor authentication available to all users. The drawback of most of these two-factor solutions is that their binding to user identity is relatively weak. They only ensure with increased reliability that it is the same user as who the two-factor solution was provided to, not who the user actually is. If the binding is weak, even the most complete personal information and the strongest authentication credential will not improve the assurance of identity. However, binding an authentication solution to a user whose identity has been verified and registered is not trivial. It often requires physical presence and verification against authentic sources which is cumbersome and expensive. This is one of the reasons that the use of the relatively weak username and password based authentication solution is still common practice in higher education and research. Nevertheless also in higher education and research increasingly there is a need for stronger authentication solutions. 1.2 Strong authentication Strong authentication implies more assurance in the user s identity. The strength of the authentication process is defined by the strength of the authentication solution used and the degree of confidence that the entity using Document Code: MS3.1 3

10 Introduction the credential is indeed the entity that the credential was issued to, i.e. the quality of the registration process (see Figure 1). Figure 1: Identity assurance. The combined quality of the authentication solution and registration process determines the overall authentication level of assurance (LoA) and thereby the assurance level of the user s identity. For resources (data and/or services) with varying levels of sensitivity, service providers may specify a minimum LoA that is required for getting access. The quality of the authentication solution is mainly determined by the strength of the solution against threats such as impersonation, man-in-the-middle, brute force attacks, and other malicious activities of hackers. Numerous authentication solutions exist, varying from the relatively weak username/password to strong smartcard based tokens. The quality of registration process is determined by two factors: 1. Proof of the identity of the user. 2. Trust in the binding between the user and his/her authentication solution. Different registration processes and mechanisms applied to identity proofing and credentialing result in different registration assurance levels. For instance, an applicant may appear in person to register, or the applicant may register remotely. In person registration in which a person shows an official ID document is the most reliable identity proofing process during user registration. It is considered suitable for cases where there is a strong need to be able to determine that a service provider (e.g. a student information system) is dealing with a legitimate user, thus necessitating a stringent identity proofing process during user registration (i.e. a face-toface process). Remote registration provides less assurance as it is more vulnerable to impersonation threats. Remote registration relies on the availability of trusted sources to cross-reference and validate the provided assertions such as name, home address, age, social security number, and photo. Examples of such sources are the institution s HR system or the government/municipal administration. Consultation of the latter source is often restricted by legislation and consequently in most cases not available for authentication purposes; the HR system on the other hand could be used as an alternative source. Typically, after a successful validation, a registration activation code is sent to the applicant s home address. This is cumbersome and expensive. Various other remote registration methods exist, such as the use of copies of identity documents, the use of the mobile phone, and bank accounts. Document Code: MS3.1 4

11 Introduction An innovative remote registration method that we are researching in the WoT4LoA project is based on the use of web of trust. Web of trust is a concept (used in e.g. Pretty Good Privacy) to establish the authenticity of the binding between an authentication solution and its owner via third party user attests. For instance, if person A claims that user B is using a particular authentication solution, it could provide extra confidence for the service provider to allow access to resources with a higher LoA. The use of web of trust for registration purposes provides a number of potential benefits: it takes away the need for expensive and cumbersome physical registration, it is user friendly as it mimics the authentication decisions we constantly make in social interactions, it combines well with the collaborative nature of research and education and the existing trust fabric that web of trust could optimally exploit, and it is relatively easy to enrol. 1.3 Objectives and goals The WoT4LoA project investigates whether it is possible to enhance the authentication LoA in a cost-efficient and user-friendly manner by using the web of trust concept that is followed by the Pretty Good Privacy (PGP) model. This deliverable will compare the envisioned benefits and drawbacks for using web of trust to enhance the registration LoA with those of existing registration practices, with a focus on research and higher education. The LoA-based assurance model can be used to analyse and define specific requirements related to identity and credentials and help to determine which aspects can be enhanced or replaced with the web of trust concept. Furthermore an inventory and evaluation of authentication solutions and their suitability for use in identity federations will be provided. Based on the outcomes of these two activities, authentication solutions will be selected that can be used in web of trust based scenarios. These solutions will be used in proof-of-concept implementation of the web of trust approach. 1.4 Approach and reading guide Section 2 provides background information regarding the process of user authentication and its strength. In section 3 several authentication registration methods for identity proofing and binding user identities to authentication tokens are presented and evaluated against a number of criteria. These methods are compared with a web of trust approach. Section 4 provides an overview and evaluation of authentication solutions. Finally, section 5 concludes with recommendations for authentication solutions that are suitable for identity federation and can be enhanced with a web of trust based registration approach. Document Code: MS3.1 5

12 2 Authentication basics 2.1 Background Identity authentication is the process whereby an organization or authority establishes its degree of confidence in an assertion that a party is who it purports to be. More laboriously, but more precisely, it is a process designed to crosscheck against additional evidence the asserted or inferred identity by an identifier acquired during an identification process. An item of evidence is usefully referred to as an 'authenticator' (such as the nomination of an additional identifier, or demonstrated knowledge), or a 'credential' such as a document purporting to be associated with the person, or a token such as an 'identity card' or 'photo-id', a piece of information such as a cryptographic secret, or an assertion created by a trusted authority). Authentication systems are frequently described by the authentication factors that they incorporate. The three factors often considered as the cornerstone of authentication are: 1. Something you know (for example, a password); 2. Something you have (for example, an ID badge or a cryptographic key); and 3. Something you are (for example, a voice print or other biometric measurement). Authentication systems that incorporate all three factors are stronger than systems that incorporate only one or two of the factors. Multiple factors raise the threshold for successful attacks. If an attacker needs to steal a cryptographic token and guess a password, the work factor may be too high. Sometimes a fourth factor is added: Somewhere you are at a certain point in time. This fourth factor basically takes the situational context into account during the authentication process. Context factors of interest are location (based on IP-address, GSM cell ID, or GPS), time, or type of device. The system may be implemented so that multiple factors are presented to the verifier, or some factors may be used to protect a secret that will be presented to the verifier. For example, a hardware device that holds a cryptographic key might be activated by a password or the hardware device might use a biometric representation to activate the key. This type of device provides two-factor authentication, although the actual authentication protocol between the verifier and the claimant only proves possession of the key. Document Code: MS3.1 6

13 Authentication basics The quality of identification, and of the authentication of identity, depends on many factors, and the challenges involved result in a substantial incidence of false inclusions and false exclusions. The following aspects need to be considered carefully: The quality of the authentication: when to trust that the one providing the authenticator is indeed the one to which the authenticator points? This is also dependent on the context and the value of the resources to be accessed. The trustworthiness and quality of the attributes obtained and used for identification. The repudiability of an assertion has a party really been uniquely identified or are there other parties with the same identity as well? The liability of the identification who is responsible for the identification and authentication. The quality of the authentication has been quantified in terms of Levels of Assurance (LoA). 2.2 LoA The strength of the entire authentication system is usually expressed in terms of levels of assurance (LoA). Authentication LoA defines the degree of confidence in identifying a user to whom the credential was issued, and the degree of confidence that the entity using the credential is indeed the entity that the credential was issued to. As more diverse resources are being incorporated into federated collaboration environments, service providers may require an assurance level in identifying an entity in an authentication process before an access control decision is made. For resources (data and/or services) with varying levels of sensitivity, the service providers may specify a minimum LoA and require that the access is only granted should the LoA derived in an authentication instance satisfy the minimum LoA. LoA frameworks constitute an to unify and standardize the perception of assurance into a digital identity for the purpose of sharing digital identities between independent trust domains. Several frameworks for expressing LoAs exist, the most well-known are: NIST defines four LoAs and describes concrete technical and procedural requirements that apply for each assurance level 1. InCommon Identity Assurance Framework 2. InCommon states that their Bronze and Silver LoAs match with NISTs assurance Level 1 and 2. In order to cover also NISTs assurance Levels 3 and 4, further InCommon profiles are possible, but do not yet exist. 1 William E. Burr, Donna F. Dodson, & W. Timothy Polk, Electronic Authentication Guideline Recommendations of the National Institute of Standards and Technology, Version 1.0.2, April 2006, see 2 InCommon Identity Assurance Assessment Framework, 9 May 2011, Version 1.1, see and InCommon Identity Assurance Profiles Bronze and Silver, 9 May 2011, Version 1.1, see Document Code: MS3.1 7

14 Authentication basics STORK European eid interoperability framework 3. The STORK Quality Assurance Framework is largely based on NIST Marginal adjustments are made to accommodate European identity authentication and practices. STORK is meant to map national LoA frameworks onto each other in Europe in order to create interoperability. Various national LoA notions exist as well. For instance, DigiD represent a family of Dutch citizen authentication solutions with varying levels: Basic (username/password), Middle (text message authentication), and High (enik) 4. eherkenning (erecognition) is the Dutch infrastructure for authenticating users representing companies. The eherkenning LoA framework is based on the STORK framework 5. Recently, ISO standardised four levels of identity assurance in the ISO/IEC standard (which coincides with ITU-T X.1254)]. 6 These four levels of assurance are: LoA 1 - Little or no confidence in the asserted identity s validity. LoA 2 - Some confidence in the asserted identity s validity. LoA 3 - High confidence in the asserted identity s validity. LoA 4 - Very high confidence in the asserted identity s validity. The levels are based on the degree of confidence needed in the process used to establish identity and in the proper use of the established credentials. Two factors are essential in the determination of the LoA: The strength of the identity proofing, registration, and the delivery of credentials which bind an identity to a token. Aspects to take into account are: o o Quality and robustness of the process (e.g., online, physical presence required, etc.). Reliability of the issuing instance (e.g., government, bank, or social network provider). The strength of the authentication mechanism to establish that a user is who he claims to be, which in turn depends upon o o o Strength of the authentication solution (passwords vs. smart card). Assertion mechanisms used to communicate the results of a remote authentication to other parties. Strength of cryptography used. 3 B. Hulsebosch, G. Lenzini, and H. Eertink, STORK Quality Authenticator Scheme, Deliverable D2.3, March 2009, see 4 DigiD levels of assurance, see 5 eherkenning levels of assurance (in Dutch), see 6 ISO/IEC 29115:2013 Entity authentication assurance framework, see Document Code: MS3.1 8

15 Authentication basics The overall authentication LoA components are shown in Figure 2. Figure 2: Overall authentication LoA components. The overall authentication assurance level is determined by the lowest assurance level achieved in any of the areas listed above. Note that the proofing phase LoA also contributes to the assurance of the registered attributes (e.g. name, address, phone number, student number, etc.). The paradigm of the LoA approach is that individuals are enrolled and undergo an identity proofing process in which their identity is bound to an authentication token. Thereafter, the individuals are (remotely) authenticated to systems and applications using the token in an authentication protocol. The authentication protocol allows an individual to demonstrate to a verifier that he has or knows the secret token, in a manner that protects the secret from compromise by different kinds of attacks. Higher authentication assurance levels require use of stronger tokens (harder to guess secrets) and better protection of the token from attacks. LoA 1 requires little or no confidence in the asserted identity. No identity proofing is required at this level, but the authentication mechanism should provide some assurance that the same claimant is accessing the protected transaction or data. A wide range of available authentication technologies can be employed and any of the token methods of Levels 2, 3, or 4, including Personal Identification Numbers (PINs), may be used. To be authenticated, the claimant must prove control of the token through a secure authentication protocol. Plaintext passwords or secrets are not transmitted across a network at LoA 1. However, this level does not require cryptographic methods that block offline attacks by an eavesdropper. For example, simple password challenge-response protocols are allowed. In many cases, an eavesdropper, having intercepted such a protocol exchange, will be able to find the password with a straightforward dictionary attack. At LoA 1, long-term shared authentication secrets may be revealed to verifiers. Assertions issued about claimants as a result of a successful authentication are either cryptographically authenticated by relying parties (using approved methods) or are obtained directly from a trusted party via a secure authentication protocol. Document Code: MS3.1 9

16 Authentication basics LoA 2 requires confidence that the asserted identity is accurate. LoA 2 provides for single-factor remote network authentication, including identity-proofing requirements for presentation of identifying materials or information. A wide range of available authentication technologies can be employed, including any of the token methods of Levels 3 or 4, as well as passwords. Successful authentication requires that the claimant prove through a secure authentication protocol that the claimant controls the token. Eavesdropper, replay, and online guessing attacks are prevented. Long-term shared authentication secrets, if used, are never revealed to any party except the claimant and verifiers operated by the provider of the credentials; however, session (temporary) shared secrets may be provided to independent verifiers by the provider. Approved cryptographic techniques are required. Assertions issued about claimants as a result of a successful authentication are either cryptographically authenticated by relying parties (using approved methods) or are obtained directly from a trusted party via a secure authentication protocol. LoA 3 is appropriate for transactions that need high confidence in the accuracy of the asserted identity. LoA 3 provides multifactor remote network authentication. At this level, identity-proofing procedures require verification of identifying materials and information. Authentication is based on proof of possession of a key or password through a cryptographic protocol. Cryptographic strength mechanisms should protect the primary authentication token (a cryptographic key) against compromise by the protocol threats, including eavesdropper, replay, online guessing, verifier impersonation, and man-in-the-middle attacks. A minimum of two authentication factors is required. Three kinds of tokens may be used: 1. soft cryptographic token, which has the key stored on a general-purpose computer, 2. hard cryptographic token, which has the key stored on a special hardware device, and 3. one-time password device token, which has symmetric key stored on a personal hardware device that is a cryptographic module validated at FIPS Level 1 or higher. Authentication requires that the user proves control of the token through a secure authentication protocol. The token must be unlocked with a password or biometric representation, or a password must be used in a secure authentication protocol, to establish two-factor authentication. Long-term shared authentication secrets, if used, are never revealed to any party except the user and verifiers operated directly by the provider of these secrets; however, session (temporary) shared secrets may be provided to independent verifiers by the provider. Approved cryptographic techniques are used for all operations. Assertions issued about users as a result of a successful authentication are either cryptographically authenticated by service providers (using approved methods) or are obtained directly from a trusted party (i.e. identity provider) via a secure authentication protocol (e.g. SAML). LoA 4 is for transactions that need very high confidence in the accuracy of the asserted identity. LoA 4 provides the highest practical assurance of authentication. Authentication is based on proof of possession of a key through a cryptographic protocol. This level is similar to LoA 3 except that only hard cryptographic tokens are allowed, cryptographic module validation requirements are strengthened, and subsequent critical data transfers must be authenticated via a key that is bound to the authentication process. The token should be a hardware cryptographic module which cannot readily be copied and ensures good, two-factor authentication. Document Code: MS3.1 10

17 Authentication basics LoA 4 requires strong cryptographic authentication of all parties and all sensitive data transfers between the parties. Either public key or symmetric key technology may be used. Authentication requires that the claimant prove through a secure authentication protocol that the claimant controls the token. Physical registration and identity proofing is required. Eavesdropper, replay, online guessing, verifier impersonation, and man-in-themiddle attacks are prevented. Long-term shared authentication secrets, if used, are never revealed to any party except the claimant and verifiers operated directly by the certification service provider. Strong approved cryptographic techniques are used for all operations. All sensitive data transfers are cryptographically authenticated using keys bound to the authentication process. Error! Reference source not found. establishes the generic registration and proofing and technical authentication requirements specific to each LoA. Note that this table is non-exhaustive, for more information we refer to the following two sections on registration practices and authentication solutions. Table 1: High-level identity registration and proofing and authentication requirements per LoA. LoA Registration and proofing Authentication 1 None or on the basis of user supplied information such as an address. 2 Remote. Use of physical address information to send credentials to, use of shared secrets 3 Remote. Verification of information provided by applicant including e.g. ID number and account number through record checks either with the applicable agency or institution or through credit bureaus or similar databases, use of physical address information to send credentials to. 4 Physical registration at desk with valid driver s license or passport. name and password name and strong passwords, knowledge based authentication, two factor authentication Two factor authentication, one-timepasswords via mobile phone or token, non-qualified certificates Qualified certificates on trusted hardware. Basically all authentication solutions (and there are many of them) can be given a LoA. For service providers this is very convenient as they do not have to bother anymore about all available authentication solutions. They only have to specify the desired LoA for the services. LoAs are becoming more and more a lingua franca around the world. Prerequisite for consistent use of LoAs is the definition of a trust framework. A trust framework is a certification program that enables service providers accepting digital identity credentials to trust the identity, security, and privacy policies of the identity and authentication providers who issue the credential and vice versa. Furthermore, the trust framework defines the qualifications necessary to be an assessor for the trust framework; there must be some kind of governance body that is able to assess whether an identity or service provider is in compliance with the policies specified for a certain LoA. E.g., an authentication solution offered by an identity provider must be evaluated and rated according to the specified levels by the governance body such that a service provider can rely on it without having to know the details of the authentication solution used. Document Code: MS3.1 11

18 Authentication basics Several attributes provided by the identity provider (IdP) of the institution will be validated during registration and identification. These attributes for instance include first and last name, address or virtual organisation membership. 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 service providers to make their authorisation more reliable. However, in most cases authorisation will be based on other less validated attributes. It will make the registration process too complex if one decides to validate all possible attributes. If specific validated attributes are required, the service provider has to find an attribute service provider that can provide them; this is beyond the scope of this research. Moreover, having attributes with varying LoAs would complicate the use of the already complicated LoA concept even further and might hamper its adoption/acceptation. We therefore solely focus on authentication LoA. Document Code: MS3.1 12

19 3 Registration LoA solutions The process by which a physical person is linked to his/her digital identity information and to his/her authentication credential is critical to deter registration fraud. If this process results in a weak link of the person to either the credential or the identity, there can be little or no assurance that the person using that credential to authenticate and access services and information is who he/she claims to be. It could be anyone including impostors that impersonate a claimed identity, it could be multiple people over time, or even subscribers that deny registration. If the linking is weak, even the most complete personal information and the strongest credential will not improve the assurance of identity. The registration process is designed, to a greater or lesser degree depending on the assurance level, to ensure that the registration authority knows the true identity of the applicant. Two processes are important for determining a registration LoA: 1. Identity proofing - the process by which identity related information is validated so as to identify a person with a degree of uniqueness and certitude sufficient for the purposes for which that identity is to be used. This usually involves a minimum set of attributes that reach a high probability that its combination is unique in a given constituency (e.g., the first and last names, date of birth, and place of birth). Identity proofing provides confidence that the user performing an authentication is the legitimate user. Identity proofing will lead to the issuance of an authentication credential to someone. A poorly identity-proofed smart card provides less identity assurance than an adequately identity-proofed password. 2. Identity binding the process of binding an association between an authentication credential and an identity to which it will be issued. How binding is accomplished and the confidence in the association determines the LoA. There are two general categories of threats to the registration processes: Impersonation of a claimed identity An applicant claims an incorrect identity, supporting the claim with a specific set of attributes created over time or by presenting false credentials. Compromise or malfeasance of the infrastructure Lack or poor implementation of security measures and policies undermine the reliability of the registration. This section concentrates on addressing the impersonation threat. Infrastructure threats are addressed by normal computer security controls (e.g., separation of duties, record keeping, independent audits, etc.) and are outside the scope of this document. Document Code: MS3.1 13

20 Registration LoA solutions Registration fraud can be deterred by making it more difficult to accomplish or by increasing the likelihood of detection. During the registration process methods should be employed to determine that a person with the claimed identity exists, and that the applicant is in fact the person who is entitled to that identity. As the level of assurance increases, the methods employed provide increasing resistance to casual, systematic and insider impersonation. A number of solutions are known for identity proofing and binding of identity to an authentication solution. This section lists and evaluates them in more detail. The following aspects are taken into account in the evaluation: How costly is the solution? Is the solution user friendly and convenient? What is the implementation to roll out the solution; does it scale? What level of assurance does it offer? Are there any risks or threats associated to it? 3.1 Physical presence with identity credentials The easiest and safest way to proof a user s identity and bind an authentication token such as a mobile phone or certificate to it is to require physical presence during registration and enrolment. Usually the user has to show his passport or driving license for identification purposes. During physical presence it is effective to register additional authentication credentials such as a mobile phone or token and bind them to the verified identity. Examples of registration processes that require physical presence: The collection of the Belgium national eid card at the city hall and on presentation of a valid identity document. The Dutch ING bank sends a new bank account password to the nearby post office and asks the user to collect it personally on presentation of his passport. The authentication token for Dutch health care professionals can be requested online and is physically handed over by a trusted courier after having verified the identity of the professional. Though the approach of physical presence is used by many organisations, it comes with several drawbacks: It is very expensive in terms of labour of desk employees and their training. It is not very user friendly as the user has to go to the registration desk. Evaluating physical presence during authentication solution binding and enrolment against the criteria results in the following table: Document Code: MS3.1 14

21 Registration LoA solutions Costs High A registration desk has to be maintained. Low The user has to go to the desk. Enrolment High Several procedures need to be arranged for registration and enrolment of the tokens. Level of High There is a strong binding between a user s verified identity and assurance the authentication solution. 3.2 Use of physical address and snail mail Knowledge of the physical address of the user can be exploited to improve the binding between the user and his authentication credentials. For instance, the Dutch government makes use of this for the issuance of its national DigiD credentials. The user is asked to enter his BSN, address details 7 and address on the DigiD website. Subsequently, an activation code is sent to the house address of the user (after verification of the entered information in an authentic government owned registry). The user enters the activation code together with his username to activate the account. Also several banks use the physical address and snail mail to communicate activation or PIN codes. A prerequisite for this approach is that the credential provider has knowledge of reliable address information of the user. Typically the government and banks are authorities that know their users home addresses. Moreover, there is a strong reliability on the security of snail mail. The recent fraud in the Netherlands with stolen DigiD activation codes from physical mail boxes illustrates that snail mail cannot be trusted completely. If an authentic registry for address information is not available, the registration authority could ask the user to send a proof of residence (e.g. a recent utility bill) but that is very inconvenient and requires manual processing. For higher education, the identity provider (of the university) may have reliable address information. The use of the physical address is relatively expensive and less user friendly as it breaks the user authentication session; the user may not come back the second time. Evaluation: Costs Moderate to Handling the process of sending letters is costly, stamps and high envelopes can make it particularly expensive for large user groups. Moderate The user has to wait for the activation code to arrive via snail mail. Breaks the authentication session; the user may not come back after he has received the activation code. Enrolment Moderate A process for sending codes via snail mail has to be constructed. Level of Moderate Mail can be stolen, phished or get lost. 7 Though address details of the user are in the GBA/BRP (Dutch municipal residence administration), the user is asked to enter them. This allows DigiD to verify the entered information against the GBA data and provides an additional check. Document Code: MS3.1 15

22 Registration LoA solutions assurance 3.3 Use of or (mobile) phone Often when users open an account they are asked to provide their address. This address is used to send an activation code or hyperlink that the user must enter or click upon to confirm that he indeed opened the account. Sometimes the mobile phone is used for such purposes as well (e.g. for sending an SMS with an activation code or for calling back the user to validate the online-provided callback code). Helpdesks employees use the phone frequently for authentication purposes. They for instance have to provide emergency authentication services for users that have lost their authentication token, forgotten their password or username and call them for help. In such cases helpdesk employees have a range of security assurances to identify the caller prior to providing new credentials. Via the phone they can ask life questions, identify the voices of callers they know personally, verify caller IDs and so forth. This form of identity proofing is weak if it does not include human intervention: it only proves that the user has access to a certain address or phone number. Moreover, it does not prove anything about the identity of the user owning the address or phone. The lack of a solid identity proofing results in a weak binding to the user s authentication solution, i.e. the username and password that he created during the opening of the account. Consequently, the solution is prone to "man-in-the-middle" phishing attacks that try to breach the registration process. The use of human intervention such as is the case for the callback and helpdesk methods provide higher assurance levels but are expensive. The evaluation of the use of the mobile phone or for identity proofing turns out as follows: Costs Low to moderate Enrolment Level assurance of High Low Low Sending an is trivial and for free, sending text messages is relatively cheap (few eurocents per message) but may become costly for large user groups. Callback methods are more time consuming and therefore more costly. The user is used to receiving s or text messages. Being called back for authentication purposes is less common. Almost everybody has or a phone; implementation is straightforward and proven. s and text messages can be spoofed, is rarely encrypted and accounts often only password protected, man-inthe-middle attacks cannot be discounted. The link between the user s identity and the address or phone is not validated. The method merely validate that the (mobile) phone or account is capable of receiving challenges Callback methods provide more assurance but are expensive. Document Code: MS3.1 16

23 Registration LoA solutions 3.4 Use of bank account An identity related to an existing account can be verified via a personal bank account that is not shared with other users. Bank accounts are usually very secure and can only be accessed via strong authentication solutions. Moreover, by law banks are required to know their customers and this implies that many banks require physical presence and proper identification prior to opening a bank account. The combination of strong authentication and identification means that the binding between a user, his personal bank account and his authentication token is very reliable. Other authentication providers can benefit from this. Paypal for instance makes use of the user s bank account for linking its own user account with a bank account. The method works as follows: 1. Sign into PayPal account. 2. Click the "Get Verified" link. 3. Click the "Add Bank" option. 4. Fill in the requested bank information. 5. PayPal makes two small deposits to your bank account. 6. Check the bank statements for the deposits. 7. Return to PayPal s account page and click on the "Confirm Bank Account" link. 8. Enter the amount of the deposits. 9. PayPal verifies the amounts and elevates the account status if the received information is correct. The two figures below illustrate how Paypal verifies the bank account with two small deposits. Figure 3: Paypal s account linking feature. Document Code: MS3.1 17

24 Registration LoA solutions Figure 4: Paypal s two deposit-based verification. A user has to use the bank s strong authentication solution to obtain Paypal s deposits and link their account with the user s bank account. In a way, Paypal leverages the bank s strong authentication solution to increase its confidence in the user s Paypal identity. The Dutch finance company Alex also makes use of this concept. There is, however, a slightly unexpected risk here. Several banks, such as the Dutch ING, only require a username/password to login and have an overview of all financial transactions 8. Fraudsters can use this relatively low level of security and subsequent lack of proper identity verification to spoof transaction details (including Paypal s deposits) and open a Paypal account that is linked to someone else s bank account. This example shows that if one doesn t carefully take into account the various LoA things can go easily wrong. Another risk associated to using a bank account for registration purposes is that the owner of the account may have mandated another user to make financial transactions on his/her behalf. In that case, the mandated user may present himself as the owner of the account during the registration phase of a new authentication solution. Evaluation: Costs Low Transferring small deposits is cheap. Moderate The user has to provide bank account information and login to his bank account and type over the deposits, it is questionable if it is intuitive in a higher education and research context. There may be a delay in the money transfer. Enrolment Moderate Making deposits to bank accounts is not trivial to implement. Level of Moderate to Bank accounts are usually pretty well secured. assurance high 8 See Document Code: MS3.1 18

25 Registration LoA solutions 3.5 Copy of official identity credentials As proof of identity a certified copy of a passport or National identity card is sometimes accepted. Such a copy can either be certified or uncertified. The latter offers almost no proof that in the sense that it really belongs to the user sending it. For certified copies, the certifier must be able to achieve the following: having seen the individual and identification document at the same time, I certify this is a true copy and the photograph is a reasonable likeness." Examples of certification authorities are: A notary public; A consular or embassy official from your consulate or embassy; A police officer; A qualified accountant or auditor. Non-certified copies provider a lower level of assurance as they can be taken from stolen or lost identity credentials. A digitized copy, even if it is certified, that falls in the hands of a user with malicious intentions can easily be reused for all kinds of purposes. Binding between a copy and a user remains a weak registration solution. Confidence should be established that the ID document it is still under the control of the entity that it relates to (e.g. it has not been stolen/cloned or being used by a bot). So checks against register of stolen/revoked official identity credentials are required. Evaluation: Costs Enrolment Level assurance of Low for uncertified copies High for certified copies High for uncertified copies Low for certified copies Low for uncertified copies High for certified copies Low for uncertified copies High for certified copies Making a copy is cheap. Certification is costly. It is easy to make a copy. Very inconvenient and requires manual processing. No required. Certification authorities are required. No proof that the copy indeed belongs to the user. It requires physical presence of the user with a valid ID credential. 3.6 Use of official electronic identity credentials More and more official identity credentials in the physical world such as passport or driving license are supplied with a chip. The chip may contain identifying information attributes such as social security number, name, address, gender, and date of birth, or even a biometric template of, e.g., a fingerprint. These attributes are signed by the issuing organisation, which in most cases is the government. Document Code: MS3.1 19

26 Registration LoA solutions The binding process of these identity credentials with the user is very solid as they require physical presence. And the recent electronic enhancement makes them suitable for online authentication processes 9. When using official ID documents like passport of driving license, the authenticity of the document should be checked. This requires trained personnel or the use of online verification services like IDchecker 10. Furthermore, confidence should be established that the ID document it is still under the control of the entity that it relates to (e.g. its not been stolen/cloned or being used by a bot). So checks against register of stolen/revoked official identity credentials are required. The use of electronic ID credentials (ID card or epassport) is rather complex but promising for the near future. It requires card readers and a solid enrolment process for binding these credentials with existing accounts. The emergence of NFC enabled mobile phone for payments could provide a boost for this authentication method. Evaluation: Costs High A reader is required to communicate with the epassport or eid card, a less expensive solution is to have a reader at the user s institution. Increasingly smartphones are becoming NFC-enabled; this may reduce the costs. Moderate The user has to have his epassport or eid card readily available. Enrolment Level assurance of Moderate Moderate Enrolment of epassport or eid card is needed; this implies e.g. a special application that is capable of reading the electronic documents securely. Enrolment could be done via self-service at a desk with a reader at the user s institution. Measures must be taken to be sure that the epassport or eid card is not stolen. The challenge-response nature of the authentication protocol is susceptible to relay threats: A rogue identity provider can relay challenges and responses to another identity provider and pretend to have direct access to an epassport. 3.7 Use of video In case the user is somehow not able to register in person, video conferencing tools such as Skype could be used. In this case the user identifies him/herself via the videoconference and shows his/her passport or other valid photo-id to the registrar. The use of video conferencing tools for identification, however, has several drawbacks: it introduces scheduling overhead and it makes it harder to detect a forged ID. If the user already has an authentication credential, he can be asked during the video-conferencing session, to perform an authentication. This immediately ensures 9 M. Oostdijk, D-J. van Dijk, & M. Wegdam, Centric Identity Using epassports, in Proceedings of SecureComm 2009 Conference, September 14-17, 2009, Athens, Greece; published in LNICST 19, Springer, pp , 2009, see 10 IDchecker, see Document Code: MS3.1 20

27 Registration LoA solutions binding between the user and his credential (if not the actual identity itself). If the user does not have an authentication credential he can be asked to provide address information to send the credential to. Evaluation: Costs Moderate Most people will have video conferencing capabilities in his laptop or mobile phone. It introduces scheduling overhead. Moderate Video conferencing is usually considered convenient but intrusive. Enrolment Moderate Common availability of conferencing tools such as Skype makes it easy to implement. Scheduling functionality is required. Level of Moderate It is difficult to detect if the ID document shown during the video assurance session is authentic or forged. 3.8 Identity verification services Identity verification services provide a verification-chain framework to identity and service providers, for example in the space of online dating services, while protecting sensitive information. These services typically work as follows: s sign up for a new account on a dating site and are prompted to click through to the site of an identity verifier. s create profiles with details such as their name, age, address, and occupation, etc. Verification services electronically check data in public-record databases to verify assertions and prompt users to answer other challenges based on public records. If users pass these challenges, they are granted a verified status. Identity verification services provide value by acting as a mediator in an identity transaction. They create trust by certifying that the user is indeed the person he claims to be, without disclosing sensitive information about the user to the other party. There are a number of players in this space. The main ones are edentiti 11, VeriSign 12, Trufina 13, and Idology 14. A couple of other services in the space are RapLeaf 15 and ikarma 16. These services rely on transaction history (RapLeaf) or explicit recommendation and testimonials (ikarma) to evaluate the reliability and trustworthiness of an individual. All of these services provide tight integration at the point of transaction. It is not unrealistic for Document Code: MS3.1 21

28 Registration LoA solutions social network providers such as Facebook, Hyves and LinkedIn to become identity verifiers in the near future as well. While these companies provide a valuable service, their penetration outside the online dating space seems to be somewhat limited, also depending on country. Some potential issues may be the cause for the low uptake. One of the main issues is that identity validation services rely on public records. These services typically ask users to provide some personal information, based on which they access public records available for that person. These services then challenge the users to answer questions, based on the information in these public records. If the user answers these questions correctly (i.e., the answers match the information available in public records), the user is considered verified. The availability of suitable public records varies per country, depending amongst others on privacy regulations. All of the public records are available online for everybody to search and see. E.g., via dedicated search engines such as Intelius or Google access to numerous public records can easily be obtained. If somebody wanted to pretend to be another person, he would certainly check all these public records to provide enough information to answer the challenge questions correctly. Evaluation: Costs Moderate Identity verification service providers will charge their customers. High The whole verification process is transparent to the user. Enrolment Moderate Links to verification service providers have to be created. Level of Low to It is mostly based on public records yet multiple records are often assurance moderate used to verify the user s identity. 3.9 Account linking or federation Account linking or federation could be used to leverage the user s federated authentication outcome for the issuance of other authentication solutions. Account federation or linking occurs when a user chooses to unite distinct service accounts and identity provider accounts. s retain the individual account information with each provider while, simultaneously, establishing a link that allows the exchange of authentication information between them. For instance, the student s account at the university s identity provider is linked with that of another authentication provider such as Google. In an identity federation, the authentication outcome is reused over a number of (federated) services. Authentication service providers in such a federation can rely on the identity assertions of the identity provider. A good example is the TCS escience Portal 17 that issues certificates to users based on federated login. 17 See Document Code: MS3.1 22

29 Registration LoA solutions Account linking uses protocols such as SAML, OAuth, or OpenID Connect to create a persistent association between these distinct user accounts. The account link, or name identifier, may be either a unique attribute, such as an address, or a pseudonym generated by the identity provider to uniquely identify individual users. Pseudonyms can be used if privacy is a concern; they cannot easily be traced back to a user's identity at the partner site. Optionally, during account linking, additional attributes may be sent with the name identifier. The authentication provider can use these attributes to challenge the user with knowledge-based questions or send activation codes to addresses or mobile phones via text message. Moreover, by comparing the attributes that are associated to each account (e.g. name, surname, address, etc.) an enhancement of the assurance of the identity of the user can be achieved, i.e. the matching attributes may proof that both accounts indeed belong to the same user. Care must be taken not to compromise privacy. Similar attributes associated to multiple accounts can be validated against each other thus providing more (or less) confidence in the attributes. Evaluation: Costs Low It is easy to implement. Moderate The user has to perform an extra authentication during account linking. There is a privacy risk not all users will be willing to link Enrolment Level assurance of Moderate Moderate their accounts. The authentication or service provider must implement accountlinking functionality which is not a core functionality of his service offering. It only works for linking lower or equal assurance identities Web of trust Web of trust is a concept (used in e.g. Pretty Good Privacy) to establish the authenticity of the binding between an authentication solution and its owner via third party user attests. For instance, if person A claims that user B is using a particular authentication solution, it could provide extra confidence for the service provider to allow access to resources with a higher LoA. Person C could also claim to know B and his authentication mechanism thereby even further increasing the trust in the identity of B. It can be considered as a kind of crowdsourcing of trust. The social or research context of the user could be used to enhance the registration part of the overall LoA. Particularly in the context of research groups or virtual organizations in which users know each other, such web of trust based LoA enhancement could be executed in an efficient manner. Moreover this approach also makes it easier to use social identities provided by e.g. Facebook and Google in higher education and research environments. The registration LoA part of these popular social identity providers is relatively weak (LoA 1) despite the fact that an increasing number of them are using two-factor authentication (LoA 2). Web of trust based enhanced LoA could help increasing the registration LoA part of these providers and thus could help in increasing the overall LoA. Document Code: MS3.1 23

30 Registration LoA solutions The web of trust approach also has its weaknesses. ENISA has summarized the possible threats such as whitewashing attack, sybil attack, impersonation and reputation theft, bootstrap issues and related to newcomers, extortion, denial-of-reputation, ballot stuffing and bad mouthing, collusion, repudiation of data and transaction, recommender dishonesty, privacy threats for voters and reputation owners, social threats such as discrimination or risk of herd behaviour, attacking of the underlying infrastructure and the exploitation of features of metrics used by the system to calculate the identity assurance 18. These threats should be taken into account to evaluate usefulness of the web of trust based solution to enhance the LoA in the context of identity federations. A potential improvement to traditional web of trust systems would revolve around reducing the validity period of the claims made by other users regarding a specific user account and to allow for automatic prolongation of the trust-based claims associated to the account by subsequent authentication sessions. This would allow for both verification of use of the account and the identity associated to it and user revocation of stale or otherwise undesired credentials. During the refresh process, the user can choose whether to continue or stop endorsing others accounts; this helps the dynamics of the web by helping to cull out untrusted persons more rapidly. Further, providing the option for anti-claims, to specifically call out an account as untrusted to others, would significantly mitigate the effect of malicious persons such as spammers gaining access to a web of trust. Allowing for this anti-measure could also form the basis of a sliding trust scale, with trust and anti-trust counting against each other and allowing for unconnected persons to see that a particular account may or may not be trustworthy. Paths connecting persons would be deprecated by paths containing anti-claims; determining whether or not to trust someone with a significant number of anti-claims would be assisted by allowing short comments with them similar to twitter messages (i.e. this person is a spammer or this person is a liar ). Further research is required to explore the possibilities and limitations of web of trust enhanced authentication. This will be done in D2.1 of WoT4LoA. Evaluation: Costs Moderate A web of trust mechanism must be implemented, managed and provided to users in a trustworthy manner. A cost-reducing factor is that web of trust enhanced authentication takes away the need for physical registration. Enrolment Level assurance of High Moderate Moderate The web of trust approach naturally matches with what users do all the time in daily life where they use human relationships for authentication purposes. In social interactions, introducing one person to another is the most common way of identifying (and implicitly authenticating) acquaintances. A web of trust needs to be established. Reuse of existing webs of trust bootstraps this problem and reduces the enrolment. Depends on the number of trustworthy nodes in the web of trust that have made claims about a user s identity. 18 Elisabetta Carrara and Giles Hogben, Reputation-based Systems: a security analysis, ENISA position paper, October Document Code: MS3.1 24

31 Registration LoA solutions 3.11 Summary In general, these described registration LoA approaches help to increase the overall authentication strength by using an additional communication channel. Using more separate channels leads to stronger authentication levels. However, higher authentication strength does not necessarily represent the best solution, as security often requires trade-offs in user convenience and/or costs. Particularly the use of snail mail comes at the cost of user convenience as it breaks the user s authentication session. The and mobile channel provide a more realtime user experience, i.e., activation codes can be entered on the fly, but are less secure. A generic feature of the registration LoA approaches that are based on remote registration is that almost none of them adequately verify the true identity of the user. Instead they merely validate that, e.g., the banking information provided is capable of routing an electronic deposit to an account or that the mobile phone or account is capable of receiving challenges. So while validating multiple paths are leading to the same user, it does not necessarily establish the identity of that user. An exception is the use of videoconferencing tools. In this case the user identifies him/herself via the videoconference and shows his/her passport or other valid photo-id to the registrar. The use of video conferencing tools for identification, however, has several drawbacks: it introduces scheduling overhead and it makes it harder to detect a forged ID. Other remote registration approaches rely on the availability of trusted sources to cross-reference and validate the provided assertions such as name, home address, age, social security number, and photo. Examples of such sources are the institution s HR system or the government/municipal administration(s). Consultation of the latter source is often restricted by legislation and therefore not available for enhancing authentication; the HR system on the other hand could be used as an alternative source. An interesting alternative is to combine multiple methods to create a stronger binding with an identity. Possible combinations are: Mobile phone and . The use of the mobile phone is most convenient but requires the verification of the phone number somehow (assuming the user s institution doesn t have knowledge of it). This can be done via another channel like . As the address is known by the user s institution, it can send a notification to the user saying that a certain mobile phone (number) has been linked to his account. Voice recognition via the mobile phone and . The mobile phone as a user friendly tool to verify the user s identity via voice recognition. The channel should be used as a second channel for the enrolment of the voice recognition, i.e., for registering the mobile phone number and for recording the voice template. Bank account and . A bank account is highly secured but its use does not proof that it is owned by the user identity that needs to be authenticated. Here an could be sent as well to verify that the bank account is indeed linked to the user owning the address. Instead of an address, the physical address can also be used to send activation or other credentials to. Document Code: MS3.1 25

32 Registration LoA solutions Account linking provides an interesting method to enhance the assurance of the user s identity. The identity attributes associated to the account can be compared. Matching attributes not only provide assurance that both accounts belong to the same user but also help to uniquely identify that user. For instance, the set of attributes that consists of name, surname, date of birth, and place of birth almost uniquely identify a user. Only the physical registration approach truly verifies the user s identity but this is expensive, time consuming and not user friendly. The web of trust approach combines the best of remote and physical registration practices. There is no need for a physical registration desk as other users in the web of trust take over the identification task. in the web of trust may use physical presence, phone or practices for this purpose. Somehow, the attestations from the web of trust need to be related to the claimant s digital identity. This needs to be catered for by some kind of federated attestation service that enhances the assurance in the claimant s federated identity with attestations from the web of trust. How this can be done will be described in deliverable D2.1 of WoT4LoA. Account linking can help for determining the web of trust and the user therein that can vouch for another user s identity. The table below provides an overview of the LoAs for the different identity proofing and registration methods. Table 2: LoA overview and corresponding methods for identity registration and proofing. LoA Objective Controls Method 1 Identity is unique within a context 2 Identity is unique within a context and the entity to which the identity pertains exists objectively 3 Identity is unique within a context and the entity to which the identity pertains exists objectively, identity is verified and is used in other contexts 4 Identity is unique within a context and the entity to which the identity pertains exists objectively, identity is verified and is used in other contexts Self-asserted Proof of identity through use of identity information from an authoritative source Proof of identity through use of identity information from an authoritative source + verification Proof of identity through use of identity information from one or more authoritative sources + verification + entity witnessed in person Use of or mobile phone Copy of ID-credential Copy of utility bill Account linking / attribute matching Use of physical address and snail mail Use of video and proof of authentication Use of bank account Use of electronic ID-credentials Identity verification services Web of trust + account linking Physical presence with ID credential (e.g. passport, ID-card, driving license) and issuance of authentication credential in person. Combinations of multiple remote methods will increase the LoA till at most level 3. For LoA 4 physical presence is required. Document Code: MS3.1 26

33 4 Authentication LoA solutions Inventories of authentication solutions have been published in recent years: Kuppinger Cole - Market Overview Strong Authentication 2010; Gartner Market Overview Authentication 2008; Gartner Market Scope for Enterprise Broad-Portfolio Authentication Vendors 2009; Novay Whitepaper: Authentication solutions state of the art ; Academic overviews (UvA MSc. thesis C. de Jong 2008, UvA MSc. thesis D. van den Ende and T. Hendrickx 2009, RU MSc. thesis Schouwenaar 2010); GLUU overview of authentication solutions see J. Bonneau, C. Herley, P.C. van Oorschot, and F. Stajano, The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes, Proceedings of the 2012 IEEE Symposium on Security and Privacy, These inventories usually consist of long lists of authentication solutions that are typically classified in four main categories: knowledge-based (e.g. username/password and challenge question), possession-based (e.g. OTP token, TAN list, PKI certificate or EMV CAP reader), out-of-band (e.g. SMS OTP and caller line identification), and biometric solutions (e.g. face and voice recognition). There are other solutions that do not fit in the four categories. These solutions typically involve new, noncryptographic authentication techniques like risk based, behavioural biometrics, and geo-location. We note that so far these solutions have not been integrated in recognized frameworks like the STORK QAA levels and NIST. In order to evaluate the suitability of the numerous authentication solutions for the education and research community and their identity federations several aspects need to be taken into account: How costly is the solution? Is the solution user friendly and convenient? 19 See (in Dutch). Document Code: MS3.1 27

34 Authentication LoA solutions What is the implementation to roll out the solution; does it scale? What level of security does it offer? Are there any risks or threats associated to it? Is the technology sufficiently mature? Is it sufficiently mobile? Other, more strategic approaches are possible to tackle the authentication challenges. For instance outsourcing two-factor authentication to a trusted third party can help address the challenges (i.e. costs and organisational management overhead) research and education face regarding authentication in the following ways: Higher education and research institutions do not need to invest in building and operating a two-factor authentication infrastructure. The trusted operator is responsible for reliability and scalability of the service. Quick time-to-market. One solution is two-factor authentication-as-a-service (AaaS). AaaS is an internet-based service that offers an on-demand verification of the user s second factor to service providers. AaaS could be very interesting as a step-up authentication solution for the higher education and research community, and could be offered by federation operators as a federated service. It is up to the federation operator to select and approve the authentication solutions that will be provided via such an AaaS. A challenge here is to make sure that the binding between the user s identity and the selected AaaS authentication token is guaranteed. When working with authentication tokens the life-cycle of the tokens should be taken into account. Authentication tokens follow a life-cycle which can be described on three levels as depicted in Figure 5. First, on the largest scale, issuers of authentication tokens will, from time to time, come to the conclusion that new authentication technologies need to be introduced. Reasons could be economic (new technologies may be cheaper) or caused by new threats. In general any number of reasons could drive an issuer to switch technologies, and the business model is usually far from simple. Second, on a medium scale, authentication tokens that are issued to individual users have a limited lifetime in which they can be used. Many tokens have a battery, which naturally limits the token s lifespan. s will also lose their token or damage a token beyond repair and request a new one. Security may be a reason to artificially limit the lifespan of authentication technology as well: it is common practice to limit the validity of certificates to a fixed period. Third, on the finest scale, tokens are used in authentication sessions, starting when the user signs in, and ending when they sign out. Before allowing a user to authenticate with the token, the token may itself want to make sure its rightful user is handling it using a process called card holder verification (CHV) which usually involves verifying that the user knows a PIN code. As some tokens combine pure authentication with other identity related procedures during sessions (such as signing messages or authorizing transactions) this lifecycle involves more than just authentication. Document Code: MS3.1 28

35 Authentication LoA solutions For the evaluation of solutions the life-cycle of authentication tokens and the complexity of it should be taken into account as well. Figure 5: Different life-cycle events of an authentication solution. From left to right: new technologies cycle, enrolment cycle, session cycle. The quality of the life-cycle of authentication solutions is taken into account in the LoA paradigm. Service providers that need to authenticate the user do not need to worry anymore about various authentication solutions, they just have to determine the required LoA for their services and ask the user authenticate with that LoA. 4.1 Classification Technical authentication solutions ( authentication tokens ) can be classified in many different ways. Typically a taxonomy of tokens is based on characteristics of the underlying technology. A possible (naive, start of a) taxonomy of solutions in given in Figure 6 below. Document Code: MS3.1 29

36 Authentication LoA solutions Figure 6: Taxonomy of authentication solutions. The taxonomy is not complete: there will be new technologies not mentioned here, there will be other ways to connect devices to the web session through which the user is interacting with the service provider, and there are, for example, many more biometric factors in addition to face and fingerprint. The taxonomy also compares apples to oranges, some technologies can be categorized as out-of-band and challenge-response at the same time, risk based technologies do not form a complete authentication solution on their own, but are typically added to take away certain risks associated with weak authentication factors. Nevertheless, we will have to use some sort of taxonomy like the above one, in order to be able to reason about the different types of tokens, their security, usability, and cost benefits and drawbacks, and the possibility to apply these tokens in a social network setting. Document Code: MS3.1 30