User authentication in SIP

Transcription

1 User authentication in SIP Pauli Vesterinen Helsinki University of Technology Abstract Today Voice over Internet Protocol (VoIP) is used in large scale to deliver voice and multimedia over the packet data networks, such as the Internet. The Session Initiation Protocol (SIP) is widely used as a signalling protocol for VoIP. As SIP is being used more, the security of it is an important issue. In this paper, we concentrate on user authentication in SIP. We examine current solutions in authentication and analyse them. As a result, some security issues and problems were found, which expose the SIP authentication to different kind of threats. KEYWORDS: SIP, authentication, VoIP 1 Introduction VoIP (Voice over Internet Protocol) is an interesting technology in the area of telecommunication, because with it voice calls can be delivered using Internet Protocol (IP) networks, the same as is used in transporting IP data. It is also promising since using Internet as a transport channel is more efficient than maintaining a separate telephone network for calls and another for data communication. Yet the usage degree of VoIP has not substituted PSTN (Public Switched Telephone Network) in telecommunications, but that could be the reality in the future. In VoIP voice is converted to data packets in contrast to PSTN, which realizes voice delivery in circuitswitched mode. VoIP packets are, as in any Internet Protocol based system, exposed to loss, delay or bandwidth limitations. When these network restrictions and issues are solved at acceptable level, VoIP technologies can be potential replacement for PSTN. As VoIP is getting popular and usage grows, it is important to consider the security issues on using it. There are many protocols used in VoIP signaling, but Session Initiation Protocol (SIP) [1] is one of the widely used ones. SIP is a signaling protocol functioning at applicationlayer, which can be used to initiate and terminate Voice over IP (VoIP) and multimedia sessions between user clients. [1, 2] Today SIP is the most promising Internet telephone signaling protocol, as Stefano, Veltri and Papadilo claim in their article [3]. While SIP is gaining reputation as a promising protocol for VoIP, can we rely completely on the security of it? In this article we will concentrate on user authentication in SIP, which is an important issue when the security of SIP is under consideration. For example, when user Jack (name not real) wants to make a SIP voice call to user Joanna (name also not real), how can he verify that he is connected exactly to SIP user client of Joanna, and not to a client pretending to be the SIP client of Joanna? Current solutions for authenticating users include different technologies and achieve multiple levels of security. This paper introduces methods and technologies for user authentication when SIP is used, how these solutions differ and what are the advantages and disadvantages of them. The objective is to give the reader a good overview and most relevant details about technologies used. Section 2 introduces SIP, authentication in general and possible attacks when SIP is used. Section 3 will concentrate on authentication mechanisms. In section 4 we will analyze the issues and problems on SIP user authentication. Finally, the conclusions will pull together the whole article. 2 SIP, authentication and different attacks We shall introduce in this section SIP, authentication in general and examine two scenarios how VoIP, especially SIP, attack might be possible. 2.1 Session Initiation Protocol (SIP) SIP is a text-based protocol which operates at application layer [1]. It is based on request-response model, invoking some function or method with request messages and getting response as a confirm or answer to the request. SIP allows end users to negotiate stream details, for example codecs used in session, using Session Description Protocol (SDP) [4]. In SIP, registration is needed and a SIP registrar handles that. User clients register to registrar server, which keeps record of SIP clients in that domain. As an example call flow, consider user Jack and user Joanna as in the Introduction section. As a beginning of a SIP call, the user client of Jack initiates a call by sending an INVITE message towards Joanna. This invitation includes Jack s proposition for session description based on SDP. That INVITE message is forwarded to the client of Joanna possibly through multiple SIP proxies. After that, the client of Joanna receives the INVITE message and replies with a 180 RINGING, which is forwarded towards the client of Jack. At the time when the client of Joanna sends 180 RINGING, it also informs Joanna about the incoming SIP call, meaning basicly that Joanna s SIP phone rings. If Joanna accepts the call, her client will reply to invitation with a 200 OK message, which includes Joanna s reply to the SDP received in the INVITE message.

