Internet Engineering Task Force (IETF) V. Gurbani
Request for Comments: 5922 Bell Laboratories, Alcatel-Lucent
Updates: 3261 S. Lawrence
Category: Standards Track
ISSN: 2070-1721 A. Jeffrey
Bell Laboratories, Alcatel-Lucent
June 2010
Internet Engineering Task Force (IETF) V. Gurbani
Request for Comments: 5922 Bell Laboratories, Alcatel-Lucent
Updates: 3261 S. Lawrence
Category: Standards Track
ISSN: 2070-1721 A. Jeffrey
Bell Laboratories, Alcatel-Lucent
June 2010
Domain Certificates in the Session Initiation Protocol (SIP)
会话启动协议（SIP）中的域证书
Abstract
摘要
This document describes how to construct and interpret certain information in a PKIX-compliant (Public Key Infrastructure using X.509) certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of certificates.
本文档描述如何构造和解释PKIX兼容（使用X.509的公钥基础设施）证书中的某些信息，以用于传输层安全（TLS）连接上的会话发起协议（SIP）。更具体地说，本文档描述了如何在证书中编码和提取SIP域的标识，以及如何将该标识用于SIP域身份验证。因此，本文件既与SIP的实施者相关，也与证书的颁发者相关。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5922.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5922.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Key Words ..................................................3
3. Problem Statement ...............................................3
4. SIP Domain to Host Resolution ...................................5
5. The Need for Mutual Interdomain Authentication ..................6
6. Certificate Usage by a SIP Service Provider .....................7
7. Behavior of SIP Entities ........................................8
7.1. Finding SIP Identities in a Certificate ....................8
7.2. Comparing SIP Identities ...................................9
7.3. Client Behavior ...........................................10
7.4. Server Behavior ...........................................11
7.5. Proxy Behavior ............................................12
7.6. Registrar Behavior ........................................12
7.7. Redirect Server Behavior ..................................12
7.8. Virtual SIP Servers and Certificate Content ...............12
8. Security Considerations ........................................13
8.1. Connection Authentication Using Digest ....................13
9. Acknowledgments ................................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
Appendix A. Editorial Guidance (Non-Normative) ...................16
A.1. Additions .................................................16
A.2. Changes ...................................................16
A.2.1. Changes to Section 26.3.1 .............................16
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Key Words ..................................................3
3. Problem Statement ...............................................3
4. SIP Domain to Host Resolution ...................................5
5. The Need for Mutual Interdomain Authentication ..................6
6. Certificate Usage by a SIP Service Provider .....................7
7. Behavior of SIP Entities ........................................8
7.1. Finding SIP Identities in a Certificate ....................8
7.2. Comparing SIP Identities ...................................9
7.3. Client Behavior ...........................................10
7.4. Server Behavior ...........................................11
7.5. Proxy Behavior ............................................12
7.6. Registrar Behavior ........................................12
7.7. Redirect Server Behavior ..................................12
7.8. Virtual SIP Servers and Certificate Content ...............12
8. Security Considerations ........................................13
8.1. Connection Authentication Using Digest ....................13
9. Acknowledgments ................................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
Appendix A. Editorial Guidance (Non-Normative) ...................16
A.1. Additions .................................................16
A.2. Changes ...................................................16
A.2.1. Changes to Section 26.3.1 .............................16
RFC 5246 [5] Transport Layer Security (TLS) is available in an increasing number of Session Initiation Protocol (SIP) RFC 3261 [2] implementations. In order to use the authentication capabilities of TLS, certificates as defined by the Internet X.509 Public Key Infrastructure, see RFC 5280 [6], are required.
RFC 5246[5]传输层安全性（TLS）在越来越多的会话启动协议（SIP）RFC 3261[2]实现中可用。为了使用TLS的身份验证功能，需要Internet X.509公钥基础设施定义的证书，请参见RFC 5280[6]。
Existing SIP specifications do not sufficiently specify how to use certificates for domain (as opposed to host) authentication. This document provides guidance to ensure interoperability and uniform conventions for the construction and interpretation of certificates used to identify their holders as being authoritative for the domain.
现有的SIP规范没有充分指定如何使用证书进行域（而不是主机）身份验证。本文件提供了确保互操作性的指南，以及用于确定其持有人在该领域具有权威性的证书的构造和解释的统一约定。
The discussion in this document is pertinent to an X.509 PKIX-compliant certificate used for a TLS connection; this document does not define use of such certificates for any other purpose (such as Secure/Multipurpose Internet Mail Extensions (S/MIME)).
本文档中的讨论与用于TLS连接的X.509 PKIX兼容证书有关；本文档未定义将此类证书用于任何其他目的（如安全/多用途Internet邮件扩展（S/MIME））。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
Additional definition(s):
其他定义：
SIP domain identity: An identity (e.g., "sip:example.com") contained in an X.509 certificate bound to a subject that identifies the subject as an authoritative SIP server for a domain.
SIP域标识：包含在绑定到主题的X.509证书中的标识（例如，“SIP:example.com”），该证书将主题标识为域的权威SIP服务器。
TLS uses RFC 5280 [6] X.509 Public Key Infrastructure to bind an identity or a set of identities, to the subject of an X.509 certificate. While RFC 3261 provides adequate guidance on the use of X.509 certificates for S/MIME, it is relatively silent on the use of such certificates for TLS. With respect to certificates for TLS, RFC 3261 (Section 26.3.1) says:
TLS使用RFC 5280[6]X.509公钥基础设施将一个身份或一组身份绑定到X.509证书的主体。虽然RFC 3261为S/MIME使用X.509证书提供了充分的指导，但对TLS使用此类证书的情况却相对沉默。关于TLS证书，RFC 3261（第26.3.1节）规定：
Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname.
代理服务器、重定向服务器和注册器应该拥有一个站点证书，其主题对应于它们的标准主机名。
The security properties of TLS and S/MIME as used in SIP are different: X.509 certificates for S/MIME are generally used for end-to-end authentication and encryption; thus, they serve to bind the identity of a user to the certificate and RFC 3261 is sufficiently clear that in certificates used for S/MIME, the subjectAltName field will contain the appropriate identity. On the other hand, X.509 certificates used for TLS serve to bind the identities of the per-hop domain sending or receiving the SIP messages. However, the lack of guidelines in RFC 3261 on exactly where to put identities -- in the subjectAltName field or carried as a Common Name (CN) in the Subject field -- of an X.509 certificate created ambiguities. Following the accepted practice of the time, legacy X.509 certificates were allowed to store the identity in the CN field of the certificate instead of the currently specified subjectAltName extension. Lack of further guidelines on how to interpret the identities, which identity to choose if more than one identity is present in the certificate, the behavior when multiple identities with different schemes were present in the certificate, etc., lead to ambiguities when attempting to interpret the certificate in a uniform manner for TLS use.
SIP中使用的TLS和S/MIME的安全属性不同：S/MIME的X.509证书通常用于端到端身份验证和加密；因此，它们用于将用户的身份绑定到证书，并且RFC 3261非常清楚，在用于S/MIME的证书中，subjectAltName字段将包含适当的身份。另一方面，用于TLS的X.509证书用于绑定发送或接收SIP消息的每跳域的身份。然而，RFC 3261中缺乏关于X.509证书的身份（在subjectAltName字段中或在Subject字段中作为通用名（CN）携带）的确切位置的指南，这造成了歧义。按照当时公认的做法，旧X.509证书被允许在证书的CN字段中存储标识，而不是当前指定的subjectAltName扩展名。在如何解释身份、如果证书中存在多个身份，则选择哪个身份、证书中存在多个具有不同方案的身份时的行为等方面缺乏进一步的指导原则，导致在尝试以统一方式解释证书以供TLS使用时出现歧义。
This document shows how the certificates are to be used for mutual authentication when both the client and server possess appropriate certificates, and normative behavior for matching the DNS query string with an identity stored in the X.509 certificate. Furthermore, a certificate can contain multiple identities for the subject in the subjectAltName extension (the "subject" of a certificate identifies the entity associated with the public key stored in the public key field). As such, this document specifies appropriate matching rules to encompass various subject identity representation options. And finally, this document also provides guidelines to service providers for assigning certificates to SIP servers.
本文档说明了当客户端和服务器都拥有适当的证书时，如何使用证书进行相互身份验证，以及将DNS查询字符串与存储在X.509证书中的标识相匹配的规范行为。此外，证书可以包含subjectAltName扩展中主体的多个标识（证书的“主体”标识与存储在公钥字段中的公钥相关联的实体）。因此，本文件规定了适当的匹配规则，以涵盖各种主体身份表示选项。最后，本文档还为服务提供商提供了为SIP服务器分配证书的指南。
The rest of this document is organized as follows: the next section provides an overview of the most primitive case of a client using DNS to access a SIP server and the resulting authentication steps. Section 5 looks at the reason why mutual inter-domain authentication is desired in SIP, and the lack of normative text and behavior in RFC 3261 for doing so. Section 6 outlines normative guidelines for a service provider assigning certificates to SIP servers. Section 7 provides normative behavior on the SIP entities (user agent clients, user agent servers, registrars, redirect servers, and proxies) that need perform authentication based on X.509 certificates. Section 8 includes the security considerations.
本文档的其余部分组织如下：下一节概述了客户端使用DNS访问SIP服务器的最基本情况以及由此产生的身份验证步骤。第5节探讨了SIP中需要相互域间认证的原因，以及RFC3261中缺乏规范性文本和行为的原因。第6节概述了服务提供商向SIP服务器分配证书的标准指南。第7节提供了需要基于X.509证书执行身份验证的SIP实体（用户代理客户端、用户代理服务器、注册器、重定向服务器和代理）的规范行为。第8节包括安全考虑。
Routing in SIP is performed by having the client execute RFC 3263 [8] procedures on a URI, called the "Application Unique String (AUS)" (c.f. Section 8 of RFC 3263 [8]). These procedures take as input a SIP AUS (the SIP URI), extract the domain portion of that URI for use as a lookup key, and query the Domain Name Service (DNS) to obtain an ordered set of one or more IP addresses with a port number and transport corresponding to each IP address in the set (the "Expected Output"). If the transport indicates the use of TLS, then a TLS connection is opened to the server on a specific IP address and port. The server presents an X.509 certificate to the client for verification as part of the initial TLS handshake.
SIP中的路由是通过让客户端在URI上执行RFC 3263[8]过程来执行的，该URI称为“应用程序唯一字符串（AUS）”（RFC 3263[8]的c.f.第8节）。这些过程将SIP AUS（SIP URI）作为输入，提取该URI的域部分以用作查找密钥，并查询域名服务（DNS）以获得一个或多个IP地址的有序集，其中端口号和传输对应于该集中的每个IP地址（“预期输出”）。如果传输指示使用TLS，则会在特定IP地址和端口上打开与服务器的TLS连接。作为初始TLS握手的一部分，服务器向客户端提供X.509证书以进行验证。
The client extracts identifiers from the Subject and any subjectAltName extension in the certificate (see Section 7.1) and compares these values to the domain part extracted from the original SIP URI (the AUS). If any identifier match is found, the server is considered to be authenticated and subsequent signaling can now proceed over the TLS connection. Matching rules for X.509 certificates and the normative behavior for clients is specified in Section 7.3.
客户端从证书中的Subject和任何subjectAltName扩展中提取标识符（参见第7.1节），并将这些值与从原始SIP URI（AUS）提取的域部分进行比较。如果发现任何标识符匹配，则认为服务器已通过身份验证，随后的信令现在可以通过TLS连接进行。第7.3节规定了X.509证书和客户规范行为的匹配规则。
As an example, consider a request that is to be routed to the SIP address "sips:alice@example.com". This address requires a secure connection to the SIP domain "example.com" (the 'sips' scheme mandates a secure connection). Through a series of DNS manipulations, the domain name is mapped to a set of host addresses and transports. The entity attempting to create the connection selects an address appropriate for use with TLS from this set. When the connection is established to that server, the server presents a certificate asserting the identity "sip:example.com". Since the domain part of the SIP AUS matches the subject of the certificate, the server is authenticated (see Section 7.2 for the normative rules that govern this comparison).
作为一个例子，考虑将要路由到SIP地址的请求“SIPS：alice@example.com". 此地址需要到SIP域“example.com”的安全连接（“sips”方案要求安全连接）。通过一系列DNS操作，域名被映射到一组主机地址和传输。试图创建连接的实体从该集中选择适合与TLS一起使用的地址。当与该服务器建立连接时，服务器将提供一个证书，声明标识“sip:example.com”。由于SIP AUS的域部分与证书的主题相匹配，因此对服务器进行身份验证（有关管理此比较的规范性规则，请参见第7.2节）。
Session Initiation Protocol Secure (SIPS) borrows this pattern of server certificate matching from HTTPS. However, RFC 2818 [7] prefers that the identity be conveyed as a subjectAltName extension of type dNSName rather than the common practice of conveying the identity in the CN field of the Subject field. Similarly, this document recommends that the SIP domain identity be conveyed as a subjectAltName extension of type uniformResourceIdentifier (c.f. Sections 6 and 7.1).
会话启动协议安全（SIPS）借用了HTTPS的这种服务器证书匹配模式。然而，RFC 2818[7]更倾向于将身份作为dNSName类型的subjectAltName扩展来传递，而不是在Subject字段的CN字段中传递身份的常见做法。同样，本文件建议将SIP域标识作为uniformResourceIdentifier类型的subjectAltName扩展进行传达（c.f.第6节和第7.1节）。
A domain name in an X.509 certificates is properly interpreted only as a sequence of octets to be compared to the URI used to reach the host. No inference can be made based on the DNS name
X.509证书中的域名仅被正确解释为要与用于到达主机的URI进行比较的八位字节序列。无法根据DNS名称进行推断
hierarchy. For example, a valid certificate for "example.com" does not imply that the owner of that certificate has any relationship at all to "subname.example.com".
等级制度例如，“example.com”的有效证书并不意味着该证书的所有者与“subname.example.com”有任何关系。
Consider the SIP trapezoid shown in Figure 1.
考虑图1所示的SIP梯形图。
Proxy-A.example.com Proxy-B.example.net
+-------+ +-------+
| Proxy |--------------------| Proxy |
+----+--+ +---+---+
| |
| |
| |
| +---+
0---0 | |
/-\ |___|
+---+ / /
+----+
alice@example.com bob@example.net
Proxy-A.example.com Proxy-B.example.net
+-------+ +-------+
| Proxy |--------------------| Proxy |
+----+--+ +---+---+
| |
| |
| |
| +---+
0---0 | |
/-\ |___|
+---+ / /
+----+
alice@example.com bob@example.net
Figure 1: SIP Trapezoid
图1:SIP梯形
A user, alice@example.com, invites bob@example.net for a multimedia communication session. Alice's outbound proxy, Proxy-A.example.com, uses normal RFC 3263 [8] resolution rules to find a proxy -- Proxy-B.example.net -- in the example.net domain that uses TLS. Proxy-A actively establishes an interdomain TLS connection with Proxy-B and each presents a certificate to authenticate that connection.
用户，alice@example.com，邀请bob@example.net用于多媒体通信会话。Alice的出站代理proxy-A.example.com使用常规RFC 3263[8]解析规则在使用TLS的example.net域中查找代理proxy-B.example.net。Proxy-A主动地与Proxy-B建立域间TLS连接，并且每个代理都提供一个证书来验证该连接。
RFC 3261 [2], Section 26.3.2.2, "Interdomain Requests" states that when a TLS connection is created between two proxies:
RFC 3261[2]，第26.3.2.2节，“域间请求”指出，在两个代理之间创建TLS连接时：
Each side of the connection SHOULD verify and inspect the certificate of the other, noting the domain name that appears in the certificate for comparison with the header fields of SIP messages.
连接的每一方都应该验证和检查另一方的证书，注意证书中出现的域名，以便与SIP消息的头字段进行比较。
However, RFC 3261 is silent on whether to use the subjectAltName or CN of the certificate to obtain the domain name, and which takes precedence when there are multiple names identifying the holder of the certificate.
但是，RFC 3261没有说明是使用证书的subjectAltName还是CN来获取域名，并且当有多个名称标识证书持有人时，域名优先。
The authentication problem for Proxy-A is straightforward: in the certificate Proxy-A receives from Proxy-B, Proxy-A looks for an identity that is a SIP URI ("sip:example.net") or a DNS name ("example.net") that asserts Proxy-B's authority over the example.net domain. Normative behavior for a TLS client like Proxy-A is specified in Section 7.3.
Proxy-A的身份验证问题很简单：在Proxy-A从Proxy-B接收的证书中，Proxy-A查找的标识是SIP URI（“SIP:example.net”）或DNS名称（“example.net”），该名称断言Proxy-B在example.net域上的权限。第7.3节规定了TLS客户端（如Proxy-a）的规范行为。
The problem for Proxy-B is slightly more complex since it accepts the TLS request passively. Thus, Proxy-B does not possess an equivalent AUS that it can use as an anchor in matching identities from Proxy-A's certificate.
Proxy-B的问题稍微复杂一些，因为它被动地接受TLS请求。因此，Proxy-B不具有等效的AUS，它可以将其用作从Proxy-A的证书匹配身份的锚。
RFC 3261 [2], Section 26.3.2.2, only tells Proxy-B to "compare the domain asserted by the certificate with the 'domainname' portion of the From header field in the INVITE request". The difficulty with that instruction is that the domainname in the From header field is not always that of the domain from which the request is received.
RFC 3261[2]第26.3.2.2节仅告诉Proxy-B“将证书声明的域与INVITE请求中From标头字段的“domainname”部分进行比较”。该指令的困难在于From头字段中的域名并不总是接收请求的域的域名。
The normative behavior for a TLS server like Proxy-B that passively accepts a TLS connection and requires authentication of the sending peer domain is provided in Section 7.4.
第7.4节提供了被动接受TLS连接并要求对发送对等域进行身份验证的TLS服务器（如Proxy-B）的规范行为。
It is possible for service providers to continue the practice of using existing certificates for SIP usage with the identity conveyed only in the Subject field, but they should carefully consider the following advantages of conveying identity in the subjectAltName extension field:
服务提供商可以继续使用SIP使用的现有证书，而仅在主题字段中传送的身份，但是他们应该仔细考虑在Cube CordNeNT扩展字段中传输身份的以下优点：
o The subjectAltName extension can hold multiple values, so the same certificate can identify multiple servers or sip domains.
o subjectAltName扩展可以包含多个值，因此同一证书可以标识多个服务器或sip域。
o There is no fixed syntax specified for the Subject field, so issuers vary in how the field content is set. This forces a recipient to use heuristics to extract the identity, again increasing opportunities for misinterpretation.
o 没有为主题字段指定固定语法，因此发布者在字段内容的设置方式上有所不同。这迫使接收者使用试探法提取身份，再次增加了误解的机会。
Because of these advantages, service providers are strongly encouraged to obtain certificates that contain the identity or identities in the subjectAltName extension field.
由于这些优点，强烈鼓励服务提供商获取包含subjectAltName扩展字段中的一个或多个标识的证书。
When assigning certificates to authoritative servers, a SIP service provider MUST ensure that the SIP domain used to reach the server appears as an identity in the subjectAltName field, or for compatibility with existing certificates, the Subject field of the certificate. In practice, this means that a service provider
将证书分配给权威服务器时，SIP服务提供商必须确保用于访问服务器的SIP域在subjectAltName字段中显示为标识，或者为了与现有证书兼容，在证书的Subject字段中显示为标识。实际上，这意味着服务提供商
distributes to its users SIP URIs whose domain portion corresponds to an identity for which the service provider has been issued a certificate.
向其用户分发其域部分与服务提供商已获颁发证书的标识相对应的SIP URI。
This section normatively specifies the behavior of SIP entities when using X.509 certificates to determine an authenticated SIP domain identity.
本节规范性地指定了使用X.509证书确定经过身份验证的SIP域标识时SIP实体的行为。
The first two subsections apply to all SIP implementations that use TLS to authenticate the peer: Section 7.1 describes how to extract a set of SIP identities from the certificate obtained from a TLS peer, and Section 7.2 specifies how to compare SIP identities. The remaining subsections provide context for how and when these rules are to be applied by entities in different SIP roles.
前两小节适用于使用TLS对对等方进行身份验证的所有SIP实现：第7.1节描述了如何从从从TLS对等方获得的证书中提取一组SIP标识，第7.2节指定了如何比较SIP标识。其余小节提供了不同SIP角色的实体应用这些规则的方式和时间的上下文。
Implementations (both clients and server) MUST determine the validity of a certificate by following the procedures described in RFC 5280 [6].
实现（客户端和服务器）必须按照RFC 5280[6]中描述的过程确定证书的有效性。
As specified by RFC 5280 [6], Section 4.2.1.12, implementations MUST check for restrictions on certificate usage declared by any extendedKeyUsage extensions in the certificate. The SIP Extended Key Usage (EKU) document [12] defines an extendedKeyUsage for SIP.
按照RFC 5280[6]第4.2.1.12节的规定，实现必须检查证书中任何extendedKeyUsage扩展声明的证书使用限制。SIP扩展密钥使用（EKU）文档[12]定义了SIP的扩展密钥使用。
Given an X.509 certificate that the above checks have found to be acceptable, the following describes how to determine what SIP domain identity or identities the certificate contains. A single certificate can serve more than one purpose -- that is, the certificate might contain identities not acceptable as SIP, domain identities and/or might contain one or more identities that are acceptable for use as SIP domain identities.
如果上述检查发现X.509证书是可接受的，下面描述如何确定该证书包含的SIP域标识。单个证书可以用于多个目的——也就是说，该证书可能包含作为SIP不可接受的标识、域标识和/或可能包含一个或多个可作为SIP域标识使用的标识。
1. Examine each value in the subjectAltName field. The subjectAltName field and the constraints on its values are defined in Section 4.2.1.6 of RFC 5280 [6]. The subjectAltName field can be absent or can contain one or more values. Each value in the subjectAltName has a type; the only types acceptable for encoding a SIP domain identity SHALL be:
1. 检查subjectAltName字段中的每个值。RFC 5280[6]第4.2.1.6节定义了subjectAltName字段及其值约束。subjectAltName字段可以不存在，也可以包含一个或多个值。subjectAltName中的每个值都有一个类型；编码SIP域标识的唯一可接受类型应为：
URI If the scheme of the URI is not "sip", then the implementation MUST NOT accept the value as a SIP domain identity.
URI如果URI的方案不是“sip”，则实现不能接受该值作为sip域标识。
If the scheme of the URI value is "sip", and the URI value that contains a userpart (there is an '@'), the implementation MUST NOT accept the value as a SIP domain identity (a value with a userpart identifies an individual user, not a domain).
如果URI值的方案是“sip”，并且URI值包含一个用户部分（有一个“@”），则实现不能接受该值作为sip域标识（带有用户部分的值标识单个用户，而不是域）。
If the scheme of the URI value is "sip", and there is no userinfo component in the URI (there is no '@'), then the implementation MUST accept the hostpart as a SIP domain identity.
如果URI值的方案是“sip”，并且URI中没有userinfo组件（没有“@”），那么实现必须接受hostpart作为sip域标识。
Note: URI scheme tokens are always case insensitive.
注意：URI方案令牌始终不区分大小写。
DNS An implementation MUST accept a domain name system identifier as a SIP domain identity if and only if no other identity is found that matches the "sip" URI type described above.
当且仅当未找到与上述“SIP”URI类型匹配的其他标识时，DNS实现必须接受域名系统标识符作为SIP域标识。
2. If and only if the subjectAltName does not appear in the certificate, the implementation MAY examine the CN field of the certificate. If a valid DNS name is found there, the implementation MAY accept this value as a SIP domain identity. Accepting a DNS name in the CN value is allowed for backward compatibility, but when constructing new certificates, consider the advantages of using the subjectAltName extension field (see Section 6).
2. 如果且仅当subjectAltName未出现在证书中，则实现可以检查证书的CN字段。如果在那里找到有效的DNS名称，则实现可以接受该值作为SIP域标识。接受CN值中的DNS名称是为了向后兼容，但是在构造新证书时，考虑使用MealCeTeNNeX扩展字段的优点（参见第6节）。
The above procedure yields a set containing zero or more identities from the certificate. A client uses these identities to authenticate a server (see Section 7.3) and a server uses them to authenticate a client (see Section 7.4).
上述过程从证书中生成一个包含零个或多个标识的集合。客户端使用这些标识对服务器进行身份验证（参见第7.3节），服务器使用这些标识对客户端进行身份验证（参见第7.4节）。
When an implementation (either client or server) compares two values as SIP domain identities:
当实现（客户端或服务器）将两个值作为SIP域标识进行比较时：
Implementations MUST compare only the DNS name component of each SIP domain identifier; an implementation MUST NOT use any scheme or parameters in the comparison.
实现必须只比较每个SIP域标识符的DNS名称组件；实现在比较中不得使用任何方案或参数。
Implementations MUST compare the values as DNS names, which means that the comparison is case insensitive as specified by RFC 4343 [3]. Implementations MUST handle Internationalized Domain Names (IDNs) in accordance with Section 7.2 of RFC 5280 [6].
实现必须将这些值作为DNS名称进行比较，这意味着按照RFC 4343[3]的规定，比较不区分大小写。实施必须按照RFC 5280[6]第7.2节处理国际化域名（IDN）。
Implementations MUST match the values in their entirety:
实现必须完全匹配这些值：
Implementations MUST NOT match suffixes. For example, "foo.example.com" does not match "example.com".
实现不能匹配后缀。例如，“foo.example.com”与“example.com”不匹配。
Implementations MUST NOT match any form of wildcard, such as a leading "." or "*." with any other DNS label or sequence of labels. For example, "*.example.com" matches only "*.example.com" but not "foo.example.com". Similarly, ".example.com" matches only ".example.com", and does not match "foo.example.com".
实现不得将任何形式的通配符（如前导“.”或“*”）与任何其他DNS标签或标签序列匹配。例如，“*.example.com”只匹配“*.example.com”，而不匹配“foo.example.com”。类似地，“.example.com”仅与“.example.com”匹配，与“foo.example.com”不匹配。
RFC 2818 [7] (HTTP over TLS) allows the dNSName component to contain a wildcard; e.g., "DNS:*.example.com". RFC 5280 [6], while not disallowing this explicitly, leaves the interpretation of wildcards to the individual specification. RFC 3261 [2] does not provide any guidelines on the presence of wildcards in certificates. Through the rule above, this document prohibits such wildcards in certificates for SIP domains.
RFC 2818[7]（HTTP over TLS）允许dNSName组件包含通配符；e、 例如，“DNS:*.example.com”。RFC 5280[6]虽然没有明确禁止这一点，但将通配符的解释留给各个规范。RFC 3261[2]未提供任何关于证书中是否存在通配符的指南。通过上述规则，本文档禁止SIP域的证书中使用此类通配符。
A client uses the domain portion of the SIP AUS to query a (possibly untrusted) DNS to obtain a result set, which is one or more SRV and A records identifying the server for the domain (see Section 4 for an overview).
客户端使用SIP AUS的域部分来查询（可能不受信任的）DNS以获得结果集，该结果集是一个或多个SRV和一个用于标识域服务器的记录（有关概述，请参阅第4节）。
The SIP server, when establishing a TLS connection, presents its certificate to the client for authentication. The client MUST determine the SIP domain identities in the server certificate using the procedure in Section 7.1. Then, the client MUST compare the original domain portion of the SIP AUS used as input to the RFC 3263 [8] server location procedures to the SIP domain identities obtained from the certificate.
SIP服务器在建立TLS连接时，向客户端提供其证书以进行身份验证。客户端必须使用第7.1节中的过程确定服务器证书中的SIP域标识。然后，客户端必须将用作RFC 3263[8]服务器定位过程输入的SIP AU的原始域部分与从证书获得的SIP域标识进行比较。
o If there were no identities found in the server certificate, the server is not authenticated.
o 如果在服务器证书中找不到标识，则服务器未经过身份验证。
o If the domain extracted from the AUS matches any SIP domain identity obtained from the certificate when compared as described in Section 7.2, the server is authenticated for the domain.
o 如果从AUS提取的域与根据第7.2节所述进行比较时从证书获得的任何SIP域标识相匹配，则服务器将针对该域进行身份验证。
If the server is not authenticated, the client MUST close the connection immediately.
如果服务器未经过身份验证，客户端必须立即关闭连接。
When a server accepts a TLS connection, the server presents its own X.509 certificate to the client. Servers that wish to authenticate the client will ask the client for a certificate. If the client possesses a certificate, that certificate is presented to the server. If the client does not present a certificate, the client MUST NOT be considered authenticated.
当服务器接受TLS连接时，服务器将向客户端提供自己的X.509证书。希望对客户端进行身份验证的服务器将向客户端请求证书。如果客户机拥有证书，则该证书将提供给服务器。如果客户端不提供证书，则不能将客户端视为已验证。
Whether or not to close a connection if the client does not present a certificate is a matter of local policy, and depends on the authentication needs of the server for the connection. Some currently deployed servers use Digest authentication to authenticate individual requests on the connection, and choose to treat the connection as authenticated by those requests for some purposes (but see Section 8.1).
如果客户端不提供证书，是否关闭连接是本地策略的问题，取决于服务器对连接的身份验证需求。一些当前部署的服务器使用摘要身份验证对连接上的单个请求进行身份验证，并出于某些目的选择将连接视为通过这些请求的身份验证（但请参见第8.1节）。
If the local server policy requires client authentication for some local purpose, then one element of such a local policy might be to allow the connection only if the client is authenticated. For example, if the server is an inbound proxy that has peering relationships with the outbound proxies of other specific domains, the server might allow only connections authenticated as coming from those domains.
如果本地服务器策略出于某些本地目的需要客户端身份验证，那么这种本地策略的一个元素可能是仅在客户端经过身份验证时才允许连接。例如，如果服务器是与其他特定域的出站代理具有对等关系的入站代理，则服务器可能只允许验证为来自这些域的连接。
When authenticating the client, the server MUST obtain the set of SIP domain identities from the client certificate as described in Section 7.1. Because the server accepted the TLS connection passively, unlike a client, the server does not possess an AUS for comparison. Nonetheless, server policies can use the set of SIP domain identities gathered from the certificate in Section 7.1 to make authorization decisions.
在对客户端进行身份验证时，服务器必须从客户端证书中获取SIP域标识集，如第7.1节所述。由于服务器被动接受TLS连接，因此与客户端不同，服务器不具有用于比较的AUS。尽管如此，服务器策略可以使用从第7.1节中的证书收集的SIP域标识集来做出授权决策。
For example, a very open policy could be to accept an X.509 certificate and validate the certificate using the procedures in RFC 5280 [6]. If the certificate is valid, the identity set is logged.
例如，非常开放的策略可以是接受X.509证书，并使用RFC 5280[6]中的过程验证证书。如果证书有效，将记录标识集。
Alternatively, the server could have a list of all SIP domains the server is allowed to accept connections from; when a client presents its certificate, for each identity in the client certificate, the server searches for the identity in the list of acceptable domains to decide whether or not to accept the connection. Other policies that make finer distinctions are possible.
或者，服务器可以有一个允许服务器接受连接的所有SIP域的列表；当客户端显示其证书时，对于客户端证书中的每个标识，服务器将在可接受域列表中搜索该标识，以决定是否接受连接。其他可以做出更精细区分的政策也是可能的。
The decision of whether or not the authenticated connection to the client is appropriate for use to route new requests to the client domain is independent of whether or not the connection is authenticated; the connect-reuse [10] document discusses this aspect in more detail.
与客户端的认证连接是否适合用于将新请求路由到客户端域的决定与连接是否被认证无关；connect reuse[10]文档更详细地讨论了这一方面。
A proxy MUST use the procedures defined for a User Agent Server (UAS) in Section 7.4 when authenticating a connection from a client.
当验证来自客户端的连接时，代理必须使用第7.4节中为用户代理服务器（UAS）定义的过程。
A proxy MUST use the procedures defined for a User Agent Client (UAC) in Section 7.3 when requesting an authenticated connection to a UAS.
当请求到UAS的认证连接时，代理必须使用第7.3节中为用户代理客户端（UAC）定义的过程。
If a proxy adds a Record-Route when forwarding a request with the expectation that the route is to use secure connections, the proxy MUST insert into the Record-Route header a URI that corresponds to an identity for which the proxy has a certificate; if the proxy does not insert such a URI, then creation of a secure connection using the value from the Record-Route as the AUS will be impossible.
如果代理在转发请求时添加了记录路由，并期望该路由使用安全连接，则代理必须在记录路由头中插入一个URI，该URI对应于代理具有证书的标识；如果代理没有插入这样的URI，那么使用记录路由中的值作为AU来创建安全连接将是不可能的。
A SIP registrar, acting as a server, follows the normative behavior of Section 7.4. When the SIP registrar accepts a TLS connection from the client, the SIP registrar presents its certificate. Depending on the registrar policies, the SIP registrar can challenge the client with HTTP Digest.
充当服务器的SIP注册器遵循第7.4节的规范行为。当SIP注册器接受来自客户端的TLS连接时，SIP注册器将出示其证书。根据注册器策略，SIP注册器可以使用HTTP摘要质询客户端。
A SIP redirect server follows the normative behavior of a UAS as specified in Section 7.4.
SIP重定向服务器遵循第7.4节规定的UAS规范行为。
In the "virtual hosting" cases where multiple domains are managed by a single application, a certificate can contain multiple subjects by having distinct identities in the subjectAltName field as specified in RFC 4474 [9]. Clients seeking to authenticate a server on such a virtual host can still follow the directions in Section 7.3 to find the identity matching the SIP AUS used to query DNS.
在由单个应用程序管理多个域的“虚拟主机”情况下，证书可以包含多个主题，方法是在subjectAltName字段中具有RFC 4474[9]中指定的不同标识。寻求对此类虚拟主机上的服务器进行身份验证的客户端仍然可以按照第7.3节中的说明查找与用于查询DNS的SIP AU匹配的标识。
Alternatively, if the TLS client hello "server_name" extension as defined in RFC 4366 [4] is supported, the client SHOULD use that extension to request a certificate corresponding to the specific domain (from the SIP AUS) with which the client is seeking to establish a connection.
或者，如果支持RFC 4366[4]中定义的TLS客户机hello“server_name”扩展，则客户机应使用该扩展请求与客户机寻求建立连接的特定域（来自SIP AUS）对应的证书。
The goals of TLS (when used with X.509 certificates) include the following security guarantees at the transport layer:
TLS的目标（与X.509证书一起使用时）包括传输层的以下安全保证：
Confidentiality: packets tunneled through TLS can be read only by the sender and receiver.
机密性：通过TLS传输的数据包只能由发送方和接收方读取。
Integrity: packets tunneled through TLS cannot be undetectably modified on the connection between the sender and receiver.
完整性：通过TLS隧道传输的数据包不能在发送方和接收方之间的连接上被不可检测地修改。
Authentication: each principal is authenticated to the other as possessing a private key for which a certificate has been issued. Moreover, this certificate has not been revoked, and is verifiable by a certificate chain leading to a (locally configured) trust anchor.
身份验证：每个主体都会向另一个主体进行身份验证，因为它拥有一个已颁发证书的私钥。此外，此证书尚未被吊销，并且可通过指向（本地配置的）信任锚点的证书链进行验证。
We expect appropriate processing of domain certificates to provide the following security guarantees at the application level:
我们希望域证书的适当处理能够在应用程序级别提供以下安全保证：
Confidentiality: SIPS messages from alice@example.com to bob@example.net can be read only by alice@example.com, bob@example.net, and SIP proxies issued with domain certificates for example.com or example.net.
机密性：SIPS消息来自alice@example.com到bob@example.net只能由alice@example.com, bob@example.net，以及使用域证书颁发的SIP代理，例如example.com或example.net。
Integrity: SIPS messages from alice@example.com to bob@example.net cannot be undetectably modified on the links between alice@example.com, bob@example.net, and SIP proxies issued with domain certificates for example.com or example.net.
完整性：SIPS消息来自alice@example.com到bob@example.net无法对之间的链接进行不可检测的修改alice@example.com, bob@example.net，以及使用域证书颁发的SIP代理，例如example.com或example.net。
Authentication: alice@example.com and proxy.example.com are mutually authenticated; moreover, proxy.example.com is authenticated to alice@example.com as an authoritative proxy for domain example.com. Similar mutual authentication guarantees are given between proxy.example.com and proxy.example.net and between proxy.example.net and bob@example.net. As a result, alice@example.com is transitively mutually authenticated to bob@example.net (assuming trust in the authoritative proxies for example.com and example.net).
身份验证：alice@example.com和proxy.example.com相互认证；此外，proxy.example.com已通过身份验证alice@example.com作为域example.com的权威代理。proxy.example.com和proxy.example.net之间以及proxy.example.net和bob@example.net. 因此alice@example.com可传递地相互验证到bob@example.net（假设信任权威代理，例如example.com和example.net）。
Digest authentication in SIP provides for authentication of the message sender to the challenging UAS. As commonly deployed, digest authentication provides only very limited integrity protection of the authenticated message, and has no provision for binding the authentication to any attribute of the transport. Many existing SIP deployments have chosen to use the Digest authentication of one or
SIP中的摘要身份验证用于向具有挑战性的UAS验证消息发送方。与通常部署的一样，摘要身份验证只提供非常有限的已验证消息的完整性保护，并且没有将身份验证绑定到传输的任何属性的规定。许多现有的SIP部署都选择使用一个或多个SIP的摘要身份验证
more messages on a particular transport connection as a way to authenticate the connection itself -- by implication, authenticating other (unauthenticated) messages on that connection. Some even choose to similarly authenticate a UDP source address and port based on the digest authentication of another message received from that address and port. This use of digest goes beyond the assurances that the Digest Authentication mechanism was designed to provide. A SIP implementation SHOULD NOT use the Digest Authentication of one message on a TCP connection or from a UDP peer to infer any authentication of any other messages on that connection or from that peer. Authentication of the domain at the other end of a connection SHOULD be accomplished using TLS and the certificate validation rules described by this specification instead.
在特定传输连接上发送更多消息，作为验证连接本身的一种方式——通过暗示，验证该连接上的其他（未经验证的）消息。有些人甚至选择基于从该地址和端口接收的另一条消息的摘要身份验证，对UDP源地址和端口进行类似的身份验证。摘要的这种使用超出了摘要身份验证机制的设计目的。SIP实现不应使用TCP连接或UDP对等方上的一条消息的摘要身份验证来推断该连接或该对等方上的任何其他消息的身份验证。连接另一端的域身份验证应该使用TLS和本规范描述的证书验证规则来完成。
The following IETF contributors provided substantive input to this document: Jeroen van Bemmel, Michael Hammer, Cullen Jennings, Paul Kyzivat, Derek MacDonald, Dave Oran, Jon Peterson, Eric Rescorla, Jonathan Rosenberg, and Russ Housley. Special acknowledgement goes to Stephen Kent for extensively reviewing document versions and suggesting invaluable feedback, edits, and comments.
以下IETF贡献者为本文件提供了实质性投入：Jeroen van Bemmel、Michael Hammer、Cullen Jennings、Paul Kyzivat、Derek MacDonald、Dave Oran、Jon Peterson、Eric Rescorla、Jonathan Rosenberg和Russ Housley。特别感谢Stephen Kent对文档版本进行了广泛审查，并提出了宝贵的反馈、编辑和评论。
Paul Hoffman, Eric Rescorla, and Robert Sparks provided many valuable WGLC comments.
Paul Hoffman、Eric Rescorla和Robert Sparks提供了许多有价值的WGLC评论。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[3] Eastlake, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006.
[3] Eastlake，D.，“域名系统（DNS）案例不敏感澄清”，RFC 4343，2006年1月。
[4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[4] Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[5] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[6] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[6] Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[7] Rescorla，E.，“TLS上的HTTP”，RFC 2818，2000年5月。
[8] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[8] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，2002年6月。
[9] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[9] Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[10] Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in the Session Initiation Protocol", RFC 5923, June 2010.
[10] Mahy，R.，Gurbani，V.，和B.Tate，“会话启动协议中的连接重用”，RFC 59232010年6月。
[11] Drage, K., "A Process for Handling Essential Corrections to the Session Initiation Protocol (SIP)", Work in Progress, July 2008.
[11] Drage，K.，“处理会话启动协议（SIP）基本修正的过程”，正在进行的工作，2008年7月。
[12] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates", RFC 5924, June 2010.
[12] Lawrence，S.和V.Gurbani，“将扩展密钥使用（EKU）用于会话启动协议（SIP）X.509证书”，RFC 59242010年6月。
Appendix A. Editorial Guidance (Non-Normative)
附录A.编辑指南（非规范性）
This document is intended to update RFC 3261 in accordance with the SIP Working Group procedures described in [11] or its successor.
本文件旨在根据[11]中描述的SIP工作组程序或其后续程序更新RFC 3261。
This appendix provides guidance to the editor of the next comprehensive update to RFC 3261 [2] on how to incorporate the changes provided by this document.
本附录为RFC 3261[2]下一次全面更新的编辑提供了关于如何纳入本文件提供的变更的指南。
The content of Sections 4 through 7 inclusive can be incorporated as subsections within a section that describes SIP domain authentication.
第4节至第7节（含第4节至第7节）的内容可以合并为描述SIP域认证的一节中的子节。
The contents of Section 8.1 can be incorporated into the Security Considerations section of the new document.
第8.1节的内容可纳入新文件的安全注意事项部分。
All normative references from this document can be carried forward to its successor.
本文件中的所有规范性引用文件均可转交给后续文件。
The following subsections describe changes in specific sections of RFC 3261 [2] that need to be modified in the successor document to align them with the content of this document. In each of the following, the token <domain-authentication> is a reference to the section added as described in Appendix A.1.
以下小节描述了RFC 3261[2]特定章节中的变更，这些变更需要在后续文件中进行修改，以使其与本文件的内容保持一致。在以下各项中，令牌<domain authentication>是对附录a.1中所述添加部分的引用。
The current text says:
目前的案文说：
Proxy servers, redirect servers and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname.
代理服务器、重定向服务器和注册器应该拥有一个站点证书，其主题对应于它们的标准主机名。
The suggested replacement for the above is:
建议的上述替代品为：
Proxy servers, redirect servers, registrars, and any other server that is authoritative for some SIP purpose in a given domain SHOULD possess a certificate whose subjects include the name of that SIP domain.
代理服务器、重定向服务器、注册器以及在给定域中对某些SIP目的具有权威性的任何其他服务器都应该拥有一个证书，其主题包括该SIP域的名称。
Authors' Addresses
作者地址
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane Room 9C-533 Naperville, IL 60566 USA
Vijay K.Gurbani Bell实验室，阿尔卡特朗讯1960朗讯巷，美国伊利诺伊州纳珀维尔9C-533室，邮编：60566
Phone: +1 630 224-0216
EMail: vkg@alcatel-lucent.com
Phone: +1 630 224-0216
EMail: vkg@alcatel-lucent.com
Scott Lawrence
斯科特·劳伦斯
EMail: scott-ietf@skrb.org
EMail: scott-ietf@skrb.org
Alan S.A. Jeffrey Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane Room 9C-533 Naperville, IL 60566 USA
艾伦S.A.杰弗里·贝尔实验室，阿尔卡特朗讯1960朗讯巷，美国伊利诺伊州纳珀维尔9C-533室，邮编60566
EMail: ajeffrey@alcatel-lucent.com
EMail: ajeffrey@alcatel-lucent.com