Subject: [AVTCORE] Review of draft-ietf-avtcore-rtp-security-options-01

From: "Correll, Christian" <[email-masked]>
Date: Wed, 12 Dec 2012 12:59:47 +0000

Hi,

I reviewed the RTP security options document and I have following comments.

1) Section 3.1.  Secure RTP

   The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly
   used mechanisms to provide confidentiality, integrity protection and
   source authentication for RTP.

Another security property that is explicitly mentioned in RFC 3711 is replay protection.

2) Section 3.1.1.  Key Management for SRTP: DTLS-SRTP

   A Datagram Transport Layer Security extension exists for establishing
   SRTP keys [RFC5763][RFC5764].  This extension provides secure key-
   exchange between two peers, including perfect forward secrecy and
   enabling binding strong identity verification to an end-point.

I wonder if the security properties of DTLS-SRTP actually depend on the ciphersuite the endpoints negotiate during the DTLS handshake. For example, when client and server agree on the ciphersuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA they perform a Diffie-Hellman key agreement; in this case DTLS-SRTP provides PFS. Whereas when they agree on TLS_RSA_WITH_AES_128_CBC_SHA the client encrypts a shared secret with the server's public key; and in that case PFS is not provided. To meet the security goals, the ciphersuites that the client can offer and the server can accept need carefully be selected.

3) Section 3.1.2.  Key Management for SRTP: MIKEY

Pre-Shared Key mode:

   This system is the most efficient from the perspective of having
   small messages and processing demands.

The downside is scalability. Usually, the effort for the provisioning of pre-shared keys is only manageable, if the number of endpoints is small.

IBAKE mode:

   If provides both perfect forward and backwards secrecy.

I think the term perfect backward secrecy needs more clarification. In what exactly is it different from forward secrecy? For example, RFC 4949 gives a definition of perfect forward secrecy and briefly discusses issues where experts disagree about it. Backward secrecy is mentioned in that context as one of the disputed issues (it seems to be a synonym for forward secrecy), but not precisely defined. I am not aware of a clear definition of this term.

SAKKE mode:

Requires additional infrastructure. A key management service (KMS) must create the secret keys associated with the identities (resp. public keys).

4) Section 3.1.3.  Key Management for SRTP: Security Descriptions

   Since keys are transported in plain text in SDP, they can easily be
   intercepted unless the SDP carrying protocol provides strong end-to-
   end confidentiality and authentication guarantees.  This is not the
   common use of security descriptions with SIP, where instead hop by
   hop security is provided between signalling nodes using TLS.  This
   still leaves the keying material sensitive to capture by the
   traversed signalling nodes.  Thus in most cases the security
   properties of security description are weak.

I agree. The usage of security descriptions usually requires additional security measures, e.g. the signalling nodes be trusted and protected by strict access control. An example where these conditions are often given is an enterprise environment. Usage of security descriptions requires careful design in order to ensure that the security goals can be met.

5) Section 3.1.4.  Key Management for SRTP: EKT

   Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP
   extension that enables group keying despite using a keying mechanism
   that can't support group keys, like DTLS-SRTP.

A second use case also described in the EKT draft is interoperability between different key management systems.

6) Section 4.1.3.  Source Authentication

Binding the Source:

      For example, consider a point to point communication system that
      use DTLS-SRTP using self-signed certificates for key-management,
      and SIP for signalling.  In such a system the end-points for the
      DTLS-SRTP handshake have securely established keys that are not
      visible to the signalling nodes.  However, as the certificates
      used by DTLS is not bound to any PKI they can't be verified.
      Instead, hashes over the certificate are sent over the signalling
      path.  If the signalling can be trusted not to collaborate on
      performaning a man in the middle attack by modifying the hashes,
      then the end-points can verify that they have reached the peer
      they are doing signalling with.

A second example is a key management method that transports the key exchange data in the signalling plane, e.g. MIKEY or security descriptions. Such a method ties the key exchange directly to the signalling. There are no additinal steps required to ensure that the "signalling peer" is the same as the "key exchange peer".

7) Section 4.1.4.  Identity

   ..., having an identity provider system can benefit the applications
   by enabling them to do strong assertion between identity and the
   actual media source.

I wonder if the draft should briefly address how identity verification can be achieved. The draft states several times that source authentication is possible using verifiable identities. I think, giving examples for the most widely used systems for asserting and verifying an identity makes reading easier.

Regards

Christian Correll