Frank, Some comments on the draft you refer to below:
1 - why insert (Proxy-)Require: sipsec? it will not work through currently deployed proxies, while section 6.6 does not require any new proxy behavior. Perhaps because 6.3 requires proxies to process mutulated responses, but 2 - why make the CONNECT response different than a normal SIP response? doing that makes it incompatible with current infrastructure, while providing little benefit 3 - section 6.5 UAS behavior should probably say that a Contact MUST be present in CONNECT response, and that it SHOULD be sips: 4 - would be nice to have a mechanism to encrypt the Contact URI in the response, specifically for the caller. An incoming request to a contact that was sent encrypted gives higher trust. At least it should be integrity protected somehow. 5 - would it be beneficial to make a link to the sip-certs work (http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-04.txt)? For example, in the CONNECT method the caller could provide a reference to its certificate server (integrity-protected as part of the body for example) 6 - 6.3 should state that CONNECT is not a dialog creating request. Consequently, 6.5 should state that UAS MUST ignore any Record-Route headers present (and so not reflect them in the CONNECT response, although this might interfere with proxy functionality - but that's kind of the point, right?) 7 - You could consider providing guidance on information that is not relevant to the CONNECT request, but needed to make requests / responses well formed. For example, you could specify default values for To and From URIs (say [EMAIL PROTECTED]) 8 - Given that the Contact URIs need to be globally reachable (I guess how that is achieved should remain out of scope), they should be marked as (temporary?) GRUUs (i.e. include 'gr=xxx') Regards, Jeroen ----- Original Message ----- From: [EMAIL PROTECTED] To: Dean Willis ; Richard Barnes Cc: sip List ; Sandy Murphy Sent: Wednesday, August 15, 2007 4:39 PM 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-fmiller/ http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt&url2=http://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-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 > 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
