This Lecture’s Topics Authentication and Authorization Authentication and Authorization in UNIX Name Service Switch PAM SASL GSSAPI Kerberos

Authentication vs. Authorization Authentication Act of Establishing a user’s identity Who you are Authorization Specifies access rights to resources What you can access Relies on authentication to establish identity

Authentication and Authorization in UNIX Handled by two components Name Service Switch (NSS) Pluggable Authentication Modules (PAM)

Name Service Switch Concept of ‘Everything is a database’ Controls where system looks up various databases passwd group shadow hosts …

Sample NSS Databases passwd /etc/passwd Contains account information These days it does NOT include a user’s password An x is used to denote the pw is in another file A * indicates the account is disabled Form user:password:uid:gid:gecos:home:shell Example jwatso8:x:1000:1000:Jason Watson,,,:/home/jwatso8:/bin/bash group /etc/group Contains group information and memberships Form: group:password:gid:members Example: admin:x:80:sgblanch,jwatso8,tkombol

Sample NSS Databases shadow /etc/shadow ( /etc/gshadow for groups) Contains password and expiration information user:password:last_change:min_life:max_life:warn:disable expired:disabled_time:reserved Example jwatso8:*:13977::99999:7::: PW Notes: PW is encripted blank (::)no pw required * account disabled hosts /etc/hosts Hostname resolution Often uses DNS in addition to the /etc/hosts file

Viewing NSS Databases getent Command line tool allows you to see the world according to NSS Saw this in previous DNS lecture Usage: getent [object]

Pluggable Authentication Modules PAM A “stack” of libraries used to verify a user and their password Some PAM modules are not directly related to authentication They set up a user’s environment Stored in /etc/pam.d Contains a file for every binary that requires authentication login sshd sudo

Pluggable Authentication Modules Several different stacks available in PAM Auth Authentication Verify users’ passwords Account Authorization Account verification Password expiration Session Maintenance Mounting, un-mounting or creating home directory Password Updating of authentication credentials (changing password)

Simple Authentication and Security Layer (SASL) Authentication framework Removes authentication from protocol implementations Often used for server applications e.g. SMTP, HTTP and LDAP servers Supports authentication ‘mechanisms’ Any SASL-aware application can authenticate users using any SASL mechanism

Selected SASL Mechanisms PLAIN Clear-text password authentication DIGEST-MD5 HTTP Digest compatible authentication NTLM Windows NT LAN Manager GSSAPI Generic Security Services API Bridge for Kerberos 5 Authentication Proxies Kerberos SASL receives password and negotiates Kerberos

Generic Security Services API Application Programming Interface for challenge- response protocols like Kerberos Kerberos implementations have different programming interfaces Before GSSAPI, applications had to support each Kerberos implementation independently Applications that support GSSAPI can use any Kerberos implementation

Kerberos By itself it is kind of useless Just verifies UID and PW Power comes from pairing it with other services

Kerberos Video Video1: ature=youtube_gdata ature=youtube_gdata ~10 min. (good) Video2: ~12 min (ok)

Kerberos Computer network authentication protocol Allows individuals communicating over a non-secure network to prove their identity to one another in a secure manner Suite of free software published by Massachusetts Institute of Technology (MIT) that implements this protocol Aimed primarily at a client-server model Provides mutual authentication Both the user and the server verify each other's identity Kerberos protocol messages are protected against eavesdropping and replay attacks

Kerberos Builds on symmetric key cryptography Requires a trusted third party Extensions to Kerberos can provide for the use of public key cryptography during certain phases of authentication

History and development MIT developed Kerberos to protect network services provided by Project Athena Named after the Greek mythological character Kerberos (Cerberus) Monstrous three-headed guard dog of Hades in Greek mythology Fluffy is an example of a Cerberus Several versions of the protocol exist Versions 1–3 internal only at MIT

History and development Version 4 published in the late 1980s Steve Miller and Clifford Neuman primary designers of Kerberos Targeted primarily for Project Athena Version 5 (1993) Addressed the limitations and security problems of version 4 Designed by John Kohl and Clifford Neuman RFC 1510 (RFC is Request for Comments) Made obsolete by RFC 4120 in 2005

History and development MIT has a free version of Kerberos available Copyright permissions similar to those used for BSD Authorities in the United States classified Kerberos as a munition Banned its export Used the DES encryption algorithm (with 56-bit keys) Non-US Kerberos 4 implementation, KTH-KRB Developed at the Royal Institute of Technology in Sweden System available outside the US before the US changed its cryptography export regulations (circa 2000) Swedish implementation was based on a version called eBones. eBones was based on the exported MIT Bones release based on version Kerberos 4 patch-level 9 Stripped of both the encryption functions and the calls to them This somewhat limited Kerberos was called the eBones release A Kerberos version 5 implementation, Heimdal, was released by basically the same group of people releasing KTH-KRB

History and development Windows 2000, XP, Server 2003 and Vista Use Kerberos as their default authentication method Microsoft additions to the Kerberos suite of protocols Documented in RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols" RFC 4757 documents Microsoft's use of the RC4 cipher Microsoft uses the Kerberos protocol Does not use the MIT software Apple's Mac OS X uses Kerberos client and server versions

