> -----Original Message----- > From: Jon Peterson [mailto:[email protected]] > Sent: Tuesday, April 14, 2009 4:07 PM > To: Dan Wing; 'Francois Audet'; 'Elwell, John'; Dean Willis > Cc: Cullen Jennings; [email protected]; 'DRAGE,Keith (Keith)' > Subject: Re: [Sip] 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.
Yes, I agree we need to sign enough headers to prevent an attack. -d > 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
