First of all, thanks to Eric for this extensive (whereby quite late...)
review. Please find my questions inline.
-Raphael.
Eric Rescorla wrote:
$Id: draft-kuthan-sip-derive-00-rev.txt,v 1.1 2008/11/15 20:48:48 ekr Exp $
This document is intended to provide caller identification for SIP
dialogs without the use of RFC 4474 Identity. The basic principle is
that when Alice calls Bob, Bob initiates a dialog in the reverse
direction (using the RFC 4235 Event Package). This message is assumed
to be routed correctly in the reverse direction and thus provides
independent confirmation of the call to Bob.
This draft has only a very short security considerations, so it's
not clear what threat models it's intended to defend against.
CUT-AND-PASTE
However, unless I've misunderstood the design, there's at least
one significant attack, namely INVITE forwarding plus cut and
paste attack. This works as follows:
Alice Attacker Bob
-----------------------------------------
INVITE ------------->
INVITE ------------->
<------------------------------ SUBSCRIBE
NOTIFY --------------------------------->
<------------- 200 OK
<------- RTP ------->
The attacker somehow convinces Alice to send him an INVITE. The
attacker forwards it to Bob, rewriting the request line and
the SDP. As specified by the draft, Bob then sends a
SUBSCRIBE towards Alice. This gets there and Alice responds with the
appropriate NOTIFY--because Alice actually is in-dialog with the
attacker. This NOTIFY looks OK, and Bob accepts the call, with Alice's
identity displayed in caller-id.
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.
Note that even cryptographic protection a la DTLS-SRTP doesn't help
here, because the attacker can simply rewrite that part of the SDP to
contain his own cryptographic parameters as well as whatever IP
addresses he wants to put in the SDP. It's interesting to contrast
this with RFC 4474, which doesn't have this problem because the SDP is
integrity protected. Of course, it would be possible to modify this
mechanism to provide protection against SDP modification by having
Alice provide the session description in the NOTIFY (S 4.1.6.3 of RFC
4235, I think). However, as I understand this design, it's explicitly
an attempt to avoid RFC 4474 full protection of the message.
Note that there's an even more obvious attack of this flavor from
one of the proxies, where it just modifies the media parameters.
That's not really discussed in the threat model, but I'm assuming
the authors think they're designing hop-by-hop security here.
ATTACKING THE CONFIRMATION STAGE
The previous attack relied on attacking the INVITE and allowing
the confirmation stage to proceed unmolested. Another form of
attack is to attack the confirmation stage. Again, say that
the attacker wants to impersonate Alice. He sends an ordinary
invite to Bob's proxy with From: [EMAIL PROTECTED] He then
uses DNS cache poisoning to hijack the connection to Atlanta.
Now, if Bob tries to use SIPS, this attack will fail, because
the attacker can't properly execute the TLS handshake with
Biloxi, but Biloxi and Bob have no way of knowing that Atlanta
can actually do TLS, so they can't safely insist on it, and
the attacker can always simulate being TLS-incapable if they
try opportunistic TLS. Note that this case is actually worse
than ordinary call hijacking because the attacker knows exactly
when Bob will do his DNS queries, which makes attacks easier.
HIGH LEVEL
It's probably useful to take a high level view of the matter.
Classically, we talk about two related security services:
1. Data origin authentication.
2. Message integrity.
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")?
In order to get DOA, we need the recipient to
be able to get *some* message that they can be sure was from the
sender. Once we have that, message integrity is a matter of tying that
single authentic message to the message to be protected.
With that in mind, while this system is completely different from RFC
4474, they occupy two points in a large and largely orthogonal design
space. I.e., the method of providing data origin authentication is
orthogonal to the method of providing message integrity and the data
to be protected. In particular, as noted above, it would be possible
to use a mechanism of this type to protect the entire message instead
of just pieces of it. Similarly, it would be possible to use RFC 4474
to protect only pieces of the message, as has been described in
multiple drafts.
As another example of this, consider a hybrid solution that uses
S/MIME signatures but DOA via SUBSCRIBE (at least partly):
Every node has a self-signed S/MIME certificate and signs all
its messages. When a node receives a message from a node its
never heard from before, it does a SUBSCRIBE to the sending
node's certificate. Once it has received it, it can then
verify all future messages.
It should be apparent that this mechanism has aspects of both the
RFC 4474 designs and this design. Moreover, one could choose to sign
all or only some of the message, further expanding the design space.
>From this perspective, this particular set of points in the design
space has two weaknesses:
1. The DOA mechanism isn't particularly strong (as indicated by
the DNS spoofing attack described above). The problem here is
that in order for it to work it requires a TLS path all
the way to the (putative) sender. Since there's no guarantee
of this existence, failures are hard to decode. Note that
by contrast, RFC 4474 only requires the *sender* to have
a certificate.
2. The message integrity mechanism doesn't cover enough of the
message, making media hijacking attacks easy. Again, RFC 4474
covers more of the message, blocking this sort of attack.
None of this is to say that there isn't room for another point
in the design space than RFC 4474. However, rather than randomly
selecting points in the space and trying them on for size, we
should try to figure out what we're trying to achieve on both
of these axes and then design specific mechanisms that achieve
these ends.
-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
