Authentication in Different Scenarios

Authentication in Different Scenarios

• 1.
  CS 521: DistributedSystems 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 distinctionsthat 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 isa 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