At a high level, when an intermediary is going to relay your media, the intermediary (not the UAC) is the source of the IP/port data that appears in SDP, and as such, I can accept alternatives to securing that data with a signature from the originating administrative domain (abstractly, that goes equally for SBCs and TURN, I suppose). I don't however believe it follows from this that it just doesn't matter at all who sets the IP/port data in SDP. I think it does matter, and it matters most when we consider approaches that defer security checks from the SIP layer to the media layer. For example, if relatively weak SIP-layer security facilitates cut-and-paste attacks, then an eavesdropper could listen to INVITEs, forge re-INVITEs with the same signature but set the IP/port to something unhelpful, and methodically tear down a target's calls five seconds after they start. So from my perspective, verifying the origin of IP/port data still has value, even if the origin of that data is not the originating administrative domain.
Jon Peterson NeuStar, Inc. On 4/9/09 12:09 PM, "Francois Audet" <[email protected]> wrote: > 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
