Re: ZRTP comments part 4: security (everything but SAS)

[EKR <ekr@xxxxxxxxxxxxxxxxxxxx>]

Alan Johnston <alan@xxxxxxxxxxxxxx> wrote:
> EKR wrote:
> > 1.1. False Forgetting/Impersonation [Pointed out by Dave McGrew]
> > When Alice calls Bob, even if she has called him before, there are two
> > cases in which ZRTP does not provide continuity of authentication.
> >
> >   1. Bob (or Alice) is using a different handset.
> >   2. Bob's handset (or Alice's) has lost some of its dynamic
> >      state and no longer has the right secrets cached.
> >      For instance, there may have been a disk crash followed by
> >      a restore from backup, rolling back your state.
> >      Also, as noted in S 3.2, this may simply be normal cache expiry.
> >
> > In practice, it's thus fairly normal for Alice to call Bob and be told
> > that there's no cached state and have to do a new SAS exchange (and
> > note that you must or you won't have any MITM defense at all.)
> >
> 
> This does not follow.  If Bob's handset normally crashes and looses
> all state, then Bob will be in the market for a new phone - users will
> not permit PC-like experiences in their communication devices.

Well, I assumed that we were also making a system that would work for
softphones, which do crash. And I've certainly had my Treo crash
and lose all its data...
 

> Secondly, different handsets will have different ZIDs, so if Alice
> calls Bob regularly (as this example implies), she will have a cache
> with each handset (ZID).

Agreed.


> > This is unpleasant, but can't be considered a security vulnerability in the
> > sense that you shouldn't have flashing red lights and alarms going off
> > on your phone.
> >
> > This facilitates the attacks described in S 4.1 because it makes
> > people used to doing SASes under conditions they don't understand and
> > so if you do have a workable active SAS attack you can mount it at
> > any time, not just at the first exchange. This attack can be mitigated
> > to some extent by making the key continuity information more stable,
> > as with SSH or DTLS-SRTP, but this would require major changes to
> > ZRTP.
> >
> 
> I don't follow this either.  What is the danger of users checking the
> SAS - it will detect a MitM.

The problem here is that key continuity mechanisms work best when
the key changing is a truly exceptional event. When it's not
exceptional, then users experience the first time mating ritual
(in this case the SAS) a lot, which tends to weaken both 
mechanisms, and since the SAS (even in the best case) depends
intensely on user vigilance, this isa real problem. Moreover,
as I noted earlier, there are cases where SAS will not detect
a MITM.


> > 4.1. Pre-ZRTP Binding
> > The first mode utilizes secrets from the initial offer/answer as
> > additional secret input to the ZRTP computation (sigs, srtps). These
> > techniques don't really work that well.  sigs always comes from
> > material that's in the clear in the SIP dialog, so an attacker who
> > observed a SIP dialog in progress could attack this binding.
> >
> 
> sigs can only be derived from Secure SIP dialog identifiers, so it is
> not in the clear, although visible to trusted proxies. 

Sorry, I meant in the clear over whatever channel the SIP is over,
hence accessible to proxies...


> > srtps either comes from an SDESCRIPTIONS exchange or a MIKEY exchange.
> > In the first case, you're again requiring confidentiality of the
> > dialog. In the second case, you need to do a full MIKEY
> > exchange, which seems unlikely.
> >
> >
> > 4.2. Post-ZRTP Binding
> > ZRTP also offers a way for the signalling to pass an SAS value in
> > another SIP exchange after the ZRTP has completed (this can't be done
> > before because the SAS emerges from the ZRTP handshake).  One side
> > sends the SAS in an SDP in a new offer/answer exchange (i.e., a
> > reinvite.) Unlike the techniques described in 4.5.1, this works with a
> > signalling channel that has integrity even if confidentiality is not
> > provided.
> >
> > Unfortunately, this binding mechanism is subject to an active attack.
> > Let's say that the attacker knows that you're trusting the signalling
> > and that you don't check the SAS (a presumably common occurrence.)  He
> > allows the first SIP exchange to go through, plus the ZRTP handshake,
> > but then blocks the re-INVITE. Because neither ZRTP nor the initial
> > offer/answer knows who would do a re-INVITE or whether it would occur
> > at all, there is no way for either side to know that there was an
> > active attack. The attacker can either simply remove the packet from
> > the network and let the re-INVITE time out or, if Identity but not
> > SIPS is in use, then he can inject a fake 200 OK (remember that
> > responses are not themselves integrity protected.)
> >
> 
> Sadly, today in SIP, nothing is integrity protected. :-(  The
> deployment of Identity, while a wonderful thing, will take a long,
> long time due to issues with SBCs.  Today, there is no integrity
> protection in the SIP signaling channel, and to rely on something that
> isn't there is not good security.
> 
> Hence the need for SAS for the next few years.

Uh, so you agree that this attack exists even if Identity is used?

-Ekr