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