2 This method of offering first a proposition of parameters and in answer receiving accepted parameters is called an offer/answer model. When the 200 OK message reaches back to Jack, his client will indicate Jack that the call is answered. His client can now determine the session details, accepted by the client of Joanna, from the SDP part of the received 200 OK message. Thereafter, SIP client of Jack sends an ACK message indicating the SIP phone of Joanna about the active and accepted session. From this point on, the client of Jack sends this ACK message straight to Joanna, without proxies, and the whole SIP conversation continues peer-topeer. The addresses of the the SIP user clients are learned through header fields in the messages during the exchange of the messages. The ongoing session ends, when either one sends an BYE message to the other peer. 2.2 Authentication Authentication means identifying the object, for example person, and knowing that the identity of the object is in reality the same as the object claims it to be [5]. It is absolutely important to be sure about the identity of receiver before sending data containing for example personal information. In SIP, authentication was introduced originally through using HTTP digest mechanism, transport layer mechanism or Secure Multipart Internet Mail Extensions (S/MIME) [1]. Details of these will be explained in next section, where mechanisms for authentication in SIP are introduced. 2.3 Attack scenarios What kind of security vulnerabilities exist? What are the threats in terms of SIP authentication? One possible threat is exposed in the registration of the user clients to the SIP registrar server, by hijacking registration of the user client. In SIP user client registration, the client sends an REG- ISTER message to registrar server, which includes both IPaddress and contact information of the user. This information can be used to hijack registration and forward incoming call to SIP phone of the hijacker. When registrar receives a request which is addressed to the user registered to the registrar receiving the request, the registrar looks for an IP address entry for the SIP contact requested. At this point hijacker might have cheated registrar by first blocking original user s registration messages by some means, for instance addressing a denial-of-service attack to user client. After blocking the user, the attacker sends it s own registration messages to registrar including the SIP contact information of the original user, but with the changed IP address. In other words, the registrar thinks only the IP address of the registered user is changed and SIP contact is associated to new IP address which is the hijacker s IP address. Then registrar will forward incoming call request to the hijacker instead of the original user. [6] In addition to register attack scenario, another type of attack is described in the article written by Cao and Jennings [7]. They introduce a threat which enables SIP calls forwarding to possibly rogue server by exploiting the lack of identifying response messages in SIP. Response identity means that responses to requests are not identified and though can be attacked. First, when SIP request is send to proxy server of the receiver, the attacker hijacks the request message and uses the header fields from that request. Then, attacker assigns the response with status code 302, which stands for "moved temporarily" [1]. When attacker sends this response message with headers stolen from request message, for example INVITE, incoming call is forwarded to attacker. The two attack scenarios introduced have implications on security and privacy, at least four major ones. First, attacker could get personal and confidential data of the users. Second, rogue party could mislead end users to participate to denial of service attack or third, to forward their calls to malicious voice mail. And fourth, existing call parties could be conferencing with rogue party. [7] 3 Authentication mechanisms in SIP Using SIP, there exists two basic principles for providing security, end-to-end and hop-by-hop [3]. End-to-end security on SIP data involves end users, for example SIP authentication. In contrast to end-to-end solutions which use SIP mechanisms to ensure security, hop-by-hop relies on the security provided by the network. Examples of hop-by-hop mechanism are transport-level security (TLS) and Internet Protocol Security (IPsec) [3]. In terms of authentication in SIP, several mechanisms exists which we introduce in succeeding subsections. SIP specification [1] introduces HTTP digest authentication and usage of S/MIME extensions. In addition to those, we introduce also other techniques of authentication, which are designed to improve security in SIP. 3.1 HTTP digest authentication in SIP In SIP specification [1], the authentication mechanism proposed is HTTP digest based authentication. In SIP terms, HTTP digest mechanism is called the SIP authentication. Originally, HTTP digest is a challenge-response protocol, in which a nonce value is used in challenging the target. The response includes then a checksum of the username, password, nonce value, HTTP method and requested URI. [8] SIP applies the digest mechanism for authenticating users to users or users to proxies, not proxies to proxies. The security between proxies relies on other mechanisms, for example TLS or IPsec. First, when a server receives a request message from the client, for example INVITE, it may challenge the sender of the message. The server sends an response message containing a nonce value and a realm towards the sender of the first request. The response is actually an error message requesting authentication. The realm in the message is the digest algorithm used in this challenge. The initiator, client, of the request receives the response and computes the response value, which is computed with nonce value received in challenge and with a username and a secret password. The secret password is known by both the client and the server. The client sends back the original request message with the computed response value, username, nonce value and realm. In figure 1 is SIP authentication mechanism as an example flow.

