1. Strong Authentication at FNAL Goals Design Status

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

3. Goals F Prevent disclosure of login passwords. u Without asking superhuman diligence. F Positive centralized control over access. F Secondary - u Provide a single-signon environment. u Simplify account management, especially terminations - take this burden off the system administrators. u Integrate AFS accounts & systems. u Enforce password policies.

4. Non-Goals F Perfection.

5. Design Criteria F Allow the work to get done. F Requiring some change in habits is acceptable. Radical changes would hinder successful deployment. F Users without special software or hardware on their systems must be provided some way to authenticate. F Must be adaptable to changes in u System security requirements u Computing styles

6. Status Quo F FNAL has a large number of independent NIS domains with only loose requirement for common ids. F FNAL has a number of independent NT domains with no id coordination F Most users have AFS account but most machines do not run AFS (and user community is hostile due to history)

7. System Design F Kerberos F On-site systems must be configured so that network logins do not prompt for or accept a password. Access requires: u Kerberos credentials, or u Challenge-response one-time authenticator. F For off-site systems, we compromise: u Other secure (e.g., encrypted) access allowed to those systems.

8. Infrastructure F KDCs run just the essential services. u TGS, kadmin, 2 flavors of password changing, “524”, kprop, NTP and secure encrypted login. F KDCs physically secured, but those in less-secured areas won’t store master database key on disk. F Account deactivation to be placed under control of CNAS.

9. Planning F Proposal and Discussion summer 1999 F Decision to proceed with Pilot Dec 1999 F Pilot Project Jan-Aug 2000 F Decision to proceed with deployment ~Sept 2000 F Run II deployment by Dec 2000 F FNAL-wide deployment by Dec 2001

10. Preliminaries F Several rounds of consultation with the user communities. (Plural.) F Test software on various platforms. F Select Kerberos s/w for Win32 access to Unix. u (Macintosh users prove self-sufficient.) F Enlist willing pioneers. F Develop user and administrative tools.

11. Breaking the Problem into bits F Unix centric deployment F Windows centric deployment F Other devices Server Client UnixWinOther Unix MITSamba ?? Win WRQWin2000? Other MIT/ OpenSource Samba ??

12. Challenge - Unattended Processes F Historical approaches have included: u Unauthenticated “.rhosts” access, u Passwords stored in files, u Passphraseless ssh keys F Our new approach: u Permit users to create extra Kerberos principals associated with their ID, a host and a purpose. u Stash keys in a file with best feasible protection. u Grant those principals the minimum necessary access for the purpose. F Added risk: u Minimum necessary exposure.

13. Challenge – Remote Access for the unKerberized F Cryptocard implements a known algorithm in a wallet-sized token. F Matching algorithm is now implemented in our KDCs. F Telnet and FTP servers now respond to unauthenticated connections with a Cryptocard challenge. F KDC delivers credentials encrypted in the service’s key, rather than the user’s. F Added risk: u Zero or negative!

14. Challenge – Windows2000 F Rely on Win2000 migration with Kerberos based authentication to achieve the bulk of the unified authentication goal (single domain/password) F Plan: Users authenticate against the MIT KDC, then obtain service tickets through standard cross-realm protocol. F Reality: It works. Should it be used ? See Mark K’s Talk. F Further challenge: How should/can non-W2000 systems access Win 2000 resources ? (NT4 ?, W9x ?, Mac ?, Unix ?)

15. Challenge – Responding to “lockouts” F A common concern is “what happens when I lose my CryptoCard” F It’s like a key. Take equivalent care. (Is there a “spare key” concern ?) F FedEx is the current replacement technique (2-3 business days) F Infrastructure can support S/Key or other OTP with “lighter” token. F Plan to provide S/Key interface and fax replacement list.

16. Modifications to the MIT KDC F Alternate authentication (CryptoCard, S/Key, …) to reusable passwords F Kcron method for unattended authentication. F ftp client enhancement to work with emacs efs mode. F Graceful fallbacks when connecting over default encrypted links to non Kerberos systems. F Most of these are included in current MIT 1.2.2 release. Very willing to take patches.

17. Deployment Status F 1309 users u 918 with Cryptocards F 923 service hosts u 17 off-site F Kerberized applications include u CVS u FBS (batch job submission) u SSH (with Cryptocard access)

18. Kerberos User Growth

19. Now the REST of the story F Remain approx 3000 users to go (~2/3 of the lab users) with a larger population of legacy users and applications. F Web, email, and most application authentication remain to be Kerberized. F Have to grapple with how to isolate “unkerberizeable” systems.

20. Deployment Plans – CD F 1 May u Production slave KDCs distributed. F May-June u Internal and restricted servers & desktops. F July u SDSS, Minos & remaining farms. F July-Nov u Customer education & preparation. F Aug – Sep – Oct – Nov u KTeV – PPD – FNALU – CAD, resp.

21. Deployment Plans - Windows F March-June u Continue testing, consultation with customers, resolving application licensing and certification. F June-August u Run pilot W2k domain with CD plus two other divisions/experiments F September u Production W2k domain, first division. F October-March u Migrate divisions @ ~400 users/month

22. Deployment Plans - Others F March – April u Take census and determine migration possibilities to Unix or W2k. F April – August u Develop solutions for remainder and/or take non-technical action. F September – December u Migrate, isolate, exempt or outsource.

23. Remaining Tasks beyond the Rollout F Web authentication F Email authentication F Application authentication u Enstore u Oracle u User code and tutorials

24. Finis