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
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
