CS 542: Distributed Systems

Term Paper

Authentication Protocol in Different 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 Goswamiemail: dgoswami@iitg.ernet.in

Department of Computer Science and EngineeringIndian 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 distributedsystems, providing increased functionality to th the user and more efficient use of resources. To obtain thebenefits of such systems parties will cooperate by exchanging messages over networks. These parties may beusers, 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 ofother principals to make decisions on how to act. These decisions depend crucially on what validity can beassumed of messages that they receive. Loosely speaking, when we receive a message we want to be sure thatit has been created recently and in good faith for a particular purpose by the principal who claims to havesent it. We must be able to detect when a message has been created or modified by a malicious principal orintruder 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 distributessecrets to some of those principals or allows the use of some secret to be recognized. At the end of the protocolthe 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 principalis operational. They may then use this information to verify claims about subsequent communication, forexample, a received message encrypted with a newly distributed key must have been created after distributionof 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 werepublished. The Needham Schroeder Conventional Key Protocol was published in 1978 and became the basisfor many similar protocols in later years. In 1981, Denning and Sacco demonstrated that the protocol wasflawed and proposed an alternative protocol. This set the general trend for the field. The authors of bothpapers suggested other protocols based on public key cryptography. In 1994 Martin Abadi demonstrated thatthe public key protocol of Denning and Sacco was flawed. In 1995, Lowe demonstrated an attack on the publickey 5 protocol of Needham and Schroeder (seventeen years after its publication). In the intervening years awhole 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 beenused to analyse them. In addition, it provides a summary of the ways in which protocols have been foundto fail. There is a large amount of material in the field and the main body of this document is intended asa 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 futureeditions of this report will provide a complete coverage. An annotated bibliography is included to guide thereader. Since authentication relies heavily on encryption and decryption to achieve its goals we also providea 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 highestlevel we have categorised them according to the principal cryptographic approach taken, i.e. symmetric key orpublic key. We distinguish also between those that use (one or more) trusted third parties to carry out someagreed function and those that operate purely between two communicating principals that wish to achieve somemode of authentication. There are further distinctions that can be made: the number of messages involvedin the protocols (e.g. one-pass, two-pass, three-pass etc.) and whether one principal wishes to convince thesecond of some matter (one-way or unilateral authentication) or whether both parties wish to convince eachother 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 UnilateralAuthentication Protocol. It consists of the single message:

A→ B : Text2, E(Kab : [Ta|Na], B, Text1) (1)

Here the text fields shown are optional; their use is implementation specific (and we shall ignore themin this discussion). We can see that the claimant A (i.e. the one who wishes to prove something) sends anencrypted message containing a nonce and the identifier of the verifier (i.e. the principal to whom the claimis made). The nonce may be a time-stamp Ta or a sequence number Na depending on the capabilities of theenvironment and the communicating principals. On receiving this message, B, who believes that the key Kabis known only to himself and A, may deduce that A has recently sent this message if the sequence numberis appropriate or if the time-stamp has a recent value. Note here that if a malicious principal has unfetteredaccess 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 theresult 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 wereotherwise 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 responseto 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, sometimesnot; sometimes it is random, sometimes predictable(but never before user). Gong highlights many issuesassociated 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 issent 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 isdescribed as follows:

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

3

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

In this protocol A requests from the server S a key to communicate with B. He includes a random nonceNa 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 hepossesses the key Kas. In doing so he will obtain the key Kab and check that the message contains the nonceNa. 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 communicationwith A. He then generates a nonce Nb, encrypts it (using the newly obtained key), and sends the result to Aas message (4).

Principal A, who possesses the appropriate key Kab , decrypts it, forms Nb 1, encrypts it and sends theresult back to B as message (5). B decrypts this and checks the result is correct. The purpose of this exchangeis to convince B that A is genuinely operational (and that message 3 was not simply the replay of an oldmessage).

