跳转至

SIP安全协商


SIP客户端和服务端之间协商并简历加密信道,后续SIP消息均在加密信道中传输。

sip安全协商大致流程

UAC第一次发消息

  • 增加Security-Client头域,此时不需要增加优先级参数
  • 增加RequireProxy-Require头域,值为sec-agree
    Text Only
    1
    2
    3
    4
    5
    #sip消息体
    from:....
    to:....
    Require: sec-agree
    Proxy-Require: sec-agree
    
    第一条消息可能是register或这options,也可能是invite。

UAS应答

当服务端收到未加密的消息且在RequireProxy-Require的值为sec-aggre时,
需要回复494(Security Agreement Required).
增加Security-Server头域,服务端列出自己的加密列表,并且不依赖客户端提供的列表。

UAC收到应答

客户端收到应答时,选取共同支持的加密参数,并且优先级最高的。 如果客户端检测到加密通道建立失败,
则认为应答的消息中security-server被修改,则需要重新发送注册请求,重新协商。

新增头域

Text Only
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#头域
Security-Client,Security-Server,Security-Verify
# 语法
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

Mechanism-name
 *  "tls" for TLS
 *  "digest" for HTTP Digest 
 *  "ipsec-ike" for IPsec with IKE 
 *  "ipsec-man" for manually keyed IPsec without IKE
 *  "ipsec-3gpp" for 3gpp
Qvalue: 每类算法的优先级。      
Digest相关参数,只适用于使用摘要的算法,这里不详细介绍。详见rfc3329。

SIP-TLS



SIP-IPSEC-IKE



SIP-IPSEC-3GPP

注册简图

4g或5g手机在SIP注册时,需要用到ipsec-3gpp
简单的注册流程图如下:

备注:
第8步骤之后,会销毁之前的IPsec隧道并新建IPsec加密通道,后续数据走新建的IPsec通道。

详细注册流程图


备注:这部分请参考《SIP Security》

真实数据隧道

第二次建立IPsec隧道时,实际建立了4条隧道,分别是:

UEP-CSCF分别发送请求和应答时,需要走不同的隧道。

IPsec消息交互


如上图所示: 1.第一次注册时,客户端需要将支持的算法,模式等参数带过去
2.服务端应答时,将从客户端提供的套件里选取,支持的套件。
3.此时,客户端和服务端都将建立IPsec隧道。
4.客户端在隧道里发送的第一条消息,需要在security-vertify回填服务端带过来的securicy-server头域的值。
5.服务端收到隧道里的第一条消息后,需要验证security-vertify头域的值是否正确。

security头域语法


参考

《sip security》
RFC 3329 - Security Mechanism Agreement for SIP Sessions