1. InCommon Technical Advisory Committee Update November 14, 2013

2. What is the InCommon Technical Advisory Committee ? The InCommon TAC will work with Steering to support the InCommon Participant community's use of shared identity and access management technology, services, recommended practices and strategies. The InCommon TAC will advise the SC regarding policy implications of technical changes and the technical implications of proposed policy changes. The TAC may suggest policy changes to support new uses or configurations of the underlying technology or its applications. The TAC shall seek further review of its recommendations within the broader community of users, both within InCommon and among the larger, shared access management community, as appropriate. The TAC will function as defined for Advisory Committees in the InCommon LLC ByLaws.InCommon LLC ByLaws

3. TAC Members Steven Carmody, Brown University (Chair) Tom Barton, University of Chicago Jim Basney, University of Illinois Scott Cantor, The Ohio State University Paul Caskey, University of Texas System Michael Gettes, Carnegie Mellon University Keith Hazelton, University of Wisconsin - Madison Jim Jokl, University of Virginia Ken Klingenstein, InCommon Steering Committee Chris Misra, University of Massachusetts - Amherst (NEW) Nick Roy, Penn State University (NEW) David Walker, Independent Ian Young, U.K. Access Management Federation In Memoriam - R.L. "Bob" Morgan, University of Washington

4. TAC does much of its work through subgroups What’s a subgroup? A community group that forms to work on a technical priority. A subgroup has a charter and goals Who can participate? Anyone in the community with an interest in the topic and time to contribute

5. Current TAC Subgroups Social Identity Working Group Interfederation – Phase 2Interfederation Metadata Distribution PKI Subcommittee

6. Agenda Multi-Factor & AssuranceTom Barton Assurance Program updateAnn West InCommon Multi-Factor servicesJoe St Sauver Shibboleth Multi-Factor supportDavid Walker InterFederation UpdatePaul Caskey Participant discussionKeith Hazelton

7. Multi-Factor Authentication & Assurance Update Tom Barton, U Chicago Ann West, Internet2 Joe St Sauver, Internet2 David Walker, Contractor

8. Passwords are bad and will get worse. We know! Need to strengthen authentication process Reduce risk that authenticated user is someone else –Stolen or shared (eg, phishing) –Inappropriate reassignment (eg, yahoo) –Fraudulently obtained InCommon’s Identity Assurance Framework provides a step- wise and standards-based way to plan your mitigation of these risks 8

9. Components of assurance 9 RiskAssurance component that mitigates Fraudulently obtained Identity proofing + credential management Vetting process, Subject attributes, record keeping Inappropriate reassignment Credential management Token issuance & revocation, binding of Token to Subject, secure infrastructure, record keeping Stolen or shared Token technologies Password/passphrase Second factor (OTP, “phone factor”, 2 nd password) Multi-factor (PIN + token) Additional factors (biometric, geolocation,...) Effort to mitigate

10. Assurance update Multi-Context Broker Shibboleth extension –Silver/Bronze, 2FA, MFA, step-up authentication –Testing code Active Directory Cookbook for Silver v1.2 –Draft available for comment. No Alternative Means needed Further Assurance program work –Bronze Adoption, Federal Cloud Credential Exchange (FCCX) Alternative Means –Multi-Factor: SafeNet, Duo (underway) –Certificates: Comodo and InCert (Manage certs on user devices) InCert, especially for using certs with secure wireless More info: http://assurance.incommon.orghttp://assurance.incommon.org 10

11. InCommon MultiFactor Program http://www.incommon.org/multifactor http://www.incommon.org/multifactor The primary offering is currently Duo Security –SafeNet hard tokens –Vasco, InCommon affiliate –Toopher, starting Net+ onboarding process Duo is a mobile device-based multifactor solution Duo's available to InCommon participants in two models –Site license for all faculty/staff and students, ~$1/student/yr –Site license for all faculty/staff, ~$0.50/person/yr –Zero paperwork "ala carte" option for $5/user/year (for 500 users or more) –Sites with academic hospitals can also separately license Duo to also cover their hospital staffs.

12. Duo deployment Is incredibly easy! –User self-registers their mobile device –User login to application as they normally would –Click "approve" in response to a confirmation query sent to their mobile device. –Poor phone connectivity? Duo also supports a soft token running on smart phones, "enter the six digits" style. –Options for users with traditional phones and traditional hard tokens (extra fees apply). –Duo integrates well with all the usual applications, including service- by-service deployments for things like ssh, VPNs, and web applications, but there's also been substantial interest in integrating Duo with Shibboleth IdPs, so integrating multifactor support on one IdP can improve the security of multiple SPs

13. Shibboleth Multi-Context Broker (MCB) Project to enhance Shibboleth’s ability to orchestrate among multiple authentication contexts, including those requiring multi-factor authentication Initiated to address needs identified by CILogon, the National Institutions of Health, the Department of Education, and others

14. What Are We Trying to Accomplish? Authentication method (including multi-factor) based on SP requests Authentication method based on user certifications and restrictions Assurance profiles based on SP and user Assurance profile hierarchies Prioritized requests for multiple authentication contexts

