Re: francois' comments and why RFC4474 not used in the field

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