Strong Authentication – System Design and Deployment
description
Transcript of Strong Authentication – System Design and Deployment
![Page 1: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/1.jpg)
Strong Authentication – System Design and Deployment
Matt CrawfordFermilab
Computer Security Team
![Page 2: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/2.jpg)
Outline Motivation and Requirements Components and Configuration Technical Factors Human Factors
![Page 3: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/3.jpg)
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
![Page 4: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/4.jpg)
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.
![Page 5: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/5.jpg)
Components and Methods
![Page 6: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/6.jpg)
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”
![Page 7: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/7.jpg)
Illusory Security
Remote Site(or local!)
Desktop Server
Server
Supposedly Secure Realm
clear encrypted
![Page 8: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/8.jpg)
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.
![Page 9: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/9.jpg)
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.
![Page 10: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/10.jpg)
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.
![Page 11: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/11.jpg)
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.
![Page 12: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/12.jpg)
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.
![Page 13: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/13.jpg)
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.
![Page 14: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/14.jpg)
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) ]
![Page 15: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/15.jpg)
Overall Schematic
Strengthened RealmPortal
Untrusted Realm
On-Site Off-Site
Application Servers
One-timepasswords
Kerberos
KerberosKDC
Trusted Realm
KDC
Desktops
![Page 16: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/16.jpg)
Kerberos-Secured Access
Strengthened RealmPortal
Untrusted Realm
On-Site Off-Site
Application Servers
One-timepasswords
Kerberos
KerberosKDC
Trusted Realm
KDC
Desktops
![Page 17: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/17.jpg)
Cross-Authenticated Access
Strengthened RealmPortal
Untrusted Realm
On-Site Off-Site
Application Servers
One-timepasswords
Kerberos
KerberosKDC
Trusted Realm
KDC
Desktops
![Page 18: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/18.jpg)
Access through Portal
Strengthened RealmPortal
Untrusted Realm
On-Site Off-Site
Application Servers
One-timepasswords
Kerberos
KerberosKDC
Trusted Realm
KDC
Desktops
![Page 19: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/19.jpg)
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.
![Page 20: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/20.jpg)
Technical Factors
![Page 21: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/21.jpg)
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.
![Page 22: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/22.jpg)
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.
![Page 23: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/23.jpg)
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.
![Page 24: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/24.jpg)
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.
![Page 25: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/25.jpg)
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.
![Page 26: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/26.jpg)
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.
![Page 27: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/27.jpg)
Human Factors
![Page 28: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/28.jpg)
How to “get Kerberized”...
UNIX– Get user key– Install UPS product– Get host key
Win32– Get user key– Get software– Run setup
![Page 29: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/29.jpg)
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.
![Page 30: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/30.jpg)
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.”
![Page 31: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/31.jpg)
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.
![Page 32: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/32.jpg)
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.
![Page 33: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/33.jpg)
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?”
![Page 34: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/34.jpg)
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?
![Page 35: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/35.jpg)
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.
![Page 36: Strong Authentication – System Design and Deployment](https://reader034.fdocuments.us/reader034/viewer/2022042616/56816848550346895dde3022/html5/thumbnails/36.jpg)
End...