# Presentation: 455419

## Project Status: Computer Security

- June 26, 2006

## Agenda

- Background, Technical
- Going Forward

## 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

## 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

## 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

## 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

## 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)

## 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

## 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

## 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

## Inbound passwords in clear text

## 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

## 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)

## Requirements

- Must support systems with OS baseline
- CA is a restricted central service

## Authorization Mechanisms

- Group account
- Individual accounts over SSL
- DOE Grid Certs
- KCA Certs

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

## 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)

## 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

## 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

## 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

**Notes:**
People have trouble with running  get-cert program.
Some browsers try to pick which certificate to use, others don’t let the user know that their certificate expired.
Many programmers/users of an application have no idea how to modify the web application to use certificates
Concern from users on hiow to access information from offsite.
Commercial certificates are in browsers so users don’t get prompted but DOE Certs aren’t. Users get use to just clicking okay without being concerned. Or they refuse to click okay because they don’t know what the cert is!

## 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

## 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

## 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

**Notes:**
User must log off/on within seven days

## 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

**Notes:**
1) We think that the PAM module work done for SLF can be used to write the Macintosh module.

## 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

## 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

## 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!

## 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)

## 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](http://www.secure-endpoints.com/)_
- Signed server certificate work can be done in-house
- Develop/Teach securing application class based on CD experiences using contractor.

## Long Range Goals

- Move to single sign-on
- Elimination of username/password combinations
- Deployment of X.509 certificate support

## Questions?