On 4/13/09 3:45 PM, "Dan Wing" <[email protected]> wrote: >> I have a hard time seeing how anything we >> do at the media layer is salient to that - again, just speaking to high >> level examples, if you accept a forged BYE request, > > The BYE would be protected from forgery sufficient to detect a > forgery, using mechanisms like RFC4474 protects a BYE from > forgery: signing enough SIP headers to block a forgery.
In so far as there's really any thrust to my argument here, it's that the situation of an INVITE that an attacker never intends to use to establish a session is comparable to that of a BYE - one must sign enough of its headers to detect a forgery to thwart its mischief. The problem is, of course, that there's no way for the security mechanism to differentiate these sorts of INVITEs from the "sunny day" session-establishment cases where media-layer security will eventually be invoked, which makes me question exactly how much we can reduce the set of INVITE headers we sign. This doesn't mean I object fundamentally to a two-pronged solution; say, signing set X of fields for all requests with an SDP body and set Y for all requests without an SDP body. It just means that in the threat model I'm considering, I have reservations about making X much smaller than Y. Jon Peterson NeuStar, Inc. >> that will presumably >> convince you to tear down a call regardless of anything that media-layer >> security has established. I've argued a similar requirement exists to >> prevent a forged re-INVITE that just sets the IP/port to >> something useless. _______________________________________________ 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
