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