I fully agree here. Only e2e security is real security and SIPS cannot obfuscate this.
Thanks, Henry ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 15, 2007 9:40 AM To: Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: Re: [Sip] Question on SIP Security considerations forfuture extensions With all due respect, I don't agree with this. Its my opinion that the current model is well-understood and unsatifactory for many applications. While I think its fine to spend some time clarifying the current model, I don't think that should hold up the development of an end-to-end mechanism as well. That development can proceed in parallel and the sipsec draft is a good start in that direction. To that end, after receiving the blessing of the majority of the authors, I'm posting a proposal I made to them regarding a mod to the sipsec draft that I believe would improve its ability to address true end-to-end security. The idea is simple, rather than having the CONNECT message establish a "tunnel" through a series of proxies, CONNECT is used to trade addressing information between the UAs that then signal each other directly. This proposal was made as modifications to the sipsec draft. The draft is available as a standalone and as a diff to the current sipsec draft at the following links. Comments are hoped for... Thanks, FM https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fm iller/ http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://svn.resipro cate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01. txt&url2=http://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/s ipsec-fmiller/draft-gurbani-sip-sipsec-fmiller-00.txt On Wed Aug 15 9:37 , Richard Barnes sent: I'm replying to Dean's original message so that I'm not deep down in the thread, but I'd like to point to one of Dean's later comments: > Look, my question about security documentation for SIP extensions had > nothing to do with SIPSEC and everything to do with documenting the > current please-molest-me proxy-mediated transitive-faith-in-goodness > I-believe-my-operator-cares-for-me model of SIP security. And we DO > need to document this model better -- the question is how. Here's my proposal: First, we need to document the situation as it stands, given the proxy model and security mechanisms defined in RFC 3261 and relevant extensions. I.e., in the current system, here's the base (please-molest-me) model, here's what proxies can do to screw you up in this model, and here's the sorts of assurances you can get by employing some security features. Second, rather than requiring boilerplate in documents defining new extensions, they should comment on how the extension affects the model described in the above document -- either providing additional security (e.g., by limiting proxy capabilities like SIPSEC) or by introducing additional risks (e.g., by increasing proxy capabilities, like answer-mode). This discussion could be a required subsection of the Security Considerations section. I think that this would encourage people to give explicit consideration to the sorts of risks Sandy noted in the answer-mode draft, and to think about how they might fix or avoid them. --Richard Dean Willis wrote: > > I'm having quite an interesting conversation with Sandy Murphy (cc'd) > who was tasked by sec-dir to review one of our drafts > (draft-ietf-sip-answermode). This draft has some rather interesting > security issues, since if implemented incorrectly and then abused it > could allow an attacker to "bug your phone" -- that is, turn it into a > remote listening device. Similar attacks could also be used to run up > the victim's connectivity bill, run down the device's battery, aggravate > the "voice hammer" DOS attack, and so on. > > This lead us into a discussion of the SIP security model in general. > Most SIP practitioners who have been at it for awhile know that if the > proxies we have decided to trust suddenly decide to get malicious, then > we're very much at their mercy. They can do all sorts of things, > including routing our media through interceptors, mangling SDP payloads, > injecting (or blocking) instant messages, altering presence information, > and so on. > > But this aspect of SIP is not obvious to naive implementors, or even to > less naive security types. > > Maybe every SIP extension document should include a boiler-plate > reminder about the sensitivity of proxies, then go on to enumerate and > describe the new ways that malicious proxies (should there be such a > thing) can wreak havoc using the extension being documented. > > what do you folks think? > > 1) Could a reasonable "How you could be violated by trusted proxies that > turn rogue" boilerplate be drafted? > 2) Would the practice of repeating this in drafts help or hurt us? > 3) Would it be useful for us to document how each extension could be > used by a rogue proxy? > > -- > Dean > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip <http://sitemail.hostway.com/sitemail6/parse.pl?redirect=https%3A%2F%2Fw ww1.ietf.org%2Fmailman%2Flistinfo%2Fsip> > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] <javascript:top.opencompose('[EMAIL PROTECTED]','','','') > for questions on current sip > Use [EMAIL PROTECTED] <javascript:top.opencompose('[EMAIL PROTECTED]','','','')> for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] <javascript:top.opencompose('[EMAIL PROTECTED]','','','') > for questions on current sip Use [EMAIL PROTECTED] <javascript:top.opencompose('[EMAIL PROTECTED]','','','')> for new developments on the application of sip
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
