Re: ZRTP, Key Continuity, and bump in the stack

Alan Johnston <alan@xxxxxxxxxxxxxx> writes:
>There is a lot of confusion around about what is meant by bump in the wire,
>bump in the stack, and just generally things that go bump in the night...
>The confusion is our fault - in the ZRTP spec we haven't spelled this out
>clearly enough, so I will attempt to do so here.

Fair enough.  Thanks.

>In the classic "bump in the *" operation, the ZRTP stack is completely
>blind to the signaling.  If the signaling is sent in the clear, it might be
>able to parse it and figure things out.  Phil has some software that does
>this (not his commercial product) - it works somewhat, however, it really
>is just a demonstration of how far ZRTP can be decoupled from the
>signaling, and points at how ZRTP could be adapted to, for example, secure
>Skype sessions.  This is *not* the normal mode of ZRTP implementation.
>This is not how Phil's libZRTP stack works, for example.

Ok.  How exactly does this work?  (I can guess for in-the-clear UDP SIP.)

>The other mode of operation is "no dependency on the signaling protocol"
>mode of ZRTP.  In this mode, ZRTP does not insert anything into the
>signaling, and does not directly extract anything from the signaling.

The ZRTP spec should call out issues regarding this if bump-in-the-* mode
is seen as relevant (and I assume it is given current implementations).

>However, this does not mean that ZRTP is blind to what is going on.  For
>example, any telephony API lets you discover who the caller and called
>party is - this has nothing to do with coupling with a given security
>protocol.  So, ZRTP can  know who called who, but there is no dependency on
>SIP signaling.  This is the normal mode of deployment of ZRTP today.  This
>is the situation we should be analyzing.

Which "telephony APIs" are you referring to?  You're appear to be assuming
it's running on the same machine as the client, which means a PC and not a
hardphone, and you're probably assuming Windows.  And if this is mandatory
to (reasonable) security in bump-in-the-* mode (and I think it is), this
needs to be really well analyzed and discussed in the spec.  Also: if ZRTP
has to be hooked into "telephony APIs" on the client, I'm not sure I would
call that "bump-in-the-wire".  I'm not sure *what* I would call it, but
bump-in-the-wire implies something very different to me.


BTW, another way to work without depending on "telephony APIs" would be to
implement a ZRTP-aware SIP (or H.323) proxy.  When run on the same machine,
it can act similarly to the current "bump-in-the-*" mode, but it gains
access to signalling info.  You'd configure the non-ZRTP-aware client to
use localhost:<port> as an outbound proxy.  The proxy could then examine
all the SIP and make the real connection to the SIP destination or real
outbound proxy, either over UDP, TCP, or TLS as per normal.  It would need
to proxy the media streams (as the current ZRTP "bump" implementation does)
You could also run it on any machine within a trusted/secure local network
to act as a security gateway to outside traffic; this would allow use of
unencrypted SIP hardphones (or encrypted ones that don't support ZRTP, if
you add the appropriate key protocols to the proxy).

The Borderware ZRTP device may well be something like this; I haven't
looked at their description of it.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup@xxxxxxxxx
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
                - James Madison, 4th US president (1751-1836)