Elwell, John wrote:
Paul, The problem is, what incentive does the SBC vendor have to go to these lengths? I really think we need a solution that doesn't require the SBC to do any more than pass information on transparently. RFC 4474 fits this criterion, except that it won't work when SBCs do media steering or make other "harmless" changes to signed information.
Well, the issue is that it doesn't work in these cases, isn't it? What I suggest would solve that issue without fundamentally changing the way 4474 works. (Without reducing the protection provided by the signature.)
Why would the SBC do it? So that the recipient wants a way to accurately verify the origin of the request. If the organization deploying the SBC doesn't want to honor the best interests of the sender and receiver then I guess it may choose not to do this. I guess this would be most likely in cases where a transit SP or the destination SP decides to obfuscate the originating address.
Thanks,
Paul
John-----Original Message-----From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: 01 August 2008 17:17To: Eric RescorlaCc: Dan Wing; 'Cullen Jennings'; 'Uzelac, Adam'; 'SIP IETF'; Elwell, JohnSubject: Re: [Sip] Thoughts on SIP Identity issues What if the SBC did the following: - made whatever changes it wants to make to the incoming request to derive the message it wants to send. - calculated the reverse diff the transforms its modified message into the message it received. - affixed the reverse diff to the new message as another body part. - signed the whole thing as itself. - sent it on.When the UAS receives this, it first validates the signature and decides if it trusts the signer.If so, it may then use the reverse diff to reconstruct the unmodified message. It can then validate any signature that may contain to verify the actual caller. This can of course be applied recursively.At any stage it can just decide to trust any assertions made by the intermediary.Paul Eric Rescorla wrote:At Fri, 1 Aug 2008 09:36:36 +0100, Dan Wing wrote:At Thu, 31 Jul 2008 20:54:43 -0400, Hadriel Kaplan wrote:Fascinating paper. (truly) But it sounds more like just-----Original Message----- From: Eric Rescorla [mailto:[EMAIL PROTECTED] Funny you should mention that. It's becoming increasingly clear that VBR codecs leak a fair amount of information, even when they are encrypted [WBC+08]. So, if, for instance, you were planning to use a fixed-rate codec and an attacker could force you into a VBR codec, that might leak information.a reason tofix SRTP for VBR, through random padding or whatever.I haven't studied the problem, but I suspect random padding is of limited use because it averages out. Probably better to use a fixed length codec.However, I think focusing on that misses the largerpoint: the UAC andUAS have certain desires as expressed in the messages/SDP To the extent to which we allow the intermediaries to change those messages, we need to carefully analyze each instance,and this analysis may actually depend on facts yet to be discovered.4474 allows intermediaries to change SDP, and re-create a new>From and a new signature.Well, it allows it in the sense that there's no known cryptographic way to stop it in any system, then sure.This (a) destroys end-to-end identity (which is the subject of this thread) *and* (b) allows intermediaries to perform the very downgrade attack youcited ([WBC+08]). This is why I want to improve upon 4474.I don't agree with this analysis. Let's say that [EMAIL PROTECTED] sends [EMAIL PROTECTED] an INVITE. It's 4474 signed by atlanta.com. Now, some SBC in the middleedits the SDP. This breaks the signature.At this point, when Bob gets the message, he knows: (1) This message claims to be from Alice. (2) The signature was broken. He therefore has no knowledge of what happen. He can choose to accept or reject the call, but can't reasonably infer thatthe call came from Alice or anything else about Alice's intentions.Now, if the SBC resigns, then Bob gets a valid message from somebody else other than Alice. Effectively, the SBC. Now, the SBC claims that it is connecting Bob to Alice, but it could be lying. If Bob trusts the SBC, he can accept the call, but he's trusting the SBC. Sure, the SBC can edit the SDP to replace codecs, but it can do *anything*. It could, for instance, replace the DTLS-SRTP fingerprint. This isn't surprising, since the SBC is really a B2BUA and this is a call from it. The schemes being proposed here allow the RFC 4474 signature to survive some editing of the message by the SBC. The question here is the extent to which that enables *silent* attacks by the SBC. To take an extreme case, if we allowed editing of the fingerprint, then Bob could think he was talking to Alice, but he was actually talking to the SBC. Editing the codecs to allow this kind of traffic analysis is a (much) less serious version of the same threat. Again, this differs qualitatively from the former case because Bob does not know he is under attack. The question, then, when someone proposes exempting some field from the signature, is what silent attacks it enables. I have yet to see any satisfactory analysis along these lines. -Ekr _______________________________________________ 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
_______________________________________________ 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
