> > -----Original Message----- > > From: Dean Willis [mailto:dean.wil...@softarmor.com] > > Sent: Thursday, April 02, 2009 11:55 PM > > > > Well we certainly can't expect transcoding to be compatible with e2e > > crypto. > > Nope, and why I do not include that function as being > compatible with it. I do think some form of signaling > caller-id may be useful in that case, but clearly media > identity is not possible short of speaking in pig-latin.
It is true that we cannot provide edge-to-edge *authenticated* media through a transcoder when that transcoder is operated by someone other than an edge. That is because e2e authenticated media is keyed with DTLS-SRTP, which we would only trust edge-to-edge. But we can provide __identity__ over the media path, even with transcoding. Identity across a transcoder only requires the transcoding function allows the identity through. AS AN EXAMPLE, if we used the ICE technique in http://tools.ietf.org/html/draft-wing-sip-identity-media-02#section-4.3, the transcoder could permit the ICE messages to pass, unmolested and unmodified, across the transcoder. The transcoder would perform its normal transcoding function with the RTP packets. I am saying "as an example" because we may not want to use ICE for this purpose; I have other ideas for how this might be done which may be more appealing. -d > > So are there any legitimate use cases for requiring that > > the protocol supports MITM rewriting of SDP? > > We already gave you some. But really the question can just > be flipped around: is there a security property of the SDP's > IP/port that you feel is important to protect, such that we > can't allow it to be changed? Do you feel an IP:port is an > identity, or is somehow actually a secure indicator of > anything? > > I mean there's plenty of other important things in > SIP we're not protecting with 4474 - maybe we should just > sign the entire SIP message, just in case. But we don't, > because we know it wouldn't work in the real world, and > because most of them have little security value to protect. > > SDP is not "the user content", as a mime text attachment in a > SIP MESSAGE or email would be. It is not "the prized > possession" from the user. In particular the indicated > IP:port to send IP packets to/from is not. The IP is not an > application nor user identity; and it is spoofable, > interceptable, reputable, etc. You yourself have argued > about SIP's dependence on the IP:port in SDP being an > architectural shortcoming, and here we are trying to make > sure it's cryptographically dependent! IPsec learned this > the hard way when it had to encapsulate itself in UDP due to > the pseudoheader and NATs, SIP learned it due to NAT's, a > whole host of things may learn it in the v4/v6 transition if > it happens (oh, did we mention that as another SDP re-writing > case?). > > > Perhaps is lots of calls started failing because they > > endpoints detect > > that a MITM attack on their signaling/media has occurred, and did so > > in a way that makes that failure evident to the MITM, then we'd see > > fewer MITMs making that mistake. > > If calls started failing because of 4474, I'm fairly sure it > would be 4474 that would be turned off, not the SDP > re-writers. Because they're not an MITM attack on users or > calls - it's a MITM attack on the IETF's principles. But > then again, there's no need to turn 4474 off - it can just be > removed by a MITM. > > -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement...@cs.columbia.edu for questions on current sip Use sipp...@ietf.org for new developments on the application of sip
