Weakness in Zhang et al.’s Authentication Protocol for Session Initiation Protocol

Abstract

Authentication is the most security service required by Session Initiation Protocol (SIP). In recently years, Zhang et al. proposed for the first time an efficient and flexible authentication protocol for SIP using smart card and Elliptic Curve Cryptography. But, in 2014, Zhang et al. showed that their latest proposed protocol is vulnerable to impersonation attack. In order to improve their protocol, Zhang et al. proposed a second protocol. However, in this work we demonstrate that Zhang et al.’s protocol is vulnerable to server spoofing attack. Furthermore to overcome the weakness of Zhang et al.’s protocol we propose an improved and secured SIP authentication and key exchange protocol. The security analysis shows that our proposed protocol can resist to various attack including server spoofing attack.

1 Introduction

The Telephony over IP (ToIP) is a service that allows to exchange multimedia flows (voice, text, video.) trough internet; ToIP is based on two types of protocols: signaling protocols and transport protocols. In recently decade, Session Initiation Protocol (SIP) [1] is the most signaling protocol used for establishing, altering and terminating session multimedia between different users. The architecture of SIP consists of a proxy server, redirect server, register server, location server, and User agents.

Authentication is the most security service required for SIP. Since, the original SIP authentication protocol (HTTP Digest Authentication [2]) was found vulnerable to deferent attacks; a large community has been participated by proposing the different protocols based on various mechanisms.

SIP authentication protocols proposed before 2013 [3,4,5,6,7] are based on the password verification using several mechanisms. Then, the password must be shared between the user and the server. The shared password is stored in the server database. Therefore, these protocols are vulnerable to stolen verifier attack. In addition to this attack these protocols suffer from the problem of managing of password’s database. In 2013, Zhang et al. [8] proposed a first SIP authentication protocol using the Smart Card. Zhang et al. have demonstrated that their protocol offers several advantages such as mutual authentication secrecy and password updating, and it is secure against replay attacks, server spoofing attack, stolen verifier attack, man in the middle attack, and offline password guessing attack. However, Wu et al. [9], Tu et al. [10], and Jiang et al. [11] showed that the protocol of Zhang et al. [8] is vulnerable to user impersonation attack. In order to solve this attack, Zhang et al. proposed a year after their second protocol [12]. Tu et al. [10] proposed a new secured SIP authentication protocol. Then, Tu et al. prove that authentication phase of their protocol reduce the computing time cost to 75% compared to the same Zhang et al.’s phase. Despite these advantages, Tu et al.’s protocol is demonstrated vulnerable to many attacks by Farash et al. [13], Mishra et al. [14] and Zhu et al. [15]. Then, Farah et al. [13] proposed their SIP authentication protocol. However, in 2015, Chaudhry et al. [16] demonstrated that the Farash et al.’s protocol is defenseless to replay attack and Denial of Service attack. As result, they proposed a new protocol and they have proven that is secure against known attacks. Also, Kumaris et al. [17] noticed that Farah et al.’s protocol is not secured against different attack. So, Kumari et al. proposed a new protocol that can resist user impersonation attack, Off-line password guessing attack, replay attack and man-in-the-middle.

In 2014, Arshad et al. [18] proposed a new SIP authentication protocol. However, in 2016, Lin et al. [19] have discovered that Arshad et al.’s protocol is vulnerable. To overcome this problem Lin et al. proposed a new protocol that is more secure and allows to users to update their password using a new method.

Recently, M. Azrour et al. [20] proved that Jiang et al.’s protocol suffer from server spoofing attack, in order to enhance the security of SIP, M. Azrour et al. proposed their protocol which is secured against various attack. For more information about related protocol please refer to [21,22,23].

In this paper, we will analysis the security performance of Zhang et al.’s [12] SIP authentication protocol. We will show that is vulnerable to server spoofing attack. Then, we propose our solution to overcome the weakness in Zhang et al.’s protocol. Performance analysis shows that our protocol is more secured if it is compared with Zhang et al.’s protocol.

The remainder of this paper is organized as follows. Section 2 delivers general information on the original SIP authentication protocol. In the Sect. 3, we briefly reviewed the Zhang et al.’s authentication protocol. Then, this protocol is analyzed in Sect. 4. The Sect. 5 presents our proposed protocol. The security and performance of our proposed protocol are analyzed respectively in Sects. 6 and 7. Finally the Sect. 8 concludes the paper.

2 Original SIP Authentication Protocol

HTTP Digest Authentication for SIP is based on the mechanism challenge/response. Before the protocol execution, the client and the server share the password, which is used to verify the client’s identity. The messages exchanged between the server and the client during authentication procedure are illustrated in Fig. 1 and they are described as following.

Fig. 1.

HTTP digest authentication

• Step 1. Client → Server: REQUEST

  The client sends a REQUEST to the server.

• Step 2. Server → Client: CHALLENGE (nonce, realm)

  After receiving REQUEST; the server generates CHALLENGE that includes a nonce and the client’s realm. Note that realm is used to verify username and password. Then, the server sends back CHALLENGE to the client.

• Step 3. Client → Server: RESPONSE (nonce, realm, username, response)

  After receiving CHALLENGE from the server, the client computes the response by using received nonce, username, secret password, and realm. response = F(nonce, username, password, realm). Note that F(.) is a one-way hash function. Next, the client sends back the original REQUEST with the computed response, username, nonce and realm.

• Step 4. According to username the server extracts the client’s password. Then, the server verifies wither nonce is correct or not. If it is correct, the server computes F(nonce, username, password, realm) and uses it to compare it with the response. If they match, the server authenticates the identity of the client.

3 Review of Zhang et al.’s Scheme

In this section, we briefly review Zhang et al.’s protocol as follows. The notations used in this paper are shown in Table 1.

Table 1. Notations and their explanations

Table 2. Security performances

3.1 System Setup Phase

The server selects $E_{p} \left( {a,b} \right)$ with the order $n,$ P $\in E_{p} \left( {a,b} \right)$, it chooses a random number $s \in_{R} Z_{p}^{*}$ as the secret key. Then, it selects two one-way hash functions, $h\left( . \right),h_{1} \left( . \right)$. Finally, the server publishes $\left\{ {E_{p} \left( {a,b} \right), P, h\left( . \right), h_{1} \left( . \right)} \right\}$ and keeps $s$ in secret.

3.2 Registration Phase

In this phase, the user registers on the SIP server through a secure channel. The details of this phase are as follows.

R1::

The user U selects his/her username, password PW and a random number $a \in_{R} Z_{p}^{*}$. After that, U computes $h(PW| |a )$ and sends $\{ h(PW| |a ), username\}$ to the server through a secure channel.

R2::

after receiving the registration information, the server computes $R = \frac{h(PW| |a )}{{h\left( {username} \right) + s}}P$.

R3::

The server stores R into the smart card and issues it to U.

R4::

Upon receiving the card, U stores $a$ in the card. Then, the card contains $\left( {R,a} \right).$

3.3 Authentication Phase

Whenever the user wants to login into the remote server, he/she performs the following steps.

A1::

$U \to S: REQUEST\left( {username,V,W} \right)$

U selects a random number $b \in_{R} Z_{p}^{*}$, and computes $V = bR$ and $W = bh(PW| |a )P$. Next, the card sends a request message REQUEST(username, V, W) to the server.

A2::

$S \to U: CHALLENGE\left( {realm, Auth_{s} , S, r} \right)$

After receiving the request message, the server S computes $W^{\prime} = h\left( {username} \right) + s) V = \left( {h\left( {username} \right) + s} \right) = bh((PW| |a )P^{ }$. Then, it checks $W^{ } { \overset{?}{=}}W^{'}$. If true, the server chooses two random integers c, $r \in_{R} Z_{p}^{*} ,$ and computes $S = cP, SK = ch\left( {username} \right)W^{\prime} = cbh(PW| |a )h\left( {username} \right)P,$ and $Auth_{s}^{ } = h_{1} \left( {S\left| {\left| {W'} \right|\left| {SK} \right|} \right|r} \right)$. Next, it sends message CHALLENGE(realm, $Auth_{s}^{ } , S^{ } ,r$) to U over a public channel.

A3::

$U \to S:$ $RESPONSE\left( {realm, Auth_{u} } \right)$

Upon receiving message REQUEST, U computes $SK^{' } = bh \left( {PW^{ } ||a} \right)h\left( {username} \right)S = cbh\left( {PW^{ } ||a} \right)h\left( {username} \right)P$ . Then, it cheks whether the equation $Auth_{s}^{ } { \overset{?}{=}} h_{1} \left( {S\left| {\left| W \right|\left| {SK'} \right|} \right|r} \right)$ holds. If so, U computes $Auth_{u}^{ } = h_{1} \left( {S\left| {\left| W \right|\left| {SK'} \right|} \right|r + 1} \right)$ and sends RESPONSE(realm, Authu) back to the server. Otherwise, it deletes received information and the protocol stops.

A4::

After receiving the RESPONSE message, the server verifies $Auth_{u} { \overset{?}{=}}h_{1} \left( {S\left| {\left| {W'} \right|\left| {SK} \right|} \right|r + 1} \right)$. If the message is authenticated, the server sets $SK$ a shared session key with user U. Otherwise, it deletes received information and the protocol stops.

4 Cryptanalysis of Zhang et al.’s Scheme

In this section, we prove that the Server spoofing attack is still effective in Zhang et al.’s protocol. Suppose that ${\mathcal{A}}$ is an attacker. ${\mathcal{A}}$ can eavesdrops the message REQUEST{username, V, W} transmitted between server S and user U. Then, he/she can execute server spoofing attack. The details of attack are presented as follows.

Step1. :

U inputs his/her username and password PW, generates randomly a number $b \in_{R} Z_{p}^{*}$, and computes $V = bR$ and $W = bh(PW| |a )P$. Then it sends a request message REQUEST(username, V, W) to S.

Step2.:

${\mathcal{A} }$ eavesdrops message REQUEST(username, V, W) and get username, V, W. He/she generates a random number $r \in_{R} Z_{p}^{*}$. Next, he/she get a value of base point P, and puts its value in $S^{{\prime }}$($S^{{\prime }}$ ← $P_{ }$). Then, he/she computes $SK = h\left( {username} \right)W$ and $Auth_{s}^{{^{{\prime }} }} = h_{1} \left( {S^{{\prime }} \left| {\left| W \right|\left| {SK} \right|} \right|r} \right)$. Next, ${\mathcal{A}}$ sends message CHALLENGE(realm, $Auth_{s}^{'} , S^{'} ,r$) to U.

Step3. :

Upon receiving message CHALLENGE (realm, $Auth_{s}^{'} , S^{'} ,r)$, U computes $SK^{{\prime }} = bh \left( {PW||a} \right)h\left( {username} \right)S^{{\prime }}$ and verifies if $Auth_{s}^{{\prime }} { \overset{?}{=}}h_{1} \left( {S^{{\prime }} \left| {\left| W \right|\left| {SK^{{\prime }} } \right|} \right|r} \right)$. The user will find true because:

$W$ ← $bh(PW| |a )P$ and $S^{{\prime }}$ ← $P_{ }$

So

$$ \begin{aligned} SK = & h\left( {username} \right)W \\ = & h\left( {username} \right)bh(PW| |a )P \\ = & bh(PW| |a )h\left( {username} \right)P \\ = & bh(PW| |a )h\left( {username} \right)S^{{\prime }} \\ = & SK^{{\prime }} \\ \end{aligned} $$

As result, user U authenticates attacker ${\mathcal{A}}$ and sends to him RESPONSE thinking that he/she communicate with a legal server S.

According to previous analysis, the adversary can easily impersonate identity of server at any time. The user U does not know whether the one he contacts is that the valid server or not. So the adversary can impersonate the server successfully. Therefore, Zhang et al.’s protocol is vulnerable to the server spoofing attack.

5 Our Proposed Protocol

In order to overcome weakness in Zhang et al.’s protocol, we propose an improved and secured authentication and key agreement protocol for SIP. Our protocol consists of four phases, which are system setup phase, registration phase, authentication and key agreement phase, and password changing phase.

5.1 System Setup Phase

In this phase, the server selects an elliptic curve equation $E_{p} \left( {a,b} \right)$, over a finite field $F_{q}$, an additive group $G$ of order $p$ and $P$ a base point generator with order $n$ over equation $E_{p} \left( {a,b} \right)$, $n$ is a large prime of height entropy. Then, the server picks a random integer $s \in_{R} Z_{p}^{*}$ as its secrete key. Next, the server chooses three one-way hash functions $h\left( \cdot \right)$, $h_{ 1} \left( \cdot \right)\,and\,h_{2} \left( \cdot \right)$. Finally, the server publishes all parameters except its private key $s$, which it is saved secretly.

5.2 Registration Phase

In this phase the user and server S perform the following steps over a secured channel.

R1::

The user U chooses freely his/her username, password W and a random number $a \in_{R} Z_{p}^{*}$. After that, U computes $h(PW| |a )$ and sends $\{ h(PW| |a ), username\}$ to the S.

R2::

After receiving the registration information, the server computes $R = h\left( {PW\left\| a \right.} \right) \oplus h\left( {username\left\| s \right.} \right)P$ Then, the server stores $R$ into the smart card and delivers it to U.

R3::

Upon receiving the card, U stores $a$ in the card. Therefore, user card contains $\left( {R,a} \right)$

5.3 Authentication and Key Agreement Phase

As illustrated in Fig. 2, whenever U wishes to log into S, he/she have to inserts his/her smart card in card reader and inputs his/her $username$ and password $PW$. Next, the following steps will be executed between server S and user U.

Fig. 2.

Authentication phase of our proposed scheme

• Auth1: U → S: REQUEST(username, V, W,$T_{1}$)

  After inserting the smart card in card reader and inputting the username and password. The user’s smart card chooses a random $b \in_{R} Z_{p}^{*}$, and computes $V = bR,$ $= h(PW||a)$, and $W = bXP$. Then, he/she sends a message REQUEST(username, V, W,$T_{1}$) to the server over a public channel. $T_{1}$ denotes the current timestamp here.

• Auth2: S → U: CHALLENGE(realm, $Auth_{s}^{ }$,S, r,$T_{3}$)

  Upon receiving the request message form $U$ at time $T_{2}$, $S$ verifies validity of $T_{2} - T_{1} \le$ ΔT. If it is OK, S computes $Y = h(username||s)$ and $W^{{\prime }} = V \oplus Y$. Then, it verifies $W{ \overset{?}{=}}W^{'}$. If it holds, the server S picks randomly two integers $c,r \in_{R} Z_{p}^{*}$. Then, it computes $S = cP, K = cW^{{\prime }} , SK = h_{1} (W^{{\prime }} \left| {\left| { r } \right|} \right| YP )$ and $Auth_{s} = h_{2} \left( {W^{{\prime }} \left| {\left| {SK} \right|\left| r \right|\left| K \right|} \right|S} \right)$. Next, it sends message CHALLENGE(realm, $Auth_{s}^{ } , S^{ } ,r,T_{3}$) to U over a public channel.

• Auth3: U → S: RESPONSE(realm, $Auth_{u}^{ }$)

  Once the user $U$ receives the CHALLENGE message form $S$ at time $T_{4}$, $U$ verifies validity of $T_{4} - T_{3} \le$ ΔT. If is not fresh, $U$ stops the process. Otherwise, $U$ calculates $K^{{\prime }} = bXS$ and $SK^{{\prime }} = h_{1} (W\left\| { r} \right\|\left( {R \oplus X} \right)P ),$ and checks $Auth_{s} \mathop = \limits^{?} h_{2} \left( {W\left\| {SK^{{\prime }} \left\| { r} \right\|K^{{\prime }} } \right\|S} \right)$. If it is true, the server is authenticated. Then, user U computes $Auth_{u} = h_{2} \left( {W \left\| {SK^{{\prime }} } \right\|r + 1\left\| { K^{{\prime }} } \right\|S} \right)$ and sends RESPONSE(realm, $Auth_{u}^{ }$) back to server S. Otherwise, it stops the protocol and deletes received and calculated parameters.

• Auth4:

  After receiving the RESPONSE message, the server verifies $Auth_{u} { \overset{?}{=}} h_{2} (W \left\| {SK} \right\|r + 1\left\| { K^{{\prime }} } \right\| S)$. If it holds, the user U is authenticated and server S sets $SK$ a shared session key with U. Otherwise, it stops the protocol and deletes received and calculated parameters.

5.4 Password Changing Phase

When the user U wants to update its password, it needs to agree on a session key with the server via the authentication phase in advance. The details of this phase are described as following.

Pass1. :

U → S: ($username,e,New_{u}$)

The user U chooses its new password $PW^{*}$ and two random integers $a^{*} ,e \in_{R} Z_{p}^{*}$ and computes $h(PW^{*} | |a^{*} )$ and $tag_{u} = h(username \left| {\left| e \right|} \right| h\left( {PW^{*} | |a^{*} )} \right)$, it then uses $SK$ to encrypt the new parameters, $New_{u} = E_{KS} \left( {username\left| {\left| e \right|} \right|h\left( {PW^{*} \left\| {a^{*} } \right.} \right)\left\| {tag_{u} } \right.} \right)$. Next, it sends message $(username,e,New_{u}$) to server.

Pass2. :

S → U: ($New_{s}$)

Upon receiving the information, the server decrypts the message and then checks the validity of the authentication $tag_{u} { \overset{?}{=}}h(username\left| {\left| e \right|} \right|h(PW^{*} \left\| {a^{*} } \right. ))$. If it is valid, the server computes the new secret information $R^{*} = h(PW^{*} \left\| a \right.^{*} ) \oplus h(username\left\| s \right.)P$ and $tag_{s} = h\left( {username\left| {\left| {e + 1} \right|} \right|R^{*} } \right)$. Then, it sends encryption information $New_{s} = E_{KS} (R^{*} ||tag_{s} )$ back to user.

Pass3. :

The user U decrypts received message and verifies the validity of $tag_{s} { \overset{?}{=}} h\left( {username\left| {\left| {e + 1} \right|} \right|R^{*} } \right)$. If it is valid, U stores $R^{*} and a^{*}$ in its smart card.

6 Security Analysis

6.1 Mutual Authentication

Mutual authentication means that both the user and server are authenticated to each other within the same protocol. In the proposed scheme the server can authenticate user after receiving REQUEST by checking W, and after receiving RESPONSE by checking $Auth_{u}^{ }$. Upon receiving message CHALLENGE user can authenticate the server by testing validity of $Auth_{s }^{ }$. As result, our protocol provides mutual authentication.

6.2 Session Key Secrecy

In our protocol the session key is computed in this way $SK = h_{1} (W^{{\prime }} \left\| { r} \right\|YP) )= h_{1} (W\left\| { r} \right\| \left( {R \oplus X} \right)P) )$. Since, $PW, a$, and $s$ are secret, the session key cannot be calculated by anyone except the server and the client. Therefore, our proposed protocol provides session key secrecy.

6.3 Server Spoofing Attack

Our scheme can resist against server spoofing attack. Suppose that an attacker ${\mathcal{A}}$ wants to impersonate the server and spoof user U, ${\mathcal{A}}$ has to computes $Auth_{s}^{ }$. However, ${\mathcal{A}}$ doesn’t have any information about a server secret key $s$. Then, ${\mathcal{A}}$ can’t compute $K\,and\,SK$. Therefore, he cannot forge a valid CHALLENGE message.

6.4 User Impersonation Attack

Assume that attacker ${\mathcal{A}}$ wishes to connect to the server as legitimate user U. ${\mathcal{A}}$ has to prove its validity by forging two messages REQUEST(username, V, W,$T_{1}$) and RESPONSE(realm, $Auth_{u}^{ }$,$T_{3}$). While ${\mathcal{A}}$ need to know some secret information $PW\,and\,a$. Therefore, he/she is not capable to send the two validate messages. As result, our scheme can resist user impersonation attack.

6.5 Denning-Sacco Attack

In our scheme, the session key is calculated in this way $SK = h_{1} (W^{{\prime }} \left\| r \right\|YP) )= h_{1} (W\left\| r \right\|\left( {R \oplus X} \right)P) )$. If an attacker has obtained it, he will have to break the one-way hash function to get $YP\,or\,\left( {R \oplus X} \right)P$. Then, he has to face Elliptic Curve Cryptography if he wants to guess the user password. So, the proposed scheme is secure against Denning Sacco attack.

6.6 Replay Attack

Suppose that the adversary Alice intercepts the messages REQUEST(username, V, W,T1) and RESPONSE(realm, $Auth_{u}^{ }$) and try to impersonate a legitimate user U. However, she cannot calculate V, W, and $Auth_{u}^{ }$. Since she don’t know server secret key. Alice has to face the ECDLP, if she wants to get the correct one by guessing the secret key s from V or W. after replaying REQUEST or RESPONSE the server will detect the attack via comparing if $W^{ } { \overset{?}{=}}V \otimes Y$ or $Auth_{u} { \overset{?}{=}} (W || SK^{{\prime }} || r + 1\left| {\left| { K^{{\prime }} } \right|} \right| S)$.

Now, Suppose that Alice intercepts the message CHALLENGE(realm, $Auth_{s}^{ } ,S,r$) and try to replay it to impersonate the legal server. In order, to be authenticated by the user, Alice have to compute the value of $Auth_{s}^{ } = h_{2} (W^{\prime}|| SK^{ } \left| {\left| r \right|} \right|K||S)$ using secret $PW, a$, $K,$ and $SK^{ }$. Since Alice don’t have any information about secret parameters she cannot computes a valid $Auth_{s}$. As result, the proposed protocol withstands replay attack.

6.7 Stolen Verifier Attack

In the proposed scheme, any user’s secret is stored in server database. So, the attacker can’t obtain the user’s secret information from server. Therefore, our proposed protocol is secure against stolen verifier attack.

6.8 Offline Password Guessing Attack

Suppose that an attacker records all messages (REQUEST, CHALLENGE and RESPONSE) transmitted between user and server, then extract $username, V, W, realm, Auth_{s}^{ } ,S,r\,and\,Auth_{u}^{ }$, and tries to guess the password $PW^{*}$ and verifies its correctness. Since, the attacker does not know any information about values of $s , a, b,$ and c. He/she can’t compute $K, SK$. Then, he can’t verify the calculated $V, W, Auth_{s} \,or\,Auth_{u}$.

If attacker steals user card he can get $R\,and\,a$, However, he must to know $s$ to check $h(PW| |a ) \oplus h(username||s)P$. Therefore, our proposed scheme is safe against password guessing attack.

6.9 Man-in-the-Middle Attack

In our protocol all messages are authenticated by server or user, to know their origin. In addition, at the end of authentication, the session key is shared between user and server, so the following messages will be encrypt using session key. To replay these messages, an attacker needs to know a session key. But, he cannot calculate it since he/she does not know $s , a,X,PW\,and\,b$. As result, our protocol is secure against Man-in-the-middle attack.

7 Performance Comparison

In this section, we will compare the performance and computation cost of our proposed protocol with Zhang et al.’s protocol. In this comparison a very lightweight operations like string concatenation operation, Exclusive-OR operation are not examined, because there computation cost is negligible. The notations used are illustrated as follows.

• $T_{h}$ The computational cost of one-way hash operation

• $T_{pm}$ The computational cost of elliptic curve point multiplication

• $T_{inv}$ The computational cost of modular inversion

• $T_{Eks}/T_{Dks}$ The computational cost of Encryption/Decryption algorithm

In the registration phase of our protocol the user uses one hash function and the server computes $1T_{h} + 1T_{pm}$. The computational costs of the user side and server side in our protocol’s authentication phase are $4T_{h}$ + $3T_{pm}$ and $4T_{h}$ + $3T_{pm}$. In the password changing phase the user computes $3T_{h}$ + $1T_{EKs}$ + $1T_{DKs}$ and the server computes $3T_{h}$ + $1T_{pm}$ + $1T_{EKs}$ + $1T_{DKs}$.

According to the Table 3 we can observe that modular inversion operation is not used in the registration phase of our protocol. So, this phase is faster than the same phase of Zhang et al.’s protocol. In the Table 2, we can see that our protocol is secured against different attacks especially server spoofing attack, which is effective in the protocol of Zhang et al. Moreover, Zhang et al.’s protocol consist on three phases: System setup phase, Registration phase, and Authentication phase; so it is impossible to change the password or it’s not clear how it can be changed. Contrary, our protocol defined Password changing phase in addition to the last three cited phases. Therefore, we can say that our protocol is suitable for applications developed on the base of SIP.

Table 3. Computational comparisons between our protocol and related protocols

8 Conclusion

In this paper, we have showed that Zhang et al.’s protocol is vulnerable to server spoofing attacks. In order to overcome this weakness we proposed an efficient and secure SIP authentication scheme. According to our analysis, our proposed protocol is secure against various attacks and can provide many security services.