Eric Rescorla wrote: > On Tue, Jan 13, 2009 at 3:16 PM, Peter Saint-Andre <[email protected]> wrote: >> For Goal #1, the IETF has settled on SRTP (RFC 3711) because it is >> optimized for media traffic. (Another alternative would have been RTP >> over DTLS, but it is not optimized in that way.) However, SRTP does not >> solve the problem of communicating the keying material that will be used >> in the transport channel. There are several major proposals for doing that: >> >> - SDP Security Descriptions <http://tools.ietf.org/html/rfc4568> (this >> defines the a=crypto SDP line, which is currently re-used in XEP-0167) >> >> - ZRTP <http://tools.ietf.org/html/draft-zimmermann-avt-zrtp> >> >> - DTLS-SRTP <http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp> and >> <http://tools.ietf.org/html/draft-ietf-sip-dtls-srtp-framework> (these >> define the a=fingerprint SDP line and a method for using it by setting >> up a DTLS association over the host/port quartet and then pulling the >> SRTP keying material out of that DTLS association) >> >> The "Requirements and Analysis of Media Security Management Protocols" >> <http://tools.ietf.org/html/draft-ietf-sip-media-security-requirements-09> >> provides an overview of these and other approaches. > > So, at the Prague IETF Meeting, the IETF decided on DTLS-SRTP. The documents > have already passed IETF Last Call and are in front of the IESG. My reading is > that there are no serious objections and I expect to provide updated text > that meets the mostly editorial objections in the next few weeks. > > >> According to my reading of RFC 4568, SDP Security Descriptions MUST NOT >> be used unless the signalling channel (that's XMPP for us) can "provide >> strong message authentication and packet-payload encryption, as well as >> effective replay protection". Because we don't provide those services in >> XMPP out of the box, I don't think we can securely use a=crypto (or our >> XMLish flavor of a=crypto as currently described in XEP-0167). But we >> might be able to use it if we negotiate XTLS (or some other e2e method) >> first. > > Yeah, this more or less matches the analysis that IETF made as well. > The fundamental problem here is establishing a secure channel between > the endpoints. Once you've done that, you can bootstrap up to any other > kind of secure channel. :)
Correct. >> That leaves ZRTP or DTLS-SRTP. ZRTP is completely independent of the >> signalling channel (or can be, see Section 8 of the ZRTP spec), so we >> don't need to define anything in Jingle to support it. However, we could >> provide some hints in the Jingle signalling. > > So, this is strictly accurate but kind of misleading. ZRTP does provide > an operational mode in which no coordination is required with the signalling, > but that operational mode relies on the communicating parties > (1) being able to recognize each other's voices and (2) reading a > "short authentication string" over the media channel. This makes it > fundamentally unsuitable for any non-voice or non-human channel > such as an IVR, and I think there are serious questions about its security > level even in human to human contexts. See my slide deck here: > > http://www.ietf.org/proceedings/07mar/slides/rtpsec-0.pdf > > The bottom line as far as I can make out is that you need to have a > mechanism for binding the keying material to the signalling. This > isn't to say that ZRTP is bad, but merely that I don't think it's integration > free You're right. My apologies for the lack of clarity. >> For DTLS, we'd need to define an XMPP-friendly mapping of the SDP >> a=fingerprint line and the various SDP parameters discussed in >> http://tools.ietf.org/html/draft-ietf-sip-dtls-srtp-framework and >> http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp -- but this seems >> fairly straightforward. > > Yes. I agree with this. I think you would need to do this for XTLS in > any case and that the same mechanisms could be used. More on that soon. /psa
