At Thu, 20 Nov 2008 16:48:54 +0100, Raphael Coeffic wrote: > > Eric Rescorla wrote: > > At Thu, 20 Nov 2008 15:41:56 +0100, > > Raphael Coeffic wrote: > > > >> First of all, thanks to Eric for this extensive (whereby quite late...) > >> review. Please find my questions inline. > >> > >> -Raphael. > >> > >> Eric Rescorla wrote: > >> > >>> I believe this attack actually works as I've described it with the > >>> examples shown in S 7.1, which don't contain any identity values in > >>> the NOTIFY. However, one countermeasure you might try is to try > >>> is to compare identity values, in particular the To line (remember > >>> that you can't compare the URI in the request because those > >>> can get transformed, hence the need for History). Unfortunately, > >>> since call forwarding is a legitimate service, there are reasons > >>> why the To received by Bob might not match what was in Alice's > >>> original INVITE, so if you rely on this check you'll get a lot > >>> of false positives, which seems problematic. > >>> > >>> > >>> > >> I believe that the counter measure that you are proposing has already > >> been adressed in the draft. Concerning call forwarding, we know that > >> this is an issue. But I still don't understand why checking the To in > >> the SUBSCRIBE should generate a false positive. In this case, Alice > >> would refuse to reply to the SUBSCRIBE, as it does come from any party > >> Alice has sent an INVITE to. > >> > > > > The problem here is the notion of "sent an invite to". When you try > > to call my cell and it gets forwarded to my landline, you indeed > > tried to call me, but you will refuse to confirm the call. > > > > > Exactly. But that won't prevent you from answering this call. We can > just make no assumptions on the "From" in this case. This is a "maybe".
I would call that a false positive. Pretty much *any* data origin authentication mechanism only gives you one of two answers: yes or maybe, since it's always possible the signature/MAC/whatever was just broken along the way somehow. > > Right. You're providing minimal message integrity for the From > > (and, if you use the above countermeasure, the To). > > > > > I'm not quite sure this is correct. The From could even have been > changed on the way. As long as the change is reverted back during the > check, we do not care. I'm not sure what that means. -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
