Project Status: Computer Security

1. Project Status: Computer Security June 26, 2006

2. Agenda • Background, Technical • Going Forward

3. Project Definition Lay groundwork (technical, philisophical, support, training) for adoption of PKI by developers and users. End result is a policy statement to enumerate a range of mechanisms for applications to authorize user activities, one of which is PKI

4. Project Scope Collaborative effort between CST and CSS to ensure technical support for policy Requires support for applications written by developers across the lab and at other institutions

5. Background • Kerberos has provided good central supported service for telnet, ftp, etc • Unfortunately many applications are unlikely to be Kerberized • Without Kerberos these applications have resulted in a multiplicity of passwords, still need some single-signon mechanism for applications • We need to choose a mechanism to establish identity for these other apps

6. Definitions • Public Key Encryption • Asymmetric encryption: public key and private key • PKI Public Key Infrastructure • A system of public key encryption using digital certificates from Certificate Authorities that verify and authenticate the validity of each party involved in an electronic transaction. • Digital Certificate • Includes your name, serial number, expiration dates, your public key, digital signature of the CA

7. Definitions • CA: Certificate Authority • verify the identity of entities and issue digital certificates attesting to that identity. • Registry • A lookup service to find other users public keys • X.509 is the international standard for Digital Certificates (not all conform)

8. Definitions • KCA: Kerberos Certificate Authority • Leverages Kerberos authentication infrastructure • Short-lived (current ticket lifetime up to 7 days) • Requires Fermi Kerberos principal • kx509 is a client program that talks to the KCA to obtain a short-lived X.509 certificate

9. Definitions • DOE Grid Certificate • Issued from DOE Grids (doegrids.org) • Long lived (1 year) • Initial credentialing and revocation is responsibility of VO • CRL Certificate Revocation List • Allows permanent or temporary disabling of a certificate’s serial number

10. Motivation to use Certificates • Single sign on for applications • Eliminate application passwords in clear • Attacks are moving more toward applications rather than OS • Central revocation of authorization • Allows centralized auditing of user accounts • Next slide indicates scope of problem with clear passwords

11. Inbound passwords in clear text

12. Requirements • Must provide support for two broad categories: • FNAL ID • Effort, Time, Labor reporting • Restricted Documents • Self service employee web pages • FNAL plus unregistered collaborators • Database for experiment • Web pages for experiment • Documents for experiment

13. Requirements • Access should match the level of protection required by the data: • No authorization necessary for some read only applications • Cert required for protected reads and all writes when used by collaborators • KCA provides increased confidence in identity (directly tied to kerberos principal)

14. Requirements • Must support systems with OS baseline • CA is a restricted central service

15. Authorization Mechanisms • Group account • Individual accounts over SSL • DOE Grid Certs • KCA Certs

16. Least Desirable • Group account • Weak identity verification • Read only, can’t publish information • Data that would otherwise be public to prevent spidering and indexing. • Because all required termination of accounts must be managed by CNAS: • Users who lose their affiliation must be assumed to continue reading • Password will be vulnerable: sniffing, from application server or phishing • It can be shared by people. • Individual accounts over SSL • Weak identity verification • Read or publish information • Because all required termination of accounts must be managed by CNAS: • Users who lose their affiliation must be assumed to continue reading or publishing data • Password will be vulnerable: from application server, phishing • Sensitivity of information requires greater protection than group password.

17. Recommendation • DOE Grid Certs • Strong identity verification • Read or publish information • User privileges can be revoked • No password vulnerability • Can support non FNAL useage • Organization based authorization • Long lifetime • KCA Certs • Strong identity verification • Read or publish information • User privileges can be revoked • No password vulnerability • Restricts useage to FNAL only • Requires frequent renewal (but application doesn’t need to check CRL)

18. Strategy • Move to single sign on by adopting certificates for all applications in CD • Establish policy: adopt lab wide use of certificates based on CD experience

19. Is FNAL Certifiable? • Project underway to improve tools in windows environment to get certificates into browsers • PKI training course • Developed in conjunction with lab’s professional development and training group • Specifications and contract written • Outside contractor hired to develop and teach course • Outline finished • Prototype course Aug 3 • “Tickler” August 22 at Computer Security Awareness Day • First production course October 2

20. Issues • Users find current utilities/tools klunky • CSI hired contractor to improve tools • Browsers react differently to certificate usage • Training class addresses specific issues • Offsite access: Home Use/Kiosk/Universities • Which Certificate? • Commercial vs. DOE Grid vs. Local

21. Utilities/Tools Worklist • Apache/IIS Server • Redirection site to instruct/help users with non-existing or invalid certificates in browser cache • Fixes to SSL code to allow redirection of connections with expired certificate • Service to allow any posted data to be saved so users don’t lose work

22. Utilities/Tools Worklist • Client- Windows • Configure desktops/laptops to trust DOEGrid etc. signed server certificates • Domain Users: • KX509 certificate transparently created during user logon • Screensaver refresh of certificate • Non-Domain Users: (fnal/offsite) • Windows ‘friendly’ Get-cert utility

23. Utilities/Tools Worklist • Client- SLF • Configure desktops/laptops to trust DOEGrid etc. signed server certificates • Kerberos Users: • PAM to get kx509 certificate into browser caches • Screensaver refresh of certificate • Non-Kerberos Users: (offsite) • Linux ‘friendly’ get-cert utility/get-cert RPM

24. Utilities/Tools Worklist • Client- Macintosh • Configure desktops/laptops to trust DOEGrid etc. signed server certificates • Kerberos Users: • PAM to get kx509 certificate into browser caches • Screensaver refresh of certificate • Non-Kerberos Users: (offsite) • Macintosh ‘friendly’ get-cert utility/get-cert rpm

25. Utilities/Tools Worklist • Client- Kiosk • Client depends on expected level of access • SSL protected applications already available • Must assume network and keyboard are sniffed • May be able to combine existing technology • Java Kerberos applet • Cryptocard/smartcard

26. Documentation Worklist • Design Note • Based on today’s feedback • Implementation Guides • Detailed How-Tos for Server and Client; Admin and User • Troubleshooting Guides/FAQs • Redirection/help website • Support • Email list with key people subscribed

27. Training Worklist • Training classes: • Server/Application. How to write web applications to use certificates • User Education. Using Certificates, understanding what happens when it doesn’t work!

28. Effort • Web Server Tools/Utilities • 1 FTE 6 months • Client Tools/Utilities • 1 FTE 3 months per OS client • 1 FTE 12 months for kiosk work • Documentation • 1 FTE 3 months • Training • 1 FTE .5 day per class (basic user – already working with consultant) • 1 FTE 3 day class (securing web applications)

29. Work Recommendations • Design Note • Define strategy and implementation in detail! • Review with stakeholders • Use consultant(s) with related experience for client work (OS) • www.secure-endpoints.com • Signed server certificate work can be done in-house • Develop/Teach securing application class based on CD experiences using contractor.

30. Long Range Goals • Move to single sign-on • Elimination of username/password combinations • Deployment of X.509 certificate support

31. Questions?