SIP安全协商¶
SIP客户端和服务端之间协商并简历加密信道,后续SIP消息均在加密信道中传输。
sip安全协商大致流程¶
UAC第一次发消息¶
- 增加
Security-Client头域,此时不需要增加优先级参数 - 增加
Require和Proxy-Require头域,值为sec-agree第一条消息可能是register或这options,也可能是invite。Text Only 1 2 3 4 5
#sip消息体 from:.... to:.... Require: sec-agree Proxy-Require: sec-agree
UAS应答¶
当服务端收到未加密的消息且在Require或Proxy-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 | |
SIP-TLS¶


SIP-IPSEC-IKE¶


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

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

备注:这部分请参考《SIP Security》
真实数据隧道¶
第二次建立IPsec隧道时,实际建立了4条隧道,分别是:

UE和P-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