Step-up-authetication as a service

Step-up-authetication as a service Pieter van der Meulen Technical Product Manager For more details see the report at: http://www.surfnet.nl/ Documents/rapport_Step-up_Authentication-as-a- Service_Architecture_and_Procedures_final.pdf

SURFsure Bind existing institutional authentication (SAML) Something you know to something you have Token, phone to offer higher a LoA to federated services Leverage existing relations SURFnet has with its constituency for the RA process Self service though website 2

SURFsure 2 Open - provide several 2nd factors SMS, Ubikey, tiqr Standards OATH SAML Easy implementation for IdPs 3

Use cases Institution administration e.g. access to financial records Research Access to sensitive data, expensive equipment e.g. life sciences VPN access Not in scope 4

Federation Models 1 to 1 IdP SP Business NSPs x NIdPs IdP SP Shared trust Point to Point IdP IdP SP SP IdP SP NSPs + NIdPs IdP SP IdP SP Central Gateway IdP Gateway SP 5 NxN : Mesh federation. Most common model N+N: Hub and Spoke model. Used by SURFnet and others. IdP: Identity Provider SP: Service provider

SURFsure AuthN flow IdP SURFconext SURFsure SP AuthN req LoA 1 AuthN reqest RequestedAuthContext AuthNResp LoA 1 Auth 2nd factor Resp 2nd factor AuthN response AuthContext Implement SURFsure as a transparant SAML proxy between the SP(s) requiring step-up and the IdPs in the federation. Can be added equally well to 1-1, NxM (Mesh) and (N+M) Hub-andspoke federation models. For hub-and-spoke the SURFsure gateway sits between the federation hub (SURFconext) and the SP. Before AuthN starts the user must have been enrolled resulting in a 2nd factor that is bound to the users federative (LoA 1) account. 1) SP uses RequestedAuthnContext (SAML 2.0 core, Section 3.3.2.2) to request the LoA (STORK/NIST) 2) SURFsure performs a normal (LoA 1) SAML authentication to the user s home IdP; discovery (WAYF) for IdP selection can be performed at SP, SURFsure, SURFconext. Choose one. 3) SURFsure has the (LoA 1) identity of the user. Use that to authenticate the user using the (LoA > 1) 2nd factor bound the to the user. 4) If authentication is successful sent an AuthN response to the SP that contains the achieved LoA. 6

LoA : NIST, STORK LoA 1 No registration requirements Minimal assurance is requested for the authentication mechanism LoA 2 Registration requires information from an authoritative source A secure authentication protocol shall be used. Controls shall be in place to reduce the effectiveness of eavesdropper and online guessing attacks. Controls shall be in place to protect against attacks on stored credentials. 7

LoA : NIST, STORK LoA 3 Registration requires information from an authoritative source + verification Any secret information exchanged in authentication protocols shall be cryptographically protected LoA 4 Registration requires information from an authoritative source + verification + entity witnessed in person Tamper-resistant hardware devices for the storage of all secret or private cryptographic keys shall be used. Sensitive data included in authentication protocols shall be cryptographically protected. 8

Transmit LoA Use a standards based approach: The SAML 2.0 Authentication Context class reference Based on the SAML 2.0 Identity Assurance Profiles 1.0 (2010) Committee Specification 01 Using internationally used identifiers (URNs) possibly using the IANA registry Transmit LoA as a single URN. No differentiation between assurance level of the registration and the assurance level of the http://docs.oasis-open.org/security/saml/post2.0/sstc-samlassurance-profile.html http://tools.ietf.org/id/draft-johansson-loa-registry-06.txt 9

Registration Remote registration Requires availability of trusted registries to validate name, address, ID numbers Dutch governmental/municipal registries may not be used by institutions Send registration letter to home address In person registration Seems more efficient!? Can meet requirements for LoA 4 10

Invite a User The RA invites a user to get and register a 2nd factor 11

The RA invites a user to get and register a 2nd factor. 12

User self registration 13

