On Tue, Jan 13, 2009 at 3:16 PM, Peter Saint-Andre <stpe...@stpeter.im> 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. :) > 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 > 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. -Ekr
