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 EngineeringIndian Institute of Technology, Guwahati

11th Nov, 2012

1

1 Introduction

The past two decades have seen an enormous increase int he development and use of networkedand distributed systems, providing increased functionality to th the user and more efficient use ofresources. To obtain the benefits of such systems parties will cooperate by exchanging messagesover networks. The parties may be users, hosts or processes, they are generally referred to asprincipals in authentication literature.

Principals use the messages received together with certain modelling assumptions about thebehaviour of other principals to make decisions on how to act. These decisions depend cruciallyon what validity can be assumed of messages that they receive. Loosely speaking, when wereceive a message we want to be sure that it has been created recently and in good faith for aparticular purpose by the principal who claims to have sent it. We must be able to detect whena message has been created or modified by a malicious principal or intruder with access to thenetwork or when a message was issued some time ago (or for a different purpose) and is currentlybeing replayed on the network.

An authentication protocol is a sequence of message exchanges between principals that eitherdistributes 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 thesystem; for example, that only certain principals have access to particular secret information(typically cryptographic keys) or that a particular principal is operational. They may thenuse this information to verify claims about subsequent communication, for example, a receivedmessage encrypted with a newly distributed key must have been created after distribution ofthat key and so is timely.

A considerable number of authentication protocols have been specified and implemented. Thearea is, however, remarkably subtle and many protocols have been shown to be flawed a long timeafter they were published. The Needham Schroeder Conventional Key Protocol was publishedin 1978 and became the basis for many similar protocols in later years. In 1981, Denning andSacco demonstrated that the protocol was flawed and proposed an alternative protocol. Thisset the general trend for the field. The authors of both papers suggested other protocols basedon public key cryptography. In 1994 Martin Abadi demonstrated that the public key protocolof Denning and Sacco was flawed [1]. In 1995, Lowe demonstrated an attack on the public key5 protocol of Needham and Schroeder (seventeen years after its publication). In the interveningyears a whole host of protocols have been specified and found to be flawed (as demonstrated inthis report).

This report describes what sorts of protocols have been specified and outlines what methodshave been used to analyse them. In addition, it provides a summary of the ways in whichprotocols have been found to fail. There is a large amount of material in the field and the mainbody of this document is intended as a concise introduction to and survey of the field. Sometypes 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 willprovide a complete coverage. An annotated bibliography is included to guide the reader. Sinceauthentication relies heavily on encryption and decryption to achieve its goals we also provide abrief 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 approachtaken, i.e. symmetric key or public key. We distinguish also between those that use (one ormore) trusted third parties to carry out some agreed function and those that operate purelybetween two communicating principals that wish to achieve some mode of authentication. There

