ITIS 3110 IT INFRASTRUCTURE II Authentication This Lectures

ITIS 3110 IT INFRASTRUCTURE II Authentication

This Lecture’s Topics �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: gecos: home: shell � gecos: generic information field � Defacto standards � Usually comma separated �Example � jwatso 8: x: 1000: Jason Watson, , , : /home/jwatso 8: /bin/bash

Sample NSS Databases �group �/etc/group �Contains group information and memberships �Form: � group: password: gid: members �Example: � admin: x: 80: sgblanch, jwatso 8, 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 �Examples � jwatso 8: *: 13977: : 99999: 7: : : � PW Notes: � “x” PW is encrypted in /etc/shadow � “*” PW is disabled � blank (: : ) no pw required

More PW notes � user: password: last_change: min_life: max_life: warn : disable expired: disabled_time: reserved � tkombol: $6$d 8 rk 63 Ao$w. J 5 Ym. Gw. MGs. Upk/f 8 s. Am. DVY 2 et. FSQIM 7929 IB 6 dt 2 Sa. DBb. O 8 e. L. xo 5 s. Vda. Mv. XHHZ 9 l 6 s. L 7 Hr. Rylr 8/EOor. Inoe/: 16477 : 0: 99999: 7: : : � PW Format: � $6 � Which encryption algorithm to use � $d 8 rk 63 Ao � Salt � $w. J 5 Ym. Gw. MGs. Upk/f 8 s. Am. DVY 2 et. FSQIM 7929 IB 6 dt 2 Sa. DBb. O 8 e. L. xo 5 s. Vda. Mv XHHZ 9 l 6 s. L 7 Hr. Rylr 8/EOor. Inoe/ � Encrypted password

Sample NSS Databases �hosts �/etc/hosts �Hostname resolution �Often uses DNS in addition to the /etc/hosts file �Example: � 127. 0. 0. 1 192. 168. 1. 50 localhost ajk 2110 debian. hades. lab ajk 2110 debian # The following lines are desirable for IPv 6 capable hosts : : 1 localhost ip 6 -loopback ff 02: : 1 ip 6 -allnodes ff 02: : 2 ip 6 -allrouters

Viewing NSS Databases �getent �Command line tool allows you to see the world according to NSS �Saw this in previous DNS lecture �Usage: �getent <database> [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 module stacks available in PAM � 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-MD 5 �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 (GSSAPI) �Application Programming Interface for challengeresponse 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 http: //en. wikipedia. org/wiki/Kerberos_%28 protocol%29

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

Kerberos Video �Video 1: �http: //www. yourepeat. com/watch/? v=_msf. Qm. CEv 4 I&f eature=youtube_gdata �~10 min. (good) �Video 2: �http: //www. youtube. com/watch? v=Xn. Wf. Lwjao 2 E �~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

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 1980 s �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) � http: //www. rfc-editor. org/ �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 e. Bones. � e. Bones 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 e. Bones 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 RC 4 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 V 5 specification � “The Kerberos Network Authentication Service (V 5)” � 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 based on 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

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 e-mail client developed by Cyrusoft, Inc. NFS (since NFSv 3) Open. SSH (with Kerberos v 5 or higher) Oracle RDBMS PAM (with the pam_krb 5 module) rcp Remote copy command in linux and unix Samba since v 3. x SOCKS (since SOCKS 5) Netatalk GSS-API X Window System implementations Indirectly, any software that allows the use of SASL for authentication, such as Open. LDAP, Dovecot IMAP 4 and POP 3 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

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 � TGS � SS � TGT = Authentication Server = Ticket Granting Server = Service Server = 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 encrypted using the secret key of the TGS � Includes the client ID, client network address, ticket validity period, and the client/TGS session key � 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

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

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

Kerberos k or w to ks cl ab ov e ve at e ur N e th on e Al of lt he cc ta ha ew m so ee ds N 0% oc at io 0% lic pp ot ith w be st ks or W 0% he ra el es s of d sk in el fi its By ns 3% us A. By itself is kind of useless B. Works best with other applications C. Needs somewhat accurate clocks to work D. All the above E. None of the above 88%