Authentication in Different Scenarios

CS 542: Distributed Systems

Term Paper

Authentication Protocol in Diﬀerent Scenarios

By:

Rajkumar Singh (09010138) Abhinav Sonker(09010102)
email: s.rajkumar@iitg.ernet.in email:a.sonker@iitg.ernet.in

Under the Supervision of:

Professor Diganata Goswami
email: dgoswami@iitg.ernet.in

Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

11th Nov, 2012

1

1 Introduction
The last few decades have seen an enormous increase in the development and use of networked and distributed
systems, providing increased functionality to th the user and more efficient use of resources. To obtain the
benefits of such systems parties will cooperate by exchanging messages over networks. These parties may be
users, hosts or processes, they are generally referred to as principals in authentication literature.
Principals use the messages received together with certain modelling assumptions about the behaviour of
other principals to make decisions on how to act. These decisions depend crucially on what validity can be
assumed of messages that they receive. Loosely speaking, when we receive a message we want to be sure that
it has been created recently and in good faith for a particular purpose by the principal who claims to have
sent it. We must be able to detect when a message has been created or modified by a malicious principal or
intruder with access to the network or when a message was issued some time ago (or for a different purpose)
and is currently being replayed on the network.
An authentication protocol is a sequence of message exchanges between principals that either distributes
secrets to some of those principals or allows the use of some secret to be recognized. At the end of the protocol
the principals involved may deduce certain properties about the system; for example, that only certain princi-
pals have access to particular secret information (typically cryptographic keys) or that a particular principal
is operational. They may then use this information to verify claims about subsequent communication, for
example, a received message encrypted with a newly distributed key must have been created after distribution
of that key and so is timely.
A considerable number of authentication protocols have been specified and implemented. The area is,
however, remarkably subtle and many protocols have been shown to be flawed a long time after they were
published. The Needham Schroeder Conventional Key Protocol was published in 1978 and became the basis
for many similar protocols in later years. In 1981, Denning and Sacco demonstrated that the protocol was
flawed and proposed an alternative protocol. This set the general trend for the field. The authors of both
papers suggested other protocols based on public key cryptography. In 1994 Martin Abadi demonstrated that
the public key protocol of Denning and Sacco was flawed. In 1995, Lowe demonstrated an attack on the public
key 5 protocol of Needham and Schroeder (seventeen years after its publication). In the intervening years a
whole host of protocols have been specified and found to be flawed (as demonstrated in this report).
This report describes what sorts of protocols have been specified and outlines what methods have been
used to analyse them. In addition, it provides a summary of the ways in which protocols have been found
to fail. There is a large amount of material in the field and the main body of this document is intended as
a concise introduction to and survey of the field. Some types of protocol are given little detailed attention,
particularly those which rely on number-theoretic properties for their security. It is envisaged that future
editions of this report will provide a complete coverage. An annotated bibliography is included to guide the
reader. Since authentication relies heavily on encryption and decryption to achieve its goals we also provide
a brief review of elements of cryptography.

2 Protocol Types
In this section we provide an overview of various forms of authentication protocol in use today. At the highest
level we have categorised them according to the principal cryptographic approach taken, i.e. symmetric key or
public key. We distinguish also between those that use (one or more) trusted third parties to carry out some
agreed function and those that operate purely between two communicating principals that wish to achieve some
mode of authentication. There are further distinctions that can be made: the number of messages involved
in the protocols (e.g. one-pass, two-pass, three-pass etc.) and whether one principal wishes to convince the
second of some matter (one-way or unilateral authentication) or whether both parties wish to convince each
other of something (two-way or mutual authentication).

2

2.1 Symmetric Key Without Trusted Third Party
Perhaps the simplest(and yet effective) example in this class is the ISO One-pass Symmetric Key Unilateral
Authentication Protocol. It consists of the single message:

A → B : T ext2, E(Kab : [T a|N a], B, T ext1) (1)
Here the text fields shown are optional; their use is implementation specific (and we shall ignore them
in this discussion). We can see that the claimant A (i.e. the one who wishes to prove something) sends an
encrypted message containing a nonce and the identifier of the verifier (i.e. the principal to whom the claim
is made). The nonce may be a time-stamp Ta or a sequence number Na depending on the capabilities of the
environment and the communicating principals. On receiving this message, B, who believes that the key Kab
is known only to himself and A, may deduce that A has recently sent this message if the sequence number
is appropriate or if the time-stamp has a recent value. Note here that if a malicious principal has unfettered
access to the network medium then use of sequence numbers will be insufficient (since he can record message
(1), prevent B from receiving it, and replay it to B at a later time).
The best-known protocols that do not use a trusted third party are simple challenge-response mechanisms.
One principal A issues data to a second principal B. B then carries out some transformation and sends the
result to A who checks to see if the appropriate transformation has occurred. Figure 1 shows a simple challenge-
response protocol. In this case the nonce Na should be random. If the nonce were a sequence number, or were
otherwise predictable, a malicious principal could issue the next nonce value to B and record the response.
When A genuinely issued the same nonce value at a later date the intruder could replay B s earlier response
to complete the protocol. A could conclude only that the message he receives was created at some time by B
(but not necessarily in response to his most recent challenge).

Figure 1: Challenge Response Protocol

There are other variations on the challenge-response theme. Sometimes the challenge is encrypted, sometimes
not; sometimes it is random, sometimes predictable(but never before user). Gong highlights many issues
associated with the use of nonces for such purposes.
The ISO Two-Pass Unilateral Authentication Protocol is described later in this document. The ISO Two-
and Three-Pass Mutual Authentication Protocols are described in further sections.
Another approach to ensuring authenticity uses cryptographic check functions. Essentially, a message is
sent together with some summary or digest calculated using a hash function using a shard key.

2.2 Symmetric Key With Trusted Third Party
Symmetric key protocols that use a trusted third party (TTP) are by far the most numerous in the literature.
The most celebrated protocol of all time, the Needham Schroeder Symmetric Key Authentication protocol is
described as follows:

(1)A → S : A, B, N a
(2)S → A : E(Kas : N a, B, Kab, E(Kbs : Kab, A))

3

(3)A → B : E(Kbs : Kab, A)
(4)B → A : E(Kab : N b)
(5)A → B : E(Kab : N b − 1)

In this protocol A requests from the server S a key to communicate with B. He includes a random nonce
Na generated specially for this run of the protocol. This nonce will be used by A to ensure that message (2)
is timely. S creates a key Kab and creates message (2). Only A can decrypt this message successfully since he
possesses the key Kas. In doing so he will obtain the key Kab and check that the message contains the nonce
Na. A passes on to B the encrypted message component E(Kbs : Kab A) as message (3).
Principal B decrypts this message to discover the key Kab and that it is to be used for communication
with A. He then generates a nonce Nb, encrypts it (using the newly obtained key), and sends the result to A
as message (4).
Principal A, who possesses the appropriate key Kab , decrypts it, forms Nb 1, encrypts it and sends the
result back to B as message (5). B decrypts this and checks the result is correct. The purpose of this exchange
is to convince B that A is genuinely operational (and that message 3 was not simply the replay of an old
message).
At the end of a correct run of the protocol, both principals should be in possession of the secret key Kab
newly generated by the server S and should believe that the other principal has the key. Rather, this is what
the protocol is intended to achieve. People have shown that it is an fact falwed. Many other protocols that
have used a trusted third party to generate and distribute keys in a similar way.

2.3 Public Key
Protocols using public key cryptography find numerous applications in authentication but the speed of encryp-
tion and decryption using public key algorithms has prevented their widespread use for general communication;
for example, Schneier states that RSA encryption is about 100 times slower than DES when both are imple-
mented in software (the fastest hardware implementation of RSA has a throughput of 64 Kbaud). However,
exchanging symmetric encryption keys using public key cryptography provides an excellent use of the tech-
nology and several such distribution schemes have been created.
Needham and Schroeder proposed the following protocol in their classic work:
(1)A → S : A, B
(2)S → A : E(Ks−1 : Kb, B)
(3)A → B : E(Kb : N a, A)
(4)B → S : B, A
(5)S → B : E(Ks−1 : Ka, A)
(6)B → A : E(Ka : N a, N b)
(7)A → A : E(Kb : N b)

The certification authoritys public key is generally assumed known to the principals. Messages (1), (2) and
(5), (6) are used by A and B to obtain each others public keys. Message (3) is encrypted under B s public
key and so can only be decrypted successfully by B. It contains a challenge Na together with A s identifier. B
decrypts this to obtain the challenge, forms a challenge of his own Nb and encrypts both challenges under A s
public key and sends the result as message (6). A then decrypts message (6). Since only B could have obtained
the information necessary to send this message A knows that B is operational and has just responded to his
recent challenge. A then encrypts B s challenge Nb using Bs public key Kb and sends message (7). B then
decrypts and checks that it contains his challenge and concludes that A is operational and indeed initiated
the protocol. This Protocol and reasoning above has only recently been shown to be flawed.