At the end of a correct run of the protocol, both principals should be in possession of the secret key Kabnewly generated by the server S and should believe that the other principal has the key. Rather, this is whatthe protocol is intended to achieve. People have shown that it is an fact falwed. Many other protocols thathave 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 : Na,A)(4)B → S : B,A(5)S → B : E(Ks−1 : Ka,A)(6)B → A : E(Ka : Na,Nb)(7)A→ A : E(Kb : Nb)

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 publickey and so can only be decrypted successfully by B. It contains a challenge Na together with A s identifier. Bdecrypts this to obtain the challenge, forms a challenge of his own Nb and encrypts both challenges under A spublic key and sends the result as message (6). A then decrypts message (6). Since only B could have obtainedthe information necessary to send this message A knows that B is operational and has just responded to hisrecent challenge. A then encrypts B s challenge Nb using Bs public key Kb and sends message (7). B thendecrypts and checks that it contains his challenge and concludes that A is operational and indeed initiatedthe 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 implentto allow in-teroperability) by the iSCSI specification. The iSCSI specification specifies requirements to makeCHAP effective against current security threats. Those same iSCSI specifications for CHAP usage are requiredby 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 withthe 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 hashalgorithms may be supported such as SHA-1.

Besides a shared secret, CHAP requires use of a challenge and a response to the challenge. A uniquechallenge value should be used each time by each initiator, to prevent reflection (i.e., playback) attacks. Whenboth entities authenticate each other it is called bidirectional authentication. Bi-directional authenticationshall 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, canbe 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 canbe 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 sendingthe secret over other links in the network, it is typical that the challenge and response values be examined ata central server, rather than each SAN attached device. If no central server is used, the secret shall be sent toeach Nx port in an encrypted form. Either case requires a trusted relationship. In addition, it is advisable tonot store the secret in plain text. A central server architecture to hold secrets would allow easier protectionof 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 KeyInfrastructure is based on the concept of asymmetric key cryptography. The PKI has two different types ofkeys.

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 theonly option to confirm User Authentication. There is a completely different technique called TESLA whichprovides 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 authenticatedsource of the message. In other words, we can describe TESLA as a lightweight broadcast authenticationmechanism. TESLA performs broadcast authentication mechanism in the same manner and applies the sameapproach 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 UniversalLogin in a variety of different ways. The selections that you, as a search appliance administrator, make byusing 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 thecorrect credentials for a content server, the content server redirects the search appliance to a login system forlog 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 cookieforwarding from the content server to the search appliance can provide silent authentication without a verifiedidentity, if the sample URL check passes. If you require a verified identity, then silent authentication can onlybe 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 meansof policy ACLs, SAML, or connectors. One way of getting a verified user name and/or group in addition tosilent 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 contentserver generates the following response HTTP headers in addition to the standard headers:X − Username : valueX −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 thatit 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 todecode the UTF-8 quoted-printable encoding. For example, the search appliance crawls the following content,

6

which contains special characters:

<html><head>

<meta http−equiv=”Content−Type” content=”text /html ; cha r s e t=UTF−8”><meta name=”goog le : a c l u s e r s ” content=”s p e c i a l ”/><meta name=”goog le : a c l u s e r s ” content=” ”/><meta name=”goog le : ac lg roups ” content=”s p e c i a l−group”/>

</head>

<body>Hel lo Man Wassup ! ! ˆ ˆ

</body></html>

Because the user ”special” and group ”special-group” include special characters, the following encodedheaders should be used:X − Username : sp = C3 = A9cial(forspecial)X −Groups : sp = C3 = A9cial − group(forspecial − group)

Because the user ”special” and group ”special-group” include special characters, the following encodedheaders should be used:X − Username : sp = C3 = A9cial(forspecial)X −Groups : sp = C3 = A9cial − group(forspecial − group)

5 Token Based Authentication

A token is a packet of data created by server, and contains information to identify a particular user and tokenvalidity. The token will contain the user’s information, as well as a special token code that user can pass to theserver 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 toa 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 asecurity 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 theservice 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 obtaina token which will allow them to access a specific resource on the server. Once the token has been obtainedfrom the server, user can offer this token to the server in subsequent requests (without passing username andpassword), 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 toidentify 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 templateis created and stored. During the verification phase, the same feature extraction algorithm is appliedto query biometric data, and the resulting query feature set is used to construct a query template. Thequery template is matched against the stored template(s) for authentication.

2. Principle: The conventional biometric authentication collects biometric data from an enrolling userand 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, theproposed approach selects a reference feature set (or extract a reference feature set from a ReferenceSubject) and computes the difference between the users feature set and the reference feature set, thenfrom the difference generates a Bio-Capsule to uniquely represent the enrolling user (as. In the vericationphase, a query biometric feature set from a user and the same reference feature set are used to generate aquery Bio-Capsule which is compared against the registered Bio-Capsule). If the registered Bio-Capsuleand 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 technologyfor 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