WO2008010003A1

WO2008010003A1 - Secure password-based authentication and key distribution protocol with robust availability properties

Info

Publication number: WO2008010003A1
Application number: PCT/IB2006/001942
Authority: WO
Inventors: Kapaleeswaran Viswanathan
Original assignee: Abb Research Ltd.
Priority date: 2006-07-14
Filing date: 2006-07-14
Publication date: 2008-01-24

Abstract

The invention provides a simple, efficient and secure password-based entity authentication and key distribution protocol. The protocol is ideally suited for use in systems where the authentication server is housed in resource-constrained computing systems such as embedded systems, while the authenticating client may be housed in less resource- constrained environments, such as on laptops or personal computers. The server process (32) and the client process (39) are connected via an insecure network communication channel (40) and the server (32) communicates with a data repository (31 ). The password verifier (35) within the server process (32) and the password prover (36) within the client process (39) communicate directly with each other to implement the authentication protocol.

Description

SECURE PASSWORD-BASED AUTHENTICATION AND KEY DISTRIBUTION PROTOCOL WITH ROBUST AVAILABILITY PROPERTIES

FIELD OF THE INVENTION

The present invention relates to data processing systems. More specifically, the present invention relates to data processing systems requiring password authentication to access data or functions in various entities, said entities being connected by a network.

BACKGROUND OF THE INVENTION

DISCUSSION OF PRIOR ART

Ih networked computer environments where there are a number of clients, each accessing one or more servers, the need for some form of authentication and consequently, key-distribution is obviated. The servers typically provide the client with access to some data or function that resides on them, or any entity that they have direct access to. Authenticating the clients that request that data or service is essential, in order to prevent unauthorized use of the server's services. One way for a client to prove its identity is by means of a password, which is an established and human- memorizable secret between the client and the server. Typically, when passwords are communicated over the network, encryption and one-way functions are used to protect their secrecy during transmission. Encryption is provided by cryptographic algorithms, which typically use one or more cryptographic keys, which are not human-memorizable for security reasons, to transform plaintext into ciphertext and vice versa. Cryptographic keys are essentially the secret identifiers without the knowledge of which, it would be impossible to render meaning to the information being exchanged. Protecting and distributing these keys in a secure manner is another design consideration in authentication systems. Key distribution techniques themselves can be based on passwords established between the key distribution center (which acts as a server with access to data, in this case keys) and the entity requiring the keys.

Public key cryptography is a branch of cryptography, which allows secure communication amongst entities without requiring prior access to a shared secret key. This is realized by using a pair of mathematically related cryptographic keys consisting of a public key and a private key. One-way functions are used in public-key cryptography, which are usually based on mathematically intractable problems. Such mathematical-intractability based one-way functions are invariably computationally expensive when compared to un-keyed one-way functions such as hash functions. The present state-of-art of public key cryptography is limited to using mathematical-intractability based one-way functions in order to still work

Prominent earlier solutions to password-based authentication and key exchange have used public key algorithms, such as the Diffie-Hellman key exchange protocol. The use of public key algorithms by servers makes them susceptible to Denial-of-Service attacks, which are attacks on networked computer systems that lead to a loss of network connectivity and access to services. A Denial-of-Service attack is launched by overloading the bandwidth available for the intended victim network or by overloading the victim's computational or memory resources. The previous protocol system designs based on prior art, such as Bellare et. al [1, 2, 3 & 4] assume the client systems to be more resource constrained than the server. They also use public key cryptography whose operations are computationally heavy and, therefore, the use of public key algorithms open up the server to more denial of service threats, whereas the protocol proposed in the present invention does not. The prior art does not have Denial of Service mitigation as an integral design goal.

Password protection for high reliability computer systems does not specify the use of hash functions to reduce Denial of Service attacks or a two-shot protocol run [5]. The goal is for high reliability computer systems and not for embedded systems, such as industrial controllers, which possess acute resource constraints. Another method for two-party authentication and key agreement uses cryptography but talks about the use of encryption functions and does not talk about denial-of-service mitigation. The proposed protocol does not use encryption technologies, it only uses a simple hash function in conjunction with the XOR operation [6]. Authentication protocols seeking to provide information security typically endeavor to achieve three goals:

1. (Confidentiality) Ensuring that information is accessible only to those authorized to have access [7].

2. (Integrity) Protection against unauthorized modification or destruction of information [8].

