Dean, > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dean Willis > Sent: 05 April 2008 18:57 > To: [email protected] List > Subject: Re: [Sip] RFC 4474 and PSTN > > > 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. [JRE] But isn't this effectively what the Wing and Fischer drafts are doing, i.e., providing a different fingerprint integrity mechanism? They would probably still need something like a PSTN disclaimer solution too.
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
