Strong Authentication –
System Design and
Deployment
Matt Crawford
Fermilab
Computer Security Team
Outline
 Motivation
and Requirements
 Components and Configuration
 Technical Factors
 Human Factors
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
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.
Components and
Methods
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”
Illusory Security
Remote Site
(or local!)
encrypted
clear
Desktop
Supposedly
Secure Realm
Server
Server
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.
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.
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.
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.
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.
Application Servers
 Any
system which provides a Kerberosauthenticated 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.
Ticket Delivery
{ Foo }K(X) denotes data Foo encrypted under X’s key.
 Service
ticket:
[ Svc, { User, SessKey, OtherInfo }K(SVC) ]
 Ticket-Granting
Ticket is just a service
ticket with Scv=“krbtgt”.
 Ticket-Granting Service reply:
[ PA_data, User, Ticket, { SessKey, OtherInfo,
Svc}K(USER) ]
Overall Schematic
Untrusted Realm
Trusted Realm
KDC
On-Site
Off-Site
One-time
passwords
Desktops
KDC
Kerberos
Kerberos
Application Servers
Portal
Strengthened Realm
Kerberos-Secured Access
Untrusted Realm
Trusted Realm
KDC
On-Site
Off-Site
One-time
passwords
Desktops
KDC
Kerberos
Kerberos
Application Servers
Portal
Strengthened Realm
Cross-Authenticated Access
Untrusted Realm
Trusted Realm
KDC
On-Site
Off-Site
One-time
passwords
Desktops
KDC
Kerberos
Kerberos
Application Servers
Portal
Strengthened Realm
Access through Portal
Untrusted Realm
Trusted Realm
KDC
On-Site
Off-Site
One-time
passwords
Desktops
KDC
Kerberos
Kerberos
Application Servers
Portal
Strengthened Realm
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.
Technical Factors
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.
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.
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.
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.
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.
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 “don’t do that.”
– Could be mostly prevented by software means.
Human Factors
How to “get Kerberized”...

UNIX
– Get user key
– Install UPS product
– Get host key

Win32
– Get user key
– Get software
– Run setup
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.
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.”
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.
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.
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@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?”
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
• Aren’t assigned to an individual (e.g. operator
consoles).
– Transient accounts
• Technically easy — policy issues?
For Developers
 GSSAPI
(Generic Security Services
Application Programming Interface)
provides calls to create a Kerberosauthenticated session, with optional
– Integrity
– Privacy
– Mutual Authentication
 Bindings
exist for C, Java, Python, Perl, and
other languages.
End...