DISPATCH S. Srivastava Internet-Draft Digitalall Intended status: Standards Track Oct 5, 2011 Expires: April 7, 2012 Avoidance of Security Issues in SIP and Internet draft-srivastava-dispatch-avoidance-of-threats-00 Abstract This memo lists the security issues not addressed by SIPS and other drafts in progress. It provides two solutions to it. First solution calls for fixing issues one by one. The second solution avoids the security issues altogether. It has potential to obviate the need of 'Security Consideration' section from IETF documents. It requires wider acceptance from the community. Author is requesting IETF community to voice it's opinion and share the second solution with non-IETF members also to have their opinion. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 7, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Srivastava Expires April 7, 2012 [Page 1] Internet-Draft Avoidance of Threats Oct 2011 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Encryption Issues . . . . . . . . . . . . . . . . . . . . . 3 2.2. Non-Encryption Issues . . . . . . . . . . . . . . . . . . . 4 3. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Detecting And Fixing . . . . . . . . . . . . . . . . . . . 4 3.2. Avoidance Of Threats . . . . . . . . . . . . . . . . . . . 5 3.3. Future Work . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. IPR Consideration . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Srivastava Expires April 7, 2012 [Page 2] Internet-Draft Avoidance of Threats Oct 2011 1. Requirements notation 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 [RFC2119] and indicate requirement levels for compliant mechanisms. 2. Problem Statement SIPS [RFC5630] by amending SIP [RFC3261] and draft-jennings-sip-dtls-05 [I-D.jennings-sip-dtls] leaves following encryption related issues unaddressed: 2.1. Encryption Issues o 1 SIP network is used to transport other URI schemes (e.g tel, im, pres). SIPS tells security about SIP URI but others are not addressed. In future, we might use SIP network to transport other URI also. SIPS for SIP, telS for tel etc is unmodular solution. Moreover SIPS kind of solution doubles the entries in registrar and DNS. o 2 SIPS [RFC5630] underspecifies the feature control. e.g. It meant that the proper authorization is needed to replace secure dialog by unsecure etc. Dialog identifier is call-id, to-tag, from-tag. It doesn't contain secure/unsecure (security-level) information. o 3 SIPS [RFC5630] uses "tls" in via header and it hides whether TCP or SCTP is used. Whereas draft-jennings-sip-dtls-05 [I-D.jennings-sip-dtls] differentiates between DTLS over UDP and DCCP. These solutions do not take into account existence of IPSEC tunnels between SIP addressable entities (IMS CSCF). In this case, SIPS in its current form causes encryption to happen at two layers. Transport and Secure protocol should be completely disjoint for future extensability. o 4 Secure protcol is one variant. Different cipher-suites are supported by different secure protocols. Based on the usage scenario different levels of security techniques are needed. US DOD considers AES256 as top secret, whereas a small shop owner in downtown might consider using DES, to avoid heavy resource requirement of AES256. Moreover as the computing/networking technologies (parallelism etc) advances and these resources become cheaper in future, breaking of existing cipher-suites cannot be ruled out. Need of the development of different cipher-suites in the past can be used as an indication for this trend. Cipher-suites are not exposed in SIP. An application cannot enforce AES256 at every SIP hop in the current Srivastava Expires April 7, 2012 [Page 3] Internet-Draft Avoidance of Threats Oct 2011 specification. Degradation of cipher-suites is very much possible. o 5 SIPS [RFC5630] has modified the text to fix the issues of retargeting, last hop exception arising out of SIP [RFC3261]. Yet it is hard for implementors to understand it and cover each use case due to complexity of it. In summary secure routing and secure reachability are two different requirements which are bundled together with resource property namely SIPS URI scheme. The hop by hop nature of SIP makes it hard to understand what needs to be done where. SIP is not like HTTP. There is very thick line between resource and routing. Therefore we have been witnessing issues in understanding of the problem itself. 2.2. Non-Encryption Issues The above deals in encryption / integrity of SIP messages at the hops. The above doesn't deal in other possible security issues such as call pattern tracking (There is still possibility of an organization to know about which research department of competitor is talking to patent lawyers to know about the stealth projects/area of research), Denial of service attacks, identity theft, spam etc. There is still possibility of misuse of any confidential information of customer/vendor etc by word of mouth by the entity keeping that information to potential competitors or gang of cheaters. Refer details of other unfair scenarios in different articles on The Dreamer [1] 3. Proposed Solutions 3.1. Detecting And Fixing Encryption related issues pertaining to SIP can be handled with the proposed solution in draft-srivastava-sip-e2e-ciphersuites-00 [I-D.srivastava-sip-e2e-ciphersuites] with a separate header describing secure protocols, cipher-suites; and tags for Proxy- Require and Require header. This solution addresses the issues described in Section 2.1. Denial of Service Attack, Call Pattern Tracking, spam etc issues have been always in N+1 cycle of detecting and solving. The current solutions donot address these by avoidance. As the vote is being sought for much bigger solution as described below, the solution of draft-srivastava-sip-e2e-ciphersuites-00 [I-D.srivastava-sip-e2e-ciphersuites] is not described in details here. Srivastava Expires April 7, 2012 [Page 4] Internet-Draft Avoidance of Threats Oct 2011 3.2. Avoidance Of Threats Refer information pertaining to Cashless Economy on The Dreamer [1] . Cashless Economy is achieved via Complete Digital World i.e. every person/entity involving business transactions has computing device(s) to do business transactions. In Complete Digital World, the common denominator of valuation is handled ONLY in computing devices, henceforth it is called as Soft Earning Unit (SEU). Cashless Economy provides end-to-end traceability to earnings/spendings. Linkage of communication records with earnings /spendings can catch the spammer always. Therefore traceability of SEU avoids this problem. Heavy encryption is not needed for deals resulting in direct transactions in money. Encryption will be needed for privacy sensitive information exchange such as stealth projects, defence mattters etc. Financial information pertaining to earnings/spendings can be exchanged with NULL encryption ciphers. Cashless economy avoids other non-internet related problems (such as terrorism, illegally printed currency bills, bribery etc) due to parallel economy of bad guys. Conversely, it is the application which will eliminate the digital /communication divide (which we have been talking for a long). Refer information pertaining to Complete Multimedia Recording on The Dreamer [1] . The current work carried out in SIP Recording (siprec) group deals in solutions for session recordings. Complete Multimedia Recording captures audio and video across time and space dimensions, even if there is no active session. In the proposed solution computing devices will capture the recordings of the walled space and satellites will capture recordings of open space. As everything is captured, whenever an attacker tries to intrude, (s)he will be caught somewhere in the recordings. As persons performing bad/illegal activities will be caught somewhere and as evidences cannot be manipulated (manipulation will be caught somewhere too), bad activities will not happen. It will avoid the issues like man-in- middle attack, denial of service attacks, identity theft, hacking of hosted email ids, online service providers games under the cover of hackers. This will obviate the need of complex encryption and integrity protection mechanism of messages. In the Complete Multimedia Recording environment, we will need bare minimum checksums for catching malfunctioning of computing resources. It will obviate the need of 'Security Consideration' section of the IETF documents. Apart from fixing security related issues for internet, it avoids the need of complex laws, misuse of any technology, miuse of any confidential traceability information via word of mouth etc. Due to wide spread usage of unfair business practices even by top leaders, it has not been possible to find starting point of the change. Everybody complains about it, but nobody wants to take lead. Srivastava Expires April 7, 2012 [Page 5] Internet-Draft Avoidance of Threats Oct 2011 As they argue that why they should be deprived; others should stop first. The proposed migration plan of Cashless Economy and Complete Multimedia Recording brings out a important silent point that things will be changed at a SINGLE point of time. So the big chunk of people who WANT to be fair and honest, will become advocate of the proposed change. Moreover everyone understands very well the difference between fair/unfair actions before commiting any unfair actions. 3.3. Future Work Author is humbly requesting the community to vote/voice their opinion for the alternatives described above. Either we end up fixing the security issues with N+1 cycle (solution of Section 3.1 ) as we have been doing till now, or take a route to avoid the security issues via proposed solutions in Section 3.2. Any opinion/flame even via annonymously is welcome. 4. Security Considerations This memo deals in Security Issues for SIP. It proposes two solutions. The solution of avoidance of threats applies to internet also. That solution has potential to obviate the need of this section from IETF documents in future. 5. IANA Considerations This document has no IANA actions. 6. IPR Consideration Author is pursuing published patent applications PCT/US2008/066617, PCT/US2008/069273, PCT/US2008/082929, PCT/US2008/083704, PCT/US2008/ 013284, PCT/US2008/013285 alongwith other unpublished patents for ideas descreibed in this draft The copyright for the referred work at The Dreamer [1] is free for individual personal usage. For IPR related issues, please contact at srivastava_samir at hush dot com alongwith samirs.lists at gmail dot com . Srivastava Expires April 7, 2012 [Page 6] Internet-Draft Avoidance of Threats Oct 2011 7. Acknowledgements Author would like to thank Khosla Ventures whom slide set on Cashless Economy was sent in 07 which gave author the feeling of value of the idea. During the article on Cashless Economy author thought of Complete Multimedia Recordings which is needed for solving white collar terrorism and complex laws. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009. 8.2. Informative References [I-D.jennings-sip-dtls] Jennings, C. and N. Modadugu, "Session Initiation Protocol (SIP) over Datagram Transport Layer Security (DTLS)", draft-jennings-sip-dtls-05 (work in progress), October 2007. [I-D.srivastava-sip-e2e-ciphersuites] Srivastava, S., "Ensuring End to End Cipher Suites in SIP", draft-srivastava-sip-e2e-ciphersuites-00 (work in progress), June 2006. URIs [1] Srivastava Expires April 7, 2012 [Page 7] Internet-Draft Avoidance of Threats Oct 2011 Author's Address Samir Srivastava Digitalall Email: samirs.lists@gmail.com Srivastava Expires April 7, 2012 [Page 8]