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

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