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

So, at a high level, if we could "sign the blob" à-la-RFC 4474, 
but exclude very specific elements (i.e., the IP:port), and combine
it with DTLS-SRTP (or TLS for non-real time media), in specific 
cases where allowing Media Relays is desireable/necessary, then
we may have a solution, right?

I'm interpreting your email as we should have an opt-out of
integrity protection (carefully used) instead of an opt-in 
(as per the draft-wing-identity-media draft).



> -----Original Message-----
> From: Jon Peterson [mailto:[email protected]] 
> Sent: Thursday, April 09, 2009 11:50
> To: Elwell, John; Audet, Francois (SC100:3055); Dean Willis
> Cc: Cullen Jennings; [email protected]; DRAGE,Keith (Keith)
> Subject: Re: [Sip] francois' comments and why RFC4474 not 
> used in the field
> 
> 
> > [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.
> 
> In fairness, I don't think the choice is between signing the 
> IP/port and not signing the IP/port. It is between signing 
> the entire MIME body as a blob the auth service does not have 
> to understand, versus selecting a set of elements (understood 
> here not to include the IP/port) and signing those 
> exclusively. If we want to understand the benefits of the 
> former approach, they go a bit beyond protecting the IP/port. 
> Architecturally, signing the blob results in better future 
> compatibility and better paths to extending SDP. If the 
> authentication service needs to know what elements in SDP are 
> to be included in the signature, then the authentication 
> service behavior needs to change every time that clients 
> start using SDP (or bodies, for that
> matter) in new ways.
> 
> If someone wakes up tomorrow, invents a new media security 
> model, and decides there is value in having an indicator in 
> SDP that will let you correlate the rendezvous layer with 
> media security keying, under the blob model that indicator 
> can just get stuck in SDP, and the authentication service 
> does not need to change its behavior in order to sign it. 
> Taking this to its extreme, while I'm sure no one would stand 
> up to defend SDPng these days, virtually everyone would say 
> that SDP isn't the ideal tool for establishing complicated 
> sessions; if we ever do get around to building something 
> better, the authentication service in the blob signature 
> model shouldn't need to understand it. This is, again, just a 
> basic SIP layering architecture we've always followed, 
> intended to maximize the ability of endpoints to innovate and 
> reduce the brittleness of intermediaries.
> 
> Even without looking to the future, I think there's 
> reasonable value in signing most of the cruft in SDP. For 
> example, as I've mentioned before, I think it's worth 
> detecting various codec downgrade sorts of attacks. But 
> speaking to the IP/port again specifically, I maintain that 
> when sending media doesn't work, it is useful for UAS to 
> ascertain who set the target IP/port, and if the IP/port 
> shouldn't be tried anyway because they were inserted by an 
> attacker, I think it's useful for the UAS to know that before 
> it processes that re-INVITE, or begins altering for that 
> initial INVITE, or what have you.
> 
> >> 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.
> 
> Certainly I agree that RFC4474 interprets "certain deployment 
> situations" as security violations, and that is a limitation 
> of its approach. I was merely pointing out that there are 
> also limitations to an approach where we largely defer 
> security to the media layer; namely, it no longer protects 
> against classes of attacks that do not intend to establish 
> sessions as such (this discussion would come around to things 
> like early media and forking, for example; there are also 
> applicability concerns here with media protocols other than 
> RTP). If these were the only two possible solutions, they 
> we'd debate their merits and flaws, pick one, and be done. I 
> at least haven't given up on the idea that we can draw up 
> some other candidate solutions; the real bar to doing so 
> seems to me to be disagreement about the problem space.
> So for the moment, I am still trying to talk at a pretty high 
> level about what sorts of qualities are desirable in a solution.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > 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