Strong Authentication Plan Why What When How it affects You

Why F We need to protect our computers from Internet turmoil F DOE expects us to exercise due diligence to prevent unauthorized use of lab computers F DOE expects us to keep track of who is using lab computers F In both cases we are much better off making our own policies than awaiting more restrictive policies to be prescribed

Why F Of 11 FIREs during the year May, 1998 to April, 1999, u 6 arose from null, weak or stolen passwords (OS default accounts, off-site sniffers, bad cgi) u 4 others spread through.rhosts, sniffers or cracked password files. F We can no longer allow network disclosure of useful passwords

Goals F Prevent disclosure of login passwords. u Without asking superhuman diligence. u This does not apply to non login passwords (eg ) 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.

What F Separate authentication (who you are - centralized) from authorization (what you are allowed to do – local) F Lab computers that are accessible from the outside internet will not allow password based remote logins, commands or file transfer F Usage is only granted after central authentication, using unforgeable tickets or single-use passwords

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

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 (obtained from local system), or u Challenge-response one-time authenticator (CryptoCard) F For off-site systems, we compromise: u Other secure (e.g., encrypted) access allowed to those systems.

Centralized Authentication F Authentication (identification of who you are) is done by the centralized Kerberos Key Distribution Centers (KDCs) F You must either log on to Kerberos on your local [the one your fingers are touching] system (without exposing your password over the network), or log on remotely using a one time password (supplied by your CryptoCard) F Once logged on, your Kerberos ticket grants you further access to lab systems

Local Authorization F Local sys admins create accounts on their own systems F Usage is granted to holders of particular Kerberos tickets rather than through password challenge/response F Accounts with same user name automatically give access to that Kerberos user (default can be changed) F Accounts can be shared amongst multiple Kerberos users without sharing passwords (with accountability)

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 don’t store master database key on disk. F Account deactivation to be placed under control of CNAS.

When F All* lab computers will be “Kerberized” before Dec 31, 2001 F Small number of well justified written temporary exemptions F CDF and D0 are already done F Many central Computing Division servers will be done over the summer F Your division/section has its own timetable and local Kerberos coordinator F * ”All” means computers that run general services (telnet, ftp, rsh, …) that are visible on the general internet

What This Means To You (1) F Does not affect or web access F Need not affect any outbound connections F Does not prevent attaching visiting laptops to network (as long as they cannot be logged in to over the network)

What This Means To You (2) F You will need to get a Kerberos account (principal) (and almost certainly a Cryptocard) F You will need to install some software on your desktop depending on how you use it F System administrators will have additional software to install, but account management will be much easier

Desktop Considerations F If desktop is dumb terminal: use Cryptocard to logon to other lab systems F If desktop has minimal intelligence (PC) but does not accept remote logins: install local kerberos telnet and ftp clients, do local kerberos login, then proceed normally using kerberized versions of clients F If desktop can be logged into remotely: install full local kerberos system, replace network services with kerberized versions

Windows Users (who don’t use UNIX resources) F W2000 users will get a Kerberos principal when they join the W2K domain (a brief visit will be made to your desktop); Kerberos is transparent F Legacy W95/98/NT systems can access W2K resources using NTLMv2 authentication (this is not Kerberos and is temporary)

When away from your desktop (travel, home, …) F Choice of using Cryptocard or installing local Kerberos system, depending on convenience

Deployment Status F 2090 users u 1637 with Cryptocards F 1609 service hosts u 57 off-site F 468,000 TGT’s issued in August u One service principal was granted tickets F Kerberized applications include u CVS u FBS (batch job submission) u SSH (with Cryptocard access)

Golden Rule: Treat your Kerberos password as a sacred object F Do not share with anyone else (much better mechanisms exist for shared accounts) F Do not use same password for any other applications (other passwords are not secure) F Always know who you are talking to when you type your password; do not expose it over the network

Strong Authentication Misunderstandings F “ssh is forbidden” u SSH as a connection method is ENCOURAGED and is in no way forbidden. The statement is that ssh encryption methods are not sufficient to protect passwords in actual use and so even with ssh, Kerberos tickets or CryptoCard challenge/response are the only accepted methods of authentication.

“Kerberos will solve all our security problems and prevent most future incidents” u Kerberos addresses at most half of the security problem: the problem of reliably identifying who is trying to access a system. u Kerberos does nothing explicitly to address the problem of application(OS) exploits. u Kerberos DOES help to reduce the damage from a compromised system.

“Kerberos means there will be no stolen passwords”  It is still possible for people to expose their Kerberos password. The most obvious example of which is writing it down on a sticky note on the terminal.  The lab relies on its computer users to show good common sense and abide by good computing practices. So far, this has been a good bet and allowed us to leave open certain types of usage that have risks associated with them.  The quest for perfection is difficult, expensive and should be avoided. We’re trying for very good.

“Using my CryptoCard makes sure my session is protected”  In fact, it is usually exactly the opposite!  The CryptoCard says nothing about the security of the connection. It was implemented primarily to address the cases of needed to connect to the lab when a secure connection was NOT possible to achieve.  Unless you explicitly know what you are doing, you should assume that everything typed in a CryptoCard authenticated session is available on the wire.

“All this worry is about potential problems that just don’t happen at FNAL”  We regularly (approx monthly) find that “wiretaps” (aka sniffers) are being run watching communications with FNAL.  Cleanup after these incidents has several times meant revalidating hundreds of users.  We have to take reasonable precautions against potential problems.

For more details: F Guide to Strong Authentication at Fermilab user guide, available in printed version or on the web: F Complications discussed there (unattended job submission, Windows and Mac issues, etc) F Questions to