五个和SIP安全相关的头字段，IMS/3GPP安全验证Sec-Agree头字段说明

很多用户经常看到SIP验证401，407消息，不知道为什么会产生不同的消息。在应用环境中，SIP协议对不同环境提供了安全验证的处理，通过不同的安全头字段来验证安全实体，因此返回的响应是不同的。我们现在和读者分享五个和SIP安全相关的头字段使用，它们包括UAC/UAS之间的验证，UAC和代理服务器的验证，IMS/3GPP相关的安全验证。

作者：james.zhu
来源：SIP实验室
原文：https://mp.weixin.qq.com/s/oT5g0bFf0gd4OPhyGdkVwg

UAC和UAS之间的安全验证

此验证用于客户端和服务器注册验证, 包括以下两个头字段：

▪ WWW-Authenticate-此字段值包含来自注册服务器的身份验证挑战，通常在401（未授权）响应消息中找到。此字段应包含用于响应生成的随机数，以及有关所使用的身份验证方案的信息。

▪ Authorization-此字段包含用户响应挑战生成的身份验证信息。

五个和SIP安全相关的头字段，IMS/3GPP安全验证Sec-Agree头字段说明

UAC和代理服务器（Proxy）安全验证

Proxy-Authenticate – 此头字段值包含代理向用户发送的身份验证挑战，出现在407（需要代理授权）响应消息中。
Proxy-Authorization – 此字段包含用户响应挑战生成的身份验证信息。

除了以上两种环境的验证机制以外，SIP协议还提供其他和安全相关的验证头字段，支持了3GPP的安全机制。全称是SIP Security Mechanism Agreement（RFC 3329），支持UE和P-CSCF之间协商一个共同的安全机制。

会话发起协议的安全机制协议，通常称为Sec-Agree。该RFC定义了三个SIP头：Security-Client、Security-Server和Security-Verify，提供了SIP用户代理和其他SIP实体（服务器、代理和注册器）协商下一跳安全机制的能力。注意，此初始实现不支持服务器发起的安全协商，也不支持媒体面安全。也就是说，支持仅限于在初始注册期间由客户端发起的协商和信令安全。

目前，P-CSCF功能包括对VoLTE部署的IMS-AKA功能的支持。为了支持RCS客户端，P-CSCF功能需要增强以支持RFC 3329，即会话发起协议的安全机制协议（通常称为Sec-Agree），其中包括支持TLS作为安全机制。

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 qvalueqvalue           = ( "0" [ "." 0*3DIGIT ] )/ ( "1" [ "." 0*3("0") ] )digest-algorithm = "d-alg" EQUAL tokendigest-qop       = "d-qop" EQUAL tokendigest-verify    = "d-ver" EQUAL LDQUOT 32LHEX RDQUOTextension        = generic-param

Security-Client-希望使用特定安全架构的客户端在发送到其第一跳代理的请求中添加一个安全客户端头字段。该头字段包含客户端支持的所有安全机制的列表。

Security-Server-接收到包含值为“sec-agree”的Require或Proxy-Require头字段的未保护请求的服务器，会以4xx响应回复客户端。服务器在此响应中添加一个安全服务器头字段，列出服务器支持的安全机制。

Security-Verify-当客户端从代理接收到安全服务器信息后，所有后续消息必须包含一个安全验证头字段，该字段反映之前在安全服务器头字段中接收到的服务器安全机制列表。这些请求还包括值为“sec-agree”的Require和Proxy-Require头字段。

SBC是IMS网络中核心网元，很多应用场景中，SBC作为P-CSCF，根据3GPP TS 33.203标准支持IMS用户设备使用TLS通过TCP进行传输。是否使用IPsec或TLS连接IMS用户设备是在注册时协商确定的。以下是使用“tls”作为安全机制的典型呼叫流程。

七步呼叫流程：

UE决定使用TLS进行注册，并在初始REGISTER的Security-Client头中提议使用“tls”作为安全机制。这一信息被不加保护地发送给P-CSCF。UE包括所有其他标准SIP/IMS头，包括3GPP TS 24.229中描述的Authorization头。
P-CSCF将该请求转发给S-CSCF，Authorization头中不带“integrity-protected”参数。
S-CSCF向UE发起挑战，P-CSCF将401响应转发至UE。
P-CSCF在Security-Server头中添加安全机制为“tls”，以指示UE其支持TLS。UE继续建立到P-CSCF的TLS连接，并在此过程中验证网络的TLS证书。
如果P-CSCF展示的证书被UE接受，则UE通过建立的TLS会话发送带有凭据的REGISTER请求。P-CSCF将该REGISTER请求连同凭据转发给S-CSCF，并在Authorization头中将“integrity-protected”参数设置为“tls-pending”。
S-CSCF验证凭据后，发送200 OK给P-CSCF，随后P-CSCF通过已建立的TLS会话将200 OK转发给UE。
任何后续的注册（例如刷新注册）都通过TLS接收，P-CSCF在转发的REGISTER消息的Authorization头中插入“integrity-protected”参数为“tls-yes”。