History and development IETF Kerberos Working Group is updating the specifications Updates include: “Encryption and Checksum Specifications” RFC 3961 “Advanced Encryption Standard (AES) for Kerberos 5” RFC 3962 New edition of the Kerberos V5 specification “The Kerberos Network Authentication Service (V5)” RFC 4120 Obsoletes RFC 1510 Clarifies aspects of the protocol and intended use in a more detailed and clearer explanation New edition of the GSS-API specification “The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2.“ RFC 4121

Description Kerberos uses as its basis the Needham-Schroeder protocol It makes use of a trusted third party Key Distribution Center (KDC), Consists of two logically separate parts: An Authentication Server (AS) A Ticket Granting Server (TGS) Kerberos works on the basis of "tickets“ Serves to prove the identity of users The KDC maintains a database of secret keys Each entity on the network — whether a client or a server — shares a secret key known only to itself and to the KDC Knowledge of this key serves to prove an entity's identity For communication between two entities KDC generates a session key Used to secure their interactions

Uses The following software can use Kerberos for authentication: VMware ESX Server AFS Apache 1 (with the mod_auth_kerb module) Apache 2 (using libapache-mod-auth-kerb) Cisco routers and switches running IOS Coda File System Eudora Mac OS X Microsoft Windows (2000 and later) uses as default authentication protocol Mulberry, an client developed by Cyrusoft, Inc. NFS (since NFSv3) OpenSSH (with Kerberos v5 or higher) Oracle RDBMS PAM (with the pam_krb5 module) rcp Remote copy command in linux and unix Samba since v3.x SOCKS (since SOCKS5) Netatalk GSS-API X Window System implementations Indirectly, any software that allows the use of SASL for authentication, such as OpenLDAP, Dovecot IMAP4 and POP3 server, Postfix mail server Kerberos software suite also comes with kerberos-enabled clients and servers for rsh, FTP, and Telnet Any Java based software (since 1.4.2) using JAAS/JGSS can use Kerberos for security

Protocol Security of the protocol relies heavily on participants maintaining loosely synchronized time and on short lived assertions of authenticity called Kerberos tickets Simplified description of the protocol abbreviations: AS = Authentication Server TGS = Ticket Granting Server SS = Service Server TGT = Ticket Granting Ticket Briefly: Client authenticates to AS using a long-term shared secret Receives a ticket from the TGS Client can use this ticket to get additional tickets from SS Doesn’t need to resort to using the shared secret These tickets can be used to prove authentication to SS

Protocol In more detail: User Client-based Logon Steps: User enters a username and password on the client Client performs a one-way function on the entered password i.e. encrypts it Becomes the secret key of the client

Protocol Client Authentication Steps: Client sends a clear-text message to the AS requesting services on behalf of the user Sample Message: "User XYZ would like to request services" Note: Neither the secret key nor the password is sent to the AS The AS checks to see if the client is in its database If it is, the AS sends back the following two messages to the client: Message A: Client/TGS session key encrypted using the secret key of the user Message B: Ticket-Granting Ticket (which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS Once the client receives messages A and B, it decrypts message A to obtain the client/TGS session key This session key is used for further communications with TGS Note: The client cannot decrypt the Message B, as it is encrypted using TGS's secret key At this point, the client has enough information to authenticate itself to the TGS.

Protocol Client Service Authorization Steps: When requesting services, the client sends the following two messages to the TGS: Message C: Composed of the Ticket-Granting Ticket from message B and the ID of the requested service Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the client/TGS session key. Upon receiving messages C and D the TGS retrieves message B out of message C It decrypts message B using the TGS secret key This gives it the "client/TGS session key". Using this key, the TGS decrypts message D (Authenticator) and sends the following two messages to the client: Message E: Client-to-server ticket encrypted using the service's secret key Includes the client ID, client network address, validity period and Client/server session key Message F: Client/server session key encrypted with the client/TGS session key

Protocol Client Service Request Steps: Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the SS (Service Server or just Server). Client connects to the SS and sends the following two messages: Message E from the previous step the client-to-server ticket, encrypted using service's secret key Message G: a new Authenticator Includes the client ID, timestamp and is encrypted using client/server session key SS decrypts the ticket using its own secret key Sends the following message to the client to confirm its true identity and willingness to serve the client: Message H: the timestamp found in client's recent Authenticator plus 1, encrypted using the client/server session key Client decrypts the confirmation using the client/server session key Checks whether the timestamp is correctly updated If so, then the client can trust the server and can start issuing service requests to the server Server can then provide the requested services to the client

Kerberos drawbacks Single point of failure: requires continuous availability of a central server When the Kerberos server is down, no one can log in Can be mitigated by using multiple Kerberos servers Requires the clocks of the involved hosts to be synchronized Tickets have time availability period If the host clock is not synchronized with the clock of Kerberos server, the authentication will fail. Default configuration requires that clock times are no more than 5 minutes apart NTP daemons are usually employed to keep the host clocks synchronized Administration protocol is not standardized Differs between server implementations Password changes described in RFC 3244

Single sign-on A method of access control that enables a user to authenticate once and gain access to the resources of multiple software systems Term enterprise reduced sign-on is preferred by some authors They believe single sign-on to be a misnomer: "no one can achieve it without a homogeneous IT infrastructure" In a homogeneous IT infrastructure or at least where a single user entity authentication scheme exists or where user database is centralized, single sign-on is a visible benefit All users in this infrastructure would have one or single authentication credentials e.g. say in an organization stores its user database in a LDAP database. All Information processing systems can use such a LDAP database for user authentication and authorization In turn means single sign-on has been achieved organization wide