5. Security Considerations

The SAVPF profile inherits its security properties from the SAVP profile; therefore, it is subject to the security considerations discussed in RFC 3711 [4]. When compared to SAVP, the SAVPF profile does not add or take away any security services.

There is a desire to support security for media streams and, at the same time, for backward compatibility with non-SAVP(F) nodes.

Application designers should be aware that security SHOULD NOT be traded for interoperability. If information is to be distributed to closed groups (i.e., confidentially protected), it is RECOMMENDED not to offer alternatives for a media session other than SAVP and SAVPF as described in Sections 3.3 and 3.4, unless other security mechanisms will be used, e.g., the ones described in Section 9.1 of RFC 3550 [1]. Similarly, if integrity protection is considered important, it is RECOMMENDED not to offer the alternatives other than SAVP and SAVPF, unless other mechanisms are known to be in place that can guarantee it, e.g., lower-layer mechanisms as described in Section 9 of RFC 3550 [1].

Offering secure and insecure profiles simultaneously may open to bidding down attacks. Therefore, such a mix of profile offer SHOULD NOT be made.

Note that the rules for sharing master keys apply as described in RFC 3711 [4] (e.g., Section 9.1). In particular, the same rules for avoiding the two-time pad (keystream reuse) apply: a master key MUST NOT be shared among different RTP sessions unless the SSRCs used are unique across all the RTP streams of the RTP sessions that share the same master key.

When 2^48 SRTP packets or 2^31 SRTCP packets have been secured with the same key (whichever occurs before), the key management MUST be called to provide new master key(s) (previously stored and used keys MUST NOT be used again), or the session MUST be terminated.

Different media sessions may use a mix of different profiles, particularly including a secure profile and an insecure profile. However, mixing secure and insecure media sessions may reveal information to third parties and thus the decision to do so MUST be in line with a local security policy. For example, the local policy MUST specify whether it is acceptable to have, e.g., the audio stream not secured and the related video secured.

The security considerations in RFC 4585 [3] are valid, too. Note in particular, applying the SAVPF profile implies mandatory integrity protection on RTCP. While this solves the problem of false packets from members not belonging to the group, it does not solve the issues related to a malicious member acting improperly.