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

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