4

2.4 Challenge Handshake Authentication Protocol
This is a secret key authentication method. This method of authentication is required (a MUST implent
to allow in-teroperability) by the iSCSI specification. The iSCSI specification specifies requirements to make
CHAP effective against current security threats. Those same iSCSI specifications for CHAP usage are required
by Fibre Channel interfaces.

When CHAP is performed over a non-encrypted channel, it is vulnerable to an offline dictionary attack.
Implementations shall support shared secrets of at least 96 bits unless encryption is used as specified with
the use of the ESP optional header. All secrets shall be machine generated using random generation techniques.

The secret should be at least the length of the hash value for the hashing algorithm chosen. Therefore,
when using MD5 the shared secret shall be at least 128 bits long. MD5 shall be supported. Other hash
algorithms may be supported such as SHA-1.

Besides a shared secret, CHAP requires use of a challenge and a response to the challenge. A unique
challenge value should be used each time by each initiator, to prevent reflection (i.e., playback) attacks. When
both entities authenticate each other it is called bidirectional authentication. Bi-directional authentication
shall be supported.

2.4.1 Switch to Switch
Secrets shall be sent in an encrypted form when transmitted over a link. Alternatively, a central server, can
be used to examine all challenge and response values.

2.4.2 Nx Port to Fabric
Secrets shall be sent in an encrypted form when transmitted over a link. Alternatively, a central server can
be used to examine all challenge and response values.

2.4.3 Nx port to Nx port
CHAP requires the secret be available in plain text form to the challenger or a central server. To avoid sending
the secret over other links in the network, it is typical that the challenge and response values be examined at
a central server, rather than each SAN attached device. If no central server is used, the secret shall be sent to
each Nx port in an encrypted form. Either case requires a trusted relationship. In addition, it is advisable to
not store the secret in plain text. A central server architecture to hold secrets would allow easier protection
of the information stored.

3 Authentication in vehicular ad hoc networks
3.1 Public Key Infrastructure (PKI)
The Public Key Infrastructure is widely used in VANET systems to ensure user validity. The Public Key
Infrastructure is based on the concept of asymmetric key cryptography. The PKI has two different types of
keys.
1 Public Key.
2 Private Key.

5

3.2 TESLA
TESLA is an acronym for ”Timed Efficient Stream Loss-Tolerant Authentication. It is used as an authen-
tication method for multi-cast and broadcast network communications. In VANET systems, PKI is not the
only option to confirm User Authentication. There is a completely different technique called TESLA which
provides an efficient alternative to signatures.

Instead of using Asymmetric Cryptography, TESLA uses symmetric cryptography with delayed key disclo-
sure (which provides the necessary element of ”asymmetry”) to prove that the sender was the authenticated
source of the message. In other words, we can describe TESLA as a lightweight broadcast authentication
mechanism. TESLA performs broadcast authentication mechanism in the same manner and applies the same
approach that is applied in the unicast authentication mechanism.

4 Cookie-Based Authentication Scenarios
Different organizations set up cookie-based authentication rules for the Google Search Appliance’s Universal
Login in a variety of different ways. The selections that you, as a search appliance administrator, make by
using the Admin Console depend on your system’s capabilities and your organization’s requirements.

For example, an organization might have a relatively simple system where, when a user does not have the
correct credentials for a content server, the content server redirects the search appliance to a login system for
log in, then the login system’s server redirects the search appliance back to the content server after login.

4.1 Silent Authentication
With silent authentication, users are authenticated without being directed to a login page. Inbound cookie
forwarding from the content server to the search appliance can provide silent authentication without a verified
identity, if the sample URL check passes. If you require a verified identity, then silent authentication can only
be achieved with cookie cracking.

4.1.1 Cookie Cracking
Your system might require a verified user name and/or group, for example to use with authorization by means
of policy ACLs, SAML, or connectors. One way of getting a verified user name and/or group in addition to
silent authentication is to configure the sample URL’s content server for cookie cracking.

With cookie cracking, if a sample URL check for user credentials is successful, the sample URL’s content
server generates the following response HTTP headers in addition to the standard headers:
X − U sername : value
X − Groups : value1, value2

