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] <http://samirsrivastava.typepad.com>
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]