Jon, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Jon Peterson > Sent: 09 April 2009 03:11 > To: Francois Audet; Dean Willis > Cc: Cullen Jennings; [email protected]; DRAGE,Keith (Keith) > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > 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. [JRE] If media is encrypted, sending it to the wrong IP address/port, whilst it will cause the call to fail, will not reveal the information to the recipient. Of course, if media is not encrypted, that has worse consequences, but unencrypted media can be eavesdropped by other mechanisms, or can be spoofed or modified. Knowing who told you which IP address/port to send to only gives you a certain amount of protection. We must ensure we do not lower the security available when encryption is in use (losing the ability to authenticate the user we performed key agreement with) by clinging on to mechanisms that give some minor benefit to the unencrypted case. > > 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. [JRE] So this suggests the need for two solutions: one for protecting the rendez-vous layer and one for protecting the media layer. The problem is that the mechanism for protecting the rendez-vous layer (RFC 4474) does not work in certain deployment situations, and because we reuse that for authenticating the media layer (using it to sign the fingerprint of the certificate used at the media layer) we are unable to have protection of the media layer in those deployment situations.
John _______________________________________________ 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
