Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6714 S. Blau
Category: Standards Track Ericsson
ISSN: 2070-1721 E. Burger
Georgetown University
August 2012
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6714 S. Blau
Category: Standards Track Ericsson
ISSN: 2070-1721 E. Burger
Georgetown University
August 2012
Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)
消息会话中继协议（MSRP）的媒体锚定（CEMA）连接建立
Abstract
摘要
This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of this extension is OPTIONAL. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed. This document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension.
本文档定义了消息会话中继协议（MSRP）扩展、媒体锚定连接建立（CEMA）。支持此扩展是可选的。扩展允许中间盒锚定MSRP连接，而无需中间盒修改MSRP消息；因此，它还可以在部署此类中间盒的网络中实现安全的端到端MSRP通信。本文档还定义了会话描述协议（SDP）属性“msrp cema”，msrp端点使用该属性表示对cema扩展的支持。
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/rfc6714.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6714.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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. Conventions .....................................................5
3. Applicability Statement .........................................6
4. Connection Establishment for Media Anchoring Mechanism ..........7
4.1. General ....................................................7
4.2. MSRP SDP Offerer Procedures ................................8
4.3. MSRP SDP Answerer Procedures ...............................9
4.4. Address Information Matching ..............................11
4.5. Usage with the Alternative Connection Model ...............12
5. The SDP 'msrp-cema' Attribute ..................................12
5.1. General ...................................................12
5.2. Syntax ....................................................12
6. Middlebox Assumptions ..........................................13
6.1. General ...................................................13
6.2. MSRP Awareness ............................................13
6.3. TCP Connection Reuse ......................................13
6.4. SDP Integrity .............................................14
6.5. TLS .......................................................14
7. Security Considerations ........................................14
7.1. General ...................................................14
7.2. Man-in-the-Middle (MITM) Attacks ..........................15
7.3. TLS Usage without Middleboxes .............................16
7.4. TLS Usage with Middleboxes ................................16
7.5. Authentication, Credentials, and Key Management ...........16
7.6. Endpoint Procedures for TLS Negotiation ...................17
7.7. Fingerprint-Based Authentication ..........................18
8. IANA Considerations ............................................19
8.1. IANA Registration of the SDP 'msrp-cema' Attribute ........19
9. Acknowledgements ...............................................20
10. References ....................................................20
10.1. Normative References .....................................20
10.2. Informative References ...................................21
1. Introduction ....................................................3
2. Conventions .....................................................5
3. Applicability Statement .........................................6
4. Connection Establishment for Media Anchoring Mechanism ..........7
4.1. General ....................................................7
4.2. MSRP SDP Offerer Procedures ................................8
4.3. MSRP SDP Answerer Procedures ...............................9
4.4. Address Information Matching ..............................11
4.5. Usage with the Alternative Connection Model ...............12
5. The SDP 'msrp-cema' Attribute ..................................12
5.1. General ...................................................12
5.2. Syntax ....................................................12
6. Middlebox Assumptions ..........................................13
6.1. General ...................................................13
6.2. MSRP Awareness ............................................13
6.3. TCP Connection Reuse ......................................13
6.4. SDP Integrity .............................................14
6.5. TLS .......................................................14
7. Security Considerations ........................................14
7.1. General ...................................................14
7.2. Man-in-the-Middle (MITM) Attacks ..........................15
7.3. TLS Usage without Middleboxes .............................16
7.4. TLS Usage with Middleboxes ................................16
7.5. Authentication, Credentials, and Key Management ...........16
7.6. Endpoint Procedures for TLS Negotiation ...................17
7.7. Fingerprint-Based Authentication ..........................18
8. IANA Considerations ............................................19
8.1. IANA Registration of the SDP 'msrp-cema' Attribute ........19
9. Acknowledgements ...............................................20
10. References ....................................................20
10.1. Normative References .....................................20
10.2. Informative References ...................................21
The Message Session Relay Protocol (MSRP) [RFC4975] expects to use MSRP relays [RFC4976] as a means for Network Address Translation (NAT) traversal and policy enforcement. However, many Session Initiation Protocol (SIP) [RFC3261] networks, which deploy MSRP, contain middleboxes. These middleboxes anchor and control media; perform tasks such as NAT traversal, performance monitoring, and address domain bridging; interconnect Service Level Agreement (SLA) policy enforcement; and so on. One example is the Interconnection
消息会话中继协议（MSRP）[RFC4975]期望使用MSRP中继[RFC4976]作为网络地址转换（NAT）遍历和策略实施的手段。然而，许多部署MSRP的会话启动协议（SIP）[RFC3261]网络都包含中间盒。这些中间盒锚定和控制媒体；执行NAT遍历、性能监视和地址域桥接等任务；互连服务水平协议（SLA）策略实施；等等互连就是一个例子
Border Control Function (IBCF) [GPP23228], defined by the 3rd Generation Partnership Project (3GPP). The IBCF controls a media relay that handles all types of SIP session media, such as voice, video, MSRP, etc.
边界控制功能（IBCF）[GPP23228]，由第三代合作伙伴计划（3GPP）定义。IBCF控制一个媒体中继，该中继处理所有类型的SIP会话媒体，如语音、视频、MSRP等。
MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], cannot anchor through middleboxes. The reason is that MSRP messages have routing information embedded in the message. Without an extension such as CEMA, middleboxes must read the message to change the routing information. This occurs because middleboxes modify the address:port information in the Session Description Protocol (SDP) [RFC4566] c/m-line in order to anchor media. An "active" [RFC6135] MSRP User Agent (UA) establishes the MSRP TCP or Transport Layer Security (TLS) connection based on the MSRP URI of the SDP 'path' attribute. This means that the MSRP connection will not be routed through the middlebox unless the middlebox also modifies the MSRP URI of the topmost SDP 'path' attribute. In many scenarios, this will prevent the MSRP connection from being established. In addition, if the middlebox modifies the MSRP URI of the SDP 'path' attribute, then the MSRP URI comparison procedure [RFC4975], which requires consistency between the address information in the MSRP messages and the address information carried in the MSRP URI of the SDP 'path' attribute, will fail.
根据RFC 4975[RFC4975]和RFC 4976[RFC4976]中的定义，MSRP不能通过中间箱锚定。原因是MSRP消息中嵌入了路由信息。如果没有诸如CEMA之类的扩展，中间盒必须读取消息才能更改路由信息。出现这种情况的原因是，为了锚定媒体，中间盒修改会话描述协议（SDP）[RFC4566]c/m-line中的地址：端口信息。“活动”[RFC6135]MSRP用户代理（UA）基于SDP“路径”属性的MSRP URI建立MSRP TCP或传输层安全（TLS）连接。这意味着MSRP连接将不会通过中间盒路由，除非中间盒还修改最顶层SDP“path”属性的MSRP URI。在许多情况下，这将阻止建立MSRP连接。此外，如果中间盒修改SDP“路径”属性的MSRP URI，则MSRP URI比较过程[RFC4975]将失败，该过程要求MSRP消息中的地址信息与SDP“路径”属性的MSRP URI中携带的地址信息保持一致。
The only way to achieve interoperability in this situation is for the middlebox to act as an MSRP back-to-back User Agent (B2BUA). Here, the MSRP B2BUA acts as the endpoint for the MSRP signaling and media, performs the corresponding modification in the associated MSRP messages, and originates a new MSRP session toward the actual remote endpoint. However, the enabling of MSRP B2BUA functionality requires substantially more resource usage in the middlebox, which normally results in a negative impact on performance. In addition, the MSRP message needs to be exposed in cleartext to the MSRP B2BUA, which violates the end-to-end principle [RFC3724].
在这种情况下，实现互操作性的唯一方法是让中间件充当MSRP背对背用户代理（B2BUA）。这里，MSRP B2BUA充当MSRP信令和媒体的端点，在相关联的MSRP消息中执行相应的修改，并且发起朝向实际远程端点的新MSRP会话。然而，启用MSRP B2BUA功能需要在中间盒中使用更多的资源，这通常会对性能产生负面影响。此外，MSRP消息需要以明文形式公开给MSRP B2BUA，这违反了端到端原则[RFC3724]。
This specification defines an MSRP extension, Connection Establishment for Media Anchoring (CEMA). In most cases, CEMA allows MSRP endpoints to communicate through middleboxes as defined in Section 2, without a need for the middleboxes to be MSRP B2BUAs. In such cases, middleboxes that want to anchor the MSRP connection simply modify the SDP c/m-line address information, similar to what the middleboxes do for non-MSRP media types. MSRP endpoints that support the CEMA extension will use the SDP c/m-line address information for establishing the TCP or TLS connection for sending and receiving MSRP messages.
本规范定义了MSRP扩展、媒体锚定连接建立（CEMA）。在大多数情况下，CEMA允许MSRP端点通过第2节中定义的中间盒进行通信，而不需要中间盒是MSRP B2BUAs。在这种情况下，想要锚定MSRP连接的中间盒只需修改SDP c/m线路地址信息，类似于中间盒对非MSRP介质类型所做的操作。支持CEMA扩展的MSRP端点将使用SDP c/m-line地址信息建立TCP或TLS连接以发送和接收MSRP消息。
The CEMA extension is backward compatible, meaning that CEMA-enabled MSRP endpoints can communicate with non-CEMA-enabled endpoints. In scenarios where MSRP endpoints do not support the CEMA extension, an MSRP endpoint that supports the CEMA extension behaves in the same way as an MSRP endpoint that does not support it. The CEMA extension only provides an alternative mechanism for negotiating and providing address information for the MSRP TCP connection. After the creation of the MSRP connection, an MSRP endpoint that supports the CEMA extension acts according to the procedures for creating MSRP messages, performing checks when receiving MSRP messages defined in RFC 4975 and, when it is using a relay for MSRP communications, RFC 4976.
CEMA扩展是向后兼容的，这意味着启用CEMA的MSRP端点可以与未启用CEMA的端点通信。在MSRP端点不支持CEMA扩展的场景中，支持CEMA扩展的MSRP端点的行为方式与不支持CEMA扩展的MSRP端点的行为方式相同。CEMA扩展仅为协商和提供MSRP TCP连接的地址信息提供替代机制。创建MSRP连接后，支持CEMA扩展的MSRP端点根据创建MSRP消息的过程进行操作，在接收RFC 4975中定义的MSRP消息时执行检查，在使用MSRP通信中继时执行RFC 4976检查。
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Definitions:
定义：
Fingerprint-Based TLS Authentication: An MSRP endpoint that uses a self-signed certificate and sends a fingerprint (i.e., a hash of the self-signed certificate) in SDP to the other MSRP endpoint. This fingerprint binds the TLS key exchange to the signaling plane and authenticates the other endpoint based on trust in the signaling plane.
基于指纹的TLS身份验证：使用自签名证书并在SDP中将指纹（即自签名证书的哈希）发送到其他MSRP端点的MSRP端点。此指纹将TLS密钥交换绑定到信令平面，并基于信令平面中的信任对另一个端点进行身份验证。
Name-Based TLS Authentication: An MSRP endpoint that uses a certificate that is bound to the endpoint's hostname or SIP address of record. In the TLS session setup, the other MSRP endpoint verifies that the identity associated with the certificate corresponds to that of the peer (as indicated in SIP/ SDP) and that the binding of the identity to the public key was done by a party that the endpoint trusts. This definition includes traditional certificates issued by a well-known certification authority as well as self-signed certificates published via the SIP Certificate Management Service [RFC6072] and other similar mechanisms.
基于名称的TLS身份验证：使用绑定到端点主机名或SIP记录地址的证书的MSRP端点。在TLS会话设置中，另一个MSRP端点验证与证书关联的标识是否与对等方的标识相对应（如SIP/SDP中所示），以及该标识与公钥的绑定是否由端点信任的一方完成。此定义包括由知名证书颁发机构颁发的传统证书以及通过SIP证书管理服务[RFC6072]和其他类似机制发布的自签名证书。
B2BUA: This is an abbreviation for back-to-back user agent.
B2BUA：这是背靠背用户代理的缩写。
MSRP B2BUA: A network element that terminates an MSRP connection from one MSRP endpoint and reoriginates that connection toward another MSRP endpoint. Note that the MSRP B2BUA is distinct from a SIP B2BUA. A SIP B2BUA terminates a SIP session and reoriginates that session toward another SIP endpoint. In the
MSRP B2BUA：从一个MSRP端点终止MSRP连接并向另一个MSRP端点重新排列该连接的网元。请注意，MSRP B2BUA不同于SIP B2BUA。SIP B2BUA终止SIP会话并将该会话重新定向到另一SIP端点。在
context of MSRP, a SIP endpoint initiates a SIP session toward another SIP endpoint. However, that INVITE may go through, for example, an outbound proxy or inbound proxy to route to the remote SIP endpoint. As part of that SIP session, an MSRP session that may follow the SIP session path is negotiated. However, there is no requirement to co-locate the SIP network elements with the MSRP network elements.
在MSRP上下文中，SIP端点向另一个SIP端点发起SIP会话。但是，该INVITE可以通过出站代理或入站代理路由到远程SIP端点。作为该SIP会话的一部分，协商可能遵循SIP会话路径的MSRP会话。但是，没有要求将SIP网元与MSRP网元放在同一位置。
TLS B2BUA: A network element that terminates security associations (SAs) from endpoints and establishes separate SAs between itself and each endpoint.
TLS B2BUA：终止来自端点的安全关联（SA）并在其自身和每个端点之间建立单独SA的网元。
Middlebox: A SIP network device that modifies SDP media address:port information in order to steer or anchor media flows described in the SDP, including TCP and TLS connections used for MSRP communication, through a media proxy function controlled by the SIP endpoint. In most cases, the media proxy function relays the MSRP messages without modification, while in some circumstances it acts as an MSRP B2BUA. Other SIP-related functions -- such as those related to routing, modification of SIP information, etc. -- performed by the Middlebox, and whether it acts as a SIP B2BUA or not, are outside the scope of this document. Section 6 describes additional assumptions regarding how the Middlebox handles MSRP in order to support the extension defined in this document.
中间盒：一种SIP网络设备，通过SIP端点控制的媒体代理功能，修改SDP媒体地址：端口信息，以引导或锚定SDP中描述的媒体流，包括用于MSRP通信的TCP和TLS连接。在大多数情况下，媒体代理功能无需修改即可中继MSRP消息，而在某些情况下，它充当MSRP B2BUA。其他与SIP相关的功能——例如与路由、SIP信息修改等相关的功能——由中间件执行，以及它是否充当SIP B2BUA，不在本文档的范围内。第6节描述了关于中间箱如何处理MSRP以支持本文件中定义的扩展的其他假设。
Media anchor: An entity that performs media anchoring inserts itself in the media path of a media communication session between two entities. The media anchor will receive, and forward, the media sent between the entities.
媒体锚定：执行媒体锚定的实体，在两个实体之间的媒体通信会话的媒体路径中插入自身。媒体锚将接收并转发实体之间发送的媒体。
This document reuses the terms "answer", "answerer", "offer", and "offerer" as defined in [RFC3264].
本文件重复使用了[RFC3264]中定义的术语“应答人”、“应答人”、“报价人”和“报价人”。
This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of this extension is OPTIONAL. The extension allows Middleboxes to anchor the MSRP connection, without the need for Middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such Middleboxes are deployed. The document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension.
本文档定义了消息会话中继协议（MSRP）扩展、媒体锚定连接建立（CEMA）。支持此扩展是可选的。扩展允许中间盒锚定MSRP连接，而无需中间盒修改MSRP消息；因此，它还可以在部署此类中间盒的网络中实现安全的端到端MSRP通信。该文档还定义了会话描述协议（SDP）属性“msrp cema”，msrp端点使用该属性表示对cema扩展的支持。
The CEMA extension is primarily intended for MSRP endpoints that operate in networks in which Middleboxes that want to anchor media connections are deployed, without the need for the Middleboxes to
CEMA扩展主要用于在网络中运行的MSRP端点，这些网络中部署了希望锚定媒体连接的中间盒，而不需要中间盒
enable MSRP B2BUA functionality. An example of such a network is the IP Multimedia Subsystem (IMS), defined by the 3rd Generation Partnership Project (3GPP), which also has the capability for all endpoints to use name-based TLS authentication. The extension is also useful for other MSRP endpoints that operate in other networks but that communicate with MSRP endpoints in networks with such Middleboxes, unless there is a gateway between these networks that by default always enables MSRP B2BUA functionality.
启用MSRP B2BUA功能。这种网络的一个例子是由第三代合作伙伴关系项目（3GPP）定义的IP多媒体子系统（IMS），它还具有使所有端点使用基于名称的TLS认证的能力。该扩展还适用于在其他网络中运行，但在具有此类中间盒的网络中与MSRP端点通信的其他MSRP端点，除非这些网络之间存在默认情况下始终启用MSRP B2BUA功能的网关。
This document assumes certain behaviors on the part of Middleboxes, as described in Section 6. These behaviors are not standardized. If Middleboxes do not behave as assumed, then the CEMA extension does not add any value over base MSRP behavior. MSRP endpoints that support CEMA are required to use RFC 4975 behavior in cases where they detect that the CEMA extension cannot be enabled.
如第6节所述，本文件假设了中间盒的某些行为。这些行为不规范。如果中间盒的行为不符合假设，那么CEMA扩展不会比基本MSRP行为增加任何价值。支持CEMA的MSRP端点在检测到无法启用CEMA扩展时，需要使用RFC 4975行为。
This section defines how an MSRP endpoint that supports the CEMA extension generates SDP offers and answers for MSRP, and which SDP information elements the MSRP endpoint uses when creating the TCP or TLS connection for sending and receiving MSRP messages.
本节定义了支持CEMA扩展的MSRP端点如何为MSRP生成SDP报价和应答，以及MSRP端点在创建TCP或TLS连接以发送和接收MSRP消息时使用的SDP信息元素。
Based on the procedures described in Sections 4.2 and 4.3, in the following cases the CEMA extension will not be enabled, and there will be a fallback to the MSRP connection establishment procedures defined in RFC 4975 and RFC 4976:
根据第4.2节和第4.3节中描述的程序，在以下情况下，CEMA扩展将不启用，并且将退回RFC 4975和RFC 4976中定义的MSRP连接建立程序：
- A non-CEMA-enabled MSRP endpoint becomes "active" [RFC6135] (no matter whether it uses a relay for its MSRP communication or not), as it will always establish the MSRP connection using the SDP 'path' attribute, which contains the address information of the remote MSRP endpoint, instead of using the SDP c/m-line, which contains the address information of the Middlebox.
- 未启用CEMA的MSRP端点变为“活动”[RFC6135]（无论其是否使用中继进行MSRP通信），因为它将始终使用SDP“路径”属性建立MSRP连接，该属性包含远程MSRP端点的地址信息，而不是使用SDP c/m-line，其中包含中间盒的地址信息。
- A non-CEMA-enabled MSRP endpoint that uses a relay for its MSRP communication becomes "passive" [RFC6135], as it cannot be assumed that the MSRP endpoint inserts the address information of the relay in the SDP c/m-line.
- 使用中继器进行MSRP通信的未启用CEMA的MSRP端点变为“被动”[RFC6135]，因为不能假定MSRP端点将中继器的地址信息插入SDP c/m线路。
- A CEMA-enabled MSRP endpoint that uses a relay for its MSRP communication becomes "active", since if it adds the received SDP c/m-line address information to the ToPath header field of the MSRP message (in order for the relay to establish the MSRP connection toward the Middlebox), the session matching [RFC4975] performed by the remote MSRP endpoint will fail.
- 使用中继器进行MSRP通信的启用CEMA的MSRP端点将变为“活动”，因为如果它将接收到的SDP c/m-line地址信息添加到MSRP消息的ToPath头字段（以便中继器建立指向中间盒的MSRP连接），则会话匹配[RFC4975]由远程MSRP端点执行的操作将失败。
When a CEMA-enabled offerer sends an SDP offer for MSRP, it generates the SDP offer according to the procedures in RFC 4975. In addition, the offerer follows RFC 4976 if it is using a relay for MSRP communication. The offerer also performs the following additions and modifications:
当启用CEMA的报价人发送MSRP的SDP报价时，它将根据RFC 4975中的程序生成SDP报价。此外，如果报价人使用中继进行MSRP通信，则报价人遵循RFC 4976。报价人还进行以下添加和修改：
1. The offerer MUST include an SDP 'msrp-cema' attribute in the MSRP media description of the SDP offer.
1. 报价人必须在SDP报价的msrp媒体描述中包含SDP“msrp cema”属性。
2. If the offerer is not using a relay for MSRP communication, it MUST include an SDP 'setup' attribute in the MSRP media description of the SDP offer, according to the procedures in RFC 6135 [RFC6135].
2. 如果报价人未使用中继进行MSRP通信，则必须根据RFC 6135[RFC6135]中的程序，在SDP报价的MSRP媒体描述中包含SDP“设置”属性。
3. If the offerer is using a relay for MSRP communication, it MUST, in addition to including the address information of the relay in the topmost SDP 'path' attribute, also include the address information of the relay, rather than its own address information, in the SDP c/m-line associated with the MSRP media description. In addition, it MUST include an SDP 'setup:actpass' attribute in the MSRP media description of the SDP offer.
3. 如果报价人使用中继器进行MSRP通信，除了在最顶端的SDP“路径”属性中包含中继器的地址信息外，还必须在与MSRP媒体描述相关联的SDP c/m行中包含中继器的地址信息，而不是其自身的地址信息。此外，它必须在SDP报价的MSRP媒体描述中包含SDP“setup:actpass”属性。
When the offerer receives an SDP answer, if the MSRP media description of the SDP answer does not contain an SDP 'msrp-cema' attribute, and if any one or more of the criteria below are met, the offerer MUST fall back to RFC 4975 behavior by sending a new SDP offer according to the procedures in RFC 4975 and RFC 4976. The new offer MUST NOT contain an SDP 'msrp-cema' attribute.
当报价人收到SDP应答时，如果SDP应答的MSRP媒体描述不包含SDP“MSRP cema”属性，并且如果满足以下任何一个或多个标准，报价人必须根据RFC 4975和RFC 4976中的程序发送新的SDP报价，从而退回到RFC 4975行为。新报价不得包含SDP“msrp cema”属性。
1. The SDP c/m-line address information associated with the MSRP media description does not match (see Section 4.4) the information in the MSRP URI of the 'path' attribute(s) (in which case it is assumed that the SDP c/m-line contains the address of a Middlebox), and the MSRP endpoint will become "passive" (if the MSRP media description of the SDP answer contains an SDP 'setup: active' attribute).
1. 与MSRP介质描述相关联的SDP c/m线地址信息与“路径”属性的MSRP URI中的信息不匹配（见第4.4节）（在这种情况下，假设SDP c/m线包含中间盒的地址），MSRP端点将变为“被动”（如果SDP应答的MSRP介质描述包含SDP“设置：活动”属性）。
NOTE: If an MSRP URI contains a domain name, it needs to be resolved into an IP address and port before it is checked against the SDP c/m-line address information, in order to determine whether the address information matches.
注意：如果MSRP URI包含域名，则需要先将其解析为IP地址和端口，然后再对照SDP c/m-line地址信息进行检查，以确定地址信息是否匹配。
2. The offerer uses a relay for its MSRP communication, the SDP c/m-line address information associated with the MSRP media description does not match the information in the MSRP URI of the SDP 'path' attribute(s) (in which case it is assumed that the SDP
2. 报价人使用中继器进行MSRP通信，与MSRP媒体描述相关联的SDP c/m线路地址信息与SDP“路径”属性的MSRP URI中的信息不匹配（在这种情况下，假设SDP
c/m-line contains the address of a Middlebox), and the offerer will become "active" (either by default or if the MSRP media description of the SDP answer contains an SDP 'setup:passive' attribute).
c/m-line包含中间盒的地址），报价人将变为“主动”（默认情况下，或者如果SDP应答的MSRP媒体描述包含SDP“设置：被动”属性）。
3. The remote MSRP endpoint, acting as an answerer, uses a relay for its MSRP communication, the SDP c/m-line address information associated with the MSRP media description does not match the information in the MSRP URI of the SDP 'path' attributes (in which case it is assumed that the SDP c/m-line contains the address of a Middlebox), and the MSRP offerer will become "active" (either by default or if the MSRP media description of the SDP answer contains an SDP 'setup:passive' attribute).
3. 作为应答器的远程MSRP端点使用中继进行MSRP通信，与MSRP媒体描述相关联的SDP c/m线地址信息与SDP“路径”属性的MSRP URI中的信息不匹配（在这种情况下，假设SDP c/m线包含中间盒的地址），MSRP报价人将变为“主动”（默认情况下，或者如果SDP应答的MSRP媒体描述包含SDP“设置：被动”属性）。
NOTE: As described in Section 6, in the absence of the SDP 'msrp-cema' attribute in the new offer, it is assumed that a Middlebox will act as an MSRP B2BUA in order to anchor MSRP media.
注：如第6节所述，在新报价中没有SDP“msrp cema”属性的情况下，假设中间箱将充当msrp B2BUA，以锚定msrp媒体。
The offerer can send the new offer within the existing early dialog [RFC3261], or it can terminate the early dialog and establish a new dialog by sending the new offer in a new initial INVITE request.
报价人可以在现有的早期对话[RFC3261]中发送新报价，也可以通过在新的初始邀请请求中发送新报价来终止早期对话并建立新对话。
The offerer MAY choose to terminate the session establishment if it can detect that a Middlebox acting as an MSRP B2BUA is not the desired remote MSRP endpoint.
如果要约人能够检测到充当MSRP B2BUA的中间盒不是期望的远程MSRP端点，则要约人可以选择终止会话建立。
If the answerer uses a relay for its MSRP communication, and the SDP c/m-line address information associated with the MSRP media description matches one of the SDP 'path' attributes, it is assumed that there is no Middlebox in the network. In that case, the offerer MUST fall back to RFC 4975 behavior, but it does not need to send a new SDP offer.
如果应答者使用中继器进行MSRP通信，并且与MSRP介质描述相关联的SDP c/m线路地址信息与SDP“路径”属性之一匹配，则假定网络中没有中间盒。在这种情况下，报价人必须退回到RFC 4975行为，但不需要发送新的SDP报价。
In other cases, where none of the criteria above are met, and where the MSRP offerer becomes "active", it MUST use the SDP c/m-line for establishing the MSRP TCP connection. If the offerer becomes "passive", it will wait for the answerer to establish the TCP connection, according to the procedures in RFC 4975.
在其他情况下，如果未满足上述任何标准，且MSRP报价人变为“活跃”，则必须使用SDP c/m-line建立MSRP TCP连接。如果报价人变得“被动”，它将根据RFC 4975中的程序等待应答人建立TCP连接。
If the MSRP media description of the SDP offer does not contain an SDP 'msrp-cema' attribute, and the SDP c/m-line address information associated with the MSRP media description does not match the information in the MSRP URI of the SDP 'path' attribute(s), the answerer MUST either reject the offered MSRP connection (by using a
如果SDP报价的MSRP媒体描述不包含SDP“MSRP cema”属性，并且与MSRP媒体描述相关联的SDP c/m-line地址信息与SDP“path”属性的MSRP URI中的信息不匹配，则应答者必须拒绝提供的MSRP连接（通过使用
zero port value number in the generated SDP answer) or reject the whole SIP request that carries the SDP offer with a 488 Not Acceptable Here [RFC3261] response.
生成的SDP应答中的零端口值编号）或使用488不可接受的[RFC3261]响应拒绝包含SDP提供的整个SIP请求。
NOTE: The reason for the rejection is that the answerer assumes that a middlebox that does not support the CEMA extension has modified the c/m-line address information of the SDP offer without enabling MSRP B2BUA functionality.
注：拒绝的原因是，应答者假设不支持CEMA扩展的中间盒在未启用MSRP B2BUA功能的情况下修改了SDP报价的c/m线路地址信息。
NOTE: If an MSRP URI contains a domain name, it needs to be resolved into an IP address and port before it is checked against the SDP c/m-line address information, in order to determine whether the address information matches.
注意：如果MSRP URI包含域名，则需要先将其解析为IP地址和端口，然后再对照SDP c/m-line地址信息进行检查，以确定地址信息是否匹配。
If any one or more of the criteria below are met, the answerer MUST fall back to RFC 4975 behavior and generate the associated SDP answer according to the procedures in RFC 4975 and RFC 4976. The answerer MUST NOT insert an SDP 'msrp-cema' attribute in the MSRP media description of the SDP answer.
如果满足以下任何一个或多个标准，应答者必须回到RFC 4975行为，并根据RFC 4975和RFC 4976中的程序生成相关的SDP答案。应答者不得在SDP应答的msrp介质描述中插入SDP“msrp cema”属性。
1. Both MSRP endpoints are using relays for their MSRP communication. The answerer can detect if the remote MSRP endpoint, acting as an offerer, is using a relay for its MSRP communication if the MSRP media description of the SDP offer contains multiple SDP 'path' attributes.
1. 两个MSRP端点都使用中继进行MSRP通信。如果SDP报价的MSRP媒体描述包含多个SDP“路径”属性，应答者可以检测作为报价人的远程MSRP端点是否正在使用中继进行MSRP通信。
2. The offerer uses a relay for its MSRP communication and will become "active" (either by default or if the MSRP media description of the SDP offer contains an SDP 'setup:active' attribute). Note that a CEMA-enabled offerer would include an SDP 'setup:actpass' attribute in the SDP offer, as described in Section 4.2.
2. 报价人使用中继进行MSRP通信，并将变为“活动”（默认情况下，或者如果SDP报价的MSRP媒体描述包含SDP“设置：活动”属性）。请注意，如第4.2节所述，启用CEMA的报价人将在SDP报价中包含SDP“设置：actpass”属性。
3. The answerer uses a relay for MSRP communication and is not able to become "passive" (if the MSRP media description of the offer contains an SDP 'setup:passive' attribute). Note that an offerer is not allowed to include an SDP 'setup:passive' attribute in an SDP offer, as described in RFC 6135.
3. 应答者使用中继进行MSRP通信，不能变为“被动”（如果报价的MSRP媒体描述包含SDP“setup:passive”属性）。请注意，如RFC 6135所述，报价人不允许在SDP报价中包含SDP“设置：被动”属性。
In all other cases, the answerer generates the associated SDP answer according to the procedures in RFC 4975 and RFC 4976, with the following additions and modifications:
在所有其他情况下，应答者根据RFC 4975和RFC 4976中的程序生成相关的SDP应答，并进行以下添加和修改：
1. The answerer MUST include an SDP 'msrp-cema' attribute in the MSRP media description of the SDP answer.
1. 应答者必须在SDP应答的msrp媒体描述中包含SDP“msrp cema”属性。
2. If the answerer is not using a relay for MSRP communication, it MUST include an SDP 'setup' attribute in the MSRP media description of the answer, according to the procedures in RFC 6135.
2. 如果应答者未使用中继进行MSRP通信，则根据RFC 6135中的程序，应答者必须在应答的MSRP媒体描述中包含SDP“设置”属性。
3. If the answerer is using a relay for MSRP communication, it MUST, in addition to including the address information of the relay in the topmost SDP 'path' attribute, also include the address information of the relay, rather than its own address information, in the SDP c/m-line associated with the MSRP media description. In addition, the answerer MUST include an SDP 'setup:passive' attribute in the MSRP media description of the SDP answer.
3. 如果应答者使用中继器进行MSRP通信，则除了将中继器的地址信息包含在最顶端的SDP“路径”属性中外，还必须将中继器的地址信息（而不是其自身的地址信息）包含在与MSRP媒体描述相关联的SDP c/m行中。此外，应答者必须在SDP应答的MSRP媒体描述中包含SDP“设置：被动”属性。
If the answerer included an SDP 'msrp-cema' attribute in the MSRP media description of the SDP answer, and if the answerer becomes "active", it MUST use the received SDP c/m-line for establishing the MSRP TCP or TLS connection. If the answerer becomes "passive", it will wait for the offerer to establish the MSRP TCP or TLS connection, according to the procedures in RFC 4975.
如果应答者在SDP应答的msrp介质描述中包含SDP“msrp cema”属性，并且如果应答者变为“活动”，则必须使用收到的SDP c/m-line建立msrp TCP或TLS连接。如果应答者变为“被动”，它将根据RFC 4975中的程序等待报价者建立MSRP TCP或TLS连接。
When comparing address information in the SDP c/m-line and an MSRP URI, for address and port equivalence, the address and port values are retrieved in the following ways:
在比较SDP c/m-line中的地址信息和MSRP URI时，为了实现地址和端口的等效性，通过以下方式检索地址和端口值：
- SDP c/m-line address information: The IP address is retrieved from the SDP c-line, and the port from the associated SDP m-line for MSRP.
- SDP c/m-line地址信息：IP地址从SDP c-line检索，端口从MSRP的相关SDP m-line检索。
- In case the SDP c-line contains a Fully Qualified Domain Name (FQDN), the IP address is retrieved using DNS.
- 如果SDP c-line包含完全限定的域名（FQDN），则使用DNS检索IP地址。
- MSRP URI address information: The IP address and port are retrieved from the authority part of the MSRP URI.
- MSRP URI地址信息：从MSRP URI的授权部分检索IP地址和端口。
- In case the authority part of the MSRP URI contains an FQDN, the IP address is retrieved using DNS, according to the procedures in Section 6.2 of RFC 4975.
- 如果MSRP URI的授权部分包含FQDN，则根据RFC 4975第6.2节中的程序，使用DNS检索IP地址。
NOTE: According to RFC 4975, the authority part of the MSRP URI must always contain a port.
注意：根据RFC 4975，MSRP URI的授权部分必须始终包含一个端口。
Before IPv6 addresses are compared for equivalence, they need to be converted into the same representation, using the mechanism defined in RFC 5952 [RFC5952].
在比较IPv6地址的等效性之前，需要使用RFC 5952[RFC5952]中定义的机制将它们转换为相同的表示形式。
NOTE: In case the DNS returns multiple records, each needs to be compared against the SDP c/m-line address information, in order to find at least one match.
注意：如果DNS返回多个记录，则需要将每个记录与SDP c/m-line地址信息进行比较，以便找到至少一个匹配项。
NOTE: If the authority part of the MSRP URI contains special characters, they are handled according to the procedures in Section 6.1 of RFC 4975.
注：如果MSRP URI的授权部分包含特殊字符，则根据RFC 4975第6.1节中的程序进行处理。
An MSRP endpoint that supports the CEMA extension MUST support the mechanism defined in RFC 6135, as it extends the number of scenarios where one can use the CEMA extension. An example is where an MSRP endpoint is using a relay for MSRP communication, and it needs to be "passive" in order to use the CEMA extension, instead of doing a fallback to RFC 4975 behavior.
支持CEMA扩展的MSRP端点必须支持RFC 6135中定义的机制，因为它扩展了可以使用CEMA扩展的场景数量。例如，MSRP端点使用中继进行MSRP通信，为了使用CEMA扩展，它需要是“被动的”，而不是回退到RFC 4975行为。
The SDP 'msrp-cema' attribute is used by MSRP entities to indicate support of the CEMA extension, according to the procedures in Sections 4.2 and 4.3.
根据第4.2节和第4.3节中的程序，msrp实体使用SDP“msrp cema”属性来表示对cema扩展的支持。
This section describes the syntax extensions to the ABNF syntax defined in RFC 4566 required for the SDP 'msrp-cema' attribute. The ABNF defined in this specification is conformant to RFC 5234 [RFC5234].
本节描述了SDP“msrp cema”属性所需的RFC 4566中定义的ABNF语法的语法扩展。本规范中定义的ABNF符合RFC 5234[RFC5234]。
attribute =/ msrp-cema-attr ;attribute defined in RFC 4566 msrp-cema-attr = "msrp-cema"
属性=/msrp cema attr；RFC 4566 msrp cema attr=“msrp cema”中定义的属性
This document does not specify explicit Middlebox behavior, even though Middleboxes enable some of the procedures described here. However, as MSRP endpoints are expected to operate in networks where Middleboxes that want to anchor media are present, this document makes certain assumptions regarding how such Middleboxes behave.
本文档未指定显式的中间盒行为，即使中间盒启用了此处描述的某些过程。然而，由于预期MSRP端点将在存在希望锚定媒体的中间盒的网络中运行，因此本文档对此类中间盒的行为进行了某些假设。
In order to support interoperability between UAs that support the CEMA extension and UAs that do not support the extension, the Middlebox is MSRP aware. This means that it implements MSRP B2BUA functionality. The Middlebox enables that functionality in cases where the offerer does not support the CEMA extension. In cases where the SDP offer indicates support of the CEMA extension, the Middlebox can simply modify the SDP c/m-line address information for the MSRP connection.
为了支持支持CEMA扩展的UAs和不支持该扩展的UAs之间的互操作性，中间盒支持MSRP。这意味着它实现了MSRP B2BUA功能。在报价人不支持CEMA扩展的情况下，中间箱启用该功能。在SDP报价表示支持CEMA扩展的情况下，中间盒可以简单地修改MSRP连接的SDP c/m线路地址信息。
In cases where the Middlebox enables MSRP B2BUA functionality, it acts as an MSRP endpoint. If it does not use the CEMA procedures, it will never forward the SDP 'msrp-cema' attribute in SDP offers and answers.
在中间盒启用MSRP B2BUA功能的情况下，它充当MSRP端点。如果不使用CEMA程序，则不会转发SDP报价和应答中的SDP“msrp CEMA”属性。
If the Middlebox does not implement MSRP B2BUA functionality, or does not enable it when the SDP 'msrp-cema' attribute is not present in the SDP offer, CEMA-enabled MSRP endpoints will in some cases be unable to interoperate with non-CEMA-enabled endpoints across the Middlebox.
如果中间箱未实现MSRP B2BUA功能，或者在SDP报价中不存在SDP“MSRP cema”属性时未启用该功能，则在某些情况下，启用cema的MSRP端点将无法与中间箱中未启用cema的端点进行互操作。
Middleboxes do not need to parse and modify the MSRP payload when endpoints use the CEMA extension. A Middlebox that does not parse the MSRP payload probably will not be able to reuse TCP connections for multiple MSRP sessions. Instead, in order to associate an MSRP message with a specific session, the Middlebox often assigns a unique local address:port combination for each MSRP session. Due to this, between two Middleboxes there might be a separate connection for each MSRP session.
当端点使用CEMA扩展时，中间盒不需要解析和修改MSRP负载。不解析MSRP有效负载的中间件可能无法为多个MSRP会话重用TCP连接。相反，为了将MSRP消息与特定会话相关联，中间盒通常为每个MSRP会话分配唯一的本地地址：端口组合。因此，在两个中间盒之间，每个MSRP会话可能有一个单独的连接。
If the Middlebox does not assign a unique address:port combination for each MSRP session, and does not parse MSRP messages, it might end up forwarding MSRP messages toward the wrong destination.
如果中间盒没有为每个MSRP会话分配唯一的地址：端口组合，并且没有解析MSRP消息，那么它可能最终将MSRP消息转发到错误的目标。
This document assumes that Middleboxes are able to modify the SDP address information associated with the MSRP media.
本文档假设中间盒能够修改与MSRP介质相关的SDP地址信息。
NOTE: Even though the CEMA extension as such works with end-to-end SDP protection, the main advantage of the extension is in networks where Middleboxes are deployed.
注意：尽管CEMA扩展本身可以与端到端SDP保护一起工作，但该扩展的主要优点是在部署了中间件的网络中。
If the Middlebox is unable to modify SDP payloads due to end-to-end integrity protection, it will be unable to anchor MSRP media, as the SIP signaling would fail due to integrity violations.
如果由于端到端完整性保护，中间盒无法修改SDP有效负载，它将无法锚定MSRP介质，因为SIP信令将由于完整性冲突而失败。
When UAs use the CEMA extension, this document assumes that Middleboxes relay MSRP media packets at the transport layer. The TLS handshake and resulting security association (SA) can be established peer-to-peer between the MSRP endpoints. The Middlebox will see encrypted MSRP media packets but is unable to inspect the cleartext content.
当UAs使用CEMA扩展时，本文档假设中间盒在传输层中继MSRP媒体数据包。TLS握手和由此产生的安全关联（SA）可以在MSRP端点之间建立对等。中间盒将看到加密的MSRP媒体包，但无法检查明文内容。
When UAs fall back to RFC 4975 behavior, Middleboxes act as TLS B2BUAs. The Middlebox decrypts MSRP media packets received from one MSRP endpoint and then re-encrypts them before sending them toward the other MSRP endpoint. Middleboxes can inspect and modify the MSRP message content.
当UAs退回到RFC 4975行为时，中间盒充当TLS B2BUAs。中间盒对从一个MSRP端点接收的MSRP媒体数据包进行解密，然后在将其发送到另一个MSRP端点之前对其重新加密。中间盒可以检查和修改MSRP消息内容。
Unless otherwise stated, the security considerations in RFC 4975 and RFC 4976 still apply. This section only describes additions and changes introduced by the CEMA extension.
除非另有说明，否则RFC 4975和RFC 4976中的安全注意事项仍然适用。本节仅描述CEMA扩展引入的添加和更改。
The purpose of CEMA is to enable MSRP communication over Middleboxes. These Middleboxes are commonly deployed by SIP network operators, who also commonly deploy firewall and routing policies that prevent media sessions from working unless they traverse the Middleboxes.
CEMA的目的是通过中间箱实现MSRP通信。这些中间盒通常由SIP网络运营商部署，他们还通常部署防火墙和路由策略，防止媒体会话工作，除非它们穿过中间盒。
CEMA makes it possible for Middleboxes to tunnel TLS to allow end-to-end SAs between endpoints. This is an improvement over the status quo, since without CEMA, the Middleboxes would be forced to both read and modify the cleartext MSRP messages, which would make end-to-end confidentiality and integrity protection of the MSRP transport channel impossible.
CEMA使中间盒能够通过隧道传输TLS，从而允许端点之间的端到端SAs。这是对现状的改进，因为没有CEMA，中间盒将被迫读取和修改明文MSRP消息，这将使MSRP传输通道的端到端机密性和完整性保护变得不可能。
RFC 4975 suggests two ways for MSRP endpoints to verify that the TLS connection is established end to end. The first option is to use certificates from a well-known certification authority and verify that the SubjectAltName matches the MSRP URI of the other side. The second option is to use self-signed certificates and include a fingerprint of the certificate in the SDP offer/answer. Provided the signaling is integrity protected, both endpoints can verify that the TLS SA is established with the correct host by matching the received certificate against the received fingerprint.
RFC 4975为MSRP端点提供了两种验证TLS连接是否建立端到端的方法。第一个选项是使用来自知名证书颁发机构的证书，并验证SubjectAltName是否与另一方的MSRP URI匹配。第二个选项是使用自签名证书，并在SDP提供/应答中包含证书的指纹。如果信令受完整性保护，则两个端点都可以通过将接收到的证书与接收到的指纹进行匹配来验证TLS SA是否与正确的主机建立。
Fingerprint-based authentication is expected to be common for end clients. In order to ensure the integrity of the fingerprint, RFC 4975 recommends using the SIP Identity mechanism [RFC4474]. However, this mechanism may not be compatible with CEMA, which operates under the assumption that Middleboxes will modify the contents of SDP offers and answers. Until a mechanism is available that enables a subset of the SDP to be signed, end clients that support CEMA and use fingerprint-based authentication are forced to trust the entire signaling path. In other words, end clients must accept the fact that every signaling proxy could potentially replace the fingerprints and insert a Middlebox that acts as a TLS B2BUA.
基于指纹的身份验证预计将在终端客户机中很常见。为了确保指纹的完整性，RFC 4975建议使用SIP标识机制[RFC4474]。然而，这一机制可能与CEMA不兼容，CEMA的运作假设是中间商将修改SDP报价和答案的内容。在能够对SDP的子集进行签名的机制可用之前，支持CEMA并使用基于指纹的身份验证的终端客户端将被迫信任整个信令路径。换句话说，终端客户端必须接受这样一个事实，即每个信令代理都可能替换指纹，并插入一个充当TLS B2BUA的中间盒。
An alternative solution that only requires a limited trust in the signaling plane is to use self-signed certificates together with the SIP Certificate Management Service [RFC6072]. The security provided by this solution is roughly equivalent to SIP Identity and fingerprint-based authentication (in fact, RFC 6072 is based on RFC 4474). Section 7.5 discusses this approach further.
在信令平面中只需要有限信任的替代解决方案是将自签名证书与SIP证书管理服务一起使用[RFC6072]。该解决方案提供的安全性大致相当于SIP身份和基于指纹的身份验证（事实上，RFC6072基于RFC4474）。第7.5节进一步讨论了这种方法。
In the remainder of this section, we will assume that fingerprint-based authentication is used without SIP Identity or similar mechanisms that protect the SDP across several hops.
在本节的其余部分中，我们将假设使用基于指纹的身份验证时，不使用SIP标识或类似机制来跨多个跃点保护SDP。
If TLS is not used to protect MSRP, the CEMA extension might make it easier for a MITM to transparently insert itself in the communication between MSRP endpoints in order to monitor or record unprotected MSRP communication. This can be mitigated by the use of TLS. It is therefore RECOMMENDED that TLS [RFC5246] be used. It is also recommended that TLS be used end to end, which CEMA enables even in the case of Middleboxes. According to RFC 4975, MSRP endpoints are required to support TLS. This also applies to CEMA-enabled endpoints.
如果TLS不用于保护MSRP，CEMA扩展可能会使MITM更容易透明地将自身插入MSRP端点之间的通信中，以便监视或记录未受保护的MSRP通信。这可以通过使用TLS来缓解。因此，建议使用TLS[RFC5246]。此外，还建议端到端使用TLS，即使是在中间盒的情况下，CEMA也支持这一点。根据RFC 4975，MSRP端点需要支持TLS。这也适用于启用CEMA的端点。
If TLS is used without Middleboxes, the security considerations in RFC 4975 and RFC 4976 still apply unchanged. Note that this is not the main use case for the CEMA extension.
如果使用TLS时没有使用中间盒，RFC 4975和RFC 4976中的安全注意事项仍然适用，不变。注意，这不是CEMA扩展的主要用例。
This is the main use case for the CEMA extension; the endpoints expect one or more Middleboxes.
这是CEMA扩展的主要用例；端点需要一个或多个中间盒。
The CEMA extension supports the usage of both name-based authentication and fingerprint-based authentication for TLS in the presence of Middleboxes. The use of fingerprint-based authentication requires signaling integrity protection. This can, for example, be hop-by-hop cryptographic protection or cryptographic access protection combined with a suitably protected core network. As stated in Section 6.4, this document assumes that Middleboxes are able to modify the SDP address information associated with the MSRP media.
CEMA扩展支持在存在中间盒的情况下对TLS使用基于名称的身份验证和基于指纹的身份验证。使用基于指纹的身份验证需要信号完整性保护。例如，这可以是逐跳加密保护或加密访问保护与适当保护的核心网络相结合。如第6.4节所述，本文件假设中间盒能够修改与MSRP介质相关的SDP地址信息。
If a Middlebox acts as a TLS B2BUA, the security considerations are the same as those without the CEMA extension. In such a case, the Middlebox acts as a TLS endpoint.
如果中间盒充当TLS B2BUA，则安全注意事项与没有CEMA扩展的安全注意事项相同。在这种情况下，中间盒充当TLS端点。
If a Middlebox does not act as a TLS B2BUA, TLS is end to end and the Middlebox just forwards the TLS packets. This requires that both peers support the CEMA extension.
如果中间箱不充当TLS B2BUA，则TLS是端到端的，中间箱仅转发TLS数据包。这要求两个对等方都支持CEMA扩展。
If fingerprint-based authentication is used, the MSRP endpoints might not be able to decide whether or not the Middlebox acts as a TLS B2BUA. But this is not an issue, as the signaling network is considered trusted by the endpoint (a requirement to use fingerprint-based authentication).
如果使用基于指纹的身份验证，则MSRP端点可能无法确定中间盒是否充当TLS B2BUA。但这不是问题，因为端点认为信令网络是可信的（使用基于指纹的身份验证的要求）。
One issue with the usage of TLS (not specific to CEMA) is the availability of a PKI. Endpoints can always provide self-signed certificates and include fingerprints in the SDP offer and answer. However, this relies on SDP signaling being integrity protected, which may not always be the case.
TLS使用的一个问题（并非针对CEMA）是PKI的可用性。端点始终可以提供自签名证书，并在SDP提供和应答中包含指纹。然而，这依赖于SDP信令的完整性保护，这可能并不总是如此。
Therefore, in addition to the authentication mechanisms defined in RFC 4975, it is RECOMMENDED that a CEMA-enabled MSRP endpoint also support self-signed certificates together with the Certificate Management Service [RFC6072], to which it publishes its self-signed certificate and from which it fetches on demand the self-signed certificates of other endpoints.
因此，除了RFC 4975中定义的身份验证机制外，建议启用CEMA的MSRP端点还支持自签名证书以及证书管理服务[RFC6072]，它向其发布自签名证书，并根据需要从中获取其他端点的自签名证书。
Alternate key distribution mechanisms, such as DNS-Based Authentication of Named Entities (DANE) [DANE], Pretty Good Privacy (PGP) [RFC6091], Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY-TICKET) [RFC6043], or some other technology, might become ubiquitous enough to solve the key distribution problem in the future.
备用密钥分发机制，如基于DNS的命名实体身份验证（DANE）[DANE]、相当好的隐私（PGP）[RFC6091]、多媒体互联网密钥分发中基于票据的密钥分发模式（MIKEY-Ticket）[RFC6043]或其他一些技术，可能变得无处不在，足以解决未来的密钥分发问题。
One of the target deployments for CEMA is the 3GPP IMS SIP network. In this environment, authentication and credential management are less of a problem, as the SDP signaling is mostly considered trusted, service providers provision signed certificates or manage signed certificates on behalf of their subscribers, and MIKEY-TICKET is available. Some of these options require trusting the service provider, but those issues are beyond the scope of this document.
CEMA的目标部署之一是3GPP IMS SIP网络。在这种环境中，身份验证和凭证管理的问题较少，因为SDP信令通常被认为是可信的，服务提供商提供签名证书或代表其订户管理签名证书，并且可以使用MIKEY-TICKET。其中一些选项需要信任服务提供商，但这些问题超出了本文档的范围。
The CEMA extension does not change the endpoint procedures for TLS negotiation. As in RFC 4975, the MSRP endpoint uses the negotiation mechanisms in SDP and then the TLS handshake to agree on mechanisms and algorithms that both support. The mechanisms can be divided into three different security levels:
CEMA扩展不会更改TLS协商的端点过程。与RFC 4975一样，MSRP端点使用SDP中的协商机制，然后使用TLS握手来商定双方都支持的机制和算法。这些机制可分为三个不同的安全级别：
1. MSRPS: Security mechanisms that do not rely on trusted signaling, such as name-based authentication
1. MSRPS：不依赖可信信令的安全机制，如基于名称的身份验证
2. MSRPS: Mechanisms that do rely on trusted signaling, such as fingerprint-based authentication
2. MSRPS：确实依赖于可信信号的机制，例如基于指纹的身份验证
3. MSRP: Unprotected
3. 管理系统更新项目：无保护
If the endpoint uses security mechanisms that do not rely on trusted signaling, the endpoint can detect if a Middlebox that acts as a B2BUA is inserted. It is therefore RECOMMENDED that such a mechanism be used.
如果端点使用不依赖可信信令的安全机制，那么端点可以检测是否插入了充当B2BUA的中间盒。因此，建议使用这种机制。
If the endpoint uses security mechanisms that rely on trusted signaling, the endpoint may not be able to detect if a Middlebox that acts as a B2BUA is inserted (by the trusted network operator). To be able to eavesdrop, a Middlebox must do an active "attack" on the setup signaling. A Middlebox cannot insert itself at a later point.
如果端点使用依赖于可信信令的安全机制，则端点可能无法检测（由可信网络运营商）是否插入了充当B2BUA的中间盒。为了能够窃听，中间盒必须对设置信号进行主动“攻击”。中间盒不能在以后插入自身。
If unprotected MSRP is used, the endpoint cannot detect if a Middlebox that acts as a B2BUA is inserted and Middleboxes may be inserted at any time during the session.
如果使用未受保护的MSRP，则端点无法检测是否插入了充当B2BUA的中间盒，并且在会话期间的任何时候都可以插入中间盒。
The mechanism in RFC 6072 [RFC6072] provides end-to-end security without relying on trust in the signaling plane and eases the use and deployment of name-based authentication.
RFC 6072[RFC6072]中的机制提供端到端安全性，而不依赖于信令平面中的信任，并简化了基于名称的身份验证的使用和部署。
The procedures for choosing and offering name-based authentication, fingerprint-based authentication, and unprotected MSRP as described in RFC 4975 still apply.
RFC 4975中所述的选择和提供基于姓名的认证、基于指纹的认证和无保护的MSRP的程序仍然适用。
If the endpoint cannot use a key management protocol that does not rely on trust in the signaling plane, such as name-based authentication, the only alternative is fingerprint-based authentication.
如果端点不能使用不依赖于信令平面中的信任的密钥管理协议，例如基于名称的身份验证，则唯一的替代方案是基于指纹的身份验证。
The use of fingerprint-based authentication requires integrity protection of the signaling plane. This can, for example, be hop-by-hop cryptographic protection or cryptographic access protection combined with a suitably protected core network. Unless cryptographic end-to-end SDP integrity protection or encryption is used, this may be hard for the endpoint to decide. In the end, it is up to the endpoint to decide whether the signaling path is trusted or not.
使用基于指纹的身份验证需要对信令平面进行完整性保护。例如，这可以是逐跳加密保护或加密访问保护与适当保护的核心网络相结合。除非使用加密端到端SDP完整性保护或加密，否则端点可能很难确定这一点。最后，由端点决定信令路径是否可信。
How this decision is done is implementation specific, but normally, signaling over the Internet SHOULD NOT be trusted. Signaling over a local or closed network might be trusted. Such networks can, for example, be a closed enterprise network or a network operated by an operator that the end user trusts. In IMS, for example, the signaling traffic in the access network is integrity protected and the traffic is routed over a closed network separated from the Internet. If the network is not trusted, the endpoints SHOULD NOT use fingerprint-based authentication.
如何做出这一决定取决于具体的实现，但通常情况下，不应信任通过Internet发送的信号。本地或封闭网络上的信令可能是可信的。例如，此类网络可以是封闭的企业网络或由最终用户信任的运营商运营的网络。例如，在IMS中，接入网络中的信令业务受到完整性保护，并且该业务通过与因特网分离的封闭网络路由。如果网络不受信任，则端点不应使用基于指纹的身份验证。
When an endpoint receives a fingerprint, that fingerprint represents a binding between the identity as established by TLS and that established via SDP. As previously noted, the fingerprint is vulnerable to an active MITM attack from any on-path proxy. Endpoints SHOULD therefore locally store fingerprints associated with the relevant identities when first seen and SHOULD provide a warning when a new fingerprint is seen for what otherwise appears to be the same peer identity. While there are valid reasons for keys to change from time to time, that ought to be the exception -- hence the suggested warning.
当端点接收到指纹时，该指纹表示TLS建立的身份与通过SDP建立的身份之间的绑定。如前所述，指纹容易受到来自任何路径代理的主动MITM攻击。因此，当第一次看到与相关身份相关联的指纹时，端点应在本地存储该指纹，并且当看到新指纹时，端点应提供警告，否则该指纹看起来是相同的对等身份。虽然有正当的理由让键不时地改变，但这应该是个例外——因此建议发出警告。
It should, however, be noted that using fingerprint-based authentication over an insecure network increases the security compared to unencrypted MSRP. In order to intercept the plaintext media when fingerprint-based authentication is used, the attacker is required to be present on both the signaling and media paths and actively modify the traffic. It is very hard for the endpoints to detect when such an attack is taking place, though. A client using DTLS-SRTP (a Secure Real-time Transport Protocol (SRTP) extension for Datagram Transport Layer Security (DTLS)) [RFC5764] for Voice over IP (VoIP) media security might wish to use fingerprint-based authentication also for MSRP media security.
但是，应该注意的是，与未加密的MSRP相比，在不安全的网络上使用基于指纹的身份验证提高了安全性。在使用基于指纹的身份验证时，为了拦截明文媒体，攻击者需要同时出现在信令和媒体路径上，并主动修改通信量。不过，端点很难检测到何时发生了此类攻击。使用DTLS-SRTP（用于数据报传输层安全性（DTLS）的安全实时传输协议（SRTP）扩展）[RFC5764]实现IP语音（VoIP）媒体安全的客户端可能也希望使用基于指纹的身份验证实现MSRP媒体安全。
MSRPS with fingerprint-based authentication is vulnerable to attacks due to vulnerabilities in the SIP signaling. If there are weaknesses in the integrity protections on the SIP signaling, an attacker may insert malicious Middleboxes to alter, record, or otherwise harm the media. With insecure signaling, it can be difficult for an endpoint to even be aware that the remote endpoint has any relationship to the expected endpoint. Securing the SIP signaling does not solve all problems. For example, in a SIP Secure (SIPS) environment, the endpoints have no cryptographic way of validating that one or more SIP proxies in the proxy chain are not, in fact, malicious.
由于SIP信令中存在漏洞，具有基于指纹的身份验证的MSRP容易受到攻击。如果SIP信令的完整性保护存在漏洞，攻击者可能会插入恶意的中间盒来更改、记录或以其他方式损坏媒体。对于不安全的信令，端点甚至很难意识到远程端点与预期端点有任何关系。保护SIP信令并不能解决所有问题。例如，在SIP安全（SIPS）环境中，端点没有密码方式来验证代理链中的一个或多个SIP代理实际上不是恶意的。
IANA has added an attribute to the 'att-field (media level only)' registry of the Session Description Protocol (SDP) Parameters registry, according to the information provided in this section.
根据本节提供的信息，IANA已向会话描述协议（SDP）参数注册表的“att字段（仅媒体级别）”注册表添加了一个属性。
This section registers a new SDP attribute, 'msrp-cema'. The required information for this registration, as specified in RFC 4566, is as follows:
本节注册一个新的SDP属性“msrp cema”。RFC 4566中规定的本次注册所需信息如下：
Contact name: Christer Holmberg
联系人姓名：Christer Holmberg
Contact email: christer.holmberg@ericsson.com
联系电子邮件：克里斯特。holmberg@ericsson.com
Attribute name: msrp-cema
属性名称：msrp cema
Type of attribute: media level
属性类型：媒体级别
Purpose: This attribute is used to indicate support of the MSRP Connection Establishment for Media Anchoring (CEMA) extension defined in RFC 6714. When present in an MSRP media description of an SDP body, it indicates that the creator of the SDP supports the CEMA mechanism.
目的：此属性用于表示支持RFC 6714中定义的媒体锚定（CEMA）扩展的MSRP连接建立。当出现在SDP主体的MSRP介质描述中时，表示SDP的创建者支持CEMA机制。
Values: The attribute does not carry a value.
值：属性不带值。
Charset dependency: none
字符集依赖项：无
Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, Ted Hardie, Richard L. Barnes, Inaki Baz Castillo, Saul Ibarra Corretge, Cullen Jennings, Adrian Georgescu, Miguel Garcia, and Paul Kyzivat for their guidance and input in order to produce this document.
感谢Ben Campbell、Remi Denis Courmon、Nancy Greene、Hadriel Kaplan、Adam Roach、Robert Sparks、Salvatore Loreto、Shida Schubert、Ted Hardie、Richard L.Barnes、Inaki Baz Castillo、Saul Ibarra Corretge、Cullen Jennings、Adrian Georgescu、Miguel Garcia和Paul Kyzivat为编制本文件提供的指导和投入。
Thanks to John Mattsson, Oscar Ohlsson, Ben Campbell, and Stephen Farrell for their help in restructuring the Security Considerations section, based on feedback from the IESG.
感谢John Mattsson、Oscar Ohlsson、Ben Campbell和Stephen Farrell根据IESG的反馈帮助重组安全考虑部分。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]Campbell，B.，Ed.，Mahy，R.，Ed.，和C.Jennings，Ed.，“消息会话中继协议（MSRP）”，RFC 49752007年9月。
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007.
[RFC4976]Jennings，C.，Mahy，R.，和A.Roach，“消息会话中继协议（MSRP）的中继扩展”，RFC 49762007年9月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC6072] Jennings, C. and J. Fischl, Ed., "Certificate Management Service for the Session Initiation Protocol (SIP)", RFC 6072, February 2011.
[RFC6072]Jennings，C.和J.Fischl，Ed.，“会话启动协议（SIP）的证书管理服务”，RFC 6072，2011年2月。
[RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)", RFC 6135, February 2011.
[RFC6135]Holmberg，C.和S.Blau，“消息会话中继协议（MSRP）的替代连接模型”，RFC 61352011年2月。
[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004.
[RFC3724]Kempf，J.，Ed.，Austein，R.，Ed.，和IAB，“中部崛起和端到端的未来：互联网架构演变的思考”，RFC 37242004年3月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，RFC 5764，2010年5月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 6043, March 2011.
[RFC6043]Mattsson，J.和T.Tian，“MIKEY-TICKET：多媒体互联网密钥分配（MIKEY）中基于票据的密钥分配模式”，RFC 60432011年3月。
[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 6091, February 2011.
[RFC6091]Mavrogiannopoulos，N.和D.Gillmor，“使用OpenPGP密钥进行传输层安全（TLS）认证”，RFC 60912011年2月。
[GPP23228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 11.5.0, June 2012, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
[GPP23228]3GPP，“IP多媒体子系统（IMS）；第2阶段”，3GPP TS 23.228 11.5.01212年6月<http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
[DANE] "DNS-Based Authentication of Named Entities (DANE) Working Group", <https://datatracker.ietf.org/wg/dane/charter/>.
[DANE]“基于DNS的命名实体认证（DANE）工作组”<https://datatracker.ietf.org/wg/dane/charter/>.
Authors' Addresses
作者地址
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: christer.holmberg@ericsson.com
EMail: christer.holmberg@ericsson.com
Staffan Blau Ericsson Stockholm 12637 Sweden
斯塔凡·布劳·爱立信斯德哥尔摩12637瑞典
EMail: staffan.blau@ericsson.com
EMail: staffan.blau@ericsson.com
Eric Burger Georgetown University Department of Computer Science 37th and O Streets, NW Washington, DC 20057-1232 United States of America
Eric Burger乔治敦大学计算机科学系美国华盛顿特区西北37街和O街，20057-1232
Fax: +1 530 267 7447
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
Fax: +1 530 267 7447
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com