Subject: [siprec] Security review of draft-ietf-siprec-protocol-05

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 28 Jun 2012 11:58:16 -0400

Dear SIPREC,

At the SIPREC meeting at the last IETF, I volunteered to do a security review of the SIPREC protocol document.  Thanks to the chairs increasingly persistent reminders, I've finally gotten around to doing it :)

At one level, my basic question is: How is this better than just doing a PCAP?  I can see the efficiency gains in terms of RTP handling, but I'm concerned that (1) the security requirements need to be more tightly specified, and (2) there seems to be quite a bit of information loss.

Starting with the most obvious part: The Security Considerations needs to be tightened up.  This document benefits from the fact that the SRC and the SRS are logically within the same administrative domain, so it should be feasible to establish credentials that they use to authenticate one another.  So the document should REQUIRE that the SRC and the SRS mutually authenticate to one another, either using SIP authentication or using TLS authentication beneath SIPS.

At the media level, is there a reason that you don't specify a keying mechanism?  Why would you not just specify DTLS-SRTP?  It may also be worth noting that because this protocol will tend to be used within an administrative domain, the need for confidentiality is lower than in the general Internet; however, there is still a strong need for authentication.  So this document should REQUIRE that implementations support the SRTP_NULL_HMAC_SHA1_* protection profiles and RECOMMEND support for others.

Speaking of SRTP, it's not clear whether there's a requirement for the SRC/SRS to have access to the keys used to protect secure media, in the case where the SRC is a middlebox, not terminating media.  To support this case, you would need (1) a way to get the key from the endpoint to the SRC, and (2) a way to get the key from the SRC ot the SRS.  I would suggest looking at EKT / KTR for both of these [http://tools.ietf.org/html/draft-mcgrew-srtp-ekt-06#section-4][http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport-03].

Finally, it seems like a gap that the SIP signaling information for the recorded session doesn't get passed off to the SRC.  Section 8 of the current document describes how to pass "metadata", but doesn't really define what the metadata is. 

Hope this helps,
--Richard