The Changing Landscape: External Drivers, Risks, and Rewards for Inter-boundary Authentication

1
The Changing LandscapeExternal Drivers, Risks,
and Rewards for Inter-boundary Authentication

• Jack Suess
• 2/8/06

2
Introduction

• UMBC - 12,000 students, R1 classification, more
  centralized than most research campuses. UMBC has
  been involved in I2 middleware initiative since
  2000.
• Myself - active in I2 early adopters since 2000.
  Co-Chair of Educause security task force since
  2003.

3
Todays Agenda

• External drivers for IdM
• Security drivers associated with IdM
• eAuthentication framework as a model
• Case study on how UMBC is approaching this
• Challenges and rewards going forward

4
Who Are Your Constituents

• Of course we have students, faculty, staff.
• We also have grad students that teach, research
  faculty that dont, contractors, alumni, parents,
  adjunct faculty, research collaborators,
  prospective students, non-credit students, and
  minors.

5
What Do Your Users Want?

• Ease of use is key
• Integration with campus portals
• Reduced number of accounts and password pairs,
  moving towards one.
• WebISO deployment to integrate campus portals
  with application authentication and enter their
  password just once as they seamlessly go between
  applications
• They dont want to change a password they finally
  remember!

6
What Are Your Services

• Internal services
• Account management - Portal, email, calendar,
  course management, ERP.
• Library access, 1-card, door access management,
  payment
• ERP self service for finance, hr, student
• External Services
• Bill payment, alumni, federal grants,
  inter-institutional courses, library services,
  etc.

7
Matching Constituents to Services?

• How do you manage who is eligible to access a
  service?
• Does every one who is eligible for services get
  the same level of service or have the same level
  of privilege.
• Does ever service represent the same level of
  risk to the institution?

8
Compliance Issues

• Regulatory compliance is pushing IdM.
• HIPPA is driving secure email, encryption of
  records, and audit trails
• SOX is driving authorization and role-based
  access.
• Data notification on NPI is causing encryption of
  documents.
• Calea?????

9
Integrating Security With IdM

• Start with a risk assessment
• Look at Educause security site,
  www.educause.edu/security
• For each service, think of the worst-case
  situation. What is the likelihood of this
  happening?
• For many services, authentication and
  authorization issues around passwords are
  critically important.

10
Text-based Password Security

• Increasing being seen as insecure due to the
  following
• Weak encryption of password files
• Availability of tools to perform automated
  dictionary attacks on passwords
• Rainbow tables with pre-defined hash tables
  available for purchase www.rainbowtables.net
• Passwords being sent in cleartext for some
  services over insecure networks.

11
Auditing - Password Requirements

• As text-based passwords become less secure we see
  auditors increasing the requirements for password
  security
• Longer minimum length
• Limit the time password is valid
• Limit reuse of prior passwords
• Require password complexity
• One they often dont look for!
• No cleartext transmission of passwords to other
  services - such as webmail, telnet, ftp, portal,
  blackboard, etc.

12
Current Situation

• We are continually increasing the number of
  web-based applications while users are demanding
  we lessen the passwords they have to remember.
• As we move to reduced sign-on we often find
  auditors require restrictive policies on
  passwords for some applications.
• The result is user frustration, increased demand
  for password resets, and often bad security
  practices as users write down their passwords to
  remember them.
• Finding a way out

13
eAuthentication

• Review eAuthentication documents,
• http//cio.gov/eAuthentication
• Identify assurance levels for your different
  applications and services.
• Use the authentication spreadsheet to review
  policy choices
• Look at two-factor or multi-level authentication
  systems for certain services
• Your CD contains an OMB memo on eAuthentication
  that lays out the process

14
eAuthentication Approach

• Much more than underlying technology.
• Policy and procedures are more important than the
  underlying authentication technology.
• Requires periodic outside review that policy and
  procedures are being followed.
• Starts with identity proofing using a picture ID
  of the people you give credentials.
• Requires some way of dealing with brute force
  guessing attacks.

15
Two Factor Authentication

• Level 3 authentication requires two factors for
  authentication. One factor can be a text password
  and the other must be a non-text password (pki,
  biometric, secure-id, other).
• Examine how your proposed WebISO supports
  two-factor
• Shibboleth 2.0 will support two-factor.
• Remember, Level 3 may only be needed by a small
  subset of the people to be effective.

16
Unsure how to Proceed ?

• Two factor often requires new technology that can
  require some integration work
• Implement what I call Level 2B - two text-based
  passwords. Establish a second text password with
  different password requirements from the first.
• It wont suffice for level 3 in a federated
  system but it might make allow you to focus
  stricter password requirements on a subset of the
  population till you can implement true two
  factor.

17
Federation Considerations

• Federations are trust relationships. I accept
  your assertion that an identity is who you claim
  it to be.
• Trust may be built upon shared beliefs, common
  policies, or legal contracts.
• InCommon is one such federation. Other
  federations may be more affinity based or related
  to shared services.
• Shibboleth is a tool for federations or multiple
  parties to come together.

18
UMBC Plans

• Present situation
• WebISO has been in place for 5 years.
• 2004 we piloted a two-factor component into our
  WebISO called passfaces.
• We have been lurking on eAuthentication calls
  with others but have not gone through a
  certification review.
