Francois, Although an opt-out might be better than an opt-in, I still fear we could end up with complex and not-forward-compatible behaviour at the authentication service and at the verifier. So I do concur with what Jon says. Thinking, for example, of the SDP capability negotiation mechanism that MMUSIC is currently adding. You can have IP addresses and ports hidden in a=lines. If the opt-out mechanism wanted to opt out of these, it would get very messy.
I am more swayed by solutions whereby a copy of the original SDP is conveyed and signed, so you can see what has been changed en route and can decide whether to agree with the changes. A precedent already exists. The To header field URI is a copy of the original Request-URI (ignoring mid-dialog requests for now). RFC 4474 signs the To header field URI (which is not expected to change) and does not sign the Request-URI (which is expected to change). So the verifier or UAS knows for sure where the request was originally targeted and has to use its own judgement as to whether the changed Request-URI is reasonable or not. John > -----Original Message----- > From: Francois Audet [mailto:[email protected]] > Sent: 09 April 2009 20:10 > To: Jon Peterson; 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 > > 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