where value becomes a verified identity for the credential group that is associated with the sample URL.
The effect of the response header is that it has ”cracked” open the cookie and revealed the username
and/or group. To use cookie cracking, the administrator of the content server must modify the server so that
it returns the appropriate response header

4.2 Using Quoted-Printable Encoding in Response Headers
If special characters are used in an X-Groups or X-Username HTTP response header, the header must be en-
coded in UTF-8 as quoted-printable. When the search appliance receives the response header, it attempts to
decode the UTF-8 quoted-printable encoding. For example, the search appliance crawls the following content,

6

which contains special characters:

<html>
<head>
<meta http−e q u i v=”Content−Type” c o n t e n t=” t e x t / html ; c h a r s e t=UTF−8”>
<meta name=”g o o g l e : a c l u s e r s ” c o n t e n t=” s p e c i a l ”/>
<meta name=”g o o g l e : a c l u s e r s ” c o n t e n t=” ”/>
<meta name=”g o o g l e : a c l g r o u p s ” c o n t e n t=” s p e c i a l −group”/>
</head>

<body>
H e l l o Man Wassup ! ! ˆ ˆ
</body>
</html>
Because the user ”special” and group ”special-group” include special characters, the following encoded
headers should be used:
X − U sername : sp = C3 = A9cial(f orspecial)
X − Groups : sp = C3 = A9cial − group(f orspecial − group)

Because the user ”special” and group ”special-group” include special characters, the following encoded
headers should be used:
X − U sername : sp = C3 = A9cial(f orspecial)
X − Groups : sp = C3 = A9cial − group(f orspecial − group)

5 Token Based Authentication
A token is a packet of data created by server, and contains information to identify a particular user and token
validity. The token will contain the user’s information, as well as a special token code that user can pass to the
server with every method that supports authentication, instead of passing a username and password directly.

Token-based authentication is a security technique that authenticates the users who attempt to log in to
a server, a network, or some other secure system, using a security token provided by the server.

An authentication is successful if a user can prove to a server that he or she is a valid user by passing a
security token. The service validates the security token and processes the user request.

After the token is validated by the service, it is used to establish security context for the client, so the
service can make authorization decisions or audit activity for successive user requests.

User passes their username and password to the server for the first time for authentication, and to obtain
a token which will allow them to access a specific resource on the server. Once the token has been obtained
from the server, user can offer this token to the server in subsequent requests (without passing username and
password), which offers access to a specific resource for a time period i.e. till the token expires.

6 Biometric Authentication
1. Introduction: Biometrics is a technology which uses physiological or behavioural characteristics to
identify or verify a person. Typical characteristics used for authentication include fingerprint, face, and

7

iris. A conventional biometric authentication system consists of two phases: enrolment and verification.
During the enrolment phase, a biometric feature set is extracted from users biometric data and a template
is created and stored. During the verification phase, the same feature extraction algorithm is applied
to query biometric data, and the resulting query feature set is used to construct a query template. The
query template is matched against the stored template(s) for authentication.

2. Principle: The conventional biometric authentication collects biometric data from an enrolling user
and extracts a biometric feature set from the biometric data; from the feature set a template is gener-
ated. Different from conventional biometric authentication approaches, during the enrolment phase, the
proposed approach selects a reference feature set (or extract a reference feature set from a Reference
Subject) and computes the difference between the users feature set and the reference feature set, then
from the difference generates a Bio-Capsule to uniquely represent the enrolling user (as. In the verication
phase, a query biometric feature set from a user and the same reference feature set are used to generate a
query Bio-Capsule which is compared against the registered Bio-Capsule). If the registered Bio-Capsule
and the query Bio-Capsule are within a certain distance, the user is successfully authenticated.

7 References
1. Biometric Based Authentication: a New Approach By Yan Sui, Xukai Zou and Yingzi Dut, at Proceed-
ings of 20th International Conference On Computer Communications and Networks, August 2011.
2. A survey on securing user authentication in vehicular ad hoc networks by Mrs. Arzoo Dahiya and Mr.
Vaibhav Sharma at National Conference on Recent Drifts, Break in ’Applied Sciences and its technology
for Innovation Management (NCRDBAIM)’.

3. http://developers.google.com/searchappliance/documentation/68/secure_search/secure_search_
cookieauthscenarios
4. http://developergeeks.com/article/18/introduction-to-token-based-authentication

8

Authentication in Different Scenarios

More Related Content

What's hot (17)

Viewers also liked (14)

Similar to Authentication in Different Scenarios (20)

Recently uploaded (20)

Authentication in Different Scenarios