• State auditors are now focusing on password
  policies such as 60-day lifetime.

19
UMBC Password Risk Assessment

• We identified these risks in order or concern.
• Cleartext password transmission with ftp and in
  some email connections.
• Helpdesk staff would enter new password for user
  on approved password change requests.
• No automated process to capture brute force
  attack and disable account.

20
UMBC Risks (cont)

1. We have not done a systematic password change for
   campus users in years.
2. Kerberos V4 has some potential exposure to
   offline attacks.
3. Certain staff with specific PeopleSoft access
   should be required to use two-factor.

21
Managing Risk Through Levels of Assurance

• Weve identified four levels of services, what we
  call level 0 through level 3
• We are mapping services to each level and looking
  at what we level of authentication we require.
• Goals - maintain ease of use for as many people
  as we can. Focus new security procedures on those
  that require it.

22
UMBC Level 0

• Level 0
• How text password
• Who
• Admitted students, alumni (via shibboleth),
  guests, people who had to have their password
  reset by helpdesk.
• What can they do
• Portal, email, Blackboard

23
UMBC Level 1

• Level 1
• How Identity proofed text password, lower
  password entropy
• Who
• Active students, staff and faculty without
  PeopleSoft approval access.
• What
• Level 0 VPN, student and staff self service in
  administrative system

24
UMBC Level 2

• Level 2
• How Identity proofed text password, higher
  password entropy (Yearly password change,
  password history of 2, password failures will
  drop level of assurance)
• Who
• Staff and faculty with PeopleSoft approval
  access.
• What
• Level 1 PS access.

25
UMBC Level 3

• Level 3
• How Level 2 two-factor
• Who
• IT staff, key HR and finance back office staff,
  ultimately all with PS approval access, campus
  security staff.
• What
• Level 2 Specific portal channels that require
  high levels of authentication.

26
UMBC Implementation Plan

• Eliminating cleartext password transmission by
  requiring encryption for all services requesting
  your password.
• Revamp password management procedures to track
  failures, change date, and history.
• Revamp our helpdesk password change process to
  use registered secondary email accounts.
• Require everyone to change their password.
• Select a second factor for authentication and
  deploy pilot service using two-factor.
• Eliminate remaining Kerberos 4 services

27
Identity Proofing

• Level 1 assurance requires identity verification.
  We issue admitted students an account without
  verifying a picture ID.
• We will grant new students a level 0 assurance.
  This will give them access to the portal and
  email but will limit many other services till we
  verify a picture ID
• We are revamping our ID card and access system to
  verify identity when they get their UMBC ID card.
• A similar process will occur with new faculty and
  staff

28
UMBC Federation Plans

• We will implement Shibboleth service and join
  InCommon this spring.
• Three potential external drivers for Shibboleth.
• Launching an external alumni portal and have
  contract language they must implement Shibboleth.
• USM is looking at a system-wide music service for
  campuses.
• Encouraging Sallie Mae to adopt Shib for eBilling.

29
Alumni Portal

• We will integrate the external alumni portal into
  our campus portal.
• The vendor looked at this and felt it was a very
  clean solution.
• The challenge that we are still working our is
  the trust relationship from the alumni portal
  back to campus. We are working with our alumni
  development group and academic services to
  determine if the level of identity proofing is
  sufficient to grant them an unofficial transcript.

30
USM Federations

• We are looking at this as a test case for a
  federation across the University System of
  Maryland campuses to validate eligibility to the
  music service.
• Long-term we want to support shared library
  services using shibboleth.

31
UMBC eAuthentication Plans

• The federal requirements are well thought out.
  Our State auditors are willing to consider using
  these requirements instead of their own.
• We are currently focusing on documenting our
  procedures and creating campus guidelines and
  polices to meet their requirements.
• We are waiting for a business reason to go
  through with certification.

32
UMBC Two-Factor Plans

• We estimate we would ultimately have 600 users
  needing two factor.
• Passfaces showed us the importance of user
  acceptance.
• Our hope is to use PKI tokens as a second factor.
  We are evaluating the alladdin USB tokens.
• We are at the very early stages of deciding how
  we want to do PKI and whether we will build our
  own CA service or buy into a commercial CA.
• Much of this is driven by other goals.

33
Plans for Parents and Affiliates

• Via Shibboleth from alumni portal, OR via myUMBC
• Students grant delegated access by specifying
  email address and checking access level boxes.
• Email is sent with link instructing them how to
  get access. Parents dont get account but will
  get portal access. Link count for parent is
  incremented
• LDAP attributes specify access. Parents get email
  whenever access rights change.
• We are looking at simple services right now,
  mostly view access and access to bill paying
• Parent loses access when link count goes to 0.

34
Role of Management

• Management support is critical. Unless you have
  an executive sponsor behind this the politics of
  change will undermine it.
• Recognize this project will impact many groups
  outside IT and build consensus early.
• Expect delays, policy development is time
  consuming on campuses.
• Build this in phases and celebrate each
  successful step along the way!

35
Resources

• Shibboleth - shibboleth.internet2.edu
• eAuthentication cio.gov/eAuthentication
• InCommon incommonfederation.org
• Security www.educause.edu/security
• Questions?
• Contact jack_at_umbc.edu