RFC3261: SIP:26.4.2 S/MIME

26.4.2 S/MIME

   The largest outstanding defect with the S/MIME mechanism is the lack of a prevalent public key infrastructure for end users.  If self-signed certificates (or certificates that cannot be verified by one of the participants in a dialog) are used, the SIP-based key exchange mechanism described in Section 23.2 is susceptible to a man-in-the-middle attack with which an attacker can potentially inspect and modify S/MIME bodies.  The attacker needs to intercept the first exchange of keys between the two parties in a dialog, remove the existing CMS-detached signatures from the request and response, and insert a different CMS-detached signature containing a certificate supplied by the attacker (but which seems to be a certificate for the proper address-of-record).  Each party will think they have exchanged keys with the other, when in fact each has the public key of the attacker.

​S/MIME机制最大的突出缺陷是缺乏适用于最终用户的通用公钥基础设施。如果使用自签名证书（或无法由对话中的一个参与者验证的证书），则第23.2节中描述的基于SIP的密钥交换机制容易受到中间人攻击，攻击者可以利用该攻击来检查和修改S/MIME主体。攻击者需要截获对话中双方之间的第一次密钥交换，从请求和响应中删除现有的CMS分离签名，并插入一个包含攻击者提供的证书（但似乎是正确记录地址的证书）的不同CMS分离签名。每一方都会认为他们已经与另一方交换了密钥，而事实上每个人都拥有攻击者的公钥。

   It is important to note that the attacker can only leverage this vulnerability on the first exchange of keys between two parties - on subsequent occasions, the alteration of the key would be noticeable to the UAs.  It would also be difficult for the attacker to remain in the path of all future dialogs between the two parties over time (as potentially days, weeks, or years pass).

需要注意的是，攻击者只能在双方首次交换密钥时利用此漏洞，在随后的情况下，密钥的更改对UA来说是显而易见的。随着时间的推移（可能几天、几周或几年后），攻击者也很难继续参与双方未来的所有对话。

   SSH is susceptible to the same man-in-the-middle attack on the first exchange of keys; however, it is widely acknowledged that while SSH is not perfect, it does improve the security of connections.  The use of key fingerprints could provide some assistance to SIP, just as it does for SSH.  For example, if two parties use SIP to establish a voice communications session, each could read off the fingerprint of the key they received from the other, which could be compared against the original.  It would certainly be more difficult for the man-in-the-middle to emulate the voices of the participants than their signaling (a practice that was used with the Clipper chip-based secure telephone).

SSH在第一次密钥交换时容易受到相同的中间人攻击；然而，人们普遍认为，虽然SSH并不完美，但它确实提高了连接的安全性。密钥指纹的使用可以为SIP提供一些帮助，就像SSH一样。例如，如果双方使用SIP来建立语音通信会话，则双方都可以读取他们从另一方接收的密钥的指纹，并将其与原始密钥进行比较。中间人模仿参与者的声音肯定比他们的信号更困难（Clipper基于芯片的安全电话使用了这种做法）。

   The S/MIME mechanism allows UAs to send encrypted requests without preamble if they possess a certificate for the destination address-of-record on their keyring.  However, it is possible that any particular device registered for an address-of-record will not hold the certificate that has been previously employed by the device's current user, and that it will therefore be unable to process an encrypted request properly, which could lead to some avoidable error signaling.  This is especially likely when an encrypted request is forked.

S/MIME机制允许UA在其密钥环上拥有记录目的地址的证书的情况下发送不带前导码的加密请求。然而，任何为记录地址注册的特定设备都可能不持有该设备当前用户以前使用的证书，因此，它将无法正确处理加密的请求，这可能导致一些可以避免的错误信号。当加密请求被分叉时，这种情况尤其可能发生。

   The keys associated with S/MIME are most useful when associated with a particular user (an address-of-record) rather than a device (a UA). When users move between devices, it may be difficult to transport private keys securely between UAs; how such keys might be acquired by a device is outside the scope of this document.

与S/MIME相关联的密钥在与特定用户（记录地址）而不是设备（UA）相关联时最有用。当用户在设备之间移动时，可能很难在UA之间安全地传输私钥；设备如何获取此类密钥不在本文档的范围内。

   Another, more prosaic difficulty with the S/MIME mechanism is that it can result in very large messages, especially when the SIP tunneling mechanism described in Section 23.4 is used.  For that reason, it is RECOMMENDED that TCP should be used as a transport protocol when S/MIME tunneling is employed.

​S/MIME机制的另一个更普通的困难是，它可能会导致非常大的消息，尤其是当使用第23.4节中描述的SIP隧道机制时。因此，建议在使用S/MIME隧道时将TCP用作传输协议。