3 Figure 1: SIP authentication mechanism based on HTTP digest. [3] 3.2 Using S/MIME in SIP for authentication The Secure Multipart Internet Mail Extensions (S/MIME) in SIP [1] is used to carry replicates of SIP header fields inside a MIME body [7]. This enables authentication by the means of signing the replicated header fields to verify the identity of the sender. In the SIP specification [1], it is proposed to replicate all header fields inside a MIME part, which exposes some problems. First, the SIP header fields might get altered by the intermediate SIP entities which makes it difficult for the recipient to identify the legal or malicious changes in headers. Second, SIP messages can be large by their size, which causes overhead for processing and transporting of the messages. Therefore, a new solution for delivering authenticated identity of the call parties is specified by using an Authenticated Identity Body (AIB) in SIP. The AIB in SIP is a MIME body, which contains an authenticated identity. This solution of using AIB is introduced by Peterson in RFC 3893 [9]. 3.3 Authentication scheme for a trusted SIP domain This subsection introduces a scheme for authentication in SIP, which is developed by Srinivasan et al [10]. Their proposition is based on authenticating user client with the proxy server. The proxy server is outbound proxy for the domain and though it is at the edge of the domain. The user client that initiates a call communicates straight with that outbound proxy server, which implies that the authentication of the user client has to be handled by that outbound proxy. Though, user clients register to the registrar server, so the outbound proxy server authenticates the user client in co-operation with the registrar server in that trusted SIP domain. The assumption that proxy server authenticates user client with registrar leads to a requirement that proxy server and registrar server are trusted. Also these servers needs to have public key certificates, which are authorized by authorities of that domain. In figure 2 is presented the scheme of authenticating user Figure 2: SIP trusted domain scheme [10]. client inside a trusted domain. In the scheme the user client registers itself to the registrar server and sends inside the registration message the identity associated to the user client. The registrar server creates a large number of bits, say N, as a secret when it receives the registration message and replies to client with a value, which is computed with the N value and the identity of the user client. This value is the password for the user client. Then the registrar server computes a number r, which is generated with identities of the user client and registrar server, a hashfunction of user client identity with N, and a hashfunction of server identity with N. The user client initiating the call is required to authenticate itself with the outbound proxy of the trusted SIP domain. The user client sends request with the parameters as follows. With the password, received in registration, user client creates a secret random number R. Also the client generates a number n by computing it with the r and the password. In addition to those, user client computes a timestamp and a temporary key K. K is created with the timestamp and the password. The secret random number R is then encrypted with key K. Then user client sends the parameter A, as in figure 2. The A consists of n, R encrypted using K, identity of registrar and timestamp. When proxy server receives the request A with the parameters, it compares the timestamp in A and current time in order to verify that the message is in acceptable timeframe. After this, proxy server verifies the user client with registrar server using the proxy certificate and the parameters received in message B. The message B is sent by the proxy to registrar. After receiving message B, the registrar replies to it by sending a message C to proxy server, if the user client is identified and authorized in this domain. The proxy server then sends to the user client a temporary certificate, which is valid until the timestamp associated with the certificate expires. The proxy encrypts the certificate with session key, which is then used for all signalling traffic. When user client

