2.2 Security Protocols & PKI: SSO, OAuth, TLS & SRTP

Security Protocols & PKI: SSO, OAuth, TLS & SRTP

Securing real-time collaboration requires protecting signaling channels, user credentials, media transport, and administrative management interfaces. Cisco Unified Communications Manager (CUCM) implements a modular Public Key Infrastructure (PKI) architecture where distinct cryptographic services are isolated into dedicated certificate stores to prevent cross-service compromise.

---

CUCM Certificate Stores and PKI Architecture

CUCM separates cryptographic keys into an Identity Store (containing the private key and server certificate) and a Trust Store (containing trusted Certificate Authority root and intermediate certificates). The six core certificate functions in CUCM include:

Self-Signed vs. CA-Signed Certificates

• Self-Signed Certificates: Generated automatically during initial CUCM installation with a default validity period of 5 years. While functional for isolated labs, self-signed certificates require manual certificate exchange across all cluster nodes and cause untrusted certificate warnings in browsers and Jabber clients.
• Certificate Authority (CA) Signed Certificates: Generated by submitting a Certificate Signing Request (CSR) to an Enterprise CA (e.g., Microsoft Active Directory Certificate Services) or a Public Third-Party CA (e.g., DigiCert, Sectigo). CA-signed certificates establish an unbroken chain of trust back to a trusted root.

Multi-Server Subject Alternative Name (SAN) Certificates

In a multi-node CUCM cluster (Publisher and multiple Subscribers), managing individual certificates for each node creates significant operational overhead. Cisco Unified Communications Manager supports Multi-Server (SAN) certificates:

• The administrator generates a single CSR on the Publisher node selecting Distribution: Multi-Server (SAN).
• CUCM automatically populates the Subject Alternative Name (SAN) extension with the hostnames and Fully Qualified Domain Names (FQDNs) of the Publisher and all Subscribers within the cluster.
• When the signed certificate is uploaded to the Publisher, CUCM automatically replicates and installs the certificate across all Subscriber nodes in the cluster, reducing certificate administration from dozens of per-server operations down to a single cluster-wide task.

CLI Verification Command: show cert own tomcat
=========================================================================
Certificate: tomcat.der
Subject: CN=cucm-pub.example.com, OU=Voice, O=Enterprise, C=US
SAN Extension:
  DNS: cucm-pub.example.com
  DNS: cucm-sub1.example.com
  DNS: cucm-sub2.example.com
  DNS: cucm-tftp.example.com
Issuer: CN=Enterprise-Sub-CA, O=Enterprise, C=US
Validity: Not Before: Oct 01 00:00:00 2026 GMT; Not After: Oct 01 00:00:00 2028 GMT
Key Usage: Digital Signature, Key Encipherment
=========================================================================

---

Mutual TLS (mTLS) Signaling Architecture

Standard TLS (unilateral TLS) validates only the identity of the server. Signaling between infrastructure devices, such as CUCM to CUBE or CUCM to Cisco Expressway, commonly uses Mutual TLS (mTLS), where both parties cryptographically verify each other before establishing a session. A certificate-based Webex Calling Local Gateway trunk also uses mTLS.

mTLS Handshake Sequence (TLS 1.2 message flow)

TLS 1.3 shortens this exchange: it drops ServerHelloDone and ChangeCipherSpec and encrypts the certificate messages, but mutual authentication still works through CertificateRequest, Certificate, and CertificateVerify.

1. ClientHello: The client sends supported TLS versions, cipher suites, and a random byte string.
2. ServerHello: The server selects the highest common TLS version (TLS 1.2 or TLS 1.3) and cipher suite.
3. Server Certificate & CertificateRequest: The server sends its X.509 certificate and issues a CertificateRequest specifying acceptable Certificate Authority distinguished names (DNs).
4. ServerHelloDone: The server signals completion of the initial negotiation phase.
5. Client Certificate & CertificateVerify: The client sends its X.509 certificate, followed by a CertificateVerify message containing a cryptographic signature generated using the client's private key.
6. Key Derivation and Finished: Both nodes exchange ChangeCipherSpec messages and verify the integrity of the handshake using the derived symmetric session keys.

---

Secure Real-Time Transport Protocol (SRTP)

While SIP TLS secures the call setup signaling, voice and video RTP payloads remain unencrypted unless protected by Secure Real-Time Transport Protocol (SRTP), defined in RFC 3711.

Cryptographic Specifications

• Payload Encryption: Advanced Encryption Standard in Counter Mode (AES-128-CM). AES-CM generates an encrypted pseudorandom keystream that is XORed with the RTP payload bytes. The RTP packet header is deliberately left unencrypted so intermediate network switches and routers can read the sequence numbers, timestamps, SSRC identifiers, and DiffServ QoS markings.
• Message Authentication and Integrity: Keyed-Hash Message Authentication Code using SHA-1 (HMAC-SHA1). An authentication tag is calculated over the RTP header, header extensions, and encrypted payload, then appended to the end of the packet.
  • AES_CM_128_HMAC_SHA1_80: Produces an 80-bit (10-octet) authentication tag (standard for voice and video media).
  • AES_CM_128_HMAC_SHA1_32: Produces a 32-bit (4-octet) authentication tag (used when conserving bandwidth, though less secure against forgery).
  • Current Cisco releases also negotiate the AEAD suites AEAD_AES_128_GCM and AEAD_AES_256_GCM, which combine encryption and integrity in one algorithm.
