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.
John > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 01 August 2008 17:17 > To: Eric Rescorla > Cc: Dan Wing; 'Cullen Jennings'; 'Uzelac, Adam'; 'SIP IETF'; > Elwell, John > Subject: 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: > >>>> > >>>> > >>>>> -----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. > >>>> Fascinating paper. (truly) But it sounds more like just > a reason to > >>>> fix 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 larger > point: the UAC and > >>> UAS 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 you > >> cited ([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 middle > > edits 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 that > > the 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
