I like this approach as this can even be used for inter-carrier-domain authentication where the signature introduced by a B2BUA in one domain can be trusted by the one in another domain by checking the intermediary IDs to say provide priority services. So if there is an RPH header associated with this request the receiving domain can honor that value. In the absence of such a thing as inter domain authentication, this can be used for that purpose without breaking 4474.
regards, Padma. Computer Sciences Corporation Registered Office: 3170 Fairview Park Drive, Falls Church, Virginia 22042, USA Registered in Nevada, USA No: C-489-59 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Paul Kyzivat <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/01/2008 12:16 PM To Eric Rescorla <[EMAIL PROTECTED]> cc "'Cullen Jennings'" <[EMAIL PROTECTED]>, "'SIP IETF'" <[email protected]>, "'Uzelac, Adam'" <[EMAIL PROTECTED]>, "'Elwell, John'" <[EMAIL PROTECTED]>, Dan Wing <[EMAIL PROTECTED]> 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
_______________________________________________ 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
