Authentication

June 24/2003

Overview

• Terminology• Local Passwords• Early Password Services• Kerberos Basics• Tickets• Ticket Acquisition• Kerberos Authentication• LDAP

Overview

• Active Directory (AD)• Apache• Cookies• Pubcookie• PAM• U of A Activities

Terminology

• Authentication– The identification of a user to a service or resource.

• Authorization– The determination of what a user is entitled to do.

– Access privileges.

• Single Signon– Use of a single user ID and password to authenticate a

user to all services.

– Minimization of need to repeatedly re-enter password.

Local Passwords

• One-way hash function converts password to key.– Password can not be determined from key.

– Hash functions can differ between OS types.

• Keys stored in local password file.– Key computed from password compared to stored key.

• Problems:– Early password (key) files publicly readable.

– Password files need to be replicated between systems for common passwords across systems.

Early Password Services

• YP/NIS/NIS+– Replaces local password database with remote database.

– Local machine obtains password entry from server on remote machine.

• Compares key obtained in same way as locally-stored key.

– Allows for both locally and remotely stored keys.

– Password entries visible over network.

– Primarily Unix-only.

Early Password Services

• Window NT primary domain controller (PDC).– Password sent to PDC for validation.

– Uses SMB protocol.

– Passwords were initially sent clear-text.

– Newer version sends hash value (key).• Hash value visible over network.

• Can be re-used to authenticate.

– Primarily Windows-only.• Also implemented in SAMBA freeware product.

Kerberos Basics

• Designed to allow users to authenticate over an open network.– Network is assumed to be hostile.

• User and service keys stored on trusted server.– Key Distribution Center (KDC).

– Each key known only to KDC and owning user/service.

– User keys derived from password using non-reversible hash function.

• All encryption performed using DES.

Kerberos Basics

• Realm:– Autonomous administration unit.

– Establishes unique KDC.

– Name usually mirrors Internet domain name.

• Principal:– Unique name assigned to each user or service.

– General form: <a>/<b>@<realm>• Form for user ID: <user>@<realm>

• Identity proven using ticket.

Tickets

• Ticket identifies a user to a service.• Ticket consists of identifier and authenticator.

– Identifier establishes user’s identity.• Encrypted with key of desired service.

– Authenticator verifies that principal and sender match.• Contains time stamp.

– Both parts contain user’s principal.

– Both parts contain (the same) random session key.• Used for DES-encrypted communication between client/server.

• Ticket valid only for a specified time period.

Ticket Acquisition

• Client requests ticket from KDC.– User and service are identified in request.

• KDC sends ticket to client.– KDC generates random session key.

– KDC generates identifier.• KDC encrypts identifier with service’s key.

– KDC generates authenticator.• KDC encrypts authenticator with user’s key.

– KDC sends encrypted identifier and authenticator.

Ticket Acquisition

• Client generates user’s key from password.• Client decrypts authenticator.

– Successful decryption indicates valid password.• Time stamp in authenticator must match current time on client

machine (within a small tolerance level).

• Principal in authenticator must match desired user principal.

– Client now has user identifier.• Client machine can not ( necessarily) decode the identifier.

– Client has random session key from authenticator.

• Client erases user key and password.

Kerberos Authentication

• Password Validation.– System uses Kerberos to validate a user password.

– Client obtains ticket for user.• Service immaterial, usually ticket granting service (TGS).

• If authenticator successfully decrypted, password valid.

• System erases ticket and session key.

– Client verifies KDC (optional).• Client obtains initial ticket for service with secret key.

– Principal: host/<machine>@<realm>

• If authenticator successfully decrypted, KDC is proper one.

Kerberos Authentication

• Ticket Passing.– Client obtains service ticket for user.

– Client decrypts authenticator.• Gets random session key.

– Client constructs new authenticator.• Encrypts authenticator with random session key.

– Client sends new ticket to desired server.

– Server decrypts identifier with its own service key.• Gets random session key.

– Server decrypts authenticator with random key.

Kerberos Authentication

• System Requirements:– Time synchronized on client, server and KDC.

– Kerberos software (libraries and utilities).• MIT: http://web.mit.edu/kerberos/www.

• Heimdal: http://www.pdc.kth.se/heimdal.

– Kerberos-aware applications.

• Observation:– KDC unaware of authentication result.

• KDC can not track authentication statistics.

Kerberos Authentication

• Benefits:– Password or user key never leave client machine!

• Single exception when changing password.– Password encrypted with random key in this case.

– Software available for virtually all OS types.• Many systems now come with built-in Kerberos 5.

– Solaris, Linux, OpenBSD, MacOS X, Windows 2000.

• Disadvantages:– Applications must often be modified to use Kerberos.

Kerberos Authentication

• Perl Interface: Authen::Krb5::Simple– Provides Kerberos authentication to Perl script.

– Easy to use.

– Requires Kerberos 5 C library and headers.• Works with MIT or Heimdal.

– ftp://ftp.cpan.org/pub/CPAN/modules/by-module/Authen/Authen-Krb5-Simple-0.31.tar.gz

– Sample script: http://www.ualberta.ca/~antoine/authentation/krb5.pl

Kerberos Authentication

• Introductory Reading:– B. Tung. A Moron’s Guide To Kerberos, Version 1.2.2

http://www.isi.edu/gost/brian/security/kerberos.html

– B. Bryant. Designing An Authentication System: A Dialogue In Four Scenes

ftp://athena-dist.mit.edu/pub/kerberos/doc/dialogue.PS

LDAP

• Directory lookup protocol.• Directory data stored in database on server.

– Generally holds data about people or resources.

• Data structured as tree.– Each node has label and value.

• Distinguished name (DN):– Full path of entry in directory.

– Consists of labels and values of all nodes to entry.

– DN: uid=<user>,ou=people,dc=ualberta,dc=ca

LDAP

• Data can be public or private.• Authentication:

– Password can be associated with node.

– Client opens connection to LDAP server.• Connection unencrypted or encrypted using SSL.

– Client binds as anonymous or as specified DN.• Password not needed for anonymous bind.

• Password passed as part of bind request.

• Password sent compared to local copy on server.

• Successful bind indicates correct password.

• Bind-based authentication.

LDAP

• OpenLDAP server allows use of Kerberos KDC.– Server password entry replaced with calls to KDC.

• Operates in Kerberos password validation mode.

LDAP

• Perl Interface: Net::LDAPS– Provides LDAP functionality to Perl script.

• Includes LDAP authentication.

– Requires other Perl modules.• See README file.

– http://prdownloads.sourceforge.net/perl-ldap/perl-ldap-0.28.tar.gz

– Sample script: http://www.ualberta.ca/~antoine/authentation/ldaps.pl

• Does NOT verify SSL certificate.– SSL certificate must be verified in production use.

Active Directory (AD)

• Combination of DNS, LDAP, and Kerberos.– Authentication performed using Kerberos 5.

• Inter-operates with MIT Kerberos.– MIT clients can authenticate seamlessly to AD server.

– AD clients can authenticate to MIT server.• Requires some configuration.

• Windows client machines require special host key.– Principal: host/<machine>@<realm>

– User authenticates to MIT realm.• Client machine uses MIT ticket for resource access.

Active Directory (AD)

• AD forest can inter-operate with MIT KDC.– AD domain controllers require trust relationship with

MIT KDC.• AD must trust MIT KDC.

• MIT KDC need not trust AD..

– Requires special key.• Principal: krbtgt/<AD domain>@<realm>

– Requires patch to MIT Kerberos server.

– User authenticates to MIT realm.• AD uses resulting MIT ticket to provide access to resources.

Apache

• Web pages can be public or private.• Client opens connection to web server.

– Connection unencrypted or encrypted using SSL.

• Basic authentication:– Web server queries client for user ID and password.

– Checks password against local password database.• htpasswd

Apache

• Mod_auth_kerb.– Replaces local password check with calls to Kerberos.

– Operates in password validation mode.

– http://modauthkerb.sourceforge.net

Cookies

• Used to retain state in web environment– HTTP protocol is stateless.

– Cookie keeps user-specific information between calls to web server.

• Identifies user to web server.

– Web server sends cookie to client browser.• Transfer is transparent to user.

– Web server retrieves cookie on subsequent calls.• May update contents on each call.

Cookies

• Many security/privacy issues associated with use.– Severity dependent on each specific web server.

• http://www.cookiecentral.com

Pubcookie

• Standalone logon server.– Interface between web server and authentication method

s.• Interfaces with Kerberos, LDAP, NIS.

– Returns cookie containing identity of user.

• Component modules for Apache and IIS servers.– Replaces other authentication modules.

• Client browsers require no change.

Pubcookie

• Operation:– Client browser contacts web server.

– Server checks for authentication cookie.• If found, web server passes back requested data.

• Request complete.

– Server redirects browser to logon server.• Redirect requests contains original URL in cookie.

– Login server prompts for user ID/password.

– Logon server validates ID and password.

– Logon server generates authentication cookie.

Pubcookie– Logon server redirects browser back to original URL.

• Redirect includes authentication cookie.

• Also includes cookie for future use by logon server.– Eliminates need to re-enter user ID/password repeatedly.

– Web server will now send requested data.

• Authentication cookies have fixed lifetime.• Single signon implementation for web services.

– Same authentication cookie works for all web servers using pubcookie.

• http://www.pubcookie.org

PAM

• Pluggable authentication module.• Designed by SUN.

– Supported by SUN, Linux, HP.

• Generic API between application and authentication method.– Client performs authentication by calling API routines.

– Authentication methods implemented as dynamically loadable modules.

– Configuration file determines modules to be used for given application.

PAM

• Benefits:– Application need only support generic API.

– New authentication methods added as modules.• Configuration file change implements new method for

application.

• Minimizes support requirements.

– More than one method can be used by application.• Configuration file determines order attempted.

PAM

• Disadvantages:– No support for AIX, BSD.

– Unix-only.

– SUN and Linux APIs differ slightly.

• Web sites:– SUN: http://www.sun.com/solaris/pam

– Linux: http://www.kernel.org/pub/linux/libs/pam

U of A Activities

• Objectives:– Minimize number of IDs/passwords for any user.

– Cover all services/platforms.

– Secure Authentication.• No clear-text.

• Kerberos 5 primary authentication method.– 60,000+ users.

– 2 servers:• krb5-1.srv.ualberta.ca and krb5-2.srv.ualberta.ca

– Preferred protocol for client authentication.

U of A Activities

• SAMBA provides Windows NT authentication.– samba.srv.ualberta.ca

– SAMBA password database synchronized real-time with Kerberos.

• OpenLDAP provides LDAP authentication.– ldapauth.srv.ualberta.ca

– LDAP authentication translated to Kerberos calls.• No passwords or keys on LDAP server.

– Only LDAPS protocol supported.

U of A Activities

• Active Directory.– Windows 2000/XP standalone clients can authenticate

using MIT KDC servers.• Web-based configuration instructions in final stages.

• Web-based tool for obtaining required host key near completion.

– Initial attempt at root AD server begun.• Some success at using MIT KDC servers in AD forest.

• Needs more work.

• Web-based tool for obtaining required trust key near completion.

U of A Activities

• Pubcookie.– Logon server being tested.

• Password changes only permitted via web page.– HTTPS access, only.

– Forces use of good passwords.

– Keeps Kerberos and Samba servers synchronized.