2

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 secondof some matter (one-way or unilateral authentication) or whether both parties wish to convinceeach 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 KeyUnilateral Authentication 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 shallignore them in this discussion). We can see that the claimant A (i.e. the one who wishes to provesomething) 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 sequencenumber 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 ifthe time-stamp has a recent value. Note here that if a malicious principal has unfettered accessto the network medium then use of sequence numbers will be insufficient (since he can recordmessage (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-responsemechanisms. One principal A issues data to a second principal B. B then carries out sometransformation and sends the result to A who checks to see if the appropriate transformationhas occurred. Figure 1 shows a simple challenge-response protocol. In this case the nonceNa 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. WhenA genuinely issued the same nonce value at a later date the intruder could replay B s earlierresponse to complete the protocol. A could conclude only that the message he receives wascreated 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 usinga shard key.

3

2.2 Symmetric Key With Trusted Third Party

Symmetric key protocols that use a trusted third party (TTP) are by far the most numerousin the literature. The most celebrated protocol of all time, the Needham Schroeder SymmetricKey Authentication protocol is described as follows:

(1)A→ S : A,B,Na(2)S → A : E(Kas : Na,B,Kab,E(Kbs : Kab,A))(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 arandom nonce Na generated specially for this run of the protocol. This nonce will be used by Ato ensure that message (2) is timely. S creates a key Kab and creates message (2). Only A candecrypt this message successfully since he possesses the key Kas. In doing so he will obtain thekey Kab and check that the message contains the nonce Na. A passes on to B the encryptedmessage 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 forcommunication with A. He then generates a nonce Nb, encrypts it (using the newly obtainedkey), and sends the result to A as message (4).

Principal A, who possesses the appropriate key Kab , decrypts it, forms Nb 1, encrypts itand 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 message3 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 thesecret key Kab newly generated by the server S and should believe that the other principal hasthe key. Rather, this is what the protocol is intended to achieve. People have shown that itis an fact falwed. Many other protocols that have used a trusted third party to generate anddistribute keys in a similar way.

2.3 Public Key

Protocols using public key cryptography find numerous applications in authentication but thespeed of encryption and decryption using public key algorithms has prevented their widespreaduse for general communication; for example, Schneier states that RSA encryption is about 100times 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 encryptionkeys using public key cryptography provides an excellent use of the technology and several suchdistribution 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)

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 underits own private key Ks 1. The certification authoritys public key is generally assumed known to

4

the principals. Messages (1), (2) and (5), (6) are used by A and B to obtain each others publickeys. Message (3) is encrypted under B s public key and so can only be decrypted successfullyby B. It contains a challenge Na together with A s identifier. B decrypts this to obtain thechallenge, forms a challenge of his own Nb and encrypts both challenges under A s public keyand sends the result as message (6). A then decrypts message (6). Since only B could haveobtained the information necessary to send this message A knows that B is operational and hasjust responded to his recent challenge. A then encrypts B s challenge Nb using Bs public key Kband sends message (7). B then decrypts and checks that it contains his challenge and concludesthat A is operational and indeed initiated the protocol. This Protocol and reasoning above hasonly 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 MUSTimplent to allow in-teroperability) by the iSCSI specification. The iSCSI specification specifiesrequirements 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 isused as specified with the use of the ESP optional header. All secrets shall be machine generatedusing 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 besupported. 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 centralserver, 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 centralserver 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 andresponse values be examined at a central server, rather than each SAN attached device. If nocentral server is used, the secret shall be sent to each Nx port in an encrypted form. Either caserequires 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 informationstored.

5

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. ThePublic Key Infrastructure is based on the concept of asymmetric key cryptography. The PKIhas 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 asan authentication method for multi-cast and broadcast network communications. In VANETsystems, PKI is not the only option to confirm User Authentication. There is a completelydifferent 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 thesender was the authenticated source of the message. In other words, we can describe TESLA asa lightweight broadcast authentication mechanism. TESLA performs broadcast authenticationmechanism in the same manner and applies the same approach that is applied in the unicastauthentication 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 searchappliance 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 userdoes not have the correct credentials for a content server, the content server redirects the searchappliance to a login system for log in, then the login system’s server redirects the search applianceback 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 silentauthentication without a verified identity, if the sample URL check passes. If you require averified 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 username and/or group in addition to silent authentication is to configure the sample URL’s contentserver for cookie cracking.

6

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

where value becomes a verified identity for the credential group that is associated with thesample URL.

The effect of the response header is that it has ”cracked” open the cookie and revealed theusername and/or group. To use cookie cracking, the administrator of the content server mustmodify 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 headermust be encoded in UTF-8 as quoted-printable. When the search appliance receives the responseheader, it attempts to decode the UTF-8 quoted-printable encoding. For example, the searchappliance crawls the following content, 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>Some content

</body></html>

Because the user ”special” and group ”special-group” include special characters, the follow-ing encoded headers 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 follow-ing encoded headers 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 particularuser and token validity. The token will contain the user’s information, as well as a special tokencode that user can pass to the server with every method that supports authentication, insteadof passing a username and password directly.

7

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

An authentication is successful if a user can prove to a server that he or she is a valid user bypassing 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 theclient, 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 thetoken has been obtained from the server, user can offer this token to the server in subsequentrequests (without passing username and password), which offers access to a specific resource fora 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 extractedfrom users biometric data and a template is created and stored. During the vericationphase, the same feature extraction algorithm is applied to query biometric data, and theresulting query feature set is used to construct a query template. The query template ismatched against the stored template(s) for authentication.

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 templateis generated. Different from conventional biometric authentication approaches, duringthe enrolment phase, the proposed approach selects a reference feature set (or extract areference feature set from a Reference Subject) and computes the difference between theusers 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 querybiometric 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 registeredBio-Capsule and the query Bio-Capsule are within a certain distance, the user is successfullyauthenticated.

7 References

1. Biometric Based Authentication: a New Approach By Yan Sui, Xukai Zou and Yingzi Dut

8