1. On the design of a MfAaaS service (Multi-factor-Authentication-as-a-Service)

2. Agenda Goal Entities and roles Why multi-factor? Architecture / standards Registration process Conclusions Next steps 2

3. Why multi-factor? zie tab beeld/kop- voettekst om dit te wijzigen3

4. Why multi-factor? zie tab beeld/kop- voettekst om dit te wijzigen4 Two reasons: 1.So that users can protect themselves… From their own stupidity and from their IdP’s stupidity (when they get hacked) 2.To allow access to high-trust services (which require more identity assurance) The latter reason is more interesting to us! Simply rolling out a second factor app is not enough…

5. Goal Design a service that Assists in introduction of multi-factor authentication Integrates well with federation (standards, arch) Allows a variety of multi-factor solutions Defines strict processes for registration Contains a portal for user self-registration Contains a portal for administration Facilitates logging SURFsure5

6. Entities and roles 6 Individual Identity Vetting Identity Record Credential Credentialing Registration Authority Identity Proofing & Identification

7. zie tab beeld/kop- voettekst om dit te wijzigen7 IdP 1IdP 2IdP 3IdP 4 Type of organization 60 staff. SME. Heavy use of cloud for HR and IT. 600 staff including visitors. Collection of smaller institutes. IT dept creates accounts. 2500 staff. Temporary teaching staff. 42K students. Accounts only created as result of HR process. 25K, students and staff. Accounts only created as result of HR process. IT infra type ADFS 2.0ADFS 2.0.Sun IdM Use cases None at this moment. Internal and external. VPN, privacy sensitive data. Internal: SIS.Internal: SIS, administrative systems. Who’s the RA? HRITHRNo RA needed Face-to- face? Not relevantMakes sense Doesn’t make sense 2nd factor needed? NoProbablyYes, already involved in pilot Yes, waiting for conclusion of this study

8. ARCHITECTURE Where to locate this new service architecturally? How to signal the acquired level-of-assurance? zie tab beeld/kop- voettekst om dit te wijzigen8

9. Location of service SURFsure9 IdPSP 1. Access SURFsure 2. Authn req incl. RequestedAuthnContext 3. Authn req LoA 1 4. Resp LoA 1 incl attributes 5. Send SMS, OTP, … 6. Resp “ok” 7. Authn resp incl. AuthnContext SURFconext

10. SAML’s AuthnContext SURFsure10

11. Options for signaling LoA info 1.OASIS AuthN context ~ 2005 2.OASIS AuthN context classes ~ 2005 3.OASIS AuthN context id assurance profile ~ 2010. Chose class id based on IANA LoA registry http://tools.ietf.org/html/draft-johansson-loa-registry- 06. http://tools.ietf.org/html/draft-johansson-loa-registry- 06 4.Yet another attribute, e.g. http://protectnetwork.org/pn/loa, with int value. http://protectnetwork.org/pn/loa (Sources for definition of LoA: OMB ~ 2003, NIST SP800-63 ~ 2006, STORK D2.3 ~ 2010, ISO/IEC 29115 (draft) ~ 2012) SURFsure11 eHerkenning 1.5 OpenID connect

12. Example: eHerkenning (NL b2g) eHerkenning niveau SAML2 AuthnContextClassRef element 1urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 2urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorUnregistrered 3urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract 4urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI SURFsure12 (Section 9.2.1 of the “Koppelvlakspecificatie DV-HM” v1.4)

13. REGISTRATION PROCESS How should users be given their second factor? What information should be gathered? Who should play the Registration Authority role? zie tab beeld/kop- voettekst om dit te wijzigen13

14. Registration & proofing requirements The registration and identity proofing process is designed, to a greater or lesser degree depending on the assurance level, to ensure that the RA knows the true identity of the applicant Requirements include measures to ensure that: A person with the applicant’s claimed attributes exists, and those attributes are authentic and sufficient to uniquely identify a single person The applicant whose token is registered is in fact the person who is entitled to the identity 14

15. Threats There are two general categories of threats to the registration process: Impersonation Compromise or malfeasance of the infrastructure (RAs). We focus on the first one Infrastructure threats are addressed by normal computer security controls (e.g., separation of duties, record keeping, independent audits, etc.) 15

16. Remote or in person registration In principle: Remote allowed for LoA 1 – 3 Typically involves the use of copies of valid photo ID, notary attestations, physical address, or verification against trusted sources for cross-referencing Exotic solutions: RBA, dynamic KBA or Skype All solutions can be characterised a complex and/or expensive No established best practices for remote registration So, remote registration is not an option for higher education Conclusion: We go for in person registration 16

17. Registration process User registration (self-registration): see mockups UR User management (RA interface): see mockups UM SURFsure17

18. Reissuance (lost / stolen / compromised) Applicant notifies RA that the token has been lost, stolen, or suffered compromise and is directed to the RA for reissuance (Or RA is informed of compromise via detection system) The token itself is revoked Any local databases must be updated to reflect the change in status The authentication token provider is informed 18

19. Logging Log all events Retain logs for 2 months Make sure only authorized people have access SURFsure19

20. MOCK-UPS Registration Authentication zie tab beeld/kop- voettekst om dit te wijzigen20

21. (In separate document) zie tab beeld/kop- voettekst om dit te wijzigen21

22. CONCLUSIONS Why multi-factor authentication? Architecture: location of service and LoA standards Registration: procedures zie tab beeld/kop- voettekst om dit te wijzigen22

23. Conclusions: why? There is a need for multi-factor authN Many parties are looking at multi-factor authN Some IdPs are already piloting Primary use case: Student Information System More use cases on horizon (SURFconext related) Not all use cases form solid business cases Cheap tokens: mobile app based OTP Make registration not as strict? Alternatives for f2f? SURFsure23

24. Conclusions: architecture Implement as transparent proxy near the SP bound border of the federation hub Use 2010 “OASIS AuthN context id assurance profile” Start with just 2 LoAs: LoA1, LoA2 Either standard levels or custom (but registered) SURFnet levels SURFsure24

25. Conclusions: registration Generate registration code (8 digits) during self-reg Check 1 st factor and 2 nd factor In person face-to-face registration Based on passport / government id card and SURFfederatie attributes Check 2 nd factor (Some IdPs see a use case for 2 nd factor without strict face-to-face procedures “the Google use case”, but out of scope) SURFsure25

26. Next steps Implementation Open source project UnitedID could be basis, other existing initiatives? Use our mock-ups, what is missing? –RA interface –Signaling LoA to SP Think about SP would be ideal launching customer of this service? Criteria for judging authN solution vendors SURFsure26