I think I've said in the past that the IP address and port remain relevant because their soundness is a necessary condition for the delivery of media, and by extension the employment of mechanisms like DTLS-SRTP. If we remove the IP address and port from the protection domain of rendezvous layer security entirely, then either an MITM or a cut-and-paste attacker could exploit those SDP lines to deny service, for example, in a manner that will not be detected by the recipient until they find their media goes AWOL. That's basically why I think the alteration of those lines should be a detectable condition in the rendezvous layer, and why I've argued we should have data origin authentication for that information. That doesn't necessarily mean we need it in the form that RFC4474 currently provides it - various sorts of patch-and-sign mechanisms would also be fine with me. But with authentication, if media isn't reaching your interlocutor because it's drifting out into space, at least you know who told you to aim it there - which is, I believe, a valuable security property.
Most of my concerns here are really about layer violations, about how many security functions we can defer to the media layer and how many must reside in the rendezvous layer in order to meet our requirements. The primitives that establish and maintain sessions, I believe, require protection in the rendezvous layer - DTLS-SRTP isn't going to protect you against a forged BYE, say. If the aggregate security that the system provides does not prevent an attack that cheap, I think we've accomplished less than we can and should. I also think that having enough credible information in a SIP request that a recipient has reasonable grounds to authorize or reject it is a good general design goal for our security work; provisionally accepting requests and initiating media (DTLS-SRTP) in order to determine whether or not the dialog is authorized protects against certain threats, but broadly I think it doesn't address threats where an attacker/impersonator can accomplish their goals without ever establishing a session. If we think about, I suspect we'll find there are actually quite a few of those. Jon Peterson NeuStar, Inc. On 4/6/09 9:54 PM, "Francois Audet" <[email protected]> wrote: >> >> Yes, but it does so at the expense of weakening RFC 4474 when it is >> used without DTLS. >> >> I believe Jon has said that he wishes to be able to use signaling >> identity without DTLS and considers the presentation of IP addresses >> in the identity signature to be essential. Since you want to change >> RFC 4474 to allow MITM editing of IP address information (thereby >> weakening RFC 4474 protections in Jon's scenario), he doesn't like >> your idea, > > I'm saying if you use identity-media, then you MUST use DTLS-SRTP (or > at least the handshake part if you don't need actual encryptio, or a > NULL encryption). > > That way it doesn't weaken anything. Also, nothing prevents anybody > from using classic 4474 if you want to prevent nasty SBCs from mucking > around with SDP: I can see enterprises doingbso between them. > _______________________________________________ > 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
