Summary

  • RFC 3329 let a SIP user agent and its first-hop entity exchange capability lists, activate the highest-preference common mechanism, and then return the server's complete static list as Security-Verify through the selected protection.
  • The design did not secure the first offer retroactively or guarantee the strongest modern security. It made list stripping detectable only if the weakest permitted selected mechanism still supplied effective integrity and replay protection.

The negotiation needed security before it could choose security

Large networks cannot upgrade every endpoint at once. A first generation of SIP devices might understand HTTP Digest; newer ones might also support TLS or IPsec. If each side had to know the other's exact mechanism in advance, transition would require tightly coordinated configuration. If they simply tried mechanisms until one worked, a forged failure could make a strong option look unavailable.

The obvious answer was negotiation: let the client announce what it supports, let the server rank what it supports, and choose the best common mechanism. But the opening request and challenge arrived before that choice had been activated. An on-path attacker could remove TLS from the offer, leave Digest, and allow both endpoints to believe the other side never proposed encryption. The protocol would appear to work precisely because the attack preserved a mutually supported weaker choice.

RFC 3329 did not pretend to protect the first exchange with security that did not yet exist. Instead, it divided the negotiation across time. A client sent Security-Client to its next-hop SIP entity. The server answered with a static, preference-ordered Security-Server list and whatever information was needed to start a mechanism. The client chose the known common mechanism with the highest server preference, activated it, then sent another request containing Security-Verify: a mirror of the server list it had received. The server compared that returned list with its own.

The final comparison was exact in the dimensions that mattered. The same mechanisms had to appear in the same order, with matching parameters. If an attacker had removed the strongest item from the unprotected server response, the client returned the shortened list. The server still held its static four-item policy and saw a three-item receipt. It refused to continue and challenged again.

An attacker could try to modify the receipt too, but the second request now used the selected mechanism. What had been a trivial deletion became an attempt to forge integrity protection in real time. RFC 3329's security gain was not an untouchable opening offer; it was the shift from editing one exposed message to defeating the protection that the peers had actually established.

Static lists made a stateless comparison possible

The server list could not be calculated from the client's list. If a server removed options the client had not advertised, an attacker could edit Security-Client, influence the server's response, and still produce a self-consistent receipt. RFC 3329 required the server's advertised list to remain static for the relevant scope. A node could maintain different lists per interface, but each list stood independently of the incoming offer.

That decision also kept the agreement stateless at the SIP layer. The server did not need to remember a bespoke challenge for every client. When the protected request returned, it compared Security-Verify with its configured list. The selected underlying mechanism could still hold state—a TLS connection or an IPsec association—but the list comparison did not require another negotiation database.

Preferences used distinct q values. The client selected the known common mechanism carrying the highest server preference. The server's priorities therefore controlled the choice among common capabilities, while the client retained knowledge of its own true capability set. Altering the initial client list could still disrupt initiation material or cause the sides to choose differently. The visible result might be failure, which the document treated as a possible attack condition rather than proof of one.

The procedure was scoped tightly. It joined a user agent to its next-hop SIP entity, commonly the first-hop or outbound proxy. A server initiating the procedure checked for exactly one Via entry. Several Via values meant it was not the first hop and must not apply this mechanism. This was not end-to-end protection for the call, the message body or every proxy chain.

421 and 494 described different points of knowledge

A client could initiate agreement by sending its list and both Require and Proxy-Require with the sec-agree option. An unprotected server response used 494 Security Agreement Required and returned Security-Server, even if the lists had no common mechanism.

A server could also require the extension by local policy. If an unprotected request did not show support, the server returned 421 Extension Required. If the client had advertised sec-agree support but had not yet completed agreement, the server returned 494. Both responses carried the server list and the information required to begin its preferred mechanism.

These status codes were protocol decisions, not forensic verdicts. A 421 could mean an old client, lost option tag or incompatible policy. A 494 could be the normal first turn of negotiation, a list mismatch or a recovery after stale state. Neither code identified an attacker. The useful record had to include the received list, local static list, selected mechanism, protection result and comparison outcome.

Mechanism activation differed. TLS required a protected connection and used SIP server-location rules; RFC 3329 treated a SIP URI as secure for the lookup once TLS was selected. Digest reused its authentication framework and added a verification calculation covering the server list. IPsec-IKE attempted an IKE connection; manually keyed IPsec depended on out-of-band key and policy knowledge. RFC 3310 supplied an AKA-based Digest neighbor, but did not replace the returned-list logic.

Security association lifetimes also remained mechanism-specific. Closing the TLS connection forced renegotiation. IKE carried its own lifetime. Digest could cause a new challenge when credentials expired. Manual IPsec depended on the out-of-band system that provisioned it. “Agreement succeeded” was therefore incomplete without an association identifier and an expiry or termination receipt.

The weakest acceptable mechanism defined the floor

The security considerations stated the limit plainly: the weakest proposed mechanism had to provide at least integrity and replay protection for the returned list. If an attacker could break that mechanism, it should not be offered. Negotiation could prevent an effortless downgrade from strong to weak; it could not convert a broken weak option into a sound foundation.

Nor did agreement imply confidentiality. Digest might authenticate and protect selected values without encrypting SIP content. TLS could provide a protected hop, not end-to-end secrecy beyond that hop. IPsec properties depended on the association and policy actually established. Header equality proved that the server's configured list and returned receipt matched at one comparison point. It did not prove the modern strength of each listed algorithm, the identity of every later hop or the confidentiality of the session.

Time changed the baseline. RFC 3329 was published in January 2003. RFC 8996 later updated it by prohibiting negotiation of TLS 1.0 and TLS 1.1. RFC 8446 defines TLS 1.3; RFC 7616 modernizes HTTP Digest. Those documents do not change the historical receipt mechanism, but they prevent a 2003 token such as “tls” from being read as present-day approval of every version once associated with it.

The errata record adds another evidence boundary. Two example passages say ACK contains Security-Verify, while the normative header-use table marks those headers inapplicable to ACK; the corrections are held for a document update. A verified erratum also changes the ipsec-3gpp SPI grammar from exactly ten digits to one through ten. Implementers and historians must distinguish normative rule, illustrative text and later correction.

The IANA SIP Parameters registry preserves mechanism names and the sec-agree assignment. Registration proves that a token has a standardized owner and reference. It does not prove that operators deployed it, that an implementation follows it, or that the mechanism remains safe.

RFC 3329's durable contribution was a way to verify an unprotected claim after protection became available. It did not erase the vulnerable moment. It carried the original offer forward as a receipt and demanded an exact comparison. That design pattern remains useful wherever capability negotiation precedes the channel meant to defend it: remember what was offered, return it once protection is live, and never confuse an intact receipt with a strong policy.

Sources