Strong Authentication – System Design and Deployment
Download
Report
Transcript Strong Authentication – System Design and Deployment
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...