This post explains how to configure SIP/TLS and SRTP so voice and multimedia sessions that carry Controlled Unclassified Information (CUI) meet the cryptographic protection expectations of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 Control SC.L2-3.13.14, with concrete implementation steps, configuration examples, and small-business scenarios.
Understanding SC.L2-3.13.14 and why SIP/TLS + SRTP matter
Control SC.L2-3.13.14 requires the use of approved or validated cryptography to protect CUI in transit. For VoIP and real-time communications this translates to ensuring the signaling channel (SIP) and media channel (RTP) are encrypted with strong, validated algorithms and that keys are managed securely. SIP over TLS (SIP/TLS or SIPS on port 5061) protects signaling (call setup, headers, session descriptions when not separately protected) while SRTP protects the media payload (voice/video). Together they prevent passive eavesdropping, man-in-the-middle attacks on call setup, and manipulation of session parameters that could expose CUI.
Key technical requirements and selections
At a technical level, implement TLS 1.2 or 1.3 for SIP signaling and SRTP using modern encryption profiles (prefer AES-GCM where supported, e.g., AES-GCM-128/256 for SRTP). Use DTLS-SRTP (RFC 5764) or SDES over TLS only when DTLS is not feasible; avoid plaintext SDES over UDP. Require certificate-based authentication (mTLS) for trunks where possible. Use certificate keys of at least 2048-bit RSA or ECC P-256/384, and prefer cipher suites that provide forward secrecy (ECDHE). Where CUI protection explicitly requires FIPS validation, deploy crypto libraries or appliances that use FIPS 140-2/140-3 validated modules (e.g., vendor SBCs with FIPS mode, or OpenSSL FIPS module builds).
Example recommended crypto settings
Examples to aim for in your SIP/SBC configuration: TLS 1.2/1.3 only; cipher list including ECDHE-ECDSA/ECDHE-RSA AES-GCM suites; SRTP profile AES-GCM-128 (or AES-GCM-256 where supported); DTLS for media key exchange. Example OpenSSL cipher string: "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256".
Implementation steps (practical)
1) Inventory and plan: List all SIP endpoints, PBXs, SIP trunks, SBCs, and cloud telephony services handling CUI. Identify which elements are within your control (on-prem PBX, SBC) versus third-party managed services. 2) PKI and certificates: Obtain certificates from a trusted CA or enterprise PKI. Use short lifetimes (<= 1 year recommended) and include SANs for FQDNs. Ensure private keys are stored securely (HSM or encrypted filesystem) and document rotation procedures. 3) Configure SIP/TLS: Enable SIP on TLS port 5061, bind your certificate, disable TLS 1.0/1.1 and SSLv3, and enforce only strong cipher suites and PFS. Require peer certificate verification for trunks where possible (mTLS). 4) Configure SRTP with key management: Prefer DTLS-SRTP (media key exchange over DTLS), configure media_encryption=dtls (or equivalent) on endpoints and SBCs. If using a cloud provider that doesn't support DTLS, require the provider to demonstrate equivalent protections and use encrypted SIP signaling plus encrypted media tunnels provided by the vendor. 5) SBC and NAT: Use a session border controller to terminate TLS/DTLS at the boundary; ensure the SBC supports RFC 5764 (DTLS-SRTP) and can interoperate with internal handsets. Open the necessary ports (TCP/5061, UDP/10000-20000 or as required) and test DTLS negotiation through NAT. 6) Logging and evidence: Configure call detail records (CDRs) and TLS session logs to show TLS versions and cipher suites. Retain configuration files and certificate artifacts for audits.
Sample configuration snippets (illustrative)
Below are illustrative examples — adapt to your product. Asterisk PJSIP transport (example):
[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
tlsbindaddr=0.0.0.0
cert_file=/etc/asterisk/keys/yourcert.pem
priv_key_file=/etc/asterisk/keys/yourkey.pem
method=tlsv1_2
ciphers=ECDHE-ECDSA-AES256-GCM-SHA384:...For SRTP with DTLS (FreeSWITCH / PJSIP): set media_encryption=dtls and configure DTLS certificates; ensure media ports allow UDP flow for DTLS handshake and encrypted RTP.
Small-business real-world scenarios
Scenario A — On-prem PBX (small MSP-managed shop): The MSP installs an SBC (e.g., hardware or virtual) in a DMZ. The PBX is configured to use TLS for SIP to the SBC and DTLS-SRTP for media to the SBC; the SBC performs mTLS with the carrier. The MSP uses a FIPS-capable software stack or FIPS-mode SBC for calls that carry CUI. Scenario B — Cloud-hosted telephony: The small business uses a cloud provider. Require the vendor to support SIP/TLS and SRTP (DTLS preferred) and provide attestation that crypto modules are FIPS-validated if needed. Obtain configuration screenshots and vendor security documentation to include in your compliance evidence package.
Compliance tips and best practices
- Document all architecture decisions and map them to the control (show how SIP/TLS + SRTP protect CUI in transit). - Use an SBC as a single enforcement point: it centralizes certificate management, logging, and protocol upgrades. - Enforce mutual TLS on trunks and use certificate pinning where practical. - Prefer DTLS-SRTP over SDES; if SDES must be used, only inside an encrypted SIP/TLS tunnel and with strong key lifetimes and rotation. - Maintain a certificate inventory and automated renewal (ACME can help for internal CAs). - Validate vendor claims: ask for FIPS validation certificates or attestation letters when contractual CUI handling is involved. - Test with packet captures (Wireshark): verify that signaling is TLS and RTP payload is SRTP (encrypted).
Risks of not implementing SIP/TLS and SRTP correctly
Failing to encrypt signaling and media exposes CUI to interception, call hijacking, and metadata leakage. An attacker could replay or impersonate calls, extract sensitive discussions, or inject media that changes session parameters. Non-implementation also creates direct compliance risk — audit findings, loss of contracts, or corrective action plans under federal agreements — and increases legal and reputational exposure if CUI is disclosed.
In summary, to meet SC.L2-3.13.14 you must apply approved/validated cryptography to both SIP signaling and RTP media: use TLS 1.2/1.3 with strong ciphers and PFS for SIP, use SRTP with DTLS key exchange and AES-GCM where possible, enforce certificate-based authentication, document key management and vendor assurances (FIPS validation where required), and retain configuration and test evidence for audits. These steps, combined with SBCs, logging, and periodic testing, give a practical and auditable path to compliance for small businesses.