15. Authentication Context An Authentication Method plus any other relevant criteria for an assertion Configuration –Authentication Method –Other Contexts satisfied by this Context –Well-known name –(“Other relevant criteria” represented in user records)

16. Example: AuthN Method by SP Two Authentication Contexts –PasswordContext with username/password authN method –MFAContext with multi-factor authN method SPs requiring PKI request MFAContext. SPs requiring username/password request PasswordContext Users are presented with the authentication method that matches the requested Context

17. User Certifications and Restrictions “Other relevant criteria” IdMS has multi-valued attribute holding list of Contexts that user can authenticate to. Contexts that can be asserted for a user are the listed Contexts, plus any satisfied by those listed.

18. Example: AuthN Method by User Two Authentication Contexts –PasswordContext with username/password authN method –MFAContext with multi-factor authN method MFAContext satisfies PasswordContext Most users given PasswordContext Users allowed to use PKI given MFAContext and PasswordContext –They may be presented with a choice of authentication methods Users required to use PKI (perhaps by their choice) are given only MFAContext

19. Example: InCommon Bronze and Silver 1 Two Authentication Contexts –BronzeContext with username/password authN method –SilverContext with username/password authN method SilverContext satisfies BronzeContext Users are certified for BronzeContext and/or SilverContext, based on identity proofing, registration, etc. This is stored in the IdMS. Users authenticate once per session

20. Example: InCommon Bronze and Silver 2 Two Authentication Contexts –BronzeContext with username/password authN method –SilverContext with multi-factor authN method SilverContext satisfies BronzeContext Users are certified for BronzeContext and/or SilverContext, based on identity proofing, registration, etc. These are stored in the IdMS. Users who have authenticated for BronzeContext will need to reauthenticate (with multi-factor) for SilverContext, but not the converse

21. More Information Assurance Enhancements for the Shibboleth Identity Provider –https://spaces.internet2.edu/download/attachments/37650957/As suranceReqShibIdP-19Apr2013.pdfhttps://spaces.internet2.edu/download/attachments/37650957/As suranceReqShibIdP-19Apr2013.pdf Project Status –Currently doing acceptance testing and correcting bugs –https://spaces.internet2.edu/x/LgFtAghttps://spaces.internet2.edu/x/LgFtAg

22. Interfederation Working Group

23. About the group Began in early 2013 Intent was to explore the area of linking federations –Technical aspects –Trust/policy issues One primary driver was LIGO users in the UK Federation Wiki: spaces.internet2.edu/display/incinterfed/Interfed+Subcommittee Mailing List: lists.incommon.org/sympa/info/interfed

24. Deliverables from Phase 1 Use Cases –spaces.internet2.edu/x/EQAwAgspaces.internet2.edu/x/EQAwAg Plans for InCommon and UK Interfederation –spaces.internet2.edu/x/tIA_Agspaces.internet2.edu/x/tIA_Ag Lessons Learned –spaces.internet2.edu/x/QwBOAgspaces.internet2.edu/x/QwBOAg Report to Technical Advisory Committee (TAC) –spaces.internet2.edu/x/Dw9OAgspaces.internet2.edu/x/Dw9OAg

25. Phase 2 Picks up where Phase 1 left off. Duration: October 2013 – March 2013 New Leadership (Phase 1 : Jim Basney): –Warren Anderson (LIGO, new to subcommittee) –Paul Caskey (UT System, Liaison to TAC) Charter drawn from recommendations document of Phase 1. Currently ~10 participants.

26. Charter for Phase 2 Establish international interfederation agreements with eduGAIN and UK federation. Review documented trust practices and policies for entity registration and publishing. Review and adopt the US-EU Code of Conduct concerning attribute release and privacy. Review and assist in the implementation of metadata management/publication/aggregation/tagging improvements. Establish practices and policies for domestic interfederation for regional, K-12, etc federations.

27. Next steps? Begin work on Phase 2 And… We need You!! (everyone is welcome) First telecon soon! (~10/23) Subscribe to the mailing list: –interfed@incommon.org All project information is linked here: –spaces.internet2.edu/display/incinterfedspaces.internet2.edu/display/incinterfed

28. Contacts Warren Anderson, Chair –warren.anderson@ligo.orgwarren.anderson@ligo.org Paul Caskey, TAC Liaison –pcaskey@utsystem.edupcaskey@utsystem.edu

29. Participant Discussion Keith Hazelton UW-Madison

30. Strategic Priorities, 2013 Assurance Metadata Administration Supporting NET+ Interfederation Metadata Distribution Federated User Experience  Mobile/Federated Non-browser Applications 

31. Some drivers for 2014 and beyond (Are they yours?) Enhanced support for research mission New models for teaching and learning Accelerating adoption of cloud-based services Serving an expanding set of user populations Next generation ERP roll-outs Pressure to consolidate admin services to free up scarce resources

32. Setting TAC Priorities for 2014 Current pain or pressure points? Unfinished journeys that must be continued? Looming trends calling for effective shared responses?

33. Thank You!