Strong Authentication System Design and Deployment

1
Strong Authentication System Design and
Deployment

• Matt Crawford
• Fermilab
• Computer Security Team

2
Outline

• Motivation and Requirements
• Components and Configuration
• Technical Factors
• Human Factors

3
Why?

• Reduce effort spent on intrusions recovery
• Regulatory climate is demanding increased
  attention to access controls
• Management has agreed with the goals outlined in
  SLCCC-TWG white paper Alternatives to Reusable
  Passwords Robust Authentication

4
Requirements

• Significant improvement in security.
• Acceptable to the user community.
• Carrots
• Single sign-on for users.
• Central account password administration for
  sysadmins.
• Schedule
• Implementation may be staged but must offer
  meaningful improvement for Run II.

5
Components and Methods
6
Why not ssh?

• Ssh addresses encryption, but misses several
  other key issues
• Performance -- why encrypt everything?
• Account management
• Password management
• Password/certificate vulnerability
• Illusory security

7
Illusory Security
Remote Site (or local!)
Supposedly Secure Realm
encrypted
clear
Server
8
Four Realms

• Strengthened
• Kerberos authentication required for all network
  logins.
• Untrusted
• Hosts, on- or off-site, from which logins to
  Strengthened realm are not permitted.
• Portal
• Gateway between Untrusted and Strengthened.
• Trusted
• An outside Kerberos realm with which we
  cross-authenticate.

9
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.

10
Kerberos Keys

• Each principal has a symmetric (secret) key.
• Users keys are hashed passwords.
• Service keys are random bit-strings.
• All keys are known by the Key Distribution Center
  (KDC)
• Keys are used to decrypt short messages from the
  KDC. Knowledge of a key proves identity.
• Kerberos does not send passwords over the
  network. Session keys are sent, encrypted under
  user and service keys.

11
Kerberos KDC

• KDC is replicated - one master per realm and N ?
  0 slaves.
• Manual intervention needed to turn slave into
  master, but all data is present on slaves.
• Addition, deletion and change of principals,
  including password changes, require communication
  with master KDC.

12
Kerberos Key Servers

• KDCs must be on dedicated, secured machines.
• Physical security is important.
• CPU, storage and network requirements are
  moderate.
• Rough O(5 min) clock synchronization is
  required between clients and KDC.
• Kerberos administrative functions may be
  performed remotely.

13
Application Servers

• Any system which provides a Kerberos-authenticated
  service over the network.
• Telnet, rlogin, FTP, POP, CVS, etc.
• Application must have a Kerberos key to receive
  and decrypt tickets prepared by the KDC.
• Authorization is done locally, as now.
• Example A user in the Kerberos realm must also
  be listed in the local or NIS password file to
  log in, although no password needs to be recorded
  locally.

14
Ticket Delivery

• Foo K(X) denotes data Foo encrypted under Xs
  key.
• Service ticket
• Svc, User, SessKey, OtherInfo K(SVC)
• Ticket-Granting Ticket is just a service ticket
  with Scvkrbtgt.
• Ticket-Granting Service reply
• PA_data, User, Ticket, SessKey, OtherInfo,
  SvcK(USER)

15
Overall Schematic
Untrusted Realm
Trusted Realm
One-time passwords
Desktops
Kerberos
Kerberos
Application Servers
Strengthened Realm
Portal
16
Kerberos-Secured Access
Untrusted Realm
Trusted Realm
One-time passwords
Desktops
Kerberos
Kerberos
Application Servers
Strengthened Realm
Portal
17
Cross-Authenticated Access
Untrusted Realm
Trusted Realm
One-time passwords
Desktops
Kerberos
Kerberos
Application Servers
Strengthened Realm
Portal
18
Access through Portal
Untrusted Realm
Trusted Realm
One-time passwords
Desktops
Kerberos
Kerberos
Application Servers
Strengthened Realm
Portal
19
Remote Access without Kerberos

