Sec-Agree

Version S-CZ7.2.0 introduces support for RFC 3329, Security Mechanism Agreement for the Session Initiation Protocol, commonly referred to as Sec-Agree. The RFC defines three SIP headers, Security-Client, Security-Server, and Security-Verify that provide the ability for SIP UAs and other SIP entities (servers, proxies, and registrars) to negotiate next-hop security mechanisms. Note that this initial implementation does not provide support for server-initiated security negotiation, nor does it support media-plane security. That is, support is limited to client-initiated negotiation during initial registration, and to signalling security.

Currently the P-CSCF functionality includes support for IMS-AKA feature for VoLTE deployments. In order to support RCS clients along with VoLTE P-CSCF functionality needs to be enhanced to support RFC 3329, Security Mechanism Agreement for the Session Initiation Protocol (commonly referred to as Sec-Agree), which includes support for TLS as security mechanism.

Sec-Agree defines three SIP headers, Security-Client, Security-Server and Security-Verify, to negotiate security agreements during initial REGISTER transactions. Header definitions are as follows:

security-client  = "Security-Client" HCOLON
                           sec-mechanism *(COMMA sec-mechanism)
security-server  = "Security-Server" HCOLON
                   sec-mechanism *(COMMA sec-mechanism)
security-verify  = "Security-Verify" HCOLON
                   sec-mechanism *(COMMA sec-mechanism)
sec-mechanism    = mechanism-name *(SEMI mech-parameters)
mechanism-name   = ( "digest" / "tls" / "ipsec-ike" /
                     "ipsec-man" / token )
mech-parameters  = ( preference / digest-algorithm /
                     digest-qop / digest-verify / extension )
preference       = "q" EQUAL qvalue
qvalue           = ( "0" [ "." 0*3DIGIT ] )/ ( "1" [ "." 0*3("0") ] )
digest-algorithm = "d-alg" EQUAL token
digest-qop       = "d-qop" EQUAL token
digest-verify    = "d-ver" EQUAL LDQUOT 32LHEX RDQUOT
extension        = generic-param

The Security-Client header contains one or more security mechanisms and associated parameters proposed by the initiating client. This initial implementation supports two security mechanisms: TLS and ipsec-3gpp.

The Security-Server header contains the security mechanism chosen by the server from those mechanisms proposed by the client.

The Security-Verify header contains the contents of the Security-Server header.

Two additional header fields, Require and Proxy-Require, are also used in support of Sec-Agree negotiations. Both headers are required in client transmissions.