Sec-Agree
The SBC supports 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.
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-paramThe 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.
TLS Session Setup During Registration
This call flow depicts a TLS session setup during the registration procedure. Only relevant header fields are noted.
(1) REGISTER
Proxy-Require:sec-agree
Security-Client: ipsec-3gpp;alg=sha2-512;ealg=aes-cbc;prot=esp;mod=trans;spi-c=8765423;port-c=7524;spi-s=1234563;port-s=1358, ipsec-3gpp;alg= hmac-sha-1-96;ealg=aes-cbc;prot=esp;mod=trans;spi-c=8765423;port-c=7524;spi-s=1234563;port-s=1358, tls
(2) REGISTER
Authorization: Digest uri="sip:ims.mnc007.mcc262.3gppnetwork.org",username="262073900320132@ims.mnc007.mcc262.3gppnetwork.org",response="",realm="ims.mnc007.mcc262.3gppnetwork.org",nonce=""
(No integrity-protected field will be present if TLS is selected as the security mechanism)
(3) 401
Security-Server: tls(4) REGISTER
Proxy-Require: sec-agree
Security-Verify: tls
(5) REGISTER
Authorization: Digest
username="262073900320132@ims.mnc007.mcc262.3gppnetwork.org",realm="imstest1.telefonica.de",uri="sip:ims.mnc007.mcc262.3gppnetwork.org",qop=auth,nonce="Ms8l2xeF3l4lb0VO8fK3KFMSKLv1sQAATdN2NpFUCgU=",nc=00000001,cnonce="3063397945",algorithm=AKAv1-MD5,response="3779ff40a057f999a2f8288bbfafc10d", integrity-protected=tls-pending
TLS Session Setup Prior to Registration
This call flow depicts a TLS session setup prior to the registration procedure.
(1) REGISTER
(No Security-Client or Proxy-Require header present)(2) REGISTER
Authorization: Digest uri="sip:ims.mnc007.mcc262.3gppnetwork.org",username="262073900320132@ims.mnc007.mcc262.3gppnetwork.org",response="",realm="ims.mnc007.mcc262.3gppnetwork.org",nonce=""
(No integrity-protected field will be present)
(3) 401
(No Security-Server header present)(4) REGISTER
(No Security-Client, or Security-Verify or Proxy-Require header present)(5) REGISTER
Authorization: Digest
username="262073900320132@ims.mnc007.mcc262.3gppnetwork.org",realm="imstest1.telefonica.de",uri="sip:ims.mnc007.mcc262.3gppnetwork.org",qop=auth,nonce="Ms8l2xeF3l4lb0VO8fK3KFMSKLv1sQAATdN2NpFUCgU=",nc=00000001,cnonce="3063397945",algorithm=AKAv1-MD5,response="3779ff40a057f999a2f8288bbfafc10d", integrity-protected=tls-pending
Regardless of TLS Session setup procedure, if the newly added configurable item sec-agree feature is enabled, any messages on unprotected port will be rejected except REGISTER messages or messages related to emergency services.
For refresh registration, if the Sec_Agree occurred during Registration, it verifies for the presence or change of Security-Client & Security-Verify headers, if they differ it will be rejected with 4xx response and also Authorization header fields are verified irrespective of the above methods and if they differ with previous association it will be rejected with 403 (Forbidden) response. Also when the refresh REGISTER is being forward to the core, it will set the integrity-protected field to "tls-yes".