The user needs to have the LoA 2 or 3 authentication credential (token) that is going to be registered. The user goes to the SURFsure website. 14

The user is asked to authenticate. Since SURFsure is part of SURFconext, the user can use his institutional username and password combination for this purpose. 15

After successful authentication, the user is presented a number of LoA 2 and 3 authentication solutions. Possible solutions are e.g. tiqr, SMS-OTP, and Yubikey. 16

The user selects one of the solutions. 17

SURFsure initiates an authentication session with the selected solution. E.g. in case of SMS- OTP the user is asked to enter his mobile phone number and OTP challenge that is sent to him via SMS. Note that each solution may have its own authentication procedure. For instance, the selection of tiqr may involve downloading and installation operations prior to continuing with the SURFsure registration. 18

After successful authentication with the selected solution an e- mail containing an activation link is sent to the user. 19

The user is asked to click on the link to confirm and prove that he/she is the owner of the token. This step proves that the user has access to the e-mail address that has been provided by the IdP and forms an additional validation of the user s identity. Moreover, the user can detect it if someone else attempts to request a token in his or her name. 20

After activation, SURFsure shows the user a registration form that contains personal information obtained from the IdP and possible authentication solution specific information such as a telephone number. The form also contains a unique registration code. The registration code should have enough entropy to prevent a guessing attack (an attacker should not be obtain the valid code via trial-and-error by generating codes), yet short enough to be written down by the user. The form is sent to the user s e-mail address. It is also possible to print the form if the user has access to a nearby printer. Additionally, SURFsure submits a second factor registration request entry to the RA of the user s institution. the user is asked to go to the RA of the institution to complete the registration process. 21

At the registration desk 22

To complete the registration the user, in possession of the registration code and the second factor and an identity document (e.g. passport, drivers license), visits the RA. The RA Logs in to the SURFsure web interface. Using two factor authentication. Note that the RA has to log in with a LoA that is equal to or higher than the LoA of the authentication solution selected by the user. Otherwise the RA cannot execute the registration. 23

The RA authenticates with the first factor. 24

The RA authenticates with the 2nd Factor. 25

The RA selects the user to register from the list. 26

At the RA desk, the user gives the registration form or shows the e-mail to the RA. The RA logs in to SURFsure and enters the registration code. 27

In registering the user, the RA must verify the IdP-provided information against other trusted sources. SURFsure shows the registration request including some personal information of the applicant obtained from the IdP (i.e. the user s first and last name and e-mail address). The registrar verifies this information against the information in the valid photo-id, i.e. he inspects the photo-id (is it valid), checks if the photo matches the applicant and if the first and last name on the ID corresponds to those provided by SURFsure14. Note that the RA is, in principle, able to perform additional checks based on other local trusted identity sources during registration. E.g. local HR sources could be used for validation of day of birth or social security number. This is not part of the requirements for SURFsure, however. 28

RA Vets identity document provided by the user 29

The user shows he or she controls the second factor by performing an authentication using the RA s workstation. The RA oversees the authentication attempt and can tell whether it was successful. 30

Having successfully identified the user, the RA confirms the registration and binds the second factor authentication solution to the user s federated account credentials; if this is not the case the registration is rejected. The user can now use step-up or strong authentication to access services. 31

De-registration 32

33

34

35

36

pieter.vandermeulen@surfnet.nl http://nl.linkedin.com/in/pmeulen/ Questions? Remarks?

Delegation of RA Step-upauthentication as a Service Account advisor (AA) AA AA Institution Contact Person (ICP) ICP ICP ICP ICP ICP Registration Authority Administrator (RAA) RAA RA Registration Authority (RA) RA RA RA RA 38 Registration of users is performed by RAs and RAAs using the SuaaS webinterface. The delegation of authorization to RAs is handled through the existing SURFnet structure whereby the ICP authorize persons in their institution to perform tasks. For SuaaS two roles are used: 1) RAA: Can designate other RAs and can perform the tasks of a RA 2) RA: Can vet users using the SuaaS web interface.