Strong Authentication Project CD/DCD/Computer Security Team Fermi National Accelerator Laboratory Mark Kaletka Matt Crawford

Philosophy "Scientific thinking and invention flourish best where people are allowed to communicate as much as possible unhampered.” -- Enrico Fermi

Why Stronger Authentication? F Reduce effort spent on intrusions & recovery; F Regulatory climate is demanding increased attention to access controls; F Management has agreed with the goals outlined in SLCCC-TWG white paper: Alternatives to Reusable Passwords: Robust Authentication

Requirements F Acceptable improvement in access controls: –must be adaptable to: changes in system security requirements; new threats; changes in computing styles; network connectivity; security options; –must allow for trust relationships with other secure domains or realms; –allow for some form of access by trusted individuals outside of trusted domains;

Requirements F Acceptable to the user community. There will be some increased inconvenience, but... –A single identifier can authorize access to multiple systems; –Fewer account name & password combinations to remember, maybe only one! F Run II schedule: –Implementation may be staged but must offer meaningful improvement for Collider Run-II (i.e. mid-next year);

Project Goals F Primary - –Prevent network disclosure of passwords. F Secondary - –Provide a single-signon environment. –Integrate AFS accounts & systems. –Simplify account management, especially terminations - take this burden off the system administrators. –Enforce password policies.

Strong Authentication - System Design

Four Realms F Strengthened Realm –Kerberos authentication required for all network logins. F Untrusted Realm –Hosts, on- or off-site, from which direct logins to Strengthened realm are not permitted. F Trusted Realm –An outside Kerberos realm with which we cross-authenticate. F Portal –Gateway between Untrusted and Strengthened.

Kerberos F Kerberos version 5 is a protocol for authentication of users and services (collectively called principals.) –Created at MIT, circa –Designed for use over insecure networks. –Still under active development. –Several commercial products are built on it. –Many Universities and Labs use it. F AFS uses the Kerberos version 4 protocol. F DCE uses Kerberos 5.

Enforcing Password Security F To avoid exposing Kerberos passwords, non-Kerberos network logins must be replaced with Kerberos - initial tickets must be obtained locally! –Easily configured. –May be verified by network scan. –Anonymous FTP is still allowed. F Password policies (dictionary check, aging, quality) are enforced by the master KDC.

Portal F Provides authentication for users who lack Kerberos software or secure network channels, and obtains their initial tickets. –Hardware tokens (CryptoCard) –One-time passwords (S/Key)

Untrusted to untrusted Untrusted

Strengthened to untrusted Strengthened Untrusted Strengthened to untrusted

Strengthened to strengthened Strengthened Key Distribution Center

Untrusted to strengthened Untrusted Strengthened Key Distribution Center

Pilot Project F OSS Department Build Cluster & CDF Run II Analysis Prototype: –Interim user, developer documentation; –Interim libraries & API’s for required OS’s & languages; –Interim kerberos principals, hw tokens; –Standard MIT distribution for required OS’s + specific local applications; –32 systems

Fin...