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".
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).
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.
-Raphael.
-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
