> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Dean Willis > Sent: Sunday, March 29, 2009 9:09 PM > To: Jiri Kuthan; Jon Peterson > Cc: SIP List; Francois Audet > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > On Mar 28, 2009, at 3:02 PM, Jiri Kuthan wrote: > > > > > > > I'm worried this is only a wishful thinking. While perfectly > > logical, still even in such constrained setups some bizzar > > ALGs do in my experience appear in the middle, change SDP > > and make thus the identity worthless. > > > If they change the SDP, they've changed the identity > assertion. They > need to re-assert. There might reasonably be a need to have a > stack of > assertions with diffs, so one could go back and see the > original SDP, > with its original key fingerprint and original verifiable signature, > but just changing stuff and pretending the associated identity > assertion hasn't changed is fundamentally bogus. > > The MAIN reason, it seems to me, to want to change the SDP (and > especially the key fingerprint) undetectably is to enable intercept > (lawful or otherwise) without detectability. That just won't do. > > Perhaps we only need are two different identity assertions; > one on the > original SDP with fingerprint, and one on whatever has resulted post- > modification by the MITM attackers. Intermediate > manipulations by yet > more MITN attackers might well be worthless. > > Let's put it another way: One of the very important things that RFC > 4474 does is protect the DTLS/SRTP key fingerprint. Arguably, its > protection of the other stuff in the SDP, such as the port > numbers and > IP addresses used for media, is just a side effect. Of course, > changing the codec (transcoding) is going to break DTLS/SRTP quite > horribly, so the codec information might as well be protected by > Identity. > > Would we be willing to accept a model where the fingerprint is > preserved across SBCs but the IP address/port number information is > not? I'm not saying that would be easy to produce; it would seem to > require a very complex modification to RFC 4474's handling of > SDP, or > complementary fundamental changes to RFC 4474 and the DTLS draft > family. But would it get us past this this stone wall?
It would not get us past this stone wall, because this very idea was already proposed and already rejected, http://tools.ietf.org/html/draft-wing-sip-identity-media-02#section-4.2 The reasons for the rejection, as I recall, were along the lines of "we don't want to require SRTP to provide identity". That argument is countered with the ICE technique in Section 4.3 of the same draft; we could change that from ICE to something else that does not overload ICE semantics of course. Other reasons included "but SBCs might [destroy | modify | manipulate]" the messages. The counter argument to that is that the operators of SBCs have an incentive to allow identity through (namely, so that people will accept incoming SIP calls), very much like the long distance phone companies in the 1980's added echo cancellation tone detectors (because it was something needed by the end users). Other arguments questioned how non-Invite requests would get protection (also answered in that same draft). It is not a lack of solutions in this space. It is a lack of participation by interested parties and an unwillingness to admit that voice networks are using SBCs -- as if SBCs operated by service providers are as real as the tooth fairy or Santa Claus. > If not, why not? And you're going to have to convince me that you're > not just building a phone-tapper protocol here . . . Strong identity makes it *harder* to build a phone-tapping system. This hop-by-hop signing thing that you are describing above, and Jon described at the microphone, is transitive trust with extra CPU horsepower and something you could fight better in a lawsuit when you learned that a service provider lied. I don't see a service provider getting very interested in the additional capex, opex, and business risk of doing such signing, especially compared to the three proposals on the table which require the service provider do _no_ signing and no stronger attestation than today (same business risk as today). -d _______________________________________________ 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
