idnits 2.17.1 draft-srivastava-dispatch-avoidance-of-threats-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Oct 5, 2011) is 4588 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH S. Srivastava 3 Internet-Draft Digitalall 4 Intended status: Standards Track Oct 5, 2011 5 Expires: April 7, 2012 7 Avoidance of Security Issues in SIP and Internet 8 draft-srivastava-dispatch-avoidance-of-threats-00 10 Abstract 12 This memo lists the security issues not addressed by SIPS and other 13 drafts in progress. It provides two solutions to it. First solution 14 calls for fixing issues one by one. The second solution avoids the 15 security issues altogether. It has potential to obviate the need of 16 'Security Consideration' section from IETF documents. It requires 17 wider acceptance from the community. Author is requesting IETF 18 community to voice it's opinion and share the second solution with 19 non-IETF members also to have their opinion. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 7, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 68 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Encryption Issues . . . . . . . . . . . . . . . . . . . . . 3 70 2.2. Non-Encryption Issues . . . . . . . . . . . . . . . . . . . 4 71 3. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1. Detecting And Fixing . . . . . . . . . . . . . . . . . . . 4 73 3.2. Avoidance Of Threats . . . . . . . . . . . . . . . . . . . 5 74 3.3. Future Work . . . . . . . . . . . . . . . . . . . . . . . . 6 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 77 6. IPR Consideration . . . . . . . . . . . . . . . . . . . . . . . 6 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 1. Requirements notation 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119] and indicate 89 requirement levels for compliant mechanisms. 91 2. Problem Statement 93 SIPS [RFC5630] by amending SIP [RFC3261] and 94 draft-jennings-sip-dtls-05 [I-D.jennings-sip-dtls] leaves following 95 encryption related issues unaddressed: 97 2.1. Encryption Issues 99 o 1 SIP network is used to transport other URI schemes (e.g tel, im, 100 pres). SIPS tells security about SIP URI but others are not 101 addressed. In future, we might use SIP network to transport other 102 URI also. SIPS for SIP, telS for tel etc is unmodular solution. 103 Moreover SIPS kind of solution doubles the entries in registrar and 104 DNS. 106 o 2 SIPS [RFC5630] underspecifies the feature control. e.g. It meant 107 that the proper authorization is needed to replace secure dialog by 108 unsecure etc. Dialog identifier is call-id, to-tag, from-tag. It 109 doesn't contain secure/unsecure (security-level) information. 111 o 3 SIPS [RFC5630] uses "tls" in via header and it hides whether TCP 112 or SCTP is used. Whereas draft-jennings-sip-dtls-05 113 [I-D.jennings-sip-dtls] differentiates between DTLS over UDP and 114 DCCP. These solutions do not take into account existence of IPSEC 115 tunnels between SIP addressable entities (IMS CSCF). In this case, 116 SIPS in its current form causes encryption to happen at two layers. 117 Transport and Secure protocol should be completely disjoint for 118 future extensability. 120 o 4 Secure protcol is one variant. Different cipher-suites are 121 supported by different secure protocols. Based on the usage scenario 122 different levels of security techniques are needed. US DOD considers 123 AES256 as top secret, whereas a small shop owner in downtown might 124 consider using DES, to avoid heavy resource requirement of AES256. 125 Moreover as the computing/networking technologies (parallelism etc) 126 advances and these resources become cheaper in future, breaking of 127 existing cipher-suites cannot be ruled out. Need of the development 128 of different cipher-suites in the past can be used as an indication 129 for this trend. Cipher-suites are not exposed in SIP. An 130 application cannot enforce AES256 at every SIP hop in the current 131 specification. Degradation of cipher-suites is very much possible. 133 o 5 SIPS [RFC5630] has modified the text to fix the issues of 134 retargeting, last hop exception arising out of SIP [RFC3261]. Yet it 135 is hard for implementors to understand it and cover each use case due 136 to complexity of it. 138 In summary secure routing and secure reachability are two different 139 requirements which are bundled together with resource property namely 140 SIPS URI scheme. The hop by hop nature of SIP makes it hard to 141 understand what needs to be done where. SIP is not like HTTP. There 142 is very thick line between resource and routing. Therefore we have 143 been witnessing issues in understanding of the problem itself. 145 2.2. Non-Encryption Issues 147 The above deals in encryption / integrity of SIP messages at the 148 hops. The above doesn't deal in other possible security issues such 149 as call pattern tracking (There is still possibility of an 150 organization to know about which research department of competitor is 151 talking to patent lawyers to know about the stealth projects/area of 152 research), Denial of service attacks, identity theft, spam etc. 153 There is still possibility of misuse of any confidential information 154 of customer/vendor etc by word of mouth by the entity keeping that 155 information to potential competitors or gang of cheaters. Refer 156 details of other unfair scenarios in different articles on The 157 Dreamer [1] 159 3. Proposed Solutions 161 3.1. Detecting And Fixing 163 Encryption related issues pertaining to SIP can be handled with the 164 proposed solution in draft-srivastava-sip-e2e-ciphersuites-00 165 [I-D.srivastava-sip-e2e-ciphersuites] with a separate header 166 describing secure protocols, cipher-suites; and tags for Proxy- 167 Require and Require header. This solution addresses the issues 168 described in Section 2.1. 170 Denial of Service Attack, Call Pattern Tracking, spam etc issues have 171 been always in N+1 cycle of detecting and solving. The current 172 solutions donot address these by avoidance. 174 As the vote is being sought for much bigger solution as described 175 below, the solution of draft-srivastava-sip-e2e-ciphersuites-00 176 [I-D.srivastava-sip-e2e-ciphersuites] is not described in details 177 here. 179 3.2. Avoidance Of Threats 181 Refer information pertaining to Cashless Economy on The Dreamer [1] . 182 Cashless Economy is achieved via Complete Digital World i.e. every 183 person/entity involving business transactions has computing device(s) 184 to do business transactions. In Complete Digital World, the common 185 denominator of valuation is handled ONLY in computing devices, 186 henceforth it is called as Soft Earning Unit (SEU). Cashless Economy 187 provides end-to-end traceability to earnings/spendings. Linkage of 188 communication records with earnings /spendings can catch the spammer 189 always. Therefore traceability of SEU avoids this problem. Heavy 190 encryption is not needed for deals resulting in direct transactions 191 in money. Encryption will be needed for privacy sensitive 192 information exchange such as stealth projects, defence mattters etc. 193 Financial information pertaining to earnings/spendings can be 194 exchanged with NULL encryption ciphers. Cashless economy avoids 195 other non-internet related problems (such as terrorism, illegally 196 printed currency bills, bribery etc) due to parallel economy of bad 197 guys. Conversely, it is the application which will eliminate the 198 digital /communication divide (which we have been talking for a 199 long). 201 Refer information pertaining to Complete Multimedia Recording on The 202 Dreamer [1] . The current work carried out in SIP Recording (siprec) 203 group deals in solutions for session recordings. Complete Multimedia 204 Recording captures audio and video across time and space dimensions, 205 even if there is no active session. In the proposed solution 206 computing devices will capture the recordings of the walled space and 207 satellites will capture recordings of open space. As everything is 208 captured, whenever an attacker tries to intrude, (s)he will be caught 209 somewhere in the recordings. As persons performing bad/illegal 210 activities will be caught somewhere and as evidences cannot be 211 manipulated (manipulation will be caught somewhere too), bad 212 activities will not happen. It will avoid the issues like man-in- 213 middle attack, denial of service attacks, identity theft, hacking of 214 hosted email ids, online service providers games under the cover of 215 hackers. This will obviate the need of complex encryption and 216 integrity protection mechanism of messages. In the Complete 217 Multimedia Recording environment, we will need bare minimum checksums 218 for catching malfunctioning of computing resources. It will obviate 219 the need of 'Security Consideration' section of the IETF documents. 220 Apart from fixing security related issues for internet, it avoids the 221 need of complex laws, misuse of any technology, miuse of any 222 confidential traceability information via word of mouth etc. 224 Due to wide spread usage of unfair business practices even by top 225 leaders, it has not been possible to find starting point of the 226 change. Everybody complains about it, but nobody wants to take lead. 228 As they argue that why they should be deprived; others should stop 229 first. The proposed migration plan of Cashless Economy and Complete 230 Multimedia Recording brings out a important silent point that things 231 will be changed at a SINGLE point of time. So the big chunk of 232 people who WANT to be fair and honest, will become advocate of the 233 proposed change. Moreover everyone understands very well the 234 difference between fair/unfair actions before commiting any unfair 235 actions. 237 3.3. Future Work 239 Author is humbly requesting the community to vote/voice their opinion 240 for the alternatives described above. Either we end up fixing the 241 security issues with N+1 cycle (solution of Section 3.1 ) as we have 242 been doing till now, or take a route to avoid the security issues via 243 proposed solutions in Section 3.2. Any opinion/flame even via 244 annonymously is welcome. 246 4. Security Considerations 248 This memo deals in Security Issues for SIP. It proposes two 249 solutions. The solution of avoidance of threats applies to internet 250 also. That solution has potential to obviate the need of this 251 section from IETF documents in future. 253 5. IANA Considerations 255 This document has no IANA actions. 257 6. IPR Consideration 259 Author is pursuing published patent applications PCT/US2008/066617, 260 PCT/US2008/069273, PCT/US2008/082929, PCT/US2008/083704, PCT/US2008/ 261 013284, PCT/US2008/013285 alongwith other unpublished patents for 262 ideas descreibed in this draft 264 The copyright for the referred work at The Dreamer [1] is free for 265 individual personal usage. 267 For IPR related issues, please contact at srivastava_samir at hush 268 dot com alongwith samirs.lists at gmail dot com . 270 7. Acknowledgements 272 Author would like to thank Khosla Ventures whom slide set on Cashless 273 Economy was sent in 07 which gave author the feeling of value of the 274 idea. During the article on Cashless Economy author thought of 275 Complete Multimedia Recordings which is needed for solving white 276 collar terrorism and complex laws. 278 8. References 280 8.1. Normative References 282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", BCP 14, RFC 2119, March 1997. 285 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 286 A., Peterson, J., Sparks, R., Handley, M., and E. 287 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 288 June 2002. 290 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 291 Initiation Protocol (SIP)", RFC 5630, October 2009. 293 8.2. Informative References 295 [I-D.jennings-sip-dtls] 296 Jennings, C. and N. Modadugu, "Session Initiation Protocol 297 (SIP) over Datagram Transport Layer Security (DTLS)", 298 draft-jennings-sip-dtls-05 (work in progress), 299 October 2007. 301 [I-D.srivastava-sip-e2e-ciphersuites] 302 Srivastava, S., "Ensuring End to End Cipher Suites in 303 SIP", draft-srivastava-sip-e2e-ciphersuites-00 (work in 304 progress), June 2006. 306 URIs 308 [1] 310 Author's Address 312 Samir Srivastava 313 Digitalall 315 Email: samirs.lists@gmail.com