Strong Authentication

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?

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

4
Requirements

• 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

• 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!
• Run II schedule
• Implementation may be staged but must offer
  meaningful improvement for Run-II.

6
Project Goals

• Primary -
• Prevent disclosure of passwords
• Without requiring superhuman diligence.
• 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

• If this project had already been in place, it
  would have had the following impact on the FIRE
  level incidents we had in FCIRTs first two
  years.
• Approximately 60 prevented outright.
• Approximately 30 contained in scope.
• Approximately 10 unaffected.
• The total hours saved by the response team, the
  sysadmins and the users would have been quite
  significant.

8
Why not just ssh?

• 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!)
Supposedly Secure Realm
encrypted
clear
Server
10
Strong Authentication - System Design
11
Four Classes of Systems

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

12
Kerberos

• 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.
• AFS uses the Kerberos version 4 protocol.
• DCE uses Kerberos 5.

13
Enforcing Password Security

• 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.
• Password policies (dictionary check, aging,
  quality) are enforced by the master KDC.

14
Portal Mode Authentication

• 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)
• Can be enabled on any system running the Fermi
  Kerberos product.
• Serves vanilla clients without exposing any
  reusable authentication data.

15
Users View - with Kerberos

• 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

• 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

• Must install Kerberized user applications and
  servers.
• Must disable non-Kerberized versions.
• Remove servers from inetd.conf, put clients later
  in PATH or hide them.
• 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)

• No Kerberos tickets for local user root.
• 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

• For cron jobs and similar unattended processes,
  we have Kerberos authentication based on keytabs,
  which are encryption keys stored in files.
• 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

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

21
Configuration Requirements

• Systems performing authentication to our Kerberos
  realm are periodically scanned to ensure that
  cleartext access methods are closed.
• 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.