AUTHONTICATION User Authentication Use of Passwords Attacks on Passwords Password Selection Criteria The Authentication Process Flaws in the Authentication Process Authentication Other Than Passwords Authentication Methods Name-based Verification of basic, available information IP address, MAC address, DNS domain, etc. Difficult to implement Not very secure Password-based Works on a challenge-response scheme Username prompts a challenge from a server Password is rarely sent over the network Secure, but still susceptible to dictionary attacks Authentication Methods (cont) Cryptographic Based on known crypto and hashing methods Users are issued a certificate to prove their identity Certificate is signed by a trusted third-party Biometric Bio: life; Metric: measure Uses body properties to authenticate a user • Fingerprint • Retina and iris scan • DNA? Biometric data is used as a token, similar to token-based Use of Passwords Passwords are mutually agreed-upon code words, assumed to be known only to the user and the system. The use of of passwords is fairly straightforward. A user enters some piece of identification, such as a name or an assigned user ID, if the identification matches that on file for the user, the user is authenticated to the system. If the identification match fails, the user is rejected by the system. Password Storage When users enter passwords for the network or operating system, they or some facsimile of them must be stored so there is something to compare user login attempts to. There are three primary choices for password storage: Clear text Encrypted password Hash value of a password - Used by Unix and Windows NT The storage locations may be: Root or administrator readable only Readable by anyone. Passwords are more secure when they can only be read by the administrator or root account. Also the best password storage security is to store the hashed value of a password. Password Protection and Cracking Passwords should be chosen wisely and a dictionary word should never be used. This is because if an attacker can get the hashed or encrypted value of a password, they can run password guessing programs to eventually guess the password by comparing the encrypted result of the guess to the actual encrypted password. The easiest password attack is a dictionary attack where dictionary words are used to guess the password. Other attacks include a brute force attack which can take much longer than a dictionary attack. This is why passwords should have a minimum length and a minimum degree of complexity. The complexity requirements should include three of four of the following four types of characters: Lowercase Uppercase Numbers Special characters such as !@#$%^&*(){}[] Attacks on Passwords Try all possible passwords exhaustive or brute force attack Try many probable passwords Users do not likely select a password uncommon, hard to spell or pronounce, very long Try passwords likely for the user Password generally is meaningful to the user Attacks on Passwords (cont’) Search for the system list of passwords Finding a plain text system password list Ask the user Get the password directly from the user. Authentication Protocols CHAP - Challenge Handshake Authentication Protocol is a three way handshake protocol which is considered more secure than PAP. Authentication Protocol. EAP - Extensible Authentication Protocol is used between a dial-in client and server to determine what authentication protocol will be used. PAP - Password Authentication Protocol is a two way handshake protocol designed for use with PPP. Authentication Protocol Password Authentication Protocol is a plain text password used on older SLIP systems. It is not secure. SPAP - Shiva PAP. Only NT RAS server supports this for clients dialing in. DES - Data Encryption Standard for older clients and servers. RADIUS - Remote Authentication Dial-In User Service used to authenticate users dialing in remotely to servers in a organization's network. S/Key - A one time password system, secure against replays. RFC 2289. Authentication Protocol. TACACS - Offers authentication, accounting, and authorization. Authentication Protocol. MS-CHAP (MD4) - Uses a Microsoft version of RSA message digest 4 challenge and reply protocol. It only works on Microsoft systems and enables data encryption. Selecting this authentication method causes all data to be encrypted. SKID - SKID2 and SKID3 are vulnerable to a man in the middle attack. The Authentication Process Intentionally slow This makes exhaustive attack infeasible identify intruder from the normal user some who continuously fails to login may not be an authorized user. System disconnect a user after three to five failed logins Introduction PPP has three main components: 1. A method for encapsulating datagrams over serial links. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during Link Establishment phase. After the link has been established, PPP provides for an optional Authentication phase before proceeding to the Network-Layer Protocol phase. By default, authentication is not mandatory. If authentication of the link is desired, an implementation MUST specify the Authentication-Protocol Configuration Option during Link Establishment phase. Protocols to send passwords PAP - Password Authentication Protocol Used with Point to Point Protocol (PPP). The password is sent in the clear. CHAP - Challenge handshake authentication protocol is preferred rather than PAP since the actual password is not sent across the internet or network. Password Authentication Scenario 1 Client I need access Server Authenticate yourself I am “A”, password “QWERTY” “A” password “QWERTY”? Yes / No Access granted / denied Shared secret: password This scenario is not secure: password is sent in plaintext Used by PAP (Password Authentication Protocol) PAP Short for Password Authentication Protocol, the most basic form of authentication, in which a user's name and password are transmitted over a network and compared to a table of namepassword pairs. Typically, the passwords stored in the table are encrypted. The Basic Authentication feature built into the HTTP protocol uses PAP. The main weakness of PAP is that both the username and password are transmitted "in the clear" -- that is, in an unencrypted form PAP: Password Authentication Protocol RFC 1334 Password must be protected on both systems Susceptible to eavesdropping and replay attacks Serves as client authentication only: server could be an impostor PAP was developed for the Point-to-Point Protocol PPP Served well when connection was established on a dial-up line PPP connections can now be established over shared networks (such as Ethernet using PPPoE) • PAP is no longer used because considered not secure PPP Authentication Most manufacturers support both PPP authentication schemes –PAP: Password Authentication Protocol (RFC 1334) –CHAP: Challenge Handshake Authentication Protocol (RFC 1994) PAP uses a simple two-way handshake –Peer router/dial-up system repeatedly sends identifier/password to authenticator –Stops when password acknowledged or link cleared –Once password is established, no further authentication is required PAP identifier and password are sent as clear text PEER AUTH ID/password PAP authentication OK PAP PAP provides a simple method for the peer to establish its identity using a 2-way handshake. This is done only upon initial link establishment. After the Link Establishment phase is complete, an Id/Password pair is repeatedly sent by the peer to the authenticator until authentication is acknowledged or the connection is terminated. PAP is not a strong authentication method. Passwords are sent over the circuit "in the clear", and there is no protection from playback or repeated trial and error attacks. This authentication method is most appropriately used where a plaintext password must be available to simulate a login at a remote host. In such use, this method provides a similar level of security to the usual user login at the remote host. Packet Format Exactly one Password Authentication Protocol packet is encapsulated in the Information field of a PPP Data Link Layer frame where the protocol field indicates type hex c023 (Password Authentication Protocol). A summary of the PAP packet format is shown below. The fields are transmitted from left to right. 01230123456789012345678901234 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+| Peer-ID Length| Peer-Id ... | Passwd-Length | Password ... +-+-+-+-+-+-+-+-+-++-+-+-+ Code 1 for Authenticate-Request. Identifier The Identifier field is one octet and aids in matching requests and replies. The Identifier field MUST be changed each time an AuthenticateRequest packet is issued. Peer-ID-Length The Peer-ID-Length field is one octet and indicates the length of the Peer-ID field. Peer-ID The Peer-ID field is zero or more octets and indicates the name of the peer to be authenticated. Passwd-Length The Passwd-Length field is one octet and indicates the length of the Password field. Password The Password field is zero or more octets and indicates the password to be used for authentication. Authenticate-Ack and Authenticate-Nak Description If the Peer-ID/Password pair received in an Authenticate-Request is both recognizable and acceptable, then the authenticator MUST transmit a PAP packet with the Code field set to 2 (AuthenticateAck). If the Peer-ID/Password pair received in a Authenticate-Request is not recognizable or acceptable, then the authenticator MUST transmit a PAP packet with the Code field set to 3 (Authenticate- Nak), and SHOULD take action to terminate the link. A summary of the Authenticate-Ack and Authenticate-Nak packet format is shown below. PAP (cont.) IIT NAS Alice Protocol 0XC023=PAP Code 1 byte Information Identifier Length Host ID Size Padding ID = Alice, Password = ??? Authenticate-Ack or Authenticate-Nak Data Host ID Password Size Password Password Authentication Scenario 2 I am “A”, I need access Client Server CHAP Challenge: H6ty”1@!p Compute Response CHAP Response: Answer: 89it%-QkL Query “A”’s password Compute response CHAP Access granted / denied Match? Shared secret: password Challenge by B: randomly generated number Response by A: Hash of (Password + Random Challenge) Used by CHAP (Challenge Handshake Authentication Protocol) Challenge Handshake Authentication Protocol (CHAP) RFC 1994 CHAP protects against eavesdropping since password is never sent It also protects against replay attacks because a random number is used It is however vulnerable to dictionary and brute force attacks • Both the challenge and the response are visible Hash method used by CHAP is MD5 • RFC 1321 CHAP Authentication CHAP provides much stronger authentication than PAP –Uses three-way handshake 1.Authenticator sends challenge to peer 2.Peer responds with the secret –A value calculated with a one-way hash function »Known only to the two parties involved 3.Authenticator recalculates secret and compares with one received –If the values match, the authentication is acknowledged »Otherwise, the connection is terminated 4.Challenge can be re-issued at any time during call CHAP authentication challenge PEER secret Ack AUTH Challenge-Handshake Authentication Protocol Challenge-Handshake Authentication Protocol The ChallengeHandshake Authentication Protocol (CHAP) is used to periodically verify the identity of the peer using a 3-way handshake. This is done upon initial link establishment, and MAY be repeated anytime after the link has been established. After the Link Establishment phase is complete, the authenticator sends a "challenge" message to the peer. The peer responds with a value calculated using a "one-way hash" function. The authenticator checks the response against its own calculation of the expected hash value. If the values match, the authentication is acknowledged; otherwise the connection SHOULD be terminated. CHAP provides protection against playback attack through the use of an incrementally changing identifier and a variable challenge value. The use of repeated challenges is intended to limit the time of exposure to any single attack. The authenticator is in control of the frequency and timing of the challenges. This authentication method depends upon a "secret" known only to the authenticator and that peer. The secret is not sent over the link. This method is most likely used where the same secret is easily accessed from both ends of the link. CHAP Authentication The CHAP algorithm requires that the length of the secret MUST be at least 1 octet. The secret SHOULD be at least as large and unguessable as a well-chosen password. It is preferred that the secret be at least the length of the hash value for the hashing algorithm chosen (16 octets for MD5). This is to ensure a sufficiently large range for the secret to provide protection against exhaustive search attacks. The one-way hash algorithm is chosen such that it is computationally infeasible to determine the secret from the known challenge and response values. The challenge value SHOULD satisfy two criteria: 1uniqueness and 2-unpredictability. Each challenge value SHOULD be unique, since repetition of a challenge value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the challenge SHOULD exhibit global and temporal uniqueness. Each challenge value SHOULD also be unpredictable, least an attacker trick a peer into responding to a predicted future challenge, and then use the response to masquerade as that peer to an authenticator. Configuration A summary of the Authenticate-Request packet format is shown below. The fields are transmitted from left to right. 0123012345678901234567890 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value-Size | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name ... Packet Format Code 1 for Challenge; 2 for Response. Identifier The Identifier field is one octet.(A unit of data that consists of exactly 8 bits) The Identifier field MUST be changed each time a Challenge is sent. The Response Identifier MUST be copied from the Identifier field of the Challenge which caused the Response. Value-Size This field is one octet and indicates the length of the Value field. Value The Value field is one or more octets. The most significant octet is transmitted first. The Challenge Value is a variable stream of octets. The importance of the uniqueness of the Challenge Value and its relationship to the secret is described above. The Challenge Value MUST be changed each time a Challenge is sent. The length of the Challenge Value depends upon the method used to generate the octets, and is independent of the hash algorithm used. The Response Value is the one-way hash calculated over a stream of octets consisting of the Identifier, followed by (concatenated with) the "secret", followed by (concatenated with) the Challenge Value. The length of the Response Value depends upon the hash algorithm used (16 octets for MD5). Name The Name field is one or more octets representing the identification of the system transmitting the packet. There are no limitations on the content of this field. For example, it MAY contain ASCII character strings or globally unique identifiers in ASN.1 syntax. The Name should not be NUL. The size is determined from the Length field. Since CHAP may be used to authenticate many different systems, the content of the name field(s) may be used as a key to locate the proper secret in a database of secrets. This also makes it possible to support more than one name/secret pair per system. Description Description The Challenge packet is used to begin the ChallengeHandshake Authentication Protocol. The authenticator MUST transmit a CHAP packet with the Code field set to 1 (Challenge). Additional Challenge packets MUST be sent until a valid Response packet is received, or an optional retry counter expires. A Challenge packet MAY also be transmitted at any time during the Network-Layer Protocol phase to ensure that the connection has not been altered. The peer SHOULD expect Challenge packets during the Authentication phase and the Network-Layer Protocol phase. Whenever a Challenge packet is received, the peer MUST transmit a CHAP packet with the Code field set to 2 (Response). Whenever a Response packet is received, the authenticator compares the Response Value with its own calculation of the expected value. Based on this comparison, the authenticator MUST send a Success or Failure packet (described below). Success and Failure If the Value received in a Response is equal to the expected value, then the implementation MUST transmit a CHAP packet with the Code field set to 3 (Success). If the Value received in a Response is not equal to the expected value, then the implementation MUST transmit a CHAP packet with the Code field set to 4 (Failure), and SHOULD take action to terminate the link. CHAP (cont.) IIT NAS Alice ID, Random Number, IIT ID, Pwd, Random No. MD5 Hash response ID, Hash response, Alice Protocol 0xC223=CHAP Information ID, Pwd, Random No. Padding MD5 Hash Value, match? Code Identifier Length Value-Size Success or Failure Data Value Name About CHAP and PAP Both CHAP and PAP protocols were created to manage remote access users Low-level authentication: controls access to network resources First iteration: dial-up networking using Point-to-Point Protocol (PPP) New uses: • Wi-Fi using WEP security (Wired-Equivalent Privacy) • PPPoE (PPP over Ethernet, used for ADSL user authentication) Because of the decentralized nature of dial-up networks, a technology for central authentication is often required Remote Access Server Remote Access Server IP Network Authentication Server (central user database) RADIUS RFC 2865 Remote Authentication Dial-In User Service Three-party authentication • Client (supplicant), request access to the network • Authenticator is the supplicant’s first contact to the network – Ethernet switch – Wi-Fi Access point – PPP end-point • Authentication Server contains the user database and grants or denies access RADIUS Authenticator Client (Supplicant) IP Network Authentication Server RADIUS Scenario 1 Client (Requestor) Authenticator Authentication Server I am “A”, I need access CHAP Challenge CHAP Response RADIUS Access-Request RADIUS Access-Accept / Reject CHAP Success / Failure RADIUS Scenario 1 (cont.) The Authenticator challenges the client upon request and collects the Client’s response to the CHAP challenge The Authenticator sends to the Authentication Server the username, ID, random number and client response (CHAP MD5 hash) in the Access-Request packet The Authentication Server computes the MD5 hash using the ID, client’s password and random number and replies with an Access-Accept or an Access-Failure packet The Authenticator forwards the information to the client in the form of a CHAP Success or CHAP Failure packet RADIUS Scenario 2 Client (Requestor) Authenticator Authentication Server I am “A”, I need access RADIUS Access-Request RADIUS Access-Challenge CHAP Challenge CHAP Response RADIUS Access-Request RADIUS Access-Accept / Reject CHAP Success / Failure RADIUS Scenario 2 (cont.) The Authenticator, upon request, sends to the Authentication Server a RADIUS AccessRequest. • The password is set to a knowingly wrong value such as the string “empty” or “void” to prompt a challenge from the server The Authentication Server sends a RADIUS Access-Challenge packet which is forwarded to the client in the form of a CHAP Challenge The client responds using the normal CHAP method The rest of the procedure follows Scenario 1 Notes on RADIUS Scenarios 1 and 2 Why use one method or the other? In some cases, the Authenticator is programmed to take a load off the Authentication Server and will provide the CHAP Challenge itself In some other cases, it is better to have the Authentication Server provide challenges from a central location to assure uniqueness of challenges and prevent replay attacks • It is the case when the Authenticator is a wireless Access Point In both scenarios, the Authenticator and Authentication Server share a secret key that is used to further encrypt the information and prevent replay attacks on that segment RADIUS Remote Authentication Dial-In User Service (RADIUS) is a widely deployed protocol enabling centralized authentication, authorization, and accounting for network access. Originally developed for dial-up remote access, RADIUS is now supported by virtual private network (VPN) servers, wireless access points, authenticating Ethernet switches, Digital Subscriber Line (DSL) access, and other network access types. RADIUS is described in RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)," (IETF Draft Standard) and RFC 2866, "RADIUS Accounting" (Informational). Key features of RADIUS Client/Server Model A Network Access Server (NAS) operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers, and then acting on the response which is returned. RADIUS servers are responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user. A RADIUS server can act as a proxy client to other RADIUS servers or other kinds of authentication servers. Network Security Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. In addition, any user passwords are sent encrypted between the client and RADIUS server, to eliminate the possibility that someone snooping on an unsecure network could determine a user's password. RADIUS message types: Access-Request. Sent by a RADIUS client to request authentication and authorization for a network access connection attempt. Access-Accept. Sent by a RADIUS server in response to an Access-Request message. This message informs the RADIUS client that the connection attempt is authenticated and authorized. Access-Reject. Sent by a RADIUS server in response to an Access-Request message. This message informs the RADIUS client that the connection attempt is rejected. A RADIUS server sends this message if either the credentials are not authentic or the connection attempt is not authorized. Access-Challenge. Sent by a RADIUS server in response to an Access-Request message. This message is a challenge to the RADIUS client that requires a response. Accounting-Request. Sent by a RADIUS client to specify accounting information for a connection that was accepted. Accounting-Response. Sent by the RADIUS server in response to the Accounting-Request message. This message acknowledges the successful receipt and processing of the Accounting-Request message. Reference D. Denning, P. Denning, Certification of Programs for Secure Information Flow, CommACM, V20 N7, Jul 1977, pp. 504-513 J. Linn, Practical Authentication for Distributed Computing, Proc IEEE symp Security & Privacy, IEEE Comp Soc Press 1990, pp. 31-40 C. P. Pfleeger, Security in Computing, Prentice Hall, NJ, 1996 IPSec Authentication RFC 2401 and 2406 IPSec works at layer 3 of the OSI model to create secure tunnels Each encrypted packet in the tunnel contains authentication data to prove its origin End-to-end Node-to-node 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Data* (variable) | ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPSec protocol types IPSec has two types Transport mode: provides protection primarily for upper layer protocols, and is used for end to end communication between two hosts Tunnel mode: provides protection to the entire IP packet. Transport mode Transport mode provides the protection of an IP payload through an AH or ESP header. Typical IP payloads are TCP segments (containing a TCP header and TCP segment data), a UDP message (containing a UDP header and UDP message data), and an ICMP message (containing an ICMP header and ICMP message data). Authentication Header transport mode Authentication Header transport mode Authentication Header (AH) provides authentication, integrity, and anti-replay for the entire packet (both the IP header and the data payload carried in the packet). It does not provide confidentiality, which means that it does not encrypt the data. The data is readable, but protected from modification. AH uses keyed hash algorithms to sign the packet for integrity. For example, Alice on Computer A sends data to Bob on Computer B. The IP header, the AH header, and the data are protected with integrity. This means Bob can be certain it was really Alice who sent the data and that the data was unmodified. Integrity and authentication are provided by the placement of the AH header between the IP header and the IP payload Encapsulating Security Payload transport mode Encapsulating Security Payload (ESP) provides confidentiality (in addition to authentication, integrity, and anti-replay) for the IP payload. ESP in transport mode does not sign the entire packet. Only the IP payload (not the IP header) is protected. ESP can be used alone or in combination with AH. For example, Alice on Computer A sends data to Bob on Computer B. The IP payload is encrypted and signed for integrity. Upon receipt, after the integrity verification process is complete, the data payload in the packet is decrypted. Bob can be certain that it was Alice who sent the data, the data is unmodified, and no one else was able to read it. Virtual private networking with IPSec Tunneling is the entire process of encapsulation, routing, and decapsulation. Tunneling wraps, or encapsulates, the original packet inside a new packet. This new packet might have new addressing and routing information, which enables it to travel through a network. When tunneling is combined with data confidentiality, the original packet data (as well as the original source and destination) is not revealed to those listening to traffic on the network. The network could be any internetwork: a private intranet or the Internet. After the encapsulated packets reach their destination, the encapsulation is removed and the original packet header is used to route the packet to its final destination. The tunnel itself is the logical data path through which the encapsulated packets travel. To the original source and destination peer, the tunnel is usually transparent and appears as just another point-to-point connection in the network path. The peers are unaware of any routers, switches, proxy servers, or other security gateways between the tunnel’s beginning point and the tunnel’s end point. When tunneling is combined with data confidentiality, it can be used to provide a virtual private network (VPN). SSL and TLS RFC 2246 SSL is Secure Socket Layer • Developed by Netscape for secure web transactions TLS is Transport Layer Security • Developed by IETF to have an open standard similar to SSL They are essentially the same, with minor differences Both rely on use of digital certificates and PKI TLS/SSL Scenario 1 Hello Client Server Hello Server Certificate Request client Certificate Client Certificate Client Key Exchange Certificate Verify Change connection state TLS/SSL Scenario 1 Both the Server and the Client use certificates Examples: • Secure exchange of electronic data between two servers • Very secure organizational network where each user gets issued a certificate TLS/SSL Scenario 1 A Hello message is sent by the Client to notify the Server. The Hello message contains information about the protocols to be used for encryption and authentication. The Server replies with its own Hello message confirming that it supports the protocols asked by the Client • Hello messages contain randomly-generated numbers to assure liveness • The Server Hello message contains an ID which will be used to match the responses to the requests The Server sends its certificate to the Client, signed by a CA The Server also sends a certificate request to obtain the Client’s certificate After confirming that the Server certificate is valid, the Client sends its own certificate to the Server A Key Exchange value is sent by the Client. This value is encrypted using the Server’s public key to prevent eavesdropping. • This value will be used by both sides as a seed to compute a symmetric secret key between Client and Server The Certificate Verify message is sent by the Client to further prove its identity • It consists of a hash of all the messages sent and received so far, signed with the client’s secret key TLS/SSL Scenario 2 Hello Client Server Hello Server Certificate Server Authentication Client Key Exchange Change connection state Server Challenge Client Response Client Authentication TLS/SSL Scenario 2 Only the Server uses a certificate The Client is authenticated by the server using an encrypted password technique Examples: • Web e-commerce transactions • Web banking Kerberos Scenario part 1 Request Ticket, I am “A”, encrypted password Client Key Distribution Centre (KDC) Encrypted Ticket-Granting Ticket Authentication Service (AS) Client and server share a secret key The user enters a password which is encrypted using the secret key The ticket-granting ticket (TGT) is an encrypted document similar to a certificate • It is encrypted using the secret key • It contains data to establish a session key for later communications with the KDC Kerberos Scenario part 2 Request Ticket for C, this is my TGT Client Key Distribution Centre (KDC) Encrypted Ticket for C Ticket for C Ticket Granting Service (TGS) File or print service Client request a ticket to use C services The ticket-granting service (TGS) verifies the validity of the TGT and issues a ticket for C • The ticket is encrypted using the session key derived in step 1 • It contains a part only decipherable by C A will now present the ticket to C which will grant access to resources Notes on Kerberos The method is widely used and supported by manufacturers such as Microsoft The method can be susceptible to a dictionary attack since every subsequent step relies on the user entering the password in the first place Kerberos is not only Authentication but also Authorization • A request for a resource may be denied, even if a user is valid • Based on policies in place Conclusion Authentication is another critical step in security Separates the “good guys” from the “bad guys” If authentication is performed or bypassed by an attacker, the attacker will be considered by the system as a “good guy” • Very difficult to identify and expel Must be performed at the beginning of a transaction and subsequently at regular intervals Has mechanisms to prevent attacks: • Replay attacks • Password attacks (dictionary, brute-force) As security administrators, NEVER rely on authentication alone • Part of a greater security policy • Use authorization and intrusion detection