RE: Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-03.txt

["Dan Wing" <dwing@xxxxxxxxx>]

> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@xxxxxxx] 
> Sent: Monday, March 12, 2007 10:11 AM
> To: Dan Wing
> Subject: Re: Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-03.txt
> 
> > Perhaps we could require or recommend one of those mechanisms for
> > early media.
> 
> The selection of a mechanism to reliably deliver answers is 
> the goal of draft-barnes-sip-em-ps-req-sol:
> <http://tools.ietf.org/html/draft-barnes-sip-em-ps-req-sol-00>

Sorry, I had not noticed that document.  Looks great, although I
don't see how we could re-define the meaning of 200 OK (your
section 3.1.1).  Cisco's Call Manager already sends out offerless
Invites (your section 3.1.2) and this causes us interop problems.

One thing I noticed is:

   o  Confidentiality: Techniques such as MIKEY [RFC3830]and Security
      Descriptions [RFC4568], which use SDP to establish keys for media
      security protocols, require a full SDP offer/answer exchange to
      negotiate keys.  Such keying techniques are therefore incompatible
      with early media.

That is true of many of MIKEY's modes (-RSA-R and -DHSIGN, for example),
but isn't true of MIKEY-PSK or MIKEY-RSA, which have the offerer dictate
the key to the answerer.  For those modes, the offerer can decrypt the
SRTP packets before the SDP answer arrives.  There are another ~8 or
so MIKEY modes and I suppose an analysis of them might uncover which
of those modes require a round-trip for the offerer to successfully
decrypt arriving SRTP media.

> The connected-identity technique isn't discussed in the 
> current version, but I'll mark it for future inclusion.

Yeah, it was only described by John Elwell recently in this thread:

http://www1.ietf.org/mail-archive/web/sip/current/msg18110.html 
http://www1.ietf.org/mail-archive/web/sip/current/msg18112.html

> > What do you advise we do -- change those get those systems changed 
> > or give up and key entirely in SIP?  There was consensus in 
> > Montreal that we can't achieve success with an entirely call-
> > signaling-based approach.  I don't see how we could revisit that
> > now, a week before the Prague IETF.
> 
> I think what's becoming clear is that we need both signaling- and 
> media-based techniques for negotiating SRTP contexts.  An 
> all-signaling approach incurs a lot of latency, but is reliably 
> full-duplex; an all-media approach is the reverse.  I don't think 
> the whole community can agree on which trade-off is preferable.  
> Perhaps the unified approach taken by MIKEYv2 is the right way 
> to go (I've only skimmed the draft).

Or suppport two (or three) techniques, like was mentioned in the
thread with Dan York.  While a pain for implementors, as long as
supporting multiple key exchange techniques doesn't cost the 
offering endpoint lots of additional computations, it is arguably
reasonable.  

For example, an offerer could support -- say -- sdescriptions, 
ZRTP, and DTLS-SRTP, and MIKEYv2; cheating at the syntax a little 
bit, you would have something like this with 
draft-ietf-mmusic-sdp-capability-negotiation-05:

  SDP offer:
      v=0 
      o=- 25678 753849 IN IP4 192.0.2.1 
      s=  
      c=IN IP4 192.0.2.1 
      t=0 0 
      m=audio 53456 RTP/AVP 0 18  
      a=tcap:1 RTP/SAVP  
      a=acap:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 ...
      a=acap:2 a=key-mgmt ...
      a=acap:3 a=zrtp-zid ...
      a=pcfg:1 t=1 a=3
      a=pcfg:2 t=1 a=2 
      a=pcfg:3 t=1 a=1

With this, ZRTP is most preferred (pcfg=1), a=key-mgmt is next preferred
(pcfg=2), and sdescriptions is next preferred (pcfg=3).  This offer will
also fall back to RTP, as well, if the answerer doesn't understand
draft-ietf-mmusic-sdp-capability-negotiation.

(Note that MIKEY requires generating an integrity check over itself, which
uses AES.  Reference section 4.1.4 of RFC3830.)


Because such an offer is possible, do we need to discuss this in Prague?

-d