idnits 2.17.1 draft-choi-sipping-experiments-spit-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 498. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2007) is 6006 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-froment-sipping-spit-requirements-01 == Outdated reference: A later version (-04) exists of draft-tschofenig-sipping-framework-spit-reduction-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Jaeduck Choi 2 Internet Draft Souhwan Jung 3 Intended status: Informational Yujung Jang 4 Expires: May 15, 2008 Soongsil University 5 Yoojae Won 6 Youngduk Cho 7 KISA 8 November 16, 2007 10 Experiments on SPIT in the Commercial VoIP Services 11 draft-choi-sipping-experiments-spit-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that 16 any applicable patent or other IPR claims of which he or she is 17 aware have been or will be disclosed, and any of which he or she 18 becomes aware will be disclosed, in accordance with Section 6 of 19 BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on May 15, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document shows some experimental results on SPIT on commercial 46 VoIP services, in which a SIP UA has not been secured by SIP security 47 protocol such as TLS. Although many service providers have been 48 applying the HTTP digest scheme to authenticate a SIP UA, they often 49 do not apply SIP signaling protection against potential threats 50 between the SIP UA and the SIP proxy. This cause vulnerabilities to 51 the VoIP services like SPIT. The aim of this memo is to inform the 52 service providers of SPIT threats by showing some experimental 53 results of SPIT on current VoIP networks. 55 Table of Contents 57 1. Introduction...................................................2 58 2. Terminology....................................................4 59 3. Experiments on SPIT............................................4 60 3.1. The SPIT between the UAC and the Outbound Proxy...........5 61 3.2. The SPIT between the Inbound Proxy and the UAS............6 62 3.3. The SPIT between the Outbound Proxy and the Inbound Proxy.7 63 3.4. The SPIT using Replay Attack..............................8 64 3.5. The SPIT using Dictionary Attack.........................10 65 4. Security Considerations.......................................10 66 5. IANA Considerations...........................................10 67 6. References....................................................11 68 6.1. Normative References.....................................11 69 6.2. Informative References...................................11 70 Author's Addresses...............................................12 71 Intellectual Property Statement..................................13 72 Disclaimer of Validity...........................................13 73 Copyright Statement..............................................14 74 Acknowledgment...................................................14 76 1. Introduction 78 The SPIT (SPam over Internet Telephony) [2] can be classified into 79 two categories: the SPIT sent on path associated with SIP signaling 80 and off path. 82 The SPIT sent on path associated with SIP signaling means that a 83 spammer who registered the VoIP service sends the SPIT message. For 84 sending SPIT, spammers SHOULD register a VoIP service, and then could 85 send a SPIT only through normal signaling routes. The studies on 86 protecting this SPIT have been discussed in several drafts 87 [4][5][6][7][8] at the SIPPING WG. The SPIT on sip signaling route is 88 out of the scope of this draft. 90 In case of the abnormal routes, a spammer who did not register to the 91 VoIP services tries to send the SPIT message using replay attack, 92 dictionary attack, or sniffing. It is not easy for spammers to send 93 this SPIT if the security mechanisms specified in the SIP protocol 94 [3] are applied to all the signaling routes in SIP: among the UA, 95 proxy, registrar, and so on. In many cases, however, the TLS 96 mechanism is not applied between the SIP nodes, this SPIT still works 97 between the UA and the SIP proxy or the SIP proxy servers. The 98 spammer can send SIP messages like INVITE or 200 OK directly to the 99 UA or the SIP proxy, and then communicate with the user by 100 establishing a media channel. 102 Currently, VoIP providers have been applying only the HTTP digest 103 scheme to authenticate a UA. They do not consider protecting SIP 104 signaling between the UA and the SIP proxy. On the commercial 105 networks where the TLS mechanism is not applied, some SPIT scenarios 106 were tested as follows. 108 - The SPIT between the UAC and the Outbound Proxy 109 - The SPIT between the Inbound Proxy and the UAS 110 - The SPIT between the Outbound Proxy and the Inbound Proxy 111 - The SPIT using Replay Attack 112 - The SPIT using Dictionary Attack 114 Although both the UA and the spammer belong to the same local area 115 network during experiments, it is possible for the spammer with 116 sophisticated spywares or monitoring tools to send a SPIT to the 117 remote users. 119 The goal of this document is to inform service providers of potential 120 SPIT threats by showing some experimental results on SPIT on current 121 VoIP networks so that they SHOULD carefully consider applying the TLS 122 mechanism to the SIP UA. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC-2119 [1]. 130 Two terminologies are defined in this document. 132 A normal route in SPIT: The SPIT sent through a normal signaling 133 route by a spammer who registered the VoIP service. 135 An abnormal route in SPIT: The SPIT sent through an abnormal 136 signaling route by a spammer who did not register the VoIP service. 138 3. Experiments on SPIT 140 The experiments are performed on the following networks. 142 - Three commercial VoIP providers 144 - Three commercial UAs and two open UAs 146 There is no TLS mechanism applied among the UAC, UAS, and Proxy 147 servers. Also, the UA and the spammer belong to the same LAN so that 148 the spammer can sniff SIP messages and send them directly to the UA. 150 +-------------+ +-------------------------+ +-------------+ 151 | LAN A | | Internet | | LAN B | 152 | | | | | | 153 |+---+ | | +--------+ +--------+ | | +---+| 154 || | | | |Outbound| |Inbound | | | | || 155 ||UAC|--------|--|-| Proxy |---| Proxy |-|--|--------|UAS|| 156 |+---+ | | | +--------+ | +--------+ | | | +---+| 157 | | | | | | | | | 158 | +---+---+ | | +---+---+ | | +---+---+ | 159 | |Spammer| | | |Spammer| | | |Spammer| | 160 | +-------+ | | +-------+ | | +-------+ | 161 +-------------+ +-------------------------+ +-------------+ 162 Figure 1 : Configuration of SPIT Testbed 164 3.1. The SPIT between the UAC and the Outbound Proxy 166 This experiment shows that the spammer sends a 200 OK response to the 167 UAC in complying with an INVITE message initiated by an UA as a call 168 request to the UAS. Figure 2 shows the message flow of our 169 experiment. When the spammer senses the INVITE message, he generates 170 a 200 OK message, spoofs IP address of the proxy server, and then 171 replies with the 200 OK message. Upon receiving the 200 OK message, 172 the media channel might be established between the UAC and the 173 spammer. As a result, the spammer could play out a recorded 174 announcement or communicate with the UAS. In the experiment, this 175 SPIT succeeded at all the tested UAs. 177 UAC Outbound Proxy Inbound Proxy UAS 178 | | | | 179 | INVITE | | | 180 |------------------>| | | 181 | 407 | | | 182 |<------------------| | | 183 | ACK | | | 184 |------------------>| | | 185 | INVITE(Credential)| | | 186 |------------------>| INVITE | | 187 | |------------------>| INVITE | 188 | Spammer | |------------------>| 189 | | | | | 190 | 200 OK | | | | 191 |<--------| | | | 192 | ACK | | | | 193 |-------->| | | | 194 | RTP | | | 180 Ring | 195 |<=======>| | 180 Ring |<------------------| 196 | 180 Ring |<------------------| 200 OK | 197 Ingnore<---------------| 200 OK |<------------------| 198 | 200 OK |<------------------| | 199 Ingnore<---------------| | | 200 | | | | | 201 Figure 2 : The Message Flow of the SPIT between the UAC and the Proxy 203 This SPIT was possible because the spammer could easily sniff the 204 INVITE message. If the TLS mechanism is used between the UA and proxy 205 server, this SPIT can be protected. 207 3.2. The SPIT between the Inbound Proxy and the UAS 209 This scenario that spammers can directly send SIP calls to the UAS 210 using P2P call signaling has been discussed on the draft [9]. This 211 document shows an experimental result using this scenario on 212 commercial VoIP networks. Figure 3 shows the message flow of our 213 experiment. To make a direct call, the spammer generates an INVITE 214 message and sends it to the UAS. The spammer needs to sniff the 200 215 OK message from the UAS. The 200 OK message includes the IP address 216 and port number for media session. Upon sniffing the 200 OK, the 217 spammer could play out a recorded announcement or communicate with 218 the UAS. In our test, this SPIT worked at all the UA's. 220 Also, the one-ring SPIT is tested. In this case, the spammer sends 221 only the INVITE message without sniffing the corresponding 200 OK 222 message. When the UAS receives the INVITE message, the phone is 223 ringing and the SIP URI is displayed at the user. The user who feels 224 curious about the name ID might make a return call to the caller. 225 Consequently, the spammer can make a successful talk with the callee. 226 This SPIT also worked at all the UAs during our experiments. 228 UAC Outbound Proxy Inbound Proxy UAS 229 | | | | 230 | | | Spammer | 231 | | | | | 232 | | | | INVITE | 233 | | | |-------->| 234 | | | |180 Ring | 235 | | Ignore<----------------| 236 | | | | 200 OK | 237 | | Ignore<----------------| 238 | | | | ACK | 239 | | | |-------->| 240 | | | | RTP | 241 | | | |<=======>| 242 | | | | | 243 Figure 3 : The Message Flow of the SPIT between the Proxy and the UA 245 This SPIT was also possible because the TLS was not established 246 between the proxy server and the UAS. If the TLS was applied to the 247 UAS, the INVITE message sent by the spammer could be blocked during 248 the TLS process. Hence, the INVITE message could be dropped. 250 3.3. The SPIT between the Outbound Proxy and the Inbound Proxy 252 Without using the TLS between SIP servers, the spammer who 253 impersonates a legitimate outbound proxy server can send a SPIT 254 message via inbound proxy server of the UAS. This is similar to the 255 SPIT between the inbound proxy and UAS. Figure 4 shows the message 256 flow of our experiment. First of all, the spammer generates the 257 INVITE message including the information of the legitimate outbound 258 proxy server and the UAC, and then sends the message to the inbound 259 proxy. The inbound proxy server normally handles this message. After 260 sending the INVITE message, the spammer performs the same procedure 261 as the section 3.2. As a result, the spammer could play out a 262 recorded announcement or communicate with the UAS. In the 263 experiment, this SPIT succeeded in the environment where the TLS 264 is not applied between the proxy servers. 266 UAC Outbound Proxy Inbound Proxy UAS 267 | | | | 268 | | Spammer | | 269 | | | | | 270 | | | INVITE | | 271 | | |-------->| INVITE | 272 | | | |------------------>| 273 | | | | 180 Ring | 274 | | |180 Ring |<------------------| 275 | Ingnore<---------------| | 276 | | | | 200 OK | 277 | | | 200 OK |<------------------| 278 | Ingnore<---------------| | 279 | | | ACK | | 280 | | |-------->| ACK | 281 | | | |------------------>| 282 | | | | RTP | 283 | | |<===========================>| 284 | | | | | 285 Figure 4 : The Message Flow of the SPIT between the Outbound Proxy 286 and Inbound Proxy 288 This SPIT was also possible because the TLS was not established 289 between the proxy servers. If the TLS was applied to the proxy 290 server, the spammer could not send the SIP messages. 292 3.4. The SPIT using Replay Attack 294 This SPIT is that the spammer tries to send a SPIT message using 295 replay attack after terminating the session between the UAC and UAS. 296 Figure 5 shows the message flow of our experiment. For sending SPIT, 297 the spammer should sniff the INVITE message including a credential. 298 The spammer sends the BYE message to the UAS to terminate the 299 established session. And then, the spammer tries to send the sniffed 300 INVITE message including the credential. This SPIT worked at all the 301 VoIP providers during our experiments. 303 UAC Outbound Proxy Inbound Proxy UAS 304 | | | | 305 |INVITE (Credential)| | | 306 | (spammer sniffing)| | | 307 |------------------>| INVITE | | 308 | |------------------>| INVITE | 309 | | |------------------>| 310 | | | 180 Ring | 311 | | 180 Ring |<------------------| 312 | 180 Ring |<------------------| 200 OK | 313 |<------------------| 200 OK |<------------------| 314 | 200 OK |<------------------| | 315 |<------------------| | | 316 | Spammer | | | 317 | | BYE | | | 318 | |-------->| BYE | | 319 | | |------------------>| BYE | 320 | | | |------------------>| 321 : : : : : 322 | | INVITE | | | 323 | |(Credential) | | 324 | |-------->| INVITE | | 325 | | |------------------>| INVITE | 326 | | | |------------------>| 327 | | | | 180 Ring | 328 | | | 180 Ring |<------------------| 329 | |180 Ring |<------------------| 200 OK | 330 |<------------------| 200 OK |<------------------| 331 | | 200 OK |<------------------| | 332 Ingnore <--------------| | | 333 | | ACK | | | 334 | |-------->| ACK | | 335 | | |------------------>| ACK | 336 | | | |------------------>| 337 | | | RTP | | 338 |<=========================================================>| 339 | | | | | 340 Figure 5 : The Message Flow of the SPIT Using Replay attack 342 This SPIT was possible because the TLS was not established between 343 the UAC and outbound proxy server, and the digest authentication 344 scheme was not applied to the BYE message. If the TLS or digest 345 scheme was applied to the UAC, the spammer could not send the SIP 346 messages. 348 3.5. The SPIT using Dictionary Attack 350 The spammer can send a SPIT message to the UA through normal routes 351 without revealing his position and privacy information. When the TLS 352 is not used at the UA, the spammer can apply the dictionary attack 353 with credential value obtained by sniffing to guess the legitimate 354 password. If the attack is successful, the spammer can make a call 355 spam via normal routes in SIP network without disclosing any of his 356 information. 358 Anybody could easily sniff the REGISTER or INVITE messages on the 359 deployed VoIP networks. They could also guess the legitimate password 360 of a UA using dictionary attack tools. For the reason, VoIP service 361 providers SHOULD apply the TLS mechanism between the UA and the SIP 362 server such as registrar and proxy server. 364 4. Security Considerations 366 This document showed some experimental results on feasible SPIT 367 scenarios on commercial VoIP networks. Spammers might try to directly 368 send SPIT to the UA or proxy server, on abnormal routes in SIP-based 369 networks. If the TLS mechanism is used among the UAC, proxy, 370 registrar, and UAS, these SPIT can be protected. The VoIP providers, 371 however, have not been applying the TLS mechanism at the UA or proxy 372 servers. Hence, the SPIT worked at all the commercial UAs during our 373 experiments. Although our experiments were performed at the situation 374 that both commercial UA and spammer belong to the same local area 375 network, it is possible for the spammer to send a SPIT to a remote UA 376 using spyware or hacking tools. 378 Therefore, it is necessary for service providers to apply strictly 379 the TLS mechanism to the UA and proxy server. If the TLS is used, it 380 is difficult for spammers who want to know information for 381 establishing media session to sniff the SIP messages. The 382 authentication value can be protected by the same reason. 384 5. IANA Considerations 386 This document does not require actions by IANA. 388 6. References 390 6.1. Normative References 392 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 393 Levels", BCP 14, RFC 2119, March 1997. 395 6.2. Informative References 397 [2] Rosenberg, J., and Jennings, C., "The Session Initiation 398 Protocol (SIP) and Spam", draft-ietf-sipping-spam-05, July 2007. 400 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Jonston, A., 401 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 402 Session Initiation Protocol", RFC 3261, June 2002. 404 [4] Hannes, T., Geoffrey, D., Thomas, F., Dan, W., and Henning, 405 S., "Requirements for Authorization Policies to tackle Spam for 406 Internet Telephony and Unwanted Trafic", draft-froment-sipping- 407 spit-requirements-01, July 2007. 409 [5] Saverio, N. and Juergen, Q., "signaling To Prevent SPIT 410 (SPITSTOP) Reference Scenario", draft-niccolini-sipping- 411 spitstop, January 2007. 413 [6] Geoffrey, D., Thomas, F., and Hannes, T., "Authorization 414 Policies for Preventing SPIT", draft-froment-sipping-spit- 415 authz-policies-02, February 2007. 417 [7] Saverio, N., Sandra, T., Martin, S., and Samir, S. "SIP 418 Extensiions for SPIT Identification", draft-niccolini-sipping- 419 feedback-spit-03, February 2007. 421 [8] Hannes, T., Henning, S., Dan, W., Jonathan, R., and David, S. 422 "A Framewor for Reducing Spam for Internet Telephony", draft- 423 tschofenig-sipping-framework-spit-reduction-01, July 2007. 425 [9] Jung, S., Choi, J., Won, Y., and Cho, Y., "Authentication 426 between the Inbound Proxy and the UAS for Protecting SPIT in 427 the Session Initiation Protocol (SIP)", draft-jung-sipping- 428 authentication-spit-00, October 2006. 430 Author's Addresses 432 Jaeduck Choi 433 Soongsil University 434 511, Sangdo-dong, Dongjak-ku 435 Seoul 156-743 436 KOREA 438 Phone: +82-2-824-1807 439 Email: cjduck@cns.ssu.ac.kr 441 Souhwan Jung 442 Soongsil University 443 511, Sangdo-dong, Dongjak-ku 444 Seoul 156-743 445 KOREA 447 Phone: +82-2-820-0714 448 Email: souhwanj@ssu.ac.kr 450 Yujung Jang 451 Soongsil University 452 511, Sangdo-dong, Dongjak-ku 453 Seoul 156-743 454 KOREA 456 Phone: +82-2-824-1807 457 Email: lilyuwjd@cns.ssu.ac.kr 459 Yoojae Won 460 Korea Information Security Agency 461 78, Karak-dong, Songpa-Gu 462 Seoul 138-160 463 KOREA 465 Phone: +82-2-405-5548 466 Email: yjwon@kisa.or.kr 467 Youngduk Cho 468 Korea Information Security Agency 469 78, Karak-dong, Songpa-Gu 470 Seoul 138-160 471 KOREA 473 Phone: +82-2-405-5548 474 Email: ydcho@kisa.or.kr 476 Intellectual Property Statement 478 The IETF takes no position regarding the validity or scope of any 479 Intellectual Property Rights or other rights that might be claimed to 480 pertain to the implementation or use of the technology described in 481 this document or the extent to which any license under such rights 482 might or might not be available; nor does it represent that it has 483 made any independent effort to identify any such rights. Information 484 on the procedures with respect to rights in RFC documents can be 485 found in BCP 78 and BCP 79. 487 Copies of IPR disclosures made to the IETF Secretariat and any 488 assurances of licenses to be made available, or the result of an 489 attempt made to obtain a general license or permission for the use of 490 such proprietary rights by implementers or users of this 491 specification can be obtained from the IETF on-line IPR repository at 492 http://www.ietf.org/ipr. 494 The IETF invites any interested party to bring to its attention any 495 copyrights, patents or patent applications, or other proprietary 496 rights that may cover technology that may be required to implement 497 this standard. Please address the information to the IETF at 498 ietf-ipr@ietf.org. 500 Disclaimer of Validity 502 This document and the information contained herein are provided on an 503 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 504 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 505 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 506 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 507 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 508 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 510 Copyright Statement 512 Copyright (C) The Internet Trust (2007). 514 This document is subject to the rights, licenses and restrictions 515 contained in BCP 78, and except as set forth therein, the authors 516 retain all their rights. 518 Acknowledgment 520 Funding for the RFC Editor function is currently provided by the 521 Internet Society.