SIPPING Souhwan Jung Internet Draft Jaeduck Choi Expires: March 14, 2007 Soongsil University Youjae Won Young Duk Cho Korea Information Security Agency October 14, 2006 Authentication between the Inbound Proxy and the UAS for Protecting SPIT in the Session Initiation Protocol (SIP) draft-jung-sipping-authentication-spit-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 14, 2006. Abstract This memo proposes to add a digest message authentication scheme between the inbound proxy and the UAS for protecting SPIT. Spammers can directly send SIP calls (such as call spam and IM spam) to the UAS using P2P call signaling. For rejecting the SPIT, the UAS should be able to verify that the SIP messages are forwarded by the proxy server, not directly from spammers. By applying the message digest scheme similar to the HTTP digest, the UAS processes the request after assuring that the INVITE message comes through the inbound proxy server. The main advantage of this scheme is to protect SPIT by Jung, et al. Expires March 14, 2007 [Page 1] Internet-Draft Authentication for Protecting SPIT October 2006 adding a very simple message authentication scheme between the proxy server and the UAS. Table of Contents 1. Introduction....................................................2 2. Terminology.....................................................3 3. Spam Scenarios..................................................3 3.1. IM Spam....................................................3 3.2. Call Spam..................................................4 4. Authentication between Inbound Proxy and UAS....................4 4.1. UAS Behavior...............................................6 4.1.1. UAS-Authenticate......................................6 4.2. Inbound Proxy Behavior.....................................6 4.2.1. UAS-Authorization.....................................6 5. Security Considerations.........................................7 6. IANA Considerations.............................................7 7. References......................................................7 7.1. Normative References.......................................7 Author's Addresses.................................................8 Intellectual Property Statement....................................9 Disclaimer of Validity............................................10 Copyright Statement...............................................10 Acknowledgment....................................................10 1. Introduction The caller authentication in the Session Initiation Protocol (SIP) is used between a user agent and a proxy or between user agents[2]. But if the TLS mechanism is not used between the inbound proxy and the user agent server (UAS), spammers can make direct call requests such as INVITE and MESSAGE [3] to the UAS. Then the UAS may process the request messages without verifying that those messages are from the inbound proxy. For rejecting SPIT (SPam over Internet Telephony) messages, the UAS needs to assure that the INVITE messages are coming through the inbound proxy. This memo proposes to add a simple message authentication scheme between an inbound proxy and the UAS. The main advantage of this scheme is its simplicity and does require a minor modification the SIP standard document (RFC3261). This memo describes digest authentication [4] between the inbound proxy and the UAS and defines a new SIP response code and new header fields. Jung, et al. Expires August 14, 2006 [Page 2] Internet-Draft Authentication for Protecting SPIT October 2006 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 3. Spam Scenarios The existing security mechanisms in the SIP protocols are not very perfect for protecting spam calls. The RFC 3261 specifies the HTTP digest, TLS [5], and S/MIME [6] for SIP security. However, in general, the HTTP digest authentication is used only between the user agent client (UAC) and the outbound proxy, and the TLS is applied among proxy servers. The TLS mechanism is known a little bit heavy to be used between the user agent and the proxy. +---+ +--------------+ +--------------+ +---+ |UAC|-----|Outbound Proxy|-----| Inbound Proxy|-----|UAS| +---+ +--------------+ +--------------+ +->+---+ / / / direct call / +-------+ |Spammer| +-------+ Figure 1 Architecture of Spam Scenario. This section describes SIP spam (such as IM and Call spam) scenarios [7] when the TLS mechanism is not established between the inbound proxy and the UAS. Figure 1 shows the architecture of spam scenarios. 3.1. IM Spam The working scenario of an IM spam is simple. A spammer modifies the SIP URI like "sip:please-buy-my-product@spam.example.com", and then send the message directly to the UAS. The telephone is ringing and the SIP URI is displayed at the user. The IM spam step is as follows. STEP 1. Collect the SIP URI and IP addresses of victims. STEP 2. Generate the INVITE message including advertisement text. STEP 3. Spoof the IP addresses of a inbound proxy server. STEP 4. Send the INVITE messages directly to the UAS. Jung, et al. Expires August 14, 2006 [Page 3] Internet-Draft Authentication for Protecting SPIT October 2006 3.2. Call Spam To generate a call spam is more complicate than to generate the IM spam. After sending out an INVITE message, the spammer needs to sniff the 200 OK message from the UAS. The 200 OK message includes the IP address and port number for RTP session. The spammer then can make free calls using the RTP information, which saves the cost for generating spam. The step for generating call spam is as follows. STEP 1. Collect SIP URI and IP address of victims. STEP 2. Generate an INVITE message including IP address and port number of spammer for RTP session in SDP. STEP 3. Spoof the IP address of a inbound proxy server. STEP 4. Send out the INVITE message directly to the UAS. STEP 5. Sniff the 200 OK message. STEP 6. Collect the IP address and port number from the 200 OK. STEP 7. Establish communication channel with the UAS. 4. Authentication between Inbound Proxy and UAS The basic operation of digest authentication between the inbound proxy and the UAS follows the RFC 3261 and RFC 2617. This section specifies the behaviors of the inbound proxy and the UAS for the message authentication, and defines new response code (such as 497 "UAS Authenticate Required") and new header fields (such as UAS- Authenticate and UAS-Authorization). Figure 2 shows authentication flow between inbound proxy and UAS. Jung, et al. Expires August 14, 2006 [Page 4] Internet-Draft Authentication for Protecting SPIT October 2006 atlanta.com biloxi.com Alice Outbound Proxy Inbound Proxy Bob | | | | | INVITE F1 | | | |--------------->| | | | 407 F2 | | | |<---------------| | | | ACK F3 | | | |--------------->| | | | INVITE F4 | | | |--------------->| INVITE F5 | | | 100 F6 |--------------->| INVITE F7 | |<---------------| |--------------->| | | | 497 F8 | | | |<---------------| | | | INVITE F9 | | | 100 F10 |--------------->| | |<---------------| | | | | 180 F11 | | | 180 F12 |<---------------| | 180 F13 |<---------------| | |<---------------| | 200 F14 | | | 200 F15 |<---------------| | 200 F16 |<---------------| | |<---------------| | | | ACK F17 | | | |--------------->| ACK F18 | | | |--------------->| ACK F19 | | | |--------------->| | Both Way RTP Media | |<================================================>| | | | BYE F20 | | | BYE F21 |<---------------| | BYE F22 |<---------------| | |<---------------| | | | 200 F23 | | | |--------------->| 200 F24 | | | |--------------->| 200 F25 | | | |--------------->| | | | | Figure 2 SIP setup example with the proposed authentication. Jung, et al. Expires August 14, 2006 [Page 5] Internet-Draft Authentication for Protecting SPIT October 2006 4.1. UAS Behavior When a UAS receives a INVITE request, the UAS MUST verify that the message is from the inbound proxy before processing the request. If no credentials (in the UAS-Authorization header) are included in the request, the UAS MUST challenge the inbound proxy with a 497 (UAS Authentication Required) status code. 4.1.1. UAS-Authenticate An UAS-Authenticate header field contains an authentication challenge value. The usage of this header field is defined in the RFC 3261 and RFC 2617, with "Proxy-Authenticate" replaced by "UAS-Authenticate". Example: UAS-Authenticate: Digest realm="biloxi.com", domain="sip:bob.biloxi.com", qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5 4.2. Inbound Proxy Behavior When the inbound proxy receives a 497 message with the UAS Authenticate header field, the inbound proxy MUST generate credential using the password of the UAS. The inbound proxy sends back the request message with adding a UAS-Authorization header field value. The inbound proxy MUST NOT increase the CSeq in the request. The change of the CSeq value causes the UAC to discard the response from the UAS, because the CSeq value does not match to the request that the UAC sent before [2]. 4.2.1. UAS-Authorization A UAS-Authorization header field allows the inbound proxy to identify itself to a UAS that requires authentication. The usage of this header field is defined in the RFC 3261 and RFC 2617, with "Proxy- Authorization" replaced by "UAS-Authorization". Example: UAS-Authorization: Digest username="Bob", realm="biloxi.com", nonce="c60f3082ee1212b402a21831ae", response="245f23415f11432b3434341c022" Jung, et al. Expires August 14, 2006 [Page 6] Internet-Draft Authentication for Protecting SPIT October 2006 5. Security Considerations The authentication between the inbound proxy and the UAS makes the authentication structure among the three SIP components complete. This memo adds a Proxy-to-UAS authentication to the existing structure of the UAC-to-Proxy and Proxy-to-Proxy authentication. The spam, therefore, might be substantially reduced by discarding the unauthenticated messages at the UAS. The digest scheme based on the password, however, is still vulnerable to the dictionary attack. 6. IANA Considerations The IANA is requested to add the following new response code to the Methods. Response Code Number: 497 Default Reason Phrase: UAS Authentication Required The IANA is requested to add the following new SIP header fields. Header Name: UAS-Authenticate Header Name: UAS-Authorization 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Jonston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Campbell, B., Rosenberg, J. Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Prtocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. Jung, et al. Expires August 14, 2006 [Page 7] Internet-Draft Authentication for Protecting SPIT October 2006 [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [5] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [6] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [7] Rosenberg, J., Jennings, C., and Peterson, J., "The Session Initiation Protocol (SIP) and Spam", draft-ietf-sipping-spam-02 (work in progress), March 2006. Author's Addresses Souhwan Jung Soongsil University 511, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82-2-820-0714 Email: souhwanj@ssu.ac.kr Jaeduck Choi Soongsil University 511, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82-2-824-1807 Email: cjduck@cns.ssu.ac.kr Jung, et al. Expires August 14, 2006 [Page 8] Internet-Draft Authentication for Protecting SPIT October 2006 YouJae Wong Korea Information Security Agency 78, Karak dong, Songpa-Gu Seoul 138-160 KOREA Phone: +82-2-405-5548 Email: yjwon@kisa.or.kr Young Duk Cho Korea Information Security Agency 78, Karak dong, Songpa-Gu Seoul 138-160 KOREA Phone: +82-2-405-5548 Email: ydcho@kisa.or.kr Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Jung, et al. Expires August 14, 2006 [Page 9] Internet-Draft Authentication for Protecting SPIT October 2006 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jung, et al. Expires August 14, 2006 [Page 10]