Re: francois' comments and why RFC4474 not used in the field
Dean Willis <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
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? If not, why not? And you're going to have to convince me that you're not just building a phone-tapper protocol here . . . -- Dean _______________________________________________ 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