1 / 27

Authentication, Authorization, Accounting Breakout Session

This session summary discusses the ongoing arms race in authentication, the challenges of OTP rollout, the need for a federated authentication system, and the importance of considering attributes in authentication. It also explores future work in hardware token usability, prevention of session hijacking, and coordination in upgrading authentication.

soltis
Download Presentation

Authentication, Authorization, Accounting Breakout Session

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Authentication,Authorization,AccountingBreakout Session Von Welch, NCSA NSF CyberSecurity Summit Feb 22, 2007

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

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

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

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

  6. 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?

  7. 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?)

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

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

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

  11. Discussion begins here • Google Apps has SAML2 SP interface • Accounting -> Auditing • Keeping track of what is going on • Centralized services help with this

  12. AAA Breakout Results

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related