Folks, I have a simple question/comments see below. thanks Arunrajan
-----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 7:54 AM To: Cullen Jennings Cc: sip List; Sandy Murphy; Dean Willis Subject: Re: [Sip] Question on SIP Security considerations for futureextensions Cullen Jennings wrote: > > I will note that we do have security mechanism to provide confidentially > over the bodies (but not headers) for attacks from proxies we do not > have a trust relationship with - and this is one of the aspects used in > determining if certain semantics might be better in a body or header. > > Cullen <with my individual hat on> > > PS - I fail to see how sipsec will help with the basic problem of if > Alice sends a call to a proxy and the proxy routes the call to some evil > user instead of sending it to Bob. True. But I think that is a lesser problem, if you can determine you have reached the wrong person. I think it is a compromise people are willing to make - to find a callee. [ap] Is there a way to find out that you have reached the wrong person? Because it would seem, that is the very basis of security, If alice calls bob, and is connected to charles, or worse is connected to bob through charles - the call is not secure. It would seem that RFC 4474, does not prevent this from happening and is kind of pointless for that reason. I have not read any of the sipsec work so maybe I am just being ignorant, right now. As a general principle, I feel very uncomfortable with high level of *trust* in the network entities. I think a model like TLS/SSH where the endpoints verify each other is desirable ( If not imperative) for sip. That is caller/callee must be able to authenticate/prevent man in the middle with as little help from external entities as possible, maybe all I can trust is my proxy/HLR/Authenticationserver with each I have a PSK trust relationship. I understand this requires an extensive infrastructure support ( for certs/keys) etc specially if conference calls are to be supported, but that is all the more reason to start now. [\ap] Paul > On Aug 13, 2007, at 4:56 PM, Paul Kyzivat wrote: > >> Maybe such a policy would encourage the adoption of sipsec. >> >> Paul >> >> 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 >>> 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 >> >> >> _______________________________________________ >> 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 > _______________________________________________ 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 _______________________________________________ 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
