On Apr 5, 2008, at 12:08 PM, Dean Willis wrote too quickly: > > So we either change need to change RFC 4474 (by making a signature > "mean less" OR by allowing one to make a disclaimer on the signature), > or we change DTLS-SRTP framework to make it nod depend on RFC 4474 for > end-to-end communication of the signature. We do have two drafts > (Wing, Fischer) that would accomplish this.
Sorry, I wrote too quickly and left out a bridge-construct, making the above more confusing than my usual rambling. And I misphrased a word or two. Sorry. Let's retry: So we either change need to change RFC 4474 (by making a signature "mean less" OR by allowing one to make a disclaimer on the signature), or we change DTLS-SRTP framework to make it not depend on RFC 4474 for end-to-end protection of the fingerprint. We also have the issue of detecting fingerprint changes midstream, meaning that we've had a MITM on the media (that has replaced the Identity header). We do have two drafts (Wing, Fischer) that would accomplish this. The consequence of the second para above, if I understand it correctly, is that DTLS-Framework is relying on the RFC 4474 Identity header to protect the integrity of the key fingerprint which is transmitted in the SDP. If the Identity header is UA-signed, this is pretty much rock-solid. However, if it is signed by an intermediate node, then it is possible that the intermediate node has altered the SDP (and fingerprint), and that it may be colluding in interception of the media. And that's just the way RFC 4474 works, so anything that relies on it (like DTLS-SRTP framework) has this limitation. The point is that there may be a possibility to fix all these flaws in one pass. I'm not sure what solution would do this, but I have the feeling there's one out there that we just haven't quite identified yet. The logic goes this way: DTLS-SRTP framework uses RFC 4474 for integrity protection of the fingerprint. By doing so it inherits weaknesses of RFC 4474. We have noted two of these as issues: 1) RFC 4474 cannot legitimately be used for calls originating on the PSTN and transiting a gateway to SIP because it lacks a way to inform the recipient that the From: field was not actually authenticated by the authentication service. Otherwise said: as written, 4474 promises that the From: field was authenticated by the authentication service, and since in this case it wasn't authenticated, the service shouldn't be saying it was authenticated. 2) RFC 4474 headers may be subject to replacement by intermediates. While this might be required for certain uses of intermediates (such as SBCs that replace SDP because they're relaying it), it can also be used to insert an intermediary that intercepts the cleartext of the media (taps the call) without the consent of the endpoints. We could work around by fixing these problems independently -- for example, by adding the From: disclaimer proposed by Adam and the assorted SBC-traversal and fingerprint preservation/verification techniques proposed by Dan, Kai, and probably others. Or we could fix it by either fundamentally changing RFC 4474, or by providing a different fingerprint integrity mechanism for DTLS-SRTP framework and thereby breaking the dependency cycle. -- 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
