But.... This is unlikely to be backward-compatible, no? Are you saying that the receiver of the INVITE would get a multipart MIME, one of them signed with RFC 4474, and the other with something else?
What I had in mind for "opt-out" was that the signature would avoid all instances of it's own IP address and port. But yeah, you are right, this is non-trivial and error-prone. Using TURN is looking more and more attractive... > -----Original Message----- > From: Elwell, John [mailto:[email protected]] > Sent: Friday, April 10, 2009 01:04 > To: Audet, Francois (SC100:3055); Jon Peterson; Dean Willis > Cc: Cullen Jennings; [email protected]; DRAGE,Keith (Keith) > Subject: RE: [Sip] francois' comments and why RFC4474 not > used in the field > > 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
