What is it in the SDP that you feel is integral to the identity of the sender of the request? If I send an offer-less Invite and sign it with rfc4474 does it not confirm my identity, because there was no SDP? Clearly it would indicate that the signed sender did not send SDP, so it prevents a MITM from inserting one, but does it actually let a MITM change the Identity of the sender of the request if it inserts one?
You say below that one of the important properties is that it protects the dtls-srtp fingerprint, presumably because that allows it to tie the identity of the sender of the SIP request to the identity of the media. Every draft proposal thus far to do rfc4474 differently has included the ability to sign that fingerprint, specifically for that purpose. The question is whether the IP-Addr/port of the media is itself integral to the identity of the sender, or not. -hadriel > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Dean > Willis > Sent: Monday, March 30, 2009 12:09 AM > > On Mar 28, 2009, at 3:02 PM, Jiri Kuthan wrote: > > > I'm worried this is only a wishful thinking. While perfectly > > logical, still even in such constrained setups some bizzar > > ALGs do in my experience appear in the middle, change SDP > > and make thus the identity worthless. > > > If they change the SDP, they've changed the identity assertion. They > need to re-assert. There might reasonably be a need to have a stack of > assertions with diffs, so one could go back and see the original SDP, > with its original key fingerprint and original verifiable signature, > but just changing stuff and pretending the associated identity > assertion hasn't changed is fundamentally bogus. > > The MAIN reason, it seems to me, to want to change the SDP (and > especially the key fingerprint) undetectably is to enable intercept > (lawful or otherwise) without detectability. That just won't do. > > Perhaps we only need are two different identity assertions; one on the > original SDP with fingerprint, and one on whatever has resulted post- > modification by the MITM attackers. Intermediate manipulations by yet > more MITN attackers might well be worthless. > > Let's put it another way: One of the very important things that RFC > 4474 does is protect the DTLS/SRTP key fingerprint. Arguably, its > protection of the other stuff in the SDP, such as the port numbers and > IP addresses used for media, is just a side effect. Of course, > changing the codec (transcoding) is going to break DTLS/SRTP quite > horribly, so the codec information might as well be protected by > Identity. > > Would we be willing to accept a model where the fingerprint is > preserved across SBCs but the IP address/port number information is > not? I'm not saying that would be easy to produce; it would seem to > require a very complex modification to RFC 4474's handling of SDP, or > complementary fundamental changes to RFC 4474 and the DTLS draft > family. But would it get us past this this stone wall? > > If not, why not? And you're going to have to convince me that you're > not just building a phone-tapper protocol here . . . > > -- > Dean > > _______________________________________________ > Sip mailing list https://www.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://www.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
