Actually, that is false in many cases.
It depends what you are trying to do, and who do you trust.
There are many cases where I'd put a lot more trust in the proxies than
"the guys at the end of the lines".
Who has the responsibility for Security is really what should drive the
solution.
An e2e model makes a lot of sense when the people that are engaged in
the session are the ones with the incentive for the session to be
secure. If Henry wants to talk to me, and we both want our session to be
secure, then that's the right model.
An e2e model does not make any sense when the people that are engaged in
the session don't care or are not savvy enough. For example, if I'm an
Enteprise IT manager (or operator of a Government internal network), I
may decide that I want all sessions between all my users to be secure
despite them. As the IT manager, I'd be responsible if a rogue employee
spies on collegue, regardless of how careless the other employees are.
I think it is important to be very clear on what we are trying to
achieve when talking about e2e (sipsec) or hop-by-hop (sips). They are
not meant to solve the same problem.
________________________________
From: Henry Sinnreich [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 15, 2007 08:30
To: [EMAIL PROTECTED]; Dean Willis; Richard Barnes
Cc: sip List; Sandy Murphy
Subject: RE: [Sip] Question on SIP Security considerations
forfuture extensions
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
