The digest authentication scheme is used in session initialisation protocol (SIP) to negotiate credentials with a voice over internet protocol (VoIP) user. It was originally designed for hyper text transfer protocol (HTTP) and was specified in RFC 2617. It is widely used in the Internet to authenticate users and to give access to restricted web areas.
The following description gives an example of a situation where a client computer requests access to a server in accordance with the digest authentication scheme. A typical transaction consists of the following steps:                The client asks for a page that requires authentication but does not provide a username and password. Typically this is because the user simply entered the address or followed a link to the page.        The server responds with a so called “401” response code, providing the authentication realm and a randomly-generated, single-use value called a nonce. A realm is a string to be displayed to users so that they know which username and password to use. This string usually contains at least the name of the host performing the authentication and can additionally contain the collection of users who might have access. A nonce is a server-specified data string which should be uniquely generated each time a 401 response is generated.        At this point, the client presents the authentication realm to the user and prompts for a username and password. The user may decide to cancel at this point.        Once a username and password have been supplied, the client resends the same request but adds an authentication header that includes the response code and the nonce. Basically, the response code is a hash value calculated by the client from the provided nonce, username and password.        The server checks the returned response code, accepts the authentication and the requested web page is returned. If the response code is incorrect, the server might return the “401” response code and the client would prompt the user again, and send again a response.        
This scheme can be implemented in a stateless way, which means that the server does not need to store any information relative to the authentication scheme to determine whether the user response is correct. However, as HTTP is transported over transmission control protocol (TCP), a TCP context is allocated for each new connection, so implementation is not completely stateless.
The digest authentication scheme does not limit the number of trials. The server always returns a 401 message with eventually a new nonce value each time the response code is not correct.
The application of the digest authentication scheme to the SIP protocol is described in RFC 3261. Some minor modifications have been applied that do not change the protocol specified by RFC 2617. However, as SIP can be transported over a user datagram protocol (UDP), the digest authentication scheme may be implemented in a completely stateless way. This method of authentication is supported by most of SIP client and server implementations.
This scheme is mainly used in SIP to authenticate REGISTER and INVITE messages. However, other type of messages such as SUBSCRIBE can also be authenticated by using this scheme.
FIG. 1 illustrates a typical SIP registering sequence with successful authentication. In step 101 the client sends an initiating REGISTER message, also called REGISTER or simply REG, to the server. Next in step 102 the server returns a “401” response message with a nonce value: this message is called a challenge. Upon reception, the client calculates the response and sends in step 103 a new REGISTER message to the server. The message includes the response code value and the nonce value which is kept identical to the nonce value sent by the server in step 102. This message is also called REG-A. When receiving the REG-A message, the server checks the response and sends in step 104 a “200” OK message to the client to notify that the registration has succeeded.
The digest authentication scheme is robust against brute force attack. From the username and the challenge response it is difficult to rediscover the password. However, some attacks are still possible.
A first kind of attack is message flooding. When choosing this attack, the attacker wants to exhaust server resources in order to create a denial of service (DoS) for all other users. To stay stealthy, the attacker can use spoofed IP addresses, which prevent applying a basic IP address filtering to protect the server against the flooding.
Initiating REGISTER message flooding can be issued by anybody since it only requires a valid username. An attacker that has collected information (sometimes directories are public) can achieve this very basic attack. The algorithm used to perform authentication must not prevent a valid user (i.e. user that can resolve the challenge) from registering itself while the system is under attack.
Authenticated REGISTER or REG-A message flooding requires knowing the passwords of the users in order to resolve the challenge proposed by the server. It also requires analysing the returned message in the attacking machine to get the nonce. This prevents spoofing of the IP address. However, the nonce values are slowly updated in most of SIP registrar servers, and thus nonce values can be shared between several attackers and IP spoofing is still possible. The authentication algorithm needs to take care that this kind of attack must not disturb authentication of healthy users, i.e. users whose password is kept secret.
The second kind of attack is a man-in-the-middle attack, and more precisely, a replay attack. It consists of replaying the REG-A message using the same nonce and response value, exploiting the possible slow variation of the nonce value in the authentication server. If the attack succeeds, the server will give the same credits as to the original user, and the attacker can freely use the service that is charged to its victim.
Digest authentication scheme can be implemented in a SIP registrar server in several ways. Indeed, RFC 2617 does not indicate how the nonce shall be chosen by the authentication server.
A first method is based on a stateless approach. A nonce is generated for a given period of time and is used for all users during this time. This method is efficient from a resource consumption point of view, but some replay attacks are possible while the nonce stays constant.
A second method is based on a state-full approach. A specific nonce is generated for every new incoming request. It is stored in a context associated to the newly opened dialog, and kept as long as the dialog is not terminated. The main problem is extensive memory resource consumed; above all when the SIP server is under flooding attacks. A “context collector” must be also implemented to release the context but as timer values are long in SIP (up to 2 minutes), the collector cannot be very efficient.
A third method proposes to generate a nonce specific for each received request taking into account sensible information of that request. This information is kept identical in the REG and REG-A messages. For a SIP REGISTER message, it can be the Contact field for instance. This method protects the server against replay attack. The main disadvantage of this method is that the nonce generation depends on the type of processed message and cannot be independent of the processing performed by the server. Furthermore, this method requires a deep message parsing to get sensible information. This operation consumes a lot of central processing unit (CPU) resources, and consequently, this mechanism is vulnerable to REG message flooding.
United States patent application publication 2006/0184681 by BEA Systems Inc. discloses a computer architecture for enterprise device applications that provides a real-time, bidirectional communication layer for device communication. An identity-based communications layer provides for secure, end-to-end telemetry and control communications by enabling mutual authentication and encryption between the devices and the enterprise. A unique identity is assigned to each device, user and application to provide security services. The unique identity is independent of a network-address. Security information and a network address may be associated with the unique identity. An authentication method based on nonce challenges is also disclosed.
The invention aims at providing an improved digest authentication method which is less vulnerable to the attacks identified above.
USPTO Backgrounds
USPTO Backgrounds