Different types of Authentications described in different scenarios. Basically a survey paper on authenitcations.

1. CS 521: Distributed Systems
Term Paper
Authentication Protocol in Different Scenarios
By:
Rajkumar Singh (09010138) Abhinav Sonker(09010102)
email: s.rajkumar[*]iitg.ernet.in a.sonker[*]iitg.ernet.in
Under the Supervision of:
Professor Diganata Goswami
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati
11th Nov, 2012
1

2. 1 Introduction
The past two decades have seen an enormous increase int he 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. The 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 principals 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 [1]. 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
2

3. 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.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 en-
crypted, 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.
3

4. 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)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 encryption 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 implemented in software (the fastest hardware imple-
mentation of RSA has a throughput of 64 Kbaud). However, exchanging symmetric encryption
keys using public key cryptography provides an excellent use of the technology 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)
Here, we see how use is made of a trusted server S, generally called a certification authority,
that stores the public keys of the various principals and distributes them on request sealed under
its own private key Ks 1. The certification authoritys public key is generally assumed known to
4

5. 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.
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 spec-
ifications for CHAP usage are required by Fibre Channel interfaces.
When CHAP is performed over a non-encrypted channel, it is vulnerable to an offline dictio-
nary 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 authen-
tication. 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.
5

6. 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.
3.2 TESLA
TESLA is an acronym for ”Timed Efficient Stream Loss-Tolerant Authentication. It is used as
an authentication 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 de-
layed key disclosure (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 Appli-
ance’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 capabili-
ties 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. In-
bound 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 autho-
rization 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.
6

7. 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 encoded 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, 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>
Some c o n t e n t
</body>
</html>
Because the user ”special” and group ”special-group” include special characters, the follow-
ing 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 follow-
ing 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.
7

8. 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 re-
quests.
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
Introduction: Biometrics is a technology which uses physiological or behavioural characteristics to iden-
tify or verify a person. Typical characteristics used for authentication include ngerprint,
face, and iris. A conventional biometric authentication system consists of two phases: en-
rolment and verication. During the enrolment phase, a biometric feature set is extracted
from users biometric data and a template is created and stored. During the verication
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.
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 generated. 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
8