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.

> > This mechanism, like RFC 4474, is intended to provide both of these
> > services to some extent. 
> Could you please explain why you think that we are trying to provide 
> message integrity (apart from the "From")?

Right. You're providing minimal message integrity for the From 
(and, if you use the above countermeasure, the To).

-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

Reply via email to