最新支持SIP协议的认证签权机制-基于Bearer令牌的认证和签
SIP协议或者IP网络技术中，SIP协议的处理包括认证和服务器端的签权处理都使用的是RFC3261中的HTTP的 Basic处理框架。随着新技术不断发展，特别是基于容器和APP端的发展，一些认证签权机制在存储处理方面存在的问题也不断涌现，例如SIP的认证问题。具体关于HTTP和Bearer的讨论读者可以参考网络资料和参考链接或者查看RFC6750关于Bearer的使用规范。为了更好满足SIP端和各种服务器端部署形式，在最近关于SIP认证框架的处理机制方面，一些RFC成员提出了使用Bearer令牌机制来对SIP验证和SIP注册签权的处理框架-RFC8898.此协议给出了SIP在认证和签权使用的Bearer令牌做了一个比较基本的定义规范。
RFC 8898-Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP)
因为此规范的发布可能会影响到SIP协议的支持和一些技术方面的演进，虽然，目前的规范内容仍然不是非常具体，框架仍然比较宽泛，但是，笔者认为有必要针对此指导规范做一个概要说明，以便在SIP网络的未来技术部署时可以作为一个有价值的参考，一些SIP解决方案厂家可以通过此规范重新设计自己的解决方案。
思科基于OAuth设计的融合通信平台
在RFC8898中，规范主要介绍了关于Bearer 令牌的机制要和基于第三方的针对SIP用户认证和注册签权处理说明（使用OAuth 2.0 framework和 OpenID Connect Core 1.0）。
1
介绍
RFC8898中，SIP协议使用OAuth 2.0框架作为认证机制对SIP用户进行认证处理，对SIP注册进行签权进行处理。OAuth 2.0使用基于令牌的框架支持OAuth客户端对用户的资源访问。OpenID Connect Core规范在OAuth协议基础上规定了一个简单的身份确认层，它支持OAuth/OpenID客户端对基于认证机制的用户身份确认。验证机制是专门的第三方授权服务器来（authorization server，简称AS）执行，例如OpenID 提供方（OP），同时可获得用户的基本信息内容。
在本规范中，用户签权的处理可以支持单个用户登录，一旦用户通过认证，它可以访问SIP和非SIP服务资源。
此规范同时更新了RFC3261中的一些流程，通过定义UAC流程实现了更新。当UAC通过multiple WWW-Authenticate/Proxy-Authenticate 头文件获得401/407响应时，同时对同样的realm会使用不同的认证机制进行查询处理。
在RFC8898中，令牌有不同的类型和格式。在第三方的授权服务器中使用的令牌类型取决于授权服务器的类型。OAuth AS可以对一个成功授权的UAC提供以下令牌：
Access Token: UAC将使用此令牌（此令牌由SIP服务器提供）访问SIP服务器资源。
Refresh Token：UAC防止使用此令牌对授权服务器刷新过时令牌。
RFC8898中支持两种令牌，两种格式分别为：
Structured Token：结构化的令牌由一些具体对象构成，包括其和声明关联的令牌，例如JSON格式，具体定义在RFC7519。
Reference Token：此令牌有一个非透明的字符串构成，它用来获得令牌的细节，和其声明关联。具体规范在RFC6749中定义。
在RFC8898中的关于SIP注册的流程中，认证机制可以通过授权服务器（AS/OP）对注册请求进行签权处理。在响应消息中401或者407中的头消息文件使用Bearer机制。SIP通过AS/OP进行注册处理的具体的示例如下：
UAC通过AS/OP实现注册流程示例
在以上的处理流程中，UAC实现注册需要经过七个步骤：
UAC对注册服务发送一个注册请求，无任何安全设置信息。
注册服务对UAC返回一个响应消息401，并且携带Bearer处理机制所要求的验证消息和AS服务器地址等。
UAC直接通过AS/OP直接和授权服务器进行通信，它们双方通过约定的机制进行处理，例如使用OAuth Aative App机制（在RFC8252定义）。AS服务器对UAC进行认证处理，然后对UAC提供一个令牌，UAC可使用此令牌访问SIP服务资源。
UAC提供AS获得的令牌消息，然后和注册服务器进行提醒注册请求。注册请求中包含从AS获得的令牌信息。
注册服务通过UAC的令牌对AS要求进行验证处理。如果此令牌是一个参考令牌，授权服务器可能对令牌执行自检处理，这个自检处理由RFC7662定义。
自检处理成功以后，AS对注册服务返回一个200 OK。
最后注册服务对UAC返回一个 200 OK。
如果UAC已经预设了AS服务器端的信息的话。处理流程相对比较简单，UAC获得访问令牌即可。
2
SIP UA中Bearer机制的处理
和RFC3261中关于Digest认证的处理流程一样，使用Bearer机制时，SIP UAC，UAS和代理也需要经过多种处理流程。下面笔者分别介绍关于在UAC，UAS和代理的处理流程中关于Bearer框架的使用方式。
UAC端的处理包括：获得令牌和对查询的响应处理，保护令牌访问，注册请求和非注册请求的处理。
根据UAC通过AS/OP实现注册流程示例，在获得令牌和对查询的响应处理过程中，当UAC在无安全信息对服务器发送请求时，UAC可能收到一个401（Unauthorized）或者407（Proxy Authentication Required）未授权访问的响应。在其响应消息中，401会携带WWW-Authenticate 头，407会携带一个Proxy-Authenticate 头。在头中会指示认证机制使用Bearer，并且包含机制的详细消息，例如AS服务器地址。通过前面所说的第二步和第三步获得令牌的信息。为了获取到令牌信息，UAC必须检查在401或者407响应中获得的AS的地址，通过对照检查一组可信任的AS地址获得令牌访问的安全有效地址，这样的检查也是为了防止UAC盲目绑定其他AS资源时的针对AS地址的安全漏洞，防止访问一些过期的或非安全保护的AS地址。关于OAuth2的处理流程不在本规范说明的范围，读者可以查阅RFC8552和其他相关的规范来进一步学习。
获取到令牌以后，令牌就会返回到UAC端。返回UAC的令牌的类型取决于授权服务器AS的类型。OAuth AS提供访问令牌和刷新令牌（可选）。其中，刷新令牌主要应用于UAC和AS之间。如果AS对UAC端提供了刷新令牌的话，UAC可使用此刷新令牌在当前访问令牌到期之前对AS请求一个新的访问令牌。如果AS没有提供刷新令牌的话，在当前访问令牌到期之前，UAC需要重新对此用户执行认证机制。OP返回一个额外的ID令牌，此ID令牌包含一个关于此用户认证的声明信息，此声明信息是有授权服务器提供。ID令牌也可以包括其他关于此用户的声明信息，例如SIP URL，UAC可以使用此URL进行注册流程处理。
如果UAC收到一个401或者407，此响应中包含多个WWW- Authenticate/Proxy-Authenticate头的话，这些头针对同一realm提供了不同的认证机制的话，UAC基于本地策略对其中一种机制提供安全信息。注意，在RFC8898发布时，UAC收到多个认证头的处理规范还没有发布，在未来的规范规定中可能会增加具体的处理机制。
令牌的安全是一个非常重要的问题。RFC6749强制规定了访问令牌的安全策略，访问令牌需要通过TLS进行加密处理。但是，一些读者可能知道，如果SIP网络使用了中间SIP代理服务器的话，当需要保护SIP信令时，TLS只能保证hop-to-hop之间的加密，简单来说，就是保证两个网络跳转的加密设置。因此，访问令牌必须通过一种方式对其进行安全保护，以便实现仅授权的SIP服务器可访问令牌。另外，当访问令牌包含在SIP请求中时，除非有其他的加密方式可以保护访问令牌，允许授权的服务器访问令牌。否则的话，在支持RFC8898规范的SIP终端必须使用加密的JWTs方式对其进行编码和保护。TLS也可以对SIP终端和AS之间的数据交换进行保护。
这里，我们先讨论一下注册请求的处理流程。前面内容中我们已经简单介绍了如何发送注册请求的流程。UAC会根据收到的访问令牌等消息对注册服务器发送注册请求。这里要注意，如果收到了多个认证机制支持的话，UAC可能会通过一个非Bearer机制的方式，使用安全信息重新尝试注册。一般情况下，对于一个新的绑定关系来说，UAC会获得一个新的访问令牌。但是，因为可能支持本地策略设置，UAC可能会包含一个访问令牌，此访问令牌用来支持请求中同一AOR的其他的绑定关联。如果包含在注册请求中的访问令牌没有被接受，UAC收到了401或者407响应的话，UAC需要重新执行获取令牌的流程。
前面我们讨论了注册请求的处理流程。如果是一个非注册请求的话，UAC发送请求时必须包含一个Authorization 头，在此头中必须声明Bearer机制。Bearer机制中包含一个有效的访问令牌，此令牌是通过AS查询请求中AS标识的访问令牌。基于本地策略，如果新请求的目的地是同样的，UAC可以包含一个访问令牌，这个访问令牌已在其他dialog或者其他独立的请求中使用过的。如果包含在注册请求中的访问令牌没有被接受，UAC收到了401或者407响应的话，UAC需要重新执行获取令牌的流程。
讨论了UAC端的处理以后，我们继续讨论UAS的处理。根据前面的注册流程步骤的示例，当UAS或者注册服务收到注册请求，UAC没有包含认证所需的安全信息以后，UAS/注册服务应该回复UAC一个401响应。如果UAS/注册服务验证此请求，并且接受以访问令牌的方式作为安全措施进行验证的话，UAS或者注册服务必须在返回的响应消息中包含一个WWW-Authenticate 头，在此头中标识出Bearer机制声明，并且包含一个AS地址，此地址解析方式根据RFC7230规范解析。UAC将来会从此AS地址获得访问令牌。
当UAS或者注册服务收到一个SIP请求，请求中包含Authorization头，携带了访问令牌的话，UAS或者注册服务必须验证访问令牌，访问令牌的验证流程根据访问令牌的类型进行不同的处理。具体关于访问令牌的处理流程查阅RFC7519。如果请求中提供的令牌是一个过期的访问令牌，UAS或者注册服务必须对UAC回复一个401响应。如果访问令牌验证成功通过对话，UAS或者注册服务可以继续执行其他接下来正常的SIP流程。如果访问令牌验证失败，UAS或者注册服务必须返回一个401响应。
前面，我们讨论了UAC端和UAS端关于访问令牌的处理流程。接下来，我们继续讨论关于SIP代理的处理流程。当SIP代理收到一个SIP请求，没有携带任何安全信息时，SIP代理服务器应该返回一个407的响应消息（Proxy Authentication Required）。如果SIP代理服务器提供验证服务，并且接受以访问令牌的方式作为安全设置的话，SIP代理服务器应该在407的返回消息中包含一个Proxy-Authenticate头，并且标识出Bearer机制和AS的访问地址。此地址解析方式根据RFC7230规范解析。UAC将来会从此AS地址获得访问令牌。当SIP代理希望验证收到的请求时，SIP代理服务器会查询Proxy-Authorization中realm参数值来匹配其realm地址。代理服务器必须至少成功匹配一个Proxy-Authorization中的安全地址。当验证机制是Bearer时，SIP代理服务器必须验证访问令牌，验证访问令牌的流程根据访问令牌的类型来决定（structured 或者 reference 令牌）。
3
访问Token Claims
读者应该知道，访问令牌是用来访问不同的资源的。访问令牌可以访问的服务类型是根据不同的方式来决定。这些访问方式是由令牌基于本地策略提供的，本地策略则是由AS和注册服务共同协商同意的结果。具体的协商内容需要授权服务器和注册服务器双方进行核实验证。
如果访问令牌被解码为JWT格式，它会包含一个声明列表（claim），其中包含已注册状态信息的和应用级的声明。注册服务授权声明中对象访问授权的服务。如果访问令牌是一个参考令牌的话，注册服务会被允许基于其他的机制来进行访问。其他的机制包括自检机制和用户属性查询等。
4
响应头-WWW-Authenticate
在401或者407的响应中，Bearer机制的标识是通过认证头来进行传输的。具体的用法格式和HTTP的类似。如果基于Bearer认证机制支持的话，UAC收到的Bearer消息头用法应该和以下语法相似：
challenge =/ ("Bearer"LWS bearer-cln *(COMMA bearer-cln))bearer-cln = realm / scope-param / authz-server-param / error-param / auth-paramrealm = <defined in RFC 3261>scope-param ="scope"EQUAL DQUOTE scope DQUOTEscope = <defined in RFC 6749>authz-server-param ="authz_server"EQUAL DQUOTE authz-server DQUOTEauthz-server = https-URIhttps-URI = <defined in RFC 7230>error-param ="error"EQUAL DQUOTE error DQUOTEerror = <defined in RFC 6749>auth-param = <defined in RFC 3261>
其中比较重要的包括：authz_server parameter，authz_server和error消息。读者可以根据RFC规范做进一步了解，这里不再累述。
5
Bearer机制的安全考虑
安全问题是一个非常重要的因素。如果协议或者规范设计不当会给系统带来很多的安全隐患和技术漏洞。安全问题存在很多讨论的空间。在前面的章节中笔者已经说明了使用TLS加密的传输方式。这里不再过多讨论。其他方面的安全设置都通过不同的规范来规定，其中OAuth在RFC6749做了规定，Bearer的令牌的安全规范在RFC6750有细节说明，JWT的安全规范通过RFC7519做了规定。这些规范都支持了SIP协议中通过访问令牌实现的安全机制。
Single Sign-On (SSO)，单点登录的验证方式是SIP终端使用的一个比较常用的场景。SSO可以支持用户一次登录验证，使用访问令牌来获取SIP和其非SIP的服务。这里，SSO就会存在一个比较宽泛的访问范围，如果SSO模式存在潜在风险的话，SIP和其他非SIP服务就会存在比较大的安全风险。因为SSO的中国问题，所以，规范必须规定一个针对SSO非常严格的安全设置方式，例如包括一个比较长的passphrase替代密码，支持多要素的认证机制和使用原生浏览器的安全设置。
在应用层级方面，如果UAC注册时，在注册请求中，注册服务器可以提供不同层级的服务级别。RFC8898推荐在响应消息中包含一个服务的级别scope来表示其访问的层级。当然，通过scope的修改，AS也可以提供更高级别的访问权限。对于SIP用户和应用级程序是一个非常好的安全保护，管理员也可以通过scope授权的方式允许某些SIP 用户访问某些特定的应用服务。
网络漏洞是经常发生的。攻击者可能会专门制造出一些非法的AS服务器地址来引诱UAC进行访问。因此，UAC必须检查AS的有效性，保证UAC访问正确的AS服务器，避免网络漏洞带来的安全隐患。
6
总结
本文章重点介绍SIP新的认证机制Bearer的使用和其和AS/OP进行交互的详解流程。通过OAuth的方式进行用户验证是目前互联网技术中常用的技术手段，如果今后使用在SIP协议的用户认证流程将会影响SIP业务的处理也会帮助其他应用级产品的权限访问和服务控制。
笔者完整介绍了其核心概念和针对UAC，UAS和代理服务器的处理流程，并且特别针对401和407响应处理做了说明。最后，针对部署bearer机制带来的安全问题进行了讨论。目前，RFC8898规范是一个非常新的规范，很多处理细节和SIP业务厂家需要进行升级才能满足RFC8898的要求，因此，我们还要继续等待SIP服务提供商和服务器开发平台首先支持此规范，以后我们才能把令牌访问等技术应用在具体的SIP网络场景中。
参考资料：
https://www.rfc-editor.org/rfc/rfc8898
https://www.rfc-editor.org/rfc/rfc6750.txt
https://www.rfc-editor.org/rfc/rfc7662.txt
https://blog.restcase.com/4-most-used-rest-api-authentication-methods/
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/jabber/11_9/Unified-CM-OAuth-Whitepaper-v17-FINAL.pdf
融合通信/IPPBX/FreePBX商业解决方案：www.hiastar.com
最新Asterisk完整中文用户手册详解：www.asterisk.org.cn
Freepbx/FreeSBC技术文档: www.freepbx.org.cn
如何使用FreeSBC，qq技术分享群：334023047
关注微信公众号：asterisk-cn，获得有价值的通信行业技术分享
