Reference11r1:Concept DTLS-SRTP: Difference between revisions
Line 11: | Line 11: | ||
In order to understand the advantages of DTLS-SRTP let's go one step back and take a look SDES - the standard that was used before. SDES transmits the secret keys as part of the signalling messages. That messages go from one endpoint through several PBXes to the other endpoint, hop-to-hop. As the secret keys have to be proteced from eavesdropping the signalling messages have to be encrypted as well. But as the signalling messages are only encrypted hop-to-hop each PBX in the middle can see or even modify the keys. | In order to understand the advantages of DTLS-SRTP let's go one step back and take a look SDES - the standard that was used before. SDES transmits the secret keys as part of the signalling messages. That messages go from one endpoint through several PBXes to the other endpoint, hop-to-hop. As the secret keys have to be proteced from eavesdropping the signalling messages have to be encrypted as well. But as the signalling messages are only encrypted hop-to-hop each PBX in the middle can see or even modify the keys. | ||
It is a conceptual problem of SDES that endpoints have to trust the PBXes. This is a managable risk when all PBXes are under control of the customer. But with internet calls across company boundaries like with SIP open fedation it becomes an actual threat. Possible attacks include corruped PBXes that give away the keys together with the CDRs to an attacker that is then capable of decrypting captured SRTP calls on a large scale. DTLS-SRTP was designed to | It is a conceptual problem of SDES that endpoints have to trust the PBXes. This is a managable risk when all PBXes are under control of the customer. But with internet calls across company boundaries like with SIP open fedation it becomes an actual threat. Possible attacks include corruped PBXes that give away the keys together with the CDRs to an attacker that is then capable of decrypting captured SRTP calls on a large scale. | ||
DTLS-SRTP was designed to solve that issue. It does not transmit the keys in signalling messages but inband as part of the media stream using end-to-end encryption. | |||
==Protocol flow== | ==Protocol flow== |
Revision as of 18:23, 10 September 2014
Applies To
This information applies to
- all innovaphone devices from v11r1 RC2
Overview
SRTP is a standard for encrypting RTP media streams. Before two endpoints can do that encryption they need to exchange secret keys. DTLS-SRTP is a new method how to do so.
In order to understand the advantages of DTLS-SRTP let's go one step back and take a look SDES - the standard that was used before. SDES transmits the secret keys as part of the signalling messages. That messages go from one endpoint through several PBXes to the other endpoint, hop-to-hop. As the secret keys have to be proteced from eavesdropping the signalling messages have to be encrypted as well. But as the signalling messages are only encrypted hop-to-hop each PBX in the middle can see or even modify the keys.
It is a conceptual problem of SDES that endpoints have to trust the PBXes. This is a managable risk when all PBXes are under control of the customer. But with internet calls across company boundaries like with SIP open fedation it becomes an actual threat. Possible attacks include corruped PBXes that give away the keys together with the CDRs to an attacker that is then capable of decrypting captured SRTP calls on a large scale.
DTLS-SRTP was designed to solve that issue. It does not transmit the keys in signalling messages but inband as part of the media stream using end-to-end encryption.
Protocol flow
Configuration
Priority of SDES and DTLS-SRTP
If nothing is configured, the device offers both SDES and DTLS-SRTP for outgoing calls. For incoming calls it selects SDES if offered. Otherwise it selects DTLS-SRTP or unencrypted RTP, as a fallback. This allows for compatibility with most endpoints.
The admin can change that behaviour at the configuration of the registration. There the key exchange mechanisms (SDES, DTLS-SRTP) and their priority can be selected. For example on phones this is can be done on page Phone/User/General. Please consult the help pages for details.
Certificates
No special configuration is needed regarding certificates. DTLS-SRTP does not require endpoints to have the certificate of the remote endpoint in the trust list. Also it doen't check the names inside certificates.
Disabling DTLS-SRTP
For debugging purposes there are config options at the signalling modules that globally turn DTLS-SRTP off. Normally this should not be needed.
config add H323 /dtls-disabled config add SIP /dtls-disabled config add TSIP /dtls-disabled config add SIPS /dtls-disabled
Tracing
Activation
Traces for debugging DTLS-SRTP can be activated at the signalling module. The trace flags are also available on the debug.xml page.
config add H323 /dtls-trace on config add SIP /dtls-trace on config add TSIP /dtls-trace on config add SIPS /dtls-trace on
Reading traces
Known limitations
References
- RFC5764 - Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)