Security Mechanism Agreement for the Session Initiation Protocol (SIP)
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (25)
The digest-verify parameter is included specifically to prevent bidding-down attacks on the SIP security mechanism agreement itself. It extends HTTP Digest's A2 parameter to include the Security-Server header field value, so that the digest authenticates not just the SIP request but also the server's advertised security capabilities.
The security agreement process is designed to be stateless for servers unless the selected security mechanism inherently requires state. Client and server lists are static and do not change based on input from the other side, though nodes may maintain multiple static lists for different interfaces.
Without a secured method to choose between security mechanisms, SIP is vulnerable to Man-in-the-Middle attacks that can downgrade security. An attacker can remove stronger security options from unprotected negotiation messages, forcing peers to use weaker security. This specification addresses that vulnerability by having the client echo back the server's security list under the selected security, making trivial downgrade attacks require real-time cryptographic forgery.
Servers configured to use this mechanism may also accept requests from clients using TLS per RFC 3263 rules. Clients that do not support this extension and do not support TLS cannot be accepted, breaking interoperability. This extension should therefore only be deployed in environments where every client implements it or supports TLS, or where insecure communication is explicitly unacceptable.
A client wishing to use the security agreement MUST add a Security-Client header field to a request addressed to its first-hop proxy containing all supported security mechanisms, and MUST add both Require and Proxy-Require header fields with the value 'sec-agree'.
A server receiving an unprotected request containing a Require or Proxy-Require header with value 'sec-agree' MUST respond with a 494 (Security Agreement Required) response and MUST include a Security-Server header field listing supported mechanisms. The server's list MUST NOT depend on the contents of the client's list.
A server using this mechanism MUST NOT apply it if the incoming request has more than one Via entry, as this indicates it is not the first-hop SIP entity. For such requests the server must return a 502 (Bad Gateway) response.
All clients that implement this specification MUST select HTTP Digest, TLS, IPsec, or any stronger method for the protection of the second request (the request containing Security-Verify).
If a client already uses TLS following RFC 3263 rules, it MUST NOT use the security agreement procedure of this specification. If a client uses non-TLS connections per RFC 3263, it MAY use this security agreement to detect DNS spoofing or negotiate other security.
If 'digest' is chosen, the client MUST use the algorithm and qop parameters from the Security-Server header to replace the same parameters in the HTTP Digest challenge, and MUST use the digest-verify parameter in the Security-Verify header to protect the Security-Server header field as specified in Section 2.2.
If 'tls' is chosen as the security mechanism, the client MUST treat the SIP URI scheme as if it were sips. If the URI scheme is not sip, the request MUST be sent using TLS.
In the server-initiated flow, if a server receives a request without the sec-agree option tag in Require/Proxy-Require/Supported, it MUST return 421 (Extension Required). If it was in Supported, it MUST return 494 (Security Agreement Required). In both cases, the server MUST include a Security-Server header and a Require header with 'sec-agree'.
The server MUST check that the security mechanisms listed in the Security-Verify header of incoming requests correspond to its static list of supported mechanisms. If modification is detected, the server MUST respond with a 494 response including the unmodified server list. Standard SIP header comparison rules apply: same mechanisms, same order, same parameter values.
To use 'ipsec-ike', the client attempts to establish an IKE connection to the host part of the Request-URI. If the IKE connection attempt fails, the agreement procedure MUST be considered to have failed and MUST be terminated.
UA and server implementations MUST be configurable to operate with or without this extension, as its use on a network interface is a matter of local policy.
When a client receives a Security-Server response, it MUST choose the mechanism with the highest q value among known mechanisms, initiate that mechanism, and then send subsequent requests with a Security-Verify header mirroring the server's list. These requests MUST also include Require and Proxy-Require with 'sec-agree'.
Four initially defined mechanism-name tokens: 'tls' for TLS, 'digest' for HTTP Digest, 'ipsec-ike' for IPsec with IKE, and 'ipsec-man' for manually keyed IPsec without IKE. A fifth, 'ipsec-3gpp', is registered for 3GPP IMS use (defined in Appendix A).
The ipsec-3gpp mechanism (Appendix A) extends the framework with parameters for 3GPP IMS: algorithm (hmac-md5-96 or hmac-sha-1-96, mandatory), protocol (ah or esp, default esp), mode (trans or tun, default trans), encrypt-algorithm (des-ede3-cbc or null, default no encryption), spi (10-digit SPI value), port1 (destination port for inbound protected messages), and optional port2 (source port for outbound protected messages).
Three new SIP header fields are defined: Security-Client (sent by client listing supported mechanisms), Security-Server (sent by server listing supported mechanisms), and Security-Verify (sent by client echoing back the server's list under the negotiated security). Each contains one or more sec-mechanism entries with a mechanism-name and optional parameters.
IANA registers a new 'Security Mechanism Names' namespace under sip-parameters. Initial entries are: digest, tls, ipsec-ike, ipsec-man, and ipsec-3gpp. New mechanism-names require IETF Consensus and a published RFC. Registrations must include the mechanism-name token and a pointer to a published RFC.
Three new SIP header fields are registered: Security-Client, Security-Server, and Security-Verify, all without compact forms. One new response code is registered: 494 with reason phrase 'Security Agreement Required'. One new option tag is registered: 'sec-agree'.
Four attack vectors are analyzed: (1) modification of the server's list in the first response, revealed when client echoes it back; (2) modification of client's echoed list in the second request, detectable via integrity protection; (3) modification of client's initial list, which affects only the server's choice and is detectable as peers would choose different mechanisms; (4) replay of old security agreement messages, which each mechanism must prevent via replay protection (e.g., HTTP Digest nonce timestamps and counters).
The method is secure only if the weakest proposed mechanism offers at least integrity and replay protection for the Security-Verify header field. If an attacker modifies the initial unprotected offers, the scheme requires them to forge the weak security in real time to avoid detection when the client echoes the server list — converting a trivial downgrade attack into one requiring active cryptographic forgery.
The security agreement proceeds through five steps: (1) client sends supported mechanism list, (2) server challenges with its own list, (3) client selects highest-preference common mechanism and activates security, (4) client sends request with Security-Verify echoing server's list under the selected security, (5) server verifies the echoed list is unmodified. If the list was modified at any step, the procedure is restarted or aborted.
Each sec-mechanism entry consists of a mechanism-name token followed by optional SEMI-delimited parameters: preference (q=qvalue, 0 to 1 with up to 3 decimal places), digest-algorithm (d-alg), digest-qop (d-qop), and digest-verify (d-ver, 32 lowercase hex digits in double quotes). All security mechanisms MUST have different q values.