• To prevent disclosure of passwords, initial entry
  to Kerberos system must not be allowed by typing
  a password over a clear network connection!
• User must log in to Portal realm first, with some
  other non-disclosing password scheme.
• No change in accessing Untrusted Realm systems.

20
Kerberos protection for non-Kerberized systems
21
Technical Factors
22
AFS Integration

• AFS uses Kerberos v4 protocol with a modified
  password ? key algorithm.
• A Kerberos v5 KDC in possession of the master key
  for an AFS cell can generate a service ticket
  which is convertible to an AFS token for that
  cell.
• Code from ANL NRL, tested.
• User with TGT runs aklog, no password.
• Transparent through krb5.conf app-defaults.

23
Enforcing Password Security

• To avoid exposing Kerberos passwords,
  non-Kerberos network logins must be disabled -
  initial tickets must be obtained locally!
• Easily configured.
• May be verified by network scan.
• Anonymous FTP is still allowed.
• Password policies (quality, cracklib check,
  expiration, history) are enforced by the master
  KDC.

24
Portal Realm

• Provides authentication for users who lack
  Kerberos software or secure network channels, and
  obtains their initial tickets.
• One-time passwords
• Hardware tokens
• Java ssh applet?
• KDC and portal kinit/login must be modified to
  use host keys in place of user keys for TGT
  passing.

25
Portal Realm Features

• Telnet and ftp are supported through the portal
  realm.
• ssh/scp may be desirable.
• File transfer by pass-through ftp or AFS.
• No strong desires expressed for additional
  services (CVS? HTTPS? XDM?)
• Clearly preferable to move to strengthened realm
  rather than use portal on a regular basis.

26
Portal Realm Features

• Real remote users use telnet more than X.
• Increased interactive load on portal realm.
• Increased consumption of one-time passwords.
• Change sociology?
• Keyboard mappings through portal realm may be
  hopeless, or may be unimportant.
• Foreign token systems will not be supported.

27
Portal Realm Features

• Ticket expiration during portal session may
  expose Kerberos password.
• E.g. a login session left overnight.
• Users should log out and in again to portal realm
  to get new tickets.
• Strong temptation to simply re-kinit in
  strengthened realm.
• Train users dont do that.
• Could be mostly prevented by software means.

28
Human Factors
29
How to get Kerberized...

• UNIX
• Get user key
• Install UPS product
• Get host key

• Win32
• Get user key
• Get software
• Run setup

30
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.
• Must know kpasswd, klist and kinit commands.

31
Users View - w/o Kerberos

• Non-Kerberos logins to Strengthened realm hosts
  will be refused without asking for a password.
• telnet ? Authentication failed.
• rlogin, rsh ? Connection refused.
• ftp ? Access denied authentication required.

32
Users View - Portal Realm

• From non-Kerberos desktops, users must log in to
  one of a special set of hosts, with a one-time
  authenticator.
• Procedures may be unfamiliar to the occasional
  user.
• From a Portal host, log in to a Strengthened
  system or ftp files to/from AFS space.
• X (and other) connections back to Untrusted
  systems are allowed.

33
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 a locally-installed product, plus
  modification of one system file.
• S/W update frequency is very low.

34
Sysadmins View (2)

• No Kerberos tickets for local user root.
• ksu can replace or supplement su, with added
  flexibility.
• Special principals such as user/root_at_REALM 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?

35
Account Administration

• Special account types are needed/requested
• Group accounts
• Access by several (many) individuals
• Best accommodated by entering individual
  principals in .k5login file.
• Generic accounts
• Arent assigned to an individual (e.g. operator
  consoles).
• Transient accounts
• Technically easy policy issues?

36
For Developers

• GSSAPI (Generic Security Services Application
  Programming Interface) provides calls to create a
  Kerberos-authenticated session, with optional
• Integrity
• Privacy
• Mutual Authentication
• Bindings exist for C, Java, Python, Perl, and
  other languages.

37
End...