1. Authentication June 24/2003

2. Overview Terminology Local Passwords Early Password Services Kerberos Basics Tickets Ticket Acquisition Kerberos Authentication LDAP

3. Overview Active Directory (AD) Apache Cookies Pubcookie PAM U of A Activities

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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: / @ Form for user ID: @ Identity proven using ticket.

10. 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.

11. 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.

12. 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.

13. 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/ @ If authenticator successfully decrypted, KDC is proper one.

14. 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.

15. 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.

16. 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.

17. 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

18. 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

19. 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=,ou=people,dc=ualberta,dc=ca

20. 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.

21. LDAP OpenLDAP server allows use of Kerberos KDC. –Server password entry replaced with calls to KDC. Operates in Kerberos password validation mode.

22. 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.

23. 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/ @ –User authenticates to MIT realm. Client machine uses MIT ticket for resource access.

24. 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/ @ –Requires patch to MIT Kerberos server. –User authenticates to MIT realm. AD uses resulting MIT ticket to provide access to resources.

25. 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

26. Apache Mod_auth_kerb. –Replaces local password check with calls to Kerberos. –Operates in password validation mode. –http://modauthkerb.sourceforge.net

27. 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.

28. Cookies Many security/privacy issues associated with use. –Severity dependent on each specific web server. http://www.cookiecentral.com

29. 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.

30. 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.

31. 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

32. 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.

33. 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.

34. 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

35. 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.

36. 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.

37. 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.

38. 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.