• Replay Protection: SRTP maintains a 32-bit Rollover Counter (ROC) combined with the 16-bit RTP sequence number to form a 48-bit index, preventing replay attacks across long-lived sessions.

SRTP Key Exchange: SDES vs. DTLS-SRTP

To establish SRTP encryption, the two communication endpoints must exchange cryptographic keys. Two mechanisms exist:

+---------------------------------------------------------------------------------------------------------+
|                                 SRTP Key Exchange Protocols Comparison                                  |
+------------------------------------+--------------------------------------------------------------------+
| SDES (RFC 4568)                    | - Transmits Master Key and Salt in plaintext inside SDP a=crypto:   |
| (Session Description Protocol      | - Mandatory: SIP signaling MUST be encrypted with TLS!             |
|  Security Descriptions)            | - Common in on-premise CUCM, Cisco IP phones, and CUBE trunks.     |
+------------------------------------+--------------------------------------------------------------------+
| DTLS-SRTP (RFC 5764)               | - Dedicated DTLS handshake executed directly over UDP media ports. |
| (Datagram Transport Layer Security | - Keys derived out-of-band; SIP signaling never sees key material. |
|  for SRTP)                         | - Mandatory for WebRTC endpoints and gateways (RFC 8827).          |
+------------------------------------+--------------------------------------------------------------------+

Sample SDES a=crypto line in SIP SDP:
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32

---

SAML 2.0 Single Sign-On (SSO)

Security Assertion Markup Language (SAML) 2.0 provides centralized authentication across Cisco Collaboration applications, allowing users to authenticate against an enterprise Identity Provider (IdP) (e.g., Microsoft Entra ID / Azure AD, Okta, PingFederate) rather than maintaining separate credentials in CUCM.

Core SAML Roles and Metadata Exchange

• Service Provider (SP): CUCM, Cisco Unity Connection, or Cisco Expressway. The SP hosts the protected collaboration resources.
• Identity Provider (IdP): The external authentication authority holding the user directory and multi-factor authentication (MFA) policies.
• Federation Metadata Exchange: The SP and IdP establish mutual trust by exchanging XML metadata:
  • The CUCM SP metadata contains the Entity ID (e.g., https://cucm-pub.example.com/sso/metadata), the Assertion Consumer Service (ACS) URL (where the IdP sends assertions), and the SP public signing certificate.
  • The IdP metadata contains the IdP Entity ID, the Single Sign-On URL, and the IdP X.509 public signing certificate.

SP-Initiated Login Flow

1. The user navigates to the CUCM Administration portal or connects via Cisco Jabber.
2. CUCM detects that the session is unauthenticated, generates a cryptographically signed SAML AuthnRequest XML document, and redirects the client's browser to the IdP SSO URL via HTTP 302.
3. The user authenticates against the IdP (entering credentials, completing MFA, or satisfying Conditional Access policies).
4. Upon successful validation, the IdP constructs a signed SAML Response containing a SAML Assertion. The assertion includes user attributes such as uid, mail, or userPrincipalName.
5. The user's browser posts the signed SAML assertion to the CUCM ACS URL via HTTP POST.
6. CUCM verifies the IdP digital signature against its stored IdP public certificate. It extracts the username attribute, verifies that the user exists in the local database or synced LDAP directory, and issues an authenticated session cookie.

---

OAuth 2.0 Token-Based Authentication

While SAML SSO handles web browser and interactive user logins, modern soft clients (Cisco Jabber and Cisco Webex App) use OAuth 2.0 (RFC 6749) for ongoing API authentication with CUCM and Webex cloud services.

• Access Tokens: Short-lived cryptographic bearer tokens (typically valid for 60 minutes). Clients present the access token in HTTP Authorization: Bearer <token> headers when invoking User Data Services (UDS) or REST APIs.
• Refresh Tokens: Long-lived cryptographic tokens (valid for 60 days) stored securely in the client operating system's credential vault (such as macOS Keychain or Windows Credential Manager). When an access token expires, the client submits the refresh token to obtain a fresh access token without prompting the user for credentials.
• Enterprise Benefits: OAuth token authentication prevents repeated LDAP password challenges, eliminates account lockouts caused by cached desktop passwords during enterprise password rotations, and supports instant session revocation from the administrative console.

Troubleshooting Security Components (Blueprint 1.4)

The exam asks you to troubleshoot, not just describe, these mechanisms. Start from the symptom and check the matching component:

A useful habit is to read the TLS alert in a packet capture: "unknown CA" points to a trust store, "certificate expired" to the identity certificate, and "handshake failure" with no certificate exchanged usually means the two sides share no TLS version or cipher suite.