3. (Availability) Timely, reliable access to data and information services for authorized users. Cryptography techniques provide means to achieve the first two goals of confidentiality and integrity. Although, there are cryptology protocols to achieve the first two goals, namely confidentiality and integrity, known protocols do not aim to realize a balance between the first two goals, on one hand, and the third goal, on the other.

SUMMARY OF THE INVENTION

It is an object of the present invention is to provide a simple, efficient, and secure password-based entity authentication and key distribution protocol achieving three information security goals i.e. confidentiality, integrity and availability. The protocol is ideally suited for use in systems where the authentication server is housed in resource-constrained computing systems, such as embedded systems, while the authenticating client may be housed in less resource-constrained environments, such as on laptops or personal computers. The novelty of the present invention is its assumption for a resource constrained server and a less resource-constrained client, which is a reversal of what is usually assumed by most protocol systems designs.

To illustrate a resource constrained authentication server, the present invention proposes to use an automation controller for example, ABB's AC800M, with the authenticating client being housed in a resource-unconstrained environment, such as personal computing machines. Examples of these include ones using smaller microprocessors found on a variety of intelligent gadgets, embedded business equipment such as printers and fax machines, personal devices such as watches or TVs, home appliances such as fridges or home security systems, laptops or personal computers. Due to its unique design assumption, the protocol of the present invention can be implemented in both systems where client platforms are more powerful than server platforms as well as in systems where server platforms are more powerful than client platforms.

The current protocol is implemented in a client-server environment, where communication occurs over an insecure network channel. The client and server processes, more generically referred to as the password prover and password verifier respectively, perform a series of operations to authenticate the identity presented by the password prover. These steps are summarized below:

1. The password prover accepts a password from a specific user. 2. The password prover generates a commitment to present to the password verifier.

3. The password verifier receives the commitment and generates a challenge for the password verifier based upon the password stored in an internal database for that specific user. 4. The password prover goes on to generate a response to satisfy the challenge raised in the previous step.

5. The password verifier verifies the response sent by the password prover.

6. The password verifier further goes on to accept the identity presented by the password prover or reject the same, if the response does not verify correctly.

The protocol of the present invention is novel since it works well hi a resource-constrained server environment. The normal assumptions about a resource rich server need not hold when this protocol is used. Further, the protocol is computationally optimized to achieve the goal of working in a resource constrained server environment.

The following terms are used in this specification and, unless otherwise specified or clear from the context, the terms have the meanings provided below:

Secure hash function: A secure hash function, y = h (x), is a one-way function (given y is shall be difficult to find x) and a collision-resistant function (given x find x' and y such that y = h (x)= H (XT)).

The symbol || specifies a string concatenation operation and the symbol ©represents the bit-wise XOR operation. Sid specifies a unique and random session identification number generated by the server.

The present invention provides confidentiality and integrity services for the server as well as denial-of-service resilience and, thereby, providing robust availability properties. That is, entities cannot be denied access to the password prover or authentication service. The proposed protocol achieves the following properties: 1. The protocol prevents eavesdropping entities from performing effective dictionary attacks. That is, the eavesdropping entities cannot learn the value of the password that the client is trying to prove to the server even after reading all protocol conversations between the client and the server.

2. The protocol provides a realization for an authentication server that is resilient to Denial-of-Service attacks. 3. The protocol uses simple modulo addition operations along with a suitable cryptographic function, such as a hash function.

4. The protocol uses three successful protocol communications between the client and the server to complete the authentication.

5. The protocol extends the authentication facility to establish a set of fresh and secure session keys between the client and the server for future use.

6. Since the protocol is independent of the communication protocol, the protocol can be realized using any communication protocol, such as TCP/IP or HTTP.

The described invention is planned for use in automation controllers used by manufacturing plants and the like, for example ABB's AC800M and AC800Web.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 illustrates the overall layout of the system

Fig. 2 is a flowchart depicting flow of control between the authenticating entities Fig. 3 shows the detailed two shot protocol

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring to Fig. 1, a client/server environment where the present invention might be applied is shown. A network topology 40, which may be comprised of a LAN and interconnected to a global network, such as the Internet, acts as a conduit for a server process 32 and a client process 39. Within the server process resides a messaging service 33 which assists the server application logic to send and receive messages to the respective clients, a message security service 34 which uses the secret keys generated by the password verifier to provide confidentiality and integrity services to the data communicated through the messaging services, and a password verifier 35. Within the client process resides a password prover 36, a message security service 37 which uses the secret keys generated by the password prover to provide confidentiality and integrity services to the data communicated through the messaging services and a messaging service 38 which assists the user in sending and receiving messages to and from the server application logic (such as a control logic on a Controller). The password verifier 35 and the password prover 36 communicate directly with each other to implement the authentication protocol.

The server process 32 talks to a central data repository 31, which maintains information about clients and their associated passwords. This information is maintained in an identification file 30. The entries that is required to be stored in the identification file for the password authentication system is user name and the corresponding password.

This invention provides a simple and efficient password-based entity authentication and key distribution protocol comprising of the processes detailed below, which are undertaken by the Password Prover 36 and the Password Verifier 35, shown in Fig. 2: a. Get Password (11,22) The password prover gets the password from the end user while the password verifier waits for the commitment derived from the password to be sent to it by the prover 36; b. Generate Commitment (12) involves selecting two n-bit random numbers, namely S₁ and r_t followed by computation of pi which is equal to h(si\\password\\u\\server-name), where the string concatenation operation is specified by the symbol ||, the symbol u specifies the user name, the shared secret string, the possession of which has to be proved, is specified by the word password, and the symbolic name of the server is represented by server-name.

The commitment C₁ which is equal to ( pi Φ r_} ), is sent to the password verifier by the password prover along with S₁; c. Wait (21) waits for the password prover to send (si, C₁, u, server-name); d. Generate Challenge (23) On receiving the information (S₁, C₁, u, server-name) from the password prover 36 and the password (password) corresponding to u from 22, the password verifier retrieves the password corresponding to the user name, u, selects two n-bit random numbers, namely: s₂ and r₂ , computes p₂ which is equal to h(sid\\s₂\\password\\server-name\\u), and c₂ which is equal to (p₂ θ r₂); e. Wait for Challenge (13) waits for the password verifier to send (sid,s₂, c₂, server-name, u) to the password prover. The password prover may generate a Timeout 16 if it does not receive a message from the password verifier within a given time interval; f. Generate Response (14) On receiving the information from 13, the password prover computes p₂ which is equal to ΛC«c?||5₂||pαs₁yword|| server-name\\u); r₂ which is equal to (c₂ Θp₂)_> and, r, which is equal to

Φ r₂))). The password prover sends (sid, r) to the password verifier; g. Wait for Response (24) waits for the password prover to send (sid, r) to the password verifier. The verifier may generate Timeout 25 if it does not receive a message from the password prover within a given time interval; h. Timeout (16, 25) The password prover and verifier are asynchronously executing and communicating programs. It is possible due to network congestion or program crash or intentional protocol aborts, that a protocol run is initiated but not completed. Li order to free the resources of the protocol partner, which could be the password prover or the password verifier, timeout conditions are specified. The precise timeout duration can be application as well as network specific; i. Verify Response (26) On receiving the information from 24, from the password prover, the password verifier verifies the validity of sid and performs computation of pi which is equal to h(sl\\password\\u\\server-name), rl which is equal to (cl Φpl) and r' which is equal to truncate(h(sid\\(rl Θ r2))) followed by the verification if r equal to r' and communicates if the login was successful or failed; j. Wait for Reply (15) The password prover waits for the response generated as a result of 26, which indicates whether or not the log-in was successful. The password prover may generate a Timeout 16 if it does not receive a message from the password verifier, in a given time interval; k. Accepted (17,27) When the password verifier accepts the presented identity of the password prover, they reach the accepted state individually.

1. Rejected (18,28) When the password verifier rejects the presented identity of the password prover, they reach the rejected state individually; m. Generate Secret Session Key (19,29) The prover and the verifier independently compute the secret session key as follows: Kl which is equal to h(cl\\r2) and K₂ which is equal to Mc₂Wr₁);

The steps in the Generate Commitment 12 and Generate Challenge 23 phases of the authentication protocol, shown in Fig. 2 uses a Pseudo Random Number Generator (PRNG) 41,42 to generate two random numbers. These random numbers are further used in conjunction with a user-name (in the client process 39) or a session id (sid, in the server process 32), to generate the information to be sent out to the password verifier 35 and the password prover 36, respectively, as shown in Fig. 1. Any known secure PRNG can be used in the proposed invention. Scenario description: Every client (prover) shares a secret password with the server (verifier). The password is considered to be a low entropy information and, therefore, easily predictable. Clients wish to prove the possession of a shared password to a server without revealing any information about the password to the server during the process of such a proving exercise. Only if the server knows the shared password can it verify the proof correctly. System settings: The server chooses a secure hash function h:{0,l}* —> {0,1}", which means that h is a function that maps binary strings of arbitrary size (*) to binary strings of size n. The server sets up a function truncate: {0,1}" →{0,l}^n/2 _i which discards the last n/2 bits from its input to produce its output For security reasons, n/2 must be greater than or equal to 80. All clients must use the hash function selected by the server in the proof exercise. The server and the clients are assumed to have access to a secure Pseudo-Random Number Generator (PRNG).

