> -----Original Message----- > From: Dean Willis [mailto:[email protected]] > Sent: Monday, April 13, 2009 12:20 PM > To: Dan Wing > Cc: 'Jon Peterson'; 'Francois Audet'; 'Elwell, John'; 'Cullen > Jennings'; [email protected]; 'DRAGE, Keith (Keith)' > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > On Apr 13, 2009, at 1:38 PM, Dan Wing wrote: > > > > That is because, ** in conjunction with media-path validation ** > > (which is the important point), the attack is prevented. > > Well, the attack is not so much "prevented" as it is "detected". It > is detectable when the media-path validation fails. > > But though detectable, the attack is not attributable. You may know > that an attack has occurred, but you don't know whether it > was enabled > by modification of the media or by modification of the signaling. > > If you had the original signed signaling and could see that the > signaling had been altered, then you might reasonably suspect > that the > attacker was on the signaling path. Without this, all you > know is that > somebody tweened your media somehow. > > Now, is this really useful if the original signed media description > (SDP) has been replaced by new signed SDP? Not really; as we then > would not be able to decide whether the attack was a compromised > intermediary authentication server or a a direct attack on the media. > > So a model wherein no intermediary replaces and resigns the SDP is > preferred, as it allows the media to always match the signaling, > thereby reducing the uncertainty. We don't have such a model yet > AFAIK, as outbound, STUN, and relays give us only two > steering points, > and I've heard it claimed we need more. I might argue that this > problem is due to the separation of signaling and media, > which I hold > to be one of the prime "complicators" in this whole house of cards. > But it might well be possible to extend the relay-discovery model of > ICE to be able to express an entire graph of candidate sequences, > including n-relay paths. On the otehr hand, I find it difficult to > propose such a mechanism that would be backward compatible with the > SIP devices I currently use, and if we have to breal backward > compatibility, I'd just as soon do it cleanly and on a large scale.
I would be content with identity that worked edge-to-edge, so that existing devices don't need to change. Over time those devices can be upgraded and could do their own proof of identity. The philosophy of RFC4474 was similar in that it allows a-device-other-than-the-UA to create the RFC4474 signature and a-device-other-than-the-UA to validate the RFC4474 signagure. -d _______________________________________________ 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
