Authentication,Authorization,

AccountingBreakout Session

Von Welch, NCSA

NSF CyberSecurity Summit

Feb 22, 2007

Summary from Authentication (one A) session last year

http://www.educause.edu/LibraryDetailPage/666?ID=CYB0525

• One Time Passwords rollout– Or lack there of

• Authentication is an arms race• Shell access vs provisioned services • Desire for a Federated Authentication

System• Authentication vs Attributes

OTP Rollout Barriers from Last Year

• OTP deployment brings high costs in terms of dollars both for initial roll-out and ongoing support.

• High costs in terms of usability– Particularly if all sites rolled it out without

coordination and each user had to have a token per site. • Session hijacking

– Sites are concerned that they would roll out hundreds of thousands of dollars of infrastructure only to have hackers change their tactics without reducing the number of compromises.

• OTP cannot be easily deployed ubiquitously across all applications (login, email, web, etc.).– So users would still need to have a normal password in

addition the • HSPD-12 emerged, causing uncertainty at DOE sites

about their future authentication requirements. • Federated ID is coming - want to avoid two rollouts

Authentication as an Arms Race

• What is the acceptable level of incidents?– E.g. Banks accept some level of fraud– As long as its not a pain to management?

• SSH rollout is a good example of a technology rollout– Clear threat– Deployed at a system-by-system level

Shell access vs provisioned services

• We give users full shell access

• Mitigate risk by levels of access– E.g. not every user has to be able to

compile codes

Desire for a Federated Authentication System

• A way to solve the usability issues with strong authentication alternatives.

• Combine with rollout of strong authentication.• Several possible mechanisms for federated

authentication were discussed: RADIUS, Shibboleth and Online CAs (e.g. the Fermilab KCA deployment), Kerberos

• Chicken and Egg problem• Privacy an issue?

– Are users concerned? Should they be?

Authentication vs Attributes

• Is authentication enough or do we need attributes?– (And from whom?)

• What are the attributes of the identifier we are authenticating?– Is the identifier good for all time or just a point in time?

– (What can you use it for?)

Future Work• Hardware token usability• What can we do to be less concerned about hackers? Several options were

• mentioned. • Having systems based on virtual machines to create “disposable” servers that could be easily discard to be compromised.

• Using provisioned services, or chroot() environments to allow for the matching of service capabilities to the strength of authentication.

• Creative second factors in place of hardware tokens• Preventing session hijacking• Validation of remote systems

Future work (cont)• How we determine the level of sensitivity of a

particular request so that we can determine the strength of authentication that should accompany it.

• What packets belong to what users? (CALEA)• Level of coordination is required for our upgrading

of authentication?– SSH allowed for very independent authentication,

• Namespace management, name federation, and identity management were discussed as areas needing work to manage the binding of different user names together in a federated environment.

Recent news…• "PayPal Security Key”

– http://tinyurl.com/yg9q5r– $5/year for personal PayPal accounts– Number of other banks have adopted over the past few

years - ETrade,USBank…

• AOL supports OpenID for 63 million users– http://dev.aol.com/aol-and-63-million-openids

– (AOL’s $1.95/month OTP service gone?)• Shibboleth access to Fastlane

– http://tinyurl.com/2flztj

• TeraGrid Federated Id Testbed– http://gridshib.globus.org/tg-paper.html

Discussion begins here

• Google Apps has SAML2 SP interface

• Accounting -> Auditing– Keeping track of what is going on– Centralized services help with this

AAA Breakout Results

Threats

• Vandalism/Petty - e.g. Web Sites• Vandalism/Serious - e.g. Data• Stealing information• Stealing computing cycles• Stealing storage/distribution - e.g. warez• Launching attacks on other sites

– “Enclaves” - e.g. TeraGrid

• Embarrassment

Authentication Changes from CSS’06

• No big changes in last year• User end systems still untrustworthy• No major moves to/from OTP

– Session hijacking and cost still concern with OTP– Won’t be able to leverage bank space

• Federated identity continuing progress in various forms

• Authentication of non-human entities still an issue– May be growing with large sensor deployments– Integration of federated and non-human a challenge

• HSPD-12 backing off

Operational Issues

• Revocation labor intensive– Not tied into registration authority databases

• Better model needed for revocation. CRLS are:– not time sensitive– distribution is an issue– Must have authorization “blacklist” anyways

• e.g. user doesn’t abide by VO AUP

– OCSP doesn’t solve this

• Provisioning of trust roots a growing issue

User Education

• Catching user education and policies up with technology

• E.g. Password Safe, Firefox plugins that manage unique (random) passwords for multiple sites

• USB token implementations available• These are non-traditional use of

passwords - require different policies

Session hijacking

• Only defense is to get rid of sessions?– Unless OS/Sys Admins save the day

• Re-authenticate important transactions– Works well for banking model– Can we take this to general purpose computing?– Batch computing might fit this model

• Unicore model

• Detection of session hijacking– Detection of unusual behavior

OTP Issues• Issues still cost, usability (esp. multiple sites), session hijacking• Will users just share them?

– Do we care? Is this a threat we’re concerned about?

• SMS messages over cell phone– RSA, SecureComputing, EU Banks– Charge per text message– Almost ubiquitous

• Some Banks moving to OTP tokens, won’t allow outside use– Will Paypal’s $5 OTP succeed?– Will banks allow use for anything else?

• Many more banks have moved to non-OTP two-factor• Need a way to allow users to have a single token for use at

multiple sites– federated identity approach– Cell phone

Federated Identity

• Progressing• Policies and requirements for LOA, Incident

Response, Liability, Privacy, “Citizenship” requirements

• Campus requirements for meeting LoAs understood

• P2P vs Federated Id?– OpenId vs SAML; Analogous to PGP vs PKI.

Authentication of non-human devices

• Secret storage for automated services• Particular issue for dynamic services - e.g.

services, sensors– Renewal

• Attribute schemas also an issue• SRP/TLS-PSK protocols

– Good for bilateral authentications– Doesn’t require PKI– Patent issues (for some implementations)

• Long-running batch jobs that need creds– Education and deployment issue

Authorization

• Debugging Authorization failure in distributed systems difficult

• Match level of authorization to level of authentication– E.g. HP project - POLARIS - process/application based privileges– Lose credibility if we require difficult authentication for pedestrian

tasks– Low bar first factor, high bar second factor when required

• Getting access to required information about the user - e.g. citizenship– LoA for attributes

• Standard AUP for Grid/HPC access to cut down on lawyer overhead

Auditing/Accounting• Need to share across sites for IR forensics

– policy and technical issue– Standardization of log formats, semantics– instrumentation of distributed systems/VOs

• Federating accounts names at different sites• Detection of authentication

mis-use/impersonation• Is there a requirement for collecting

demographics for Grids/VOs?• Debugging of failures

Browsers as the UI for HPC

• Browsers becoming more important to HPC authentication– E.g. TeraGrid Science Gateway

• Policies, education need to take this into account

• Agreement on browser single sign-on interoperability

Models, Policies and Tools for Distributed Systems and VOs

• VO boundaries -what sites are in a VO?– What happens in the VO stays in the VO

• NIST policies for distributed sites?• Responsibility boundaries• Different models - OSG, TG, ORION, etc.• Has to connect network traversal (firewalls) to IdM• Need a path for developing community consensus

on policies– Don’t nail things down too soon– Local site autonomy vs TG,OSG vs NSF

Issues

• Are we authenticating the right things?– Sessions vs transactions

• Are we authenticating them strongly enough?

• How do we detect when authentication is spoofed?– And what fails.