Goals
- Implement support for SIP over TLS on the SR140
- Method to secure the SIP signaling exchange, to protect headers, addresses and SDP
- Method to protect SDES SRTP key exchange which occurs in the crypto attr of the SDP (without SIP TLS, SDES is unsecure)
Background and strategic fit
SIP TLS is also referred to as Secure SIP and represents a way to encrypt the SIP exchange.
SIP TLS is the method that VoIP networks use to secure signaling. Providing SIP TLS protects the SDES key exchange over public networks.
Assumptions
- SIP TLS can be used with or without secure RTP
Information from Pablo DePaulis (Deactivated)
\\pysnas01\Infofactory\MCPD Export Data\MCPD Program Information\Protocols\Design Docs\SIP TLS.doc
The sources are more likely portable to any other RV implementation relatively easily… In fact it’s very clear we took the RV TLS examples and augmented them as required. The HMP interface resembles the RV interface a lot as you will see from the API committee document at a quick glance.
If you have CC access to our database (otherwise Brian O. will be able to provide), this is the subsystem build that contains it: \\pysnas02\INT_BLD\scm\subsystem_builds\iphost\5.0.1
Developer’s Config spec should be there…
I can walk you or anyone else thru the sources, to take you specifically where the files are (SIP Sigal subcomponent).
It might also be of interest in having a quick overview of the high-level components of the Iphost subsystem: \\pysnas01\Infofactory\MCPD Export Data\MCPD Program Information\Protocols\Training Docs\NJ
The IP CCLIB Overview is relatively short, and though very old it’s still relevant.
TLS requirements indicates TLS 1.0, i.e. RFC 2246 compliance:
That said the TLS support comes from RV stack… they support TLS v1.2 options, but it doesn’t look we have taken advantage of them. In fact:
http://www.dialogic.com/~/media/manuals/docs/globalcall_for_ip_hmp_v12.pdf
sip_tls_method indicates the version of SSL to use. Defined enumerations are: Dialogic® Global Call IP Technology Guide 679 TLS engine configuration information — SIP_TLS_ENGINE • ENUM_TLS_METHOD_TLS_V1 – use TLS ver. 1 (Default value)
if (ENUM_TLS_METHOD_TLS_V1 != pEngine->E_sip_tls_method)
{
pDbg->print (Dbg::M_SHM,Dbg::LEVEL_ERROR,0,__FILE__,__LINE__,
"<< checkTLSEngineParams: invalid TLS method %d\n",pEngine->E_sip_tls_method);
return IPERR_INVALID_TLS_PARAM;
}
Information from Dan LoPresti (Deactivated)
I did find a few useful general topics on the links.
- http://etutorials.org/Networking/802.11+security.+wi-fi+protected+access+and+802.11i/Part+II+The+Design+of+Wi-Fi+Security/Chapter+9.+Upper-Layer+Authentication/Transport+Layer+Security+TLS/
- https://computing.ece.vt.edu/~jkh/Understanding_SSL_TLS.pdf
In our docs, we do also provide an overview and then get into the weeds on using it with out API
- Page 335 - http://www.dialogic.com/~/media/manuals/docs/globalcall_for_ip_hmp_v12.pdf
The security package for the SR140 will be an add-on component. This add-on package will contain the openssl library required by the Radvision SIP stack to provide security capabilities.
Security features for the SR140 will be enabled by a licensed keyword. This keyword may be installed as a standalone license to allow an existing system to enable security features. *Need to define keyword and allowed values. If the key does not exist, it shall default to 0 (disabled).
The config tool will be updated to detect if the security license is available. When enabled the config tool will display relevant fields pertaining to the configuration of the security options (TBD). The installation of a certificate will be a configuration option. If the user does not have a certificate, the config tool will provide a mechanism to generate a self-signed certificate.
The default port for SIP over TLS will be 5061. This port may configured by the end user.
Information on DMG and IMG Support
Both the IMG 1010 and the BND 2020 support SIP over TLS. Documentation is located at:
http://www.dialogic.com/webhelp/IMG1010/10.5.3/WebHelp/IMG.htm
http://www.dialogic.com/webhelp/BorderNet2020/2.2.0/WebHelp/default.htm
Requirements
| # | Title | Importance | Notes |
|---|---|---|---|
| 1 | SHALL support SIP with TLS (RFC5246) and use cases shall follow SIP TLS examples shown in RFC6216 (SIP Secure Call Flows) | ||
| 2 | SHALL support SIP TLS with TLS v1.2, and older (SSLv3 and TLSv1) | ||
| 3 | SHALL support standard cipher suites, such as: TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_RC4_128_MD5. | ||
| 4 | SHALL allow SIP TLS to establish RTP media with G.711 or to establish T.38 SIP TLS SHALL be independent of media. It SHALL not be required to use SIP TLS to establish a secure media channel. | ||
| Config Tool Requirements | |||
| 5 | SHALL allow a field to enable or disable the use of SIP over TLS. | ||
| 6 | SHALL allow a field to allow the end user to provide a configuration file for SIP over TLS. This configuration file will be used to config the required SIP over TLS parameters. Required parameters will be defined in a seperate TLS configuration document. |
| |
| 7 | If SIP over TLS is enabled and the configuration file can not be found, an error will be generated in the ECC log. When reading the SIP over TLS configuration file, the parsing of the parameters will be shown in the ECC log file.
| ||
| 10 | SIP TLS implementation SHALL be tested against a variety of endpoints and network equipment for accurate implementation. | BN2020 gateway, Cisco Gateway. other Dialogic products. | |
| Licensing | |||
| 20 | SIP over TLS supported on by a single license keyword (Security). This keyword enables TLS functionality on a per system basis. To enabled security the system must have installed security licenses equal or greater than the number of fax channels installed. For example, if the customer has an 8 channel SR140 fax licenses and only 2 channels of security, the system will not support security features. If they are licensed for 8 or more security channels, security features will be available on the system. Add on part will need to be defined to add security to an existing SR140 deployment. This part will be added to the back office for normal order processing and will allow the end user to activate a security LAC via the current methods. The SR140 base feature license will not include Security support. Added support MUST require a separate add-on LAC for security. | ||
951-105-21 SR140-EVAL-Feature-Security (eDelivery) 951-105-22 SR140-NFR-1YR-Feature-Security (eDelivery) 951-105-23 SR140-2-Feature-Security (eDelivery) 951-105-24 SR140-4-Feature-Security (eDelivery) 951-105-25 SR140-8-Feature-Security (eDelivery) 951-105-26 SR140-12-Feature-Security (eDelivery) 951-105-27 SR140-24-Feature-Security (eDelivery) 951-105-28 SR140-30-Feature-Security (eDelivery) 951-105-29 SR140-48-Feature-Security (eDelivery) 951-105-50 SR140-60-Feature-Security (eDelivery) 951-105-51 SR140-DEV-1YR-Feature-Security (eDelivery) | BRKT-707 | ||
| Documentation Requirements TBD | |||
| 50 | COO Will need to be updated with changes to include OpenSSL into the product. Will be required for both Windows and Linux. | ||
| Radvision Stack | |||
| 60 | The Ravision SIP stack will be updated to a version that support SIP over TLS v1.2. This update will be performed for the SIP portion of the stack only and will not impact the H.323 stack. Both the Windows and the Linux stack will be updated. | ||
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
0 Comments