Protocol Description: The client and the server engage in the following four-pass protocol as shown in Fig. 3.

1. Generate Commitment (43): The client has to commit the password, of which possession is to be proved, without revealing it. The client performs the following operations. a. Choose two re-bit random numbers, namely: S₁ and rj b. Compute: pi = h(sj\\password\\u\\server-name), where the string concatenation operation is specified by the symbol ||, the symbol u specifies the user name, and the shared secret string, the possession of which has to be proved, is specified by the word password. c. Compute C₁ =(pi @ rj) d. Send : (sj, cj, u, server-name) to the server.

2. Generate Challenge (44): On receiving (S₁, C₁, u, server-name) from the client, the server retrieves the password corresponding to the user name, u, and performs the following operations. The symbol Φ represents the bit-wise XOR operation. a. Choose two n-bit random numbers, namely: s₂ and r₂ b. Compute: p₂ = h(sid\\s₂\\password\\server-name\\u), where sid specifies a unique and random session identification number generated by the server. c. Compute C₂ = (pi Φ r₂) d. Send (sid,s₂, C₂, server-name, u) to the client. 3. Generate Response (45): On receiving (sid,s₂, c₂, server-name, u) from the server, the client performs the following operations. a. Compute: p₂ = h(sid\ \s₂\ \password\ | server-name] \u) b. Compute: r₂= (c₂ Θp₂) c. Compute: r = truncate(h(sid\\(r] Φ r₂))) d. Send (sid, r) to server

4. Verify Response (46): On receiving (sid ,r) from the client, the server verifies the validity of sid and performs the following operations. A session identifier is valid only if it was generated by the server during Protocol Step 2 and it was not received during this Step previously. a. Compute: pi = h(si\\password\\u\\server-name) b. Compute: r_t= (ci Φpi) c. Compute: r' = truncate(h(sid\\(ri Φ r₂))) d. Verify if r = r': i. Success: Send (sid,OK) to client, where OK is the success flag ii. Failure: Send (sid,NOK) to client, where NOK is the failure flat

When the server verifies the response (r) successfully and the client receives the success flag from the server, they can independently compute the shared set of secret session keys as follows. This process is depicted by the Generate Secret Session Key 47,48 process

These two keys can be used for subsequent cryptographic operations. The session identification number, sid, established during the protocol can be used to index into these two keys by the client and the server. The session identification number and the keys can be used to tear-down a session securely using appropriate mechanisms.

Security of the invention

The password is communicated by the client and the server in the following forms: (Equation 1) C₁ =(Pi 0 T₁)

(Equation 2) P₁ = hfSiWpasswordWuWserver-name)

(Equation 3) C₂ =( p₂ θ r₂)

(Equation 4) p₂ =

(Equation 5) r = truncate(h(sid\ \(n θ r₂)))

Confidentiality: Security against password guessing attacks Note that only the numbers C₁ and c₂ are sent on the network by the client and the server, respectively, but the numbers^ and p₂ are not sent on the network. Since the Y₁ and r₂ are random and secrets, knowing only the numbers C₁ and C₂, the password information is not compromised or revealed. Also, since every password can be mapped to the numbers C₁ and c₂, the password cannot be guessed. Since only a truncated value of the response, namely r, is sent on the wire, only partial information about the information (n Φ r₂) would be available to the adversary. This means that many passwords could have yielded the same communication ensemble, namely (c_h C₂, r). Thus the communication ensemble hides the password/?;.

Integrity The client must compute (Equation 3), in Protocol Step 3, with the same inputs used by the server in Protocol Step 2. Due to the properties of the cryptographic hash function, h, and the randomness of the numbers s₂, the client must use the same password as used by the server. Thus the integrity of the password proved is guaranteed. That is, the client cannot use a password that the server did not use and still induce the server in accepting (or sending the O^ flag) the session.

Availability Note that the server performs a minimal number of operations, namely one addition modulo 2" and one hash computation, during Protocol Step 2. After this step, the server associates a unique and random session identifier, sid, with the instance of password proving attempt by the client. It accepts messages during Protocol Step 4 only when the unique and random session identifier is sent by the client. The session identifier guarantees that only after performing Protocol Step 2, the server can be induced to perform Protocol Step 4. Thus the server can establish that the machine a client commitment came from is indeed alive. Such ability provides a mechanism for the server to slow down distributed denial of server attacks, which usually use IP addresses of machines that either may not be alive or did not send a Client Commitment. Therefore, the availability of the password verifying server, which performs Protocol Steps 2 and 4, is greatly improved for access by clients wishing to prove possession of passwords.

In order to verify the computational optimization of the protocol, the following observations on the protocol would be useful.

1. The first protocol run of any authentication protocol must deal with unauthenticated messages. That is messages with a claimed but unproven source identity.

2. It is important that minimal computational power is expended after receiving unauthenticated messages. Therefore, the first round of computations on the verifier (server) side must be minimal. The first round of computations on the server side for the protocol is the set of computations named Generate Challenge. 3. The computations for the Generate Challenge operation require two random numbers to be selected, one hash function to be computed, and one XOR operation to be performed. This operation also establishes a session identifier (sid) to ensure that only those entities that successfully interacted with the Generate Challenge operation of the prover can successfully interact with the Verify Response operation of the prover. The hash function is a very efficient cryptographic operation and the selection of random numbers can be made very efficient by choosing suitable Pseudo Random Number Generators. XOR is a very fast computer operation. Thus the Generate Challenge operation is highly optimized for computations and generates a security session ID for protecting subsequent operations. Let the computational load on the server hardware due to the execution of Generate Challenge be wl.

4. When the client has successfully engaged the Generate Challenge operation and received a valid sid, only then can it interact with the Verify Response operation of the prover. The Verify Response operation requires two hash functions to be computed. That is it is at least twice as expensive as the Generate Challenge operation. Let the computational load on the server hardware due to the execution of Verify Response be w2 . This load w2 is at least twice greater than wl, which was the load on the server hardware due to the execution of the Generate Challenge operation.

5. Thus no unknown entity or entities that are not interested in engaging the Generate Challenge operation are allowed to interact with the Verify Response operation, which is computationally more expensive. This is arrangement of protocol requirements to interact with the computationally less expensive operations before interacting with computationally more expensive operations is an optimization that would protect the availability property of the verifier (server) for other provers (clients). In other words, unknown entities are prevented from causing the execution of the more expensive computation, namely Verify Response, without doing some additional work, namely interacting with Generate Challenge.

The proposed protocol is ideal for resource-constrained servers because it uses only cryptographic hash functions, pseudo random number generators, and XOR operations. It does not use any public key cryptography operations, such as modular exponentiation of large numbers (1024 bits or higher), or symmetric key encryption routines which are empirically three to four times more computationally expensive when compared to hash functions. The two main protocol operations on the server side, namely Generate Challenge and Verify Response, are linked by the session identifier, which is a data. This means that the protocol can be implemented over state-less communication protocols, which is widely believed to protect against denial of service attacks and, thereby, improve the availability of the server (verifier) for the clients (provers). Other alternative solutions or variations of the invention

Variations of the proposed invention may attempt to adopt one or many variation patters, which are described as follows.

1. Variations of the invention may attempt to alter the sequence of operations by the client or the server or both. One sequence variation can be for the server to compute the response before receiving the same from the client. Once it receives the response from the client, the server needs only to verify if the computed response and the received response are the same. Clearly such a protocol will work and is self-evident. This sequence would load the server if the client never sends the response or is, in fact, not interested in sending the response. The server would have done an operation that is of no use. Therefore, the present invention specifies that the server should compute the response only after receiving the response from the client. The most optimal sequence of operations to prevent denial-of-service attacks is described in this document.

2. Other variations may try to use alternative instantiations of One-Time Pad (OTP) encryption. The use of OTP instantiations using the bit-wise exclusive-OR (XOR) operation of the form aθ b is used in this document.

3. Other variations may use different techniques for choosing the session identifier, namely sid_% instead of using random session identifiers. Randomly chosen session identifiers provide optimal security. 4. Other variations may use different input parameters to the hash function. The input sequences to various uses of the hash function in the proposed protocol achieve ideal security properties.

5. Other variants may not specify sid and propose the use of s₂ only. The invention proposes the use of sid because it can be of shorter size than s₂, which would improve performance and, therefore, provide security against denial of service attacks. REFERENCES

1. Bellare, M., Pointcheval, D., & Rogaway, P. (2000). Authenticated Key Exchange Secure Against Dictionary Attacks. In Advances in Cryptology - Eurocrypt 2000 (pp. 139 -155). Springer-Verlag. (Volume 1807 of Lecture Notes in Computer Science)

(Available from http://www.di.ens.fr/~pointche/pub.php? and http://www.cs.ucsd.edu/users/mihir/papers.html).

2. Bellare, M., & Rogaway, P. (2000). The AuthA Protocol for Password-Based Authenticated Key Exchange, hi Contribution to the IEEE Pl 363 study group for Future PKC Standards. (Available from http://grouper.ieee.org/groups/1363/ ).

3. Boyko, V., MacKenzie, P., Sc Patel, S. (2000). Provably Secure Password Authenticated Key Exchange Using Diffie-Hellman. In Advances in Cryptology - Eurocrypt 2000. Springer-Verlag. (Available from http://eprint.iacr.org/2000/044/).

4. Hitchcock, Y., Tin, Y. S. T., Boyd, C, Gonzalez-Nieto, J. M., & Montague, P. (2003). A Password-Based Authenticator: Security Proof and Applications. In4th International

Conference on Cryptology in India - Indocrypt 2003 (pp. 388-401). Springer-Verlag. (Volume 2904 of Lecture Notes in Computer Science) (Available from http://sky.fit.qut.edu.au/~boydc/papers/).

5. Password protection for high reliability computer systems by Kristen Marie Robins (San Jose, CA) - US patent # 6918044.

6. Method for two-party authentication and key agreement by Sarvar Patel, US Patent # 6918035.

7. National Institute of Standards and Technology http://ts.nist.gov/ts/htdocs/230/232/ABOUT/DEFINITIONS.HTM 8. National Information Systems Security Glossary (NSTISSI No. 4009), http://www.cnss.gov/Assets/pdf/cnssi_4009.pdf

Claims

1. A method for mutual network authentication between a password prover and a password verifier utilizing a secure authentication scheme comprising the steps, performed at said password prover, of: a. getting a password from the user; b. generating a commitment; c. waiting for a challenge; d. generating a response; e. waiting for reply; and f. if the password verifier accepts the identity that the password prover presents, computing a secret session key; further comprising the steps, performed at said password verifier, of: g. looking up the user name and password of the password prover; h. generating the challenge; i. waiting for the response; j. verifying the response; k. accepting or rejecting the verified response; 1. sending an acceptance or rejection; and m. if accepting the password prover' s identity, computing a secret session key 2. A method for mutual network authentication between a password prover and a password verifier utilizing a secure authentication scheme comprising the steps of: a. getting a password from the user and generating a commitment at the password prover; b. looking up the user name and password of the password prover, generating a challenge and waiting for a response at the password verifier; c. waiting for the challenge and generating the response at the password prover; d. verifying the response and accepting or rejecting the verified response and sending an acceptance or rejection at the password verifier; and e. waiting for the reply and if the password verifier accepts the identity the password prover presents, computing a secret session key, at the password prover simultaneously if accepting the password prover' s identity, computing a secret session key, at the password verifier.

3. The method of claim 1 wherein the step of generating the commitment by the password prover, further comprises: a. Getting a password from the user with a user name u; j. Choosing two n-bit random numbers S₁ and r_1; c. Computing pi as a function of the random number S₁, the password, the user name u and a server-name ; d. Computing the commitment C₁ as a function of pi and r_1; and e. Sending (s_h C₁, u, server-name) to a password verifier whose server-name was used in step A. 4. The method of claim 1 or 2 wherein the step of computing pi when generating the commitment uses a secure hash function performing a string concatenation function on the random number S₁, the password, the user name u and the server-name.

5. The method of claim 1 or 2 wherein the step of computing cl when generating the commitment uses the XOR function on pi and the random number rl. 6. The method of claim 1 or 2 wherein the step of waiting for the challenge and waiting for the response by the password prover, further comprises: a. Generating a timeout when the wait-time has exceeded a pre-determined limit.

7. The method of claim 1 or 2 wherein the step of generating the response by the password prover, further comprises: a. Computing p₂ as a function of a session id sid and a random number s₂ generated by the password verifier and sent to the password prover, the password, the server-name and the user-name u; b. Computing r₂ as a function of a challenge c₂ generated by the password verifier and p_2; c. Computing the response r as a function of the session id sid, the random-number r₁ sent to the password prover by the password verifier and r₂; and d. Sending (sid, r) to a password verifier whose server-name was used in step A.

8. The method of claim 6 wherein the step of computing p2, when generating the response uses a secure hash function performing a string concatenation function on the session id sid, the random number s2 the password, the user name u and the server-name .

9. The method of claim 6 wherein the step of computing r, when generating the response truncates the result of a secure hash function performing a string concatenation function applied to the session id sid, and the result of the XOR function applied to the random numbers riand r2. 10. The method of claim 1 or 2 wherein the step of generating the challenge by the password verifier, further comprises: a. Choosing two »-bit random numbers, s₂ and r₂ ; b. Computing p₂ as a function of a generated session identifier sid, the random number ^₂, a password that the password verifier retrieves from a secure, local database, the server-name and the user-name u, sent to the password verifier by the password; c. Computing c₂ as a function of p₂ and the random number r₂ ,. and d. Sending (sid,s₂, C₂, server-name, u) to the client.

11. The method of claim 9 wherein the step of computing p2 when generating the challenge uses the a secure hash function performing a string concatenation function on the session id sid, the random number s_2t the password, the user name u and the server-name, said session id being a unique and random session identification number generated by the password verifier.

12. The method of claim 9 wherein the step of computing c2 when generating the challenge uses the XOR function on p2 and the random number r2.

13. The method of claim 1 or 2 wherein the step of verifying the response by the password verifier, further comprises the steps of: a. Computing pi as a function of the random number S₁ sent to the password verifier by the password prover when the password prover generated its commitment, the password, the user-name u and the server-name; b. Computing r₂ as a function of the commitment C₁ and P₁; c. Computing r' as a function of the session id sid and the random numbers r₂ and r2; and d. Verifying if r is equal to r', equality equating to success i. Success: Send (sid, OK) to client, where OK is the success flag ii. Failure: Send (sid,NOK) to client, where NOK is the failure flat.

14. The method of claim 12 wherein the step of computing pi when verifying the response uses a secure hash function performing a string concatenation function on the random number sl_t the password, the user name u and the server-name. 15. The method of claim 12 wherein the step of computing rl when verifying the response uses the XOR function on the commitment cl and pi.

16. The method of claim 12 wherein the step of computing r\ when verifying the response truncates the result of a secure hash function performing a string concatenation function applied to the session id sid, and the result of the XOR function applied on the random numbers riand r2.

17. The method of claim 1 or 2 for providing security against password guessing attacks.

18. The method of claim 1 or 2 for providing availability of a server that may house the password verifier since the password verifier breaks down its workload into two steps, the second being computationally more expensive than the first, thereby reducing the load on itself.

19. The method of claim 1 or 2 for ensuring availability of a server that may house the password verifier, specifically security against Denial Of Service attacks.

20. The method of claims 1 and 2 wherein the sequence of operation within a particular protocol step can be altered, by the password prover, the password verifier, or both . 21. The method of claims 5,9,15 wherein other instantiations of the One-Time Pad (OTP) encryption might be used, than the XOR function.

22. The method of claims 10 wherein the password verifier generates the session id sid, by means other than random generation.

23. The method of claims 3,8,9,11,14,16 wherein different parameters are used as input to the secure hash function.

24. A system to perform authentication in a networked environment, comprising: a. A password prover and a password verifier, optionally located within a client and a server, respectively, said server optionally being resource-constrained; b. Said password prover having the means to get a password from the user, means to generate a commitment, means to wait for a challenge, means to generate a response, means to wait for reply and means to compute a secret session key; and c. Said password verifier having the means to look up the user name and password of the password prover, means to generate the challenge, means to wait for the response, means to verify the response, means to accept or reject the verified response, means to send an acceptance or rejection and means to compute a secret session key;

25. A system of claim 24, wherein means to generate a commitment by the password prover, further comprises means for getting a password from the user with a user name u, means for choosing two n-bit random numbers S₁ and r_lt means for computing pi as a function of the random number s_lt the password, the user name u and a server-name, means for computing the commitment Q as a function of pi and r_1; and means for sending (s_lr C₁, u, server-name) to a password verifier with a name server-name.

26. A system of claim 24, wherein means to generate a commitment by the password prover, uses a secure hash function performing a string concatenation function on the random number S₁, the password, the user name u and the server-name. 27. A system of claim 24, wherein means for computing pi in the means generate a commitment by the password prover, uses a secure hash function performing a string concatenation function on the random number s_lf the password, the user name u and the server-name.

28. A system of claim 24, wherein means to wait for the challenge and wait for the response by the password prover, further comprises means to generate a timeout when the wait-time has exceeded a pre-determined limit.

29. A system of claim 24, wherein means to generate the response by the password prover, further comprises means to compute p₂ as a function of a session id sid and a random number S₂ generated by the password verifier and sent to the password prover, the password, the server-name and the user-name u, means to compute r₂ as a function of a challenge c₂ generated by the password verifier and p₂, means to compute the response r as a function of the session id sid, the random-number n sent to the password prover by the password verifier and r₂; and means to send (sid, r) to a password verifier with a name server-name. 30. A system of claim 24, wherein means to generate the response by the password prover, uses a secure hash function performing a string concatenation function on the session id sid, the random number s2, the password, the user name u and the server-name.

31. A system of claim 24, wherein means to generate the response by the password prover, truncates the result of a secure hash function performing a string concatenation function applied to the session id sid, and the result of the XOR function applied to the random numbers rZand r2. 32. A system of claim 24, wherein means to generate the challenge by the password verifier further comprises means to choose two w-bit random numbers, s₂ and r__> means to compute p₂ as a function of the session id sid, the random number S₂, Ά password that the password verifier retrieves from a secure, local database, the server-name and the user- name u, sent to the password verifier by the password, means to compute C₂ as a function of jp₂ and the random number r₂, means to send (sid,s₂, c₂, server-name, ύ) to the client.

33. A system of claim 24, wherein means to generate the challenge uses the a secure hash function performing a string concatenation function on the session id sid, the random number s₂, the password, the user name u and the server-name, said session id being a unique and random session identification number generated by the password verifier. 34. A system of claim 24, wherein means to compute c2 when generating the challenge uses the XOR function on p2 and the random number r2.

35. A system of claim 24, wherein means to verify the response by the password verifier, further comprises means to compute pi as a function of the random number S₁ sent to the password verifier by the password prover when the password prover generated its commitment, the password, the user-name u and the server-name, means to computing T₁ as a function of the commitment ci and p_lt means to compute r' as a function of the session id sid and the random numbers rj and r2 and means to verify if r is equal to r', equality equating to success and upon success means to send (sid,OK) to client, where OK is the success flag or alternatively upon failure means to send (sid,NOK) to client, where NOK is the failure flat.

36. A system of claim 24, wherein means to verify the response uses a secure hash function performing a string concatenation function on the random number sl_t the password, the user name u and the server-name.

37. A system of claim 24, wherein means to verify the response uses the XOR function on the commitment cl and pi.

38. A system of claim 24, wherein means to compute r', within means to verify the response truncates the result of a secure hash function performing a string concatenation function applied to the session id sid, and the result of the XOR function applied on the random numbers rl and r2.

39. A system of claim 24, wherein it provides security against password guessing attacks.

40. A system of claim 24, wherein availability is provided to a server that may house the password verifier since the password verifier breaks down its workload into two steps, the second being computationally more expensive than the first, thereby reducing the load on itself.

41. A system of claim 24, wherein it provides availability of a server that may house the password verifier by specifically providing security against Denial Of Service attacks. 42. A system of claims 31, 34, 37 wherein other instantiations of the One-Time Pad (OTP) encryption might be used, than the XOR function. llllA system of claim 10 wherein the password verifier generates the session id sid, by means other than random generation.

44. A system of claim s 3,8,9,11,14,16 wherein different parameters are used as input to the secure hash function.

45. A computer program product containing software code means loadable into the internal memory of a computer in a computerized system, wherein said computer product has means to make said computer carry out the steps of a method according to claims 1 and 2.

46. A computer program product of claim 45 where the software code is loadable into the internal memory of a plurality of computers in a computerized system.

47. A computer program product of claim 45 where the computerized system has the computers connected by a network.

48. A computer program product of claim 47 where the network connecting the computers could be any of a LAN or the Internet. 49. A computer program product of claim 45 where the software code is loadable into the internal memory of a server and a client.

50. A computer program product of claim 45 where the server is optionally resource- constrained.

51. A computer program product of claim 45, wherein said computer product has means to make said computer carry out the steps of a method according to any of claims 1 to 23

52. A computer program product of claim 45, embodied on a computer readable medium.

53. Use of a computer program product of claim 45 to provide secure authentication in a resource-constrained environment.