# Presentation: 455418

## Certificate Briefing

- March 9, 2006

## Agenda

- Background, Motivation, Proposed Strategy
- Mark Leininger
- Tasks and Workload
- Jack Schmidt

## Objective

- Division guidelines which enumerate a range of mechanisms for applications to authorize user activities

## Background

- Kerberos has provided good central supported service for telnet, ftp, etc
- Unfortunately many applications are unlikely to be Kerberized
- Multiplicity of passwords not solved by Kerberos, still need some single sign on mechanism for applications
- We need to choose a mechanism to establish identity for other apps

## Definitions (sorry)

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

## Objective

- Division guidelines which enumerate a range of mechanisms for applications to authorize user activities
*Not* the objective of this briefing
- email signing and encryption

## 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, eg:
- 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? 

- Certificate usability work to be done
- Jack Schmidt

## Issues

- Users find current utilities/tools klunky
- Browsers react differently to certificate usage
- Securing web applications knowledge
- Offsite access: Home Use/Kiosk/Universities
- Which Certificate?
- Commercial vs. DOE Grid vs. Local: should users just click “okay?”

**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. Use CD resources?

## Long Range Goals

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

## Questions?