Strong authentication system design and deployment
This presentation is the property of its rightful owner.
Sponsored Links
1 / 36

Strong Authentication – System Design and Deployment PowerPoint PPT Presentation


  • 51 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Strong Authentication – System Design and Deployment

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Strong authentication system design and deployment

Strong Authentication – System Design and Deployment

Matt Crawford

Fermilab

Computer Security Team


Outline

Outline

  • Motivation and Requirements

  • Components and Configuration

  • Technical Factors

  • Human Factors


Strong authentication system design and deployment

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

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

Components and Methods


Why not ssh

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

Desktop

Server

Illusory Security

Remote Site

(or local!)

Supposedly Secure Realm

encrypted

clear

Server


Four realms

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

  • 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

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

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

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

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.


Ticket delivery

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

On-Site

Off-Site

KDC

KDC

Overall Schematic

Untrusted Realm

Trusted Realm

One-time

passwords

Desktops

Kerberos

Kerberos

Application Servers

Portal

Strengthened Realm


Kerberos secured access

On-Site

Off-Site

KDC

KDC

Kerberos-Secured Access

Untrusted Realm

Trusted Realm

One-time

passwords

Desktops

Kerberos

Kerberos

Application Servers

Portal

Strengthened Realm


Cross authenticated access

On-Site

Off-Site

KDC

KDC

Cross-Authenticated Access

Untrusted Realm

Trusted Realm

One-time

passwords

Desktops

Kerberos

Kerberos

Application Servers

Portal

Strengthened Realm


Access through portal

KDC

On-Site

Off-Site

KDC

Access through Portal

Untrusted Realm

Trusted Realm

One-time

passwords

Desktops

Kerberos

Kerberos

Application Servers

Portal

Strengthened Realm


Remote access without kerberos

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

Technical Factors


Afs integration

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

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

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

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 features1

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 features2

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

Human Factors


How to get kerberized

UNIX

Get user key

Install UPS product

Get host key

Win32

Get user key

Get software

Run setup

How to “get Kerberized”...


Users view with kerberos

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

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

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

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

Sysadmins’ View (2)

  • No Kerberos tickets for local user “root”.

  • ksu can replace or supplement su, with added flexibility.

    • Special principals such as [email protected] 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

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

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.


Strong authentication system design and deployment

End...


  • Login