Strong Authentication Plan

WhyWhatWhen

How it affects You

Why We need to protect our computers

from Internet turmoil DOE expects us to exercise due

diligence to prevent unauthorized use of lab computers

DOE expects us to keep track of who is using lab computers

In both cases we are much better off making our own policies than awaiting more restrictive policies to be prescribed

Why Of 11 FIREs during the year May,

1998 to April, 1999, 6 arose from null, weak or stolen

passwords• (OS default accounts, off-site sniffers, bad

cgi) 4 others spread through .rhosts,

sniffers or cracked password files.

We can no longer allow network disclosure of useful passwords

Goals Prevent disclosure of login passwords.Prevent disclosure of login passwords.

Without asking superhuman diligence. This does not apply to non login passwords (eg

email) Positive centralized control over

access. Secondary -

Provide a single-signon environment. Simplify account management, especially

terminations - take this burden off the system administrators.

Integrate AFS accounts & systems. Enforce password policies.

What Separate authentication (who you

are - centralized) from authorization (what you are allowed to do – local)

Lab computers that are accessible from the outside internet will not allow password based remote logins, commands or file transfer

Usage is only granted after central authentication, using unforgeable tickets or single-use passwords

Design Criteria Allow the work to get done. Requiring some change in habits is

acceptable. Radical changes would hinder successful deployment.

Users without special software or hardware on their systems must be provided some way to authenticate.

Must be adaptable to changes in System security requirements Computing styles

System Design Kerberos On-site systems must be configured

so that network logins do not prompt for or accept a password. Access requires: Kerberos credentials (obtained from

local system), or Challenge-response one-time

authenticator (CryptoCard) For off-site systems, we compromise:

Other secure (e.g., encrypted) access allowed to those systems.

Centralized Authentication Authentication (identification of who you

are) is done by the centralized Kerberos Key Distribution Centers (KDCs)

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)

Once logged on, your Kerberos ticket grants you further access to lab systems

Local Authorization Local sys admins create accounts on

their own systems Usage is granted to holders of

particular Kerberos tickets rather than through password challenge/response

Accounts with same user name automatically give access to that Kerberos user (default can be changed)

Accounts can be shared amongst multiple Kerberos users without sharing passwords (with accountability)

Infrastructure KDCs run just the essential

services. TGS, kadmin, 2 flavors of password

changing, “524”, kprop, NTP and secure encrypted login.

KDCs physically secured, but those in less-secured areas don’t store master database key on disk.

Account deactivation to be placed under control of CNAS.

When All* lab computers will be “Kerberized”

before Dec 31, 2001 Small number of well justified written

temporary exemptions CDF and D0 are already done Many central Computing Division servers

will be done over the summer Your division/section has its own

timetable and local Kerberos coordinator

* ”All” means computers that run general services (telnet, ftp, rsh, …) that are visible on the general internet

What This Means To You (1) Does not affect email or web

access Need not affect any outbound

connections 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) You will need to get a Kerberos

account (principal) (and almost certainly a Cryptocard)

You will need to install some software on your desktop depending on how you use it

System administrators will have additional software to install, but account management will be much easier

Desktop Considerations If desktop is dumb terminal: use Cryptocard to logon

to other lab systems

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

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

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, …) Choice of using Cryptocard or

installing local Kerberos system, depending on convenience

Deployment Status 2090 users

1637 with Cryptocards 1609 service hosts

57 off-site 468,000 TGT’s issued in August

One service principal was granted 183615 tickets

Kerberized applications include CVS FBS (batch job submission) SSH (with Cryptocard access)

Golden Rule: Treat your Kerberos password as a sacred object Do not share with anyone else

(much better mechanisms exist for shared accounts)

Do not use same password for any other applications (other passwords are not secure)

Always know who you are talking to when you type your password; do not expose it over the network

Strong Authentication Misunderstandings “ssh is forbidden”

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”

Kerberos addresses at most half of the security problem: the problem of reliably identifying who is trying to access a system.

Kerberos does nothing explicitly to address the problem of application(OS) exploits.

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: Guide to Strong Authentication at

Fermilab user guide, available in printed version or on the web: http://www.fnal.gov/docs/strongauth

Complications discussed there (unattended job submission, Windows and Mac issues, etc)

Questions to kerberos-users@fnal.gov