Arun Punj (WD/EUS) wrote:
Folks,
I have a simple question/comments see below.
[snip]
[ap]
Is there a way to find out that you have reached the wrong person?
Not in general. Its not well defined who the *right* person is if
forwarding is involved.
There have been proposals to push all forwarding/redirection back to the
UAC, so that it can make its own decision is the new target is an
acceptable target to it. I believe that is necessary to make sipsec work.
The sipsec draft establishes an e2e TLS connection. This allows the cert
of the UAS to be verified. Of course it will only work if the UAS *has*
a cert that can be verified by the UAC, which brings up many issues of
certificate management, etc. Its far from a done deal.
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.
Yeah, a lot of people share your concern.
The need for proxies was motivated initially by the lack of fixed
addresses for phones. Hence the need for registration and retargeting
from an AOR to the address of the phone.
However, this is pretty similar to not knowing what server you want to
contact on the web. When you don't know you use a search engine to find
some candidates. Then you can, if you wish, establish a secure
connection to one of the candidates. In the end you can know you are
talking to somebody who has rights to the address you are connected to.
But you still have to trust a bunch of infrastructure to know that is
who you want to be talking to.
Paul
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
_______________________________________________
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