4 receives the message D containing the encrypted certificate, it has got a temporary certificate and the session key to continue the call establishment to receiving user client. The details and computation equations of the messages B, C and D are out of the scope of this article. When the call is established between calling user client and called user s server, the identity information is shared. The server of the called user verifies the received certificate and if it is valid, it saves the session key and allows call to be established to called user client. 3.4 Lightweight scheme for authentication User clients register to the registrar server in SIP and though enable the SIP contact address binding to IP address of the user client [1]. The registration binding expires in certain time after registration, for example in a matter of hours, and then a new registration is needed. If the registrar needs to calculate signatures for each registration, the computational overhead increases and might reveal a threat of denial-ofservice attack. In this section we introduce a lightweight scheme, which can be used for SIP user authentication and securing the integrity of SIP contact addresses. This lightweight scheme is developed by Kong et al [11]. The scheme proposes that user client phones do the signing of their contact addresses instead of the registrar server. As an assumption in this scheme is, that the registrar servers have pre-issued certificates which are issued by trusted authority, and that the SIP servers in both calling party and called party domain trust each other. Each user client creates a pair of public key and private key, from which the private key is stored to client machine and public key distributed to registrar server. In registration, client signs the registration message with the public key of itself and the registrar verifies that registration message with the public key of the client. The authors [11] claim that verifying the messages signed by the user client requires less computational effort than creating signatures to clients. The scenario of public key usage is easy to achieve inside the trusted domain by distributing the public keys to all user clients, but how can users in that domain reach the users in other domain securely? The distribution of public keys in the scenario of [11] is handled by using Transport Layer Security (TLS) and Secure Sockets Layer (SSL) [12, 11]. The user client which does not have the public key of the user in other domain, initiates the call by opening a SSL/TLS channel to the proxy of the home domain. The proxy then retrieves the public key of the called user from the proxy in the other domain. The retrieval of called user public key is assumed to be secure and enabled by the assumption that the proxies are issued with certificates. Therefore the calling user receives the public key from the proxy in home domain through the opened secure SSL/TLS channel. The same secure channel is also used to send the public key of the caller to called party. The use of SSL/TLS channel is only needed when public key is exchanged, which happens at first call initiation when caller does not have the public key of the called party at all, or when the public key expires and a new one is needed. At meantime, the usual SIP can be used. 4 Issues and analysis of the SIP user authentication Previous sections in this paper have introduced mechanisms for authentication in SIP. The solutions are either from the original SIP specification [1] or defined by other parties. In this section, we will define and analyze the problems and issues related to authentication in SIP. 4.1 Problems in SIP authentication The HTTP digest authentication in SIP, introduced in section 3.1, suffers from two major weaknesses when it is applied in SIP, as Salsano et al state in their article of SIP security issues [3]. The first missing security issue is the lack of securing all headers and parameters in SIP which would possibly need protection. The second security weakness related to digest authentication is the requirement of pre-existing user configuration on servers, which does not scale well. S/MIME in SIP is used in carrying signed or encrypted replicates of headers and in authentication of users, as presented in section 3.2. This mechanism lacks the public key distribution problem, which means that the public keys used in authentication are difficult to distribute and maintain. The public key infrastructure is also susceptible to man-in-themiddle attack. [3] The authentication scheme for a trusted SIP domain, presented in 3.3 and based on [10], introduced an new authentication technique for user clients. It uses several hash computations and server certificates to ensure security. We think that there are problems in this solution in performance and overhead. The fact that outbound server and registrar server create user certificates and compute multiple functions in authentication [10], causes additional load and decreases the overall performance of the server. Also, if the load increases, the server comes more vulnerable to denial of service attacks as stated in [6, 11]. The authors of [10] claim, that their solution, tested with Pentium III 1.0 GHz processor, increased the processing overhead of SIP messages by 10 ms. The overhead was 60 ms without their solution and 70 ms with it. Our opinion is that from the performance point of view, in this solution there are too many computationally expensive operations to achieve authentication. The lightweight scheme defined by Kong et al [11], which we introduced in section 3.4, presents another solution for authentication in SIP. This mechanism uses SIP user client phones in signing contact addresses instead of the registrar servers. The authors claim, that this solution performs approximately same as using SIP traditionally. They have tested the throughput of a SIP server in call setup phase and evaluated the results by the amount of INVITE requests served per minute. The authors state also that using their solution performs approximately similar as when using traditional SIP. The actual amount of throughput is not given in the article of the lightweight scheme, but they present their findings in informative graph, which indicates that their solution is supposed to perform as they claim it is. Our opinion is, that this solution is performing well if the results presented by the authors are correct. Also, compared to the authentication scheme for a trusted SIP domain, presented in section

5 3.3, we think that this solution is performing well. 4.2 Analysis We think the security holes and problems in SIP user authentication are severe and should be noted when applying the SIP technology. As introduced in previous subsection, each of the solutions have their advantages and disadvantages. The HTTP digest authentication in SIP does not secure all the headers, which would need security. We think, that this weakness enables security threat since the registration hijacking scenario might be feasible also in this case. That scenario could possibly reveal to attacker personal data or other valuable information. Also the scalability problem related to digest mechanism is decreasing the use of it. The pre-configuration of users on servers is not very usable in large-scale, and the problem expands if there are many SIP users who join and leave frequently the domain. What comes to public key usage in authentication, there are some point-of-views to it. Though the public keys could be used to sign for example the contact addresses of the user clients, the sign operation is computationally expensive. Therefore, from the performance point-of-view, if the SIP user client phones do the signing of their contact addresses, the performance is claimed to be better than using SIP servers in signing. This might be true as the SIP servers are connected to many user clients, and the user clients only to that server. This leads to a star topology of SIP network inside a domain, where the SIP server is in the middle and user clients in the branches of the star. Therefore, distribution of any computationally expensive operation to branches of the star decreases the overall load of the server and decreases the threat of denial-of-service attack. From the security point-ofview, the distribution of user client public keys in a secure way could be problematic. When user client enters the domain, how can it distribute the public key of it without being man-in-the-middle attacked? Or from the scalability pointof-view, how can the user client distribute the public keys to all receiving peers it is going to contact? We find these problems related to public key usage in authentication an issue of future work and deeper research. 5 Conclusions In this article we have studied current solutions for authentication in SIP. The Session Initiation Protocol (SIP) and security threats from the VoIP and SIP point-of-view were introduced. The authentication in general and different kind of attack scenarios which might be possible when using VoIP technologies, especially SIP, were also presented. The solutions for authentication in using SIP were introduced in detail. These include mechanisms from SIP specification, for example the SIP authentication based on HTTP digest and the usage of S/MIME in SIP. There exists also other solutions, for instance an authentication scheme for a trusted domain and a lightweight scheme for authenticating users in SIP. We analyse the presented authentication mechanism and the problems related to them. The findings in this research are that SIP authentication, HTTP digest authentication in SIP, is not providing security at acceptable level. In addition, the usage of S/MIME suffers from the use of public key infrastructure. The two mechanisms for authentication in SIP, the authentication scheme for a trusted domain and the lightweight scheme provide some advantages in contrast to original SIP methods. References [1] Rosenberg J., Schulzrinne H., Camarillo G., Johnston A., Peterson J., Sparks R., Handley M. and Schooler E. SIP: Session Initiation Protocol. RFC 3261, IETF Network Working Group, June [2] Gooden Bur. Voice over Internet protocol (VoIP). In Proceedings of the IEEE, Volume 90, Issue 9, Sep Page(s): [3] Salsano Stefano, Veltri Luca and Papalilo Donald. SIP security issues: the SIP authentication procedure and its processing load. IEEE Network, Volume 16, Issue 6, Nov-Dec Page(s): [4] Handley J. and Jacobson V. SDP: Session Description Protocol. RFC 2327, IETF Network Working Group, April [5] Lowe Gavin. A Hierarchy of Authentication Specifications. Computer Security Foundations Workshop, Proceedings, June Page(s): [6] Thermos Peter. Two attacks against VoIP. SecurityFocus, April [7] Cao F. and Jennings C. Providing response identity and authentication in IP telephony. Availability, Reliability and Security, April [8] Franks J., Hallam-Baker P., Hostetler J., Lawrence S., Leach P., Luotonen A. and Stewart L. HTTP Authentication: Basic and Digest Access Authentication. RFC 2617, IETF Network Working Group, June [9] Peterson J. Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format. RFC 3893, IETF Network Working Group, September [10] Srinivasan R., Vaidehi V., Harish K., Lakshmi- Narasimhan K., LokeshwerBabu S. and Srikanth V. Authentication of Signalling in VoIP Applications. Communications, Asia-Pacific Conference, Oct Page(s): [11] Kong L., Balasubramaniyan V.B. and Ahamad M. A lightweight scheme for securely and reliably locating SIP users. VoIP Management and Security, IEEE Workshop, Apr Page(s): [12] Dierks T and Allen C. The TLS protocol version 1.0. RFC 2246, IETF Network Working Group, January 1999.