Jon, So a consequence of what you are saying is that to verify who you are negotiating DTLS-SRTP security with you need one signature, covering the certificate fingerprint and sufficient other stuff to prevent replay, and to verify which intermediary told you the IP address and port to send media to you need a second signature. Correct?
John > -----Original Message----- > From: Jon Peterson [mailto:[email protected]] > Sent: 10 April 2009 17:10 > To: Francois Audet; Elwell, John; Dean Willis > Cc: Cullen Jennings; [email protected]; DRAGE,Keith (Keith) > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > 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
