InCommon Technical Advisory Committee Update

November 14, 2013

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.

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

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

Current TAC Subgroups

• Social Identity Working Group

• Interfederation – Phase 2

• Metadata Distribution

• PKI Subcommittee

Agenda

Multi-Factor & Assurance Tom Barton

Assurance Program update Ann West

InCommon Multi-Factor services Joe St Sauver

Shibboleth Multi-Factor support David Walker

InterFederation Update Paul Caskey

Participant discussion Keith Hazelton

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

9

Components of assurance

Risk Assurance 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”, 2nd

password)• Multi-factor (PIN + token)• Additional factors (biometric, geolocation, ...)

Eff

ort

to

mit

iga

te

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.org

InCommon MultiFactor Programhttp://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.

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

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

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

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)

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

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.

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

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

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

More Information

• Assurance Enhancements for the Shibboleth Identity Provider– https://spaces.internet2.edu/download/attachments/37650957/A

ssuranceReqShibIdP-19Apr2013.pdf

• Project Status– Currently doing acceptance testing and correcting bugs

– https://spaces.internet2.edu/x/LgFtAg

Interfederation Working Group

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

Deliverables from Phase 1

• Use Cases– spaces.internet2.edu/x/EQAwAg

• Plans for InCommon and UK Interfederation– spaces.internet2.edu/x/tIA_Ag

• Lessons Learned– spaces.internet2.edu/x/QwBOAg

• Report to Technical Advisory Committee (TAC)– spaces.internet2.edu/x/Dw9OAg

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.

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.

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/incinterfed

Contacts

• Warren Anderson, Chair– warren.anderson@ligo.org

• Paul Caskey, TAC Liaison– pcaskey@utsystem.edu

Participant Discussion

Keith Hazelton

UW-Madison

Strategic Priorities, 2013• Assurance

• Metadata Administration

• Supporting NET+

• Interfederation

• Metadata Distribution

• Federated User Experience

• Mobile/Federated Non-browser Applications

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

Setting TAC Priorities for 2014

• Current pain or pressure points?

• Unfinished journeys that must be continued?

• Looming trends calling for effective shared responses?

Thank You!