Thanks for the comments. Let me first describe how we got to this point. Hopefully that will help when people start to make comments. When I read the sipsec draft, it struck me that there was the opportunity to provide a real end-to-end solution as I've proposed based on the CONNECT method. I contacted Vijay and asked for the XML for the draft. I spent some time sketching what I was thinking about within the context of the draft XML and sent it to Vijay, Francois, and Dean. I purposely did not fill in all the details because I suspected that there would be discussion about it and so wanted to wait until there was some indication that adding details would be fruitful. There has been some discussion as was alluded to by Francois in another email. Mainly, the question seems to be if this should be noted as an optimization to the originally proposed mechanism or should replace the originally proposed mechanism. All this took place in private emails among the four of us and I did not want to post it on the list until the authors were comfortable with that. So, when this discussion thread around security came up, it contained some interesting points that were relevant to the proposal. I asked the authors if it would be ok to post the links and they said fine and so here we are. All that said, my opinion would be similar to what Francois sent earlier. I believe this should be the default mechanism and that the proxy tunneling machinery, if kept at all, should be used only in situations where some network topology forces it. However, the draft belongs to the authors and they need to determine what happens next. If this change is incorporated, I would have opinions on the comments that you made and I'll respond inline here: Thanks, FM -----Original Message----- From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 15, 2007 10:18 AM To: [EMAIL PROTECTED] Cc: sip List Subject: SIPSEC comments (Was Re: [Sip] Question on SIP Security considerations forfuture extensions) 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 FM: That's legacy from the original draft. We can revisit that I think. It may not make sense with this approach. 2 - why make the CONNECT response different than a normal SIP response? doing that makes it incompatible with current infrastructure, while providing little benefit FM: As mentioned, I was sketching the basics of the solutions. Specific responses can be changes as needed. 3 - section 6.5 UAS behavior should probably say that a Contact MUST be present in CONNECT response, and that it SHOULD be sips: FM: I agree. 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. FM: I don't have strong feelings on this. I think that encrypting this URI might yield implementation complexity that may not buy much. 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) FM: I'm sure there will be lots of discussion about this. I do think that self-signing should be allowed so that parties that want to use it can. 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?) FM: I agree. 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]) FM: I think there is a lot more specification that needs to be done. 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') FM: If there was ever an application for GRUUs, this has to be it.
_______________________________________________ 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
