> [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
