1. Strong Authentication Matt Crawford CD/DCD/Computer Security Team

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

3. Why Stronger Authentication? F Reduce effort spent on intrusions and recovery. F Regulatory climate is demanding increased attention to access controls. –Incidents which would have been utterly insignificant in past years now get national- level attention. F Our experience shows most incidents stem from a stolen password and are exacerbated by other weak forms of authentication.

4. Requirements F Significant improvement in access controls. –Must be adaptable to: Changes in system security requirements New threats Changes in computing styles Network connectivity Diverse security levels –Must allow for trust relationships with other secure domains or realms. –Allow for some form of access by trusted individuals outside of trusted domains.

5. 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 Run-II.

6. Project Goals F Primary - –Prevent disclosure of passwords… Without requiring superhuman diligence. F 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.

7. Estimated Payoff F If this project had already been in place, it would have had the following impact on the “FIRE” level incidents we had in FCIRT’s first two years. –Approximately 60% prevented outright. –Approximately 30% contained in scope. –Approximately 10% unaffected. F The total hours saved by the response team, the sysadmins and the users would have been quite significant.

8. Why not just ssh? F Ssh addresses encryption, but misses several other key issues: –Performance - why encrypt everything? –Account management –Password management –Password/certificate vulnerability –“Illusory security”

9. Illusory Security Remote Site (or local!) Desktop Server Supposedly Secure Realm clear encrypted

10. Strong Authentication - System Design

11. Four Classes of Systems F Strengthened Realm, on-site –Kerberos authentication required for all network logins. F Strengthened Realm, off-site –Any reasonably secure authentication required for all network logins. Runs Kerberos clients and possibly services. F Trusted Realm –An outside Kerberos realm with which we cross- authenticate. F Untrusted Realm –Hosts, on- or off-site, which do not authenticate to our Kerberos realm

12. Kerberos F Kerberos version 5 is a protocol for authentication of users and services (collectively called principals.) –Created at MIT, circa 1987. –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.

13. Enforcing Password Security F To avoid exposing Kerberos passwords, network logins must be made with Kerberos credentials - 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.

14. Portal Mode Authentication 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 style - coming) F Can be enabled on any system running the Fermi Kerberos product. F Serves “vanilla” clients without exposing any reusable authentication data.

15. Users’ View - with Kerberos F With a desktop in the strengthened realm and the login.krb5 program which obtains initial tickets, the users’ experience changes only slightly: –Auto-login available with telnet & ftp. –Tickets will expire if session is very long. Established connections will not be terminated. Tickets may be renewable, or new ones may be obtained when needed to establish new sessions. –User must know kpasswd, klist and kinit commands.

16. Users’ View - w/o Kerberos F Non-Kerberos logins to Strengthened realm hosts will be refused without asking for a password. –telnet  “Authentication failed.” or a prompt for portal-mode authentication. –rlogin, rsh  Connection refused. –ftp  “Access denied: authentication required.”

17. Sysadmins’ View F Must install Kerberized user applications and servers. F Must disable non-Kerberized versions. –Remove servers from inetd.conf, put clients later in $PATH or hide them. F Maintenance effort is roughly equivalent to maintaining any other locally-installed product, plus occasional updates of one new file /etc/krb5.conf. –S/W update frequency is low.

18. Sysadmins’ View (2) F No Kerberos tickets for local user “root”. F ksu can replace or supplement su, with added flexibility. –Selected principals can be given general root access, or be restricted to certain commands. –Possible savings in distribution and typing of root passwords, and quicker answers to “Who has root access to this host?”

19. Unattended Processes F For cron jobs and similar unattended processes, we have Kerberos authentication based on keytabs, which are encryption keys stored in files. F Guiding principles –Keytabs must be as well protected as possible, consistent with being accessible to the process. –Only the minimum necessary access must be granted by use of the keytab.  special kerberos principals

20. For Developers F Kerberos and GSS (Generic Security Services) libraries provide calls to create a Kerberos-authenticated session, with optional –Integrity protection –Privacy –Mutual Authentication F Bindings exist for C, Java, Python, Perl, and other languages.

21. Configuration Requirements F Systems performing authentication to our Kerberos realm are periodically scanned to ensure that cleartext access methods are closed. F Because some off-site systems are shared with non-FNAL users, ordinary SSH servers are allowed to be present. On-site, only Kerberized SSH will be allowed.