Thank you for the extensive review indeed.
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).
Agreed. Generally there is no MiTM attack against which DERIVE is safe,
be it mounted on DNS or SIP.
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.
By the SIP standard, the To URI shall remain unchanged, but if Call
Forwarding is deployed, Bob ([EMAIL PROTECTED]) may wonder if it makes
sense to launch a DERIVE test with such a URI ([EMAIL PROTECTED]).
That would be workable (I do have all my email addresses configured
in my central procmail too....)
What makes me more worried here is the B2BUA traversal. If TO is changed
and is not consistently translated for DERIVE query, we will get a negative
DERIVE test result.
--
This has not been really DERIVE's purpose, but it seems it would be
helpful for the WG to revisit the phenomena of B2BUA. (the kind of
study what they do, why they do it, what they break by doing what
they are doing, and how to fix it.)
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.
yes.
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.
agreed.
HIGH LEVEL
It's probably useful to take a high level view of the matter.
I agree; the "DERIVE question" is primarily about whether we want
to have better-than-nothing security or not, and I think that's the
key question to ask ourselves.
Particularly here we are not really promising determining identity,
but cryptographically unsecured reverse routing check. We cannot
answer "who are you", but we can answer "where are you" (and still
have residual uncertainty because we don't use cryptography to
establish that).
I think this can be still useful provided we document well the
limitations. For some practical purposes, it is "good enough" -- say
if someone is using your URI in a request to me, this type of
check can detect the request as uncertain.
In the non-SIP world, I would compare it to SPF. In fact even SPF
could be a legitimate answer along the better-than-nothing security.
The key difference here is if we are interested in domain-level
or per-call verification granularity.
Classically, we talk about two related security services:
1. Data origin authentication.
2. Message integrity.
in this context, I think that DERIVE and alike can provide a weak
assertion for 1 and none for 2. (unless we combine those with
additional techniques, which would however weaken the promise
of simplicity)
This mechanism, like RFC 4474, is intended to provide both of these
services to some extent. 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).
agreed.
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.
well I think DERIVE is weaker in that does not give any real
integrity at all.
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.
I think the key point here is what you call DOA, and at the same time
simplicity. I think if we try to indirectly compare it to RFC4474
this is value small in size compared to RFC4474 (particularly if we
realize the limitations such as MiTM vulnerabilities) but promising
in use (it is easily deployable, has an adoption path, and can help
to sort out some attacks that are now way too easy to mount.)
-jiri
-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
_______________________________________________
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
