Re: Review of draft-kuthan-sip-derive-00

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