Transcript authentication

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/bymodule/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-ldap0.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
methods.
• 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.