Network Working Group J. Walker
Request for Comments: 4261 A. Kulkarni, Ed.
Updates: 2748 Intel Corp.
Category: Standards Track December 2005
Network Working Group J. Walker
Request for Comments: 4261 A. Kulkarni, Ed.
Updates: 2748 Intel Corp.
Category: Standards Track December 2005
Common Open Policy Service (COPS) Over Transport Layer Security (TLS)
传输层安全（TLS）上的公共开放策略服务（COPS）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet.
本文档介绍如何使用传输层安全性（TLS）来保护Internet上的公共开放策略服务（COPS）连接。
This document also updates RFC 2748 by modifying the contents of the Client-Accept message.
本文档还通过修改客户机接受消息的内容来更新RFC 2748。
Table Of Contents
目录
1. Introduction ....................................................2
2. COPS Over TLS ...................................................3
3. Separate Ports versus Upward Negotiation ........................3
4. COPS/TLS Objects and Error codes ................................4
4.1. The TLS Message Integrity Object (Integrity-TLS) ...........4
4.2. Error Codes ................................................4
5. COPS/TLS Secure Connection Initiation ...........................5
5.1. PEP Initiated Security Negotiation .........................5
5.2. PDP Initiated Security Negotiation .........................6
6. Connection Closure ..............................................7
6.1. PEP System Behavior ........................................7
6.2. PDP System Behavior ........................................8
7. Endpoint Identification and Access Control ......................8
7.1. PEP Identity ...............................................9
7.2. PDP Identity ...............................................9
8. Cipher Suite Requirements ......................................10
9. Backward Compatibility .........................................10
10. IANA Considerations ...........................................10
11. Security Considerations .......................................11
12. Acknowledgements ..............................................11
13. References ....................................................12
13.1. Normative References .....................................12
13.2. Informative References ...................................12
1. Introduction ....................................................2
2. COPS Over TLS ...................................................3
3. Separate Ports versus Upward Negotiation ........................3
4. COPS/TLS Objects and Error codes ................................4
4.1. The TLS Message Integrity Object (Integrity-TLS) ...........4
4.2. Error Codes ................................................4
5. COPS/TLS Secure Connection Initiation ...........................5
5.1. PEP Initiated Security Negotiation .........................5
5.2. PDP Initiated Security Negotiation .........................6
6. Connection Closure ..............................................7
6.1. PEP System Behavior ........................................7
6.2. PDP System Behavior ........................................8
7. Endpoint Identification and Access Control ......................8
7.1. PEP Identity ...............................................9
7.2. PDP Identity ...............................................9
8. Cipher Suite Requirements ......................................10
9. Backward Compatibility .........................................10
10. IANA Considerations ...........................................10
11. Security Considerations .......................................11
12. Acknowledgements ..............................................11
13. References ....................................................12
13.1. Normative References .....................................12
13.2. Informative References ...................................12
COPS [RFC2748] was designed to distribute clear-text policy information from a centralized Policy Decision Point (PDP) to a set of Policy Enforcement Points (PEP) in the Internet. COPS provides its own security mechanisms to protect the per-hop integrity of the deployed policy. However, the use of COPS for sensitive applications (e.g., some types of security policy distribution) requires additional security measures, such as data confidentiality. This is because some organizations find it necessary to hide some or all of their security policies, e.g., because policy distribution to devices such as mobile platforms can cross domain boundaries.
COPS[RFC2748]设计用于将明文策略信息从集中策略决策点（PDP）分发到Internet上的一组策略执行点（PEP）。COPS提供了自己的安全机制来保护已部署策略的每跳完整性。但是，对敏感应用程序（例如，某些类型的安全策略分发）使用COP需要额外的安全措施，例如数据保密性。这是因为一些组织发现有必要隐藏其部分或全部安全策略，例如，因为向移动平台等设备分发的策略可以跨越域边界。
TLS [RFC2246] was designed to provide channel-oriented security. TLS standardizes SSL and may be used with any connection-oriented service. TLS provides mechanisms for both one- and two-way authentication, dynamic session keying, and data stream privacy and integrity.
TLS[RFC2246]旨在提供面向通道的安全性。TLS标准化了SSL，可用于任何面向连接的服务。TLS为单向和双向身份验证、动态会话密钥以及数据流隐私和完整性提供了机制。
This document describes how to use COPS over TLS. "COPS over TLS" is abbreviated COPS/TLS.
本文档描述了如何通过TLS使用COPS。“TLS上的警察”缩写为COPS/TLS。
Glossary
术语汇编
COPS - Common Open Policy Service. See [RFC2748].
共同开放政策服务。见[RFC2748]。
COPS/TCP - A plain-vanilla implementation of COPS.
COPS/TCP——一种简单的COPS实现。
COPS/TLS - A secure implementation of COPS using TLS.
COPS/TLS-使用TLS安全实现COPS。
PDP - Policy Decision Point. Also referred to as the Policy Server. See [RFC2753].
PDP——政策决策点。也称为策略服务器。见[RFC2753]。
PEP - Policy Enforcement Point. Also referred to as the Policy Client. See [RFC2753].
政治公众人物-政策执行点。也称为策略客户端。见[RFC2753]。
Conventions used in this document
本文件中使用的公约
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
COPS/TLS is very simple: use COPS over TLS similar to how you would use COPS over TCP (COPS/TCP). Apart from a specific procedure used to initialize the connection, there is no difference between COPS/TLS and COPS/TCP.
COPS/TLS非常简单：在TLS上使用COPS，类似于在TCP上使用COPS（COPS/TCP）。除了用于初始化连接的特定过程外，COPS/TLS和COPS/TCP之间没有区别。
There are two ways in which insecure and secure versions of the same protocol can be run simultaneously.
有两种方法可以同时运行同一协议的不安全版本和安全版本。
In the first method, the secure version of the protocol is also allocated a well-known port. This strategy of having well-known port numbers for both, the secure and insecure versions, is known as 'Separate Ports'. The clients requiring security can simply connect to the well-known secure port. This method is easy to implement, with no modifications needed to existing insecure implementations. The disadvantage, however, is that it doesn't scale well, because a new port is required for each secure implementation. More problems with this approach have been listed in [RFC2595].
在第一种方法中，还为协议的安全版本分配了一个已知端口。这种为安全和不安全版本都提供已知端口号的策略称为“单独端口”。需要安全性的客户端可以简单地连接到众所周知的安全端口。此方法易于实现，无需修改现有的不安全实现。然而，缺点是它不能很好地扩展，因为每个安全实现都需要一个新端口。[RFC2595]中列出了此方法的更多问题。
The second method is known as 'Upward Negotiation'. In this method, the secure and insecure versions of the protocol run on the same port. The client connects to the server, both discover each others' capabilities, and start security negotiations if desired. This method usually requires some changes to the protocol being secured.
第二种方法称为“向上协商”。在此方法中，协议的安全版本和不安全版本在同一端口上运行。客户端连接到服务器，发现彼此的功能，并根据需要启动安全协商。此方法通常需要对受保护的协议进行一些更改。
In view of the many issues with the Separate Ports approach, the authors have decided to use the Upward Negotiation method for COPS/TLS.
鉴于单独端口方法存在许多问题，作者决定对COPS/TLS使用向上协商方法。
This section describes the COPS objects and error codes needed to support COPS/TLS.
本节介绍支持COPS/TLS所需的COPS对象和错误代码。
The TLS Integrity object is used by the PDP and the PEP to start the TLS negotiation. This object should be included only in the Client-Open or Client-Accept messages. It MUST NOT be included in any other COPS message.
PDP和PEP使用TLS完整性对象启动TLS协商。此对象应仅包含在客户端打开或客户端接受消息中。不得将其包含在任何其他警察信息中。
0 1 2 3
0 1 2 3
+----------+----------+----------+----------+
| Length (Octets) | C-Num=16 | C-Type=2 |
+----------+----------+----------+----------+
| //////// | Flags |
+----------+----------+----------+----------+
+----------+----------+----------+----------+
| Length (Octets) | C-Num=16 | C-Type=2 |
+----------+----------+----------+----------+
| //////// | Flags |
+----------+----------+----------+----------+
Note: //// implies the field is reserved, set to 0, and should be ignored on receipt.
注意：///表示该字段为保留字段，设置为0，在收到时应忽略该字段。
Flags: 16 bits 0x01 = StartTLS This flag indicates that the sender of the message wishes to initiate a TLS handshake.
标志：16位0x01=StartTLS此标志表示消息发送方希望启动TLS握手。
The Client-Type of any message containing this object MUST be 0. Client-Type 0 is used to negotiate COPS connection level security and must only be used during the connection establishment phase. Please refer to section 4.1 of [RFC2748] for more details.
包含此对象的任何消息的客户端类型必须为0。客户端类型0用于协商COPS连接级别安全性，并且只能在连接建立阶段使用。更多详情请参考[RFC2748]第4.1节。
This section uses the error codes described in section 2.2.8 (Error Object) of [RFC2748].
本节使用[RFC2748]第2.2.8节（错误对象）中描述的错误代码。
Error Code: 13= Unknown COPS Object:
错误代码：13=未知的COPS对象：
Sub-code (octet 2) contains the unknown object's C-Num, and (octet 3) contains unknown object's C-Type. If the PEP or PDP does not support TLS, the C-Num specified MUST be 16 and the C-Type MUST be 2. This demonstrates that the TLS version of the Integrity object is not known.
子代码（八位组2）包含未知对象的C-Num，而（八位组3）包含未知对象的C-Type。如果PEP或PDP不支持TLS，则指定的C-Num必须为16，C-Type必须为2。这表明Integrity对象的TLS版本未知。
This error code MUST be used by either PEP or PDP to indicate a security-related connection closure if it cannot support a TLS connection for the COPS protocol.
如果PEP或PDP不能支持COPS协议的TLS连接，则必须使用此错误代码指示安全相关连接关闭。
If the PDP wishes to negotiate a different security mechanism than requested by the PEP in the Client-Open, it MUST send the following error code:
如果PDP希望协商不同于PEP在客户端打开中请求的安全机制，则必须发送以下错误代码：
Error Code: 15= Authentication Required
错误代码：15=需要身份验证
Where the Sub-code (octet 2) contains the C-Num=16 value for the Integrity Object and (octet 3) MUST specify the PDP required/preferred Integrity object C-Type. If the server does not support any form of COPS-Security, it MUST set the Sub-code (octet 2) to 16 and (octet 3) to zero instead, signifying that no type of the Integrity object is supported.
其中子代码（八位字节2）包含完整性对象的C-Num=16值，并且（八位字节3）必须指定PDP要求/首选完整性对象C-Type。如果服务器不支持任何形式的COPS安全性，则必须将子代码（八位字节2）设置为16，将子代码（八位字节3）设置为零，表示不支持任何类型的完整性对象。
Security negotiation may be initiated by either the PDP or the PEP. The PEP can initiate a negotiation via a Client-Open message, while a PDP can initiate a negotiation via a Client-Accept message.
安全协商可由PDP或政治公众人物发起。PEP可以通过客户端开放消息发起协商，而PDP可以通过客户端接受消息发起协商。
Once the TLS connection is established, all COPS data MUST be sent as TLS "application data".
一旦TLS连接建立，所有COPS数据必须作为TLS“应用程序数据”发送。
A PEP MAY initiate a TLS security negotiation with a PDP using the Client-Open message. To do this, the Client-Open message MUST have a Client-Type of 0 and MUST include the Integrity-TLS object.
PEP可以使用客户端打开消息与PDP发起TLS安全协商。为此，客户端打开消息的客户端类型必须为0，并且必须包含Integrity TLS对象。
Upon receiving the Client-Open message, the PDP SHOULD respond with a Client-Accept message containing the Integrity-TLS object.
收到客户机打开消息后，PDP应使用包含Integrity TLS对象的客户机接受消息进行响应。
Note that in order to carry the Integrity-TLS object, the contents of the Client-Accept message defined in section 3.7 of [RFC2748] need not change, except that the C-Type of the integrity object contained there-in should now be C-Type=2. For Example:
请注意，为了携带Integrity TLS对象，不需要更改[RFC2748]第3.7节中定义的Client Accept消息的内容，但其中包含的Integrity对象的C-Type现在应为C-Type=2。例如：
<Client-Accept> ::= <Common Header>
<KA Timer>
[<ACCT Timer>]
[<Integrity (C-Num=16, C-Type=2)>]
<Client-Accept> ::= <Common Header>
<KA Timer>
[<ACCT Timer>]
[<Integrity (C-Num=16, C-Type=2)>]
Note also that this new format of the Client-Accept message does not replace or obsolete the existing Client-Accept message format, which can continue to be used for non-secure COPS session negotiations.
还请注意，此新的客户端接受消息格式不会取代或废弃现有的客户端接受消息格式，该格式可继续用于非安全的COPS会话协商。
Upon receiving the appropriate Client-Accept message, the PEP SHOULD initiate the TLS handshake.
在收到适当的客户端接受消息后，PEP应启动TLS握手。
The message exchange is as follows:
消息交换如下：
C: Client-Open (Client-Type = 0, Integrity-TLS)
S: Client-Accept (Client-Type = 0, Integrity-TLS)
<TLS handshake>
C/S: <...further messages...>
C: Client-Open (Client-Type = 0, Integrity-TLS)
S: Client-Accept (Client-Type = 0, Integrity-TLS)
<TLS handshake>
C/S: <...further messages...>
In case the PDP does not wish to open a secure connection with the PEP, it MUST reply with a Client-Close message and close the connection. The Client-Close message MUST include the error code 15= Authentication required, with the Sub-code (octet 2) set to 16 for the Integrity object's C-Num, and (octet 3) set to the C-Type corresponding to the server's preferred Integrity type, or zero for no security.
如果PDP不希望打开与PEP的安全连接，则必须回复客户端关闭消息并关闭连接。客户端关闭消息必须包括错误代码15=需要身份验证，子代码（八位组2）设置为16表示完整性对象的C-Num，并且（八位组3）设置为与服务器首选完整性类型对应的C-Type，或者零表示无安全性。
A PEP requiring the Integrity-TLS object in a Client-Accept message MUST close the connection if the Integrity-TLS object is missing. The ensuing Client-Close message MUST include the error code 15= Authentication required, with the Sub-code (octet 2) containing the required Integrity object's C-Num=16, and (octet 3) containing the required Integrity object's C-Type=2.
如果缺少Integrity TLS对象，则在客户端接受消息中需要Integrity TLS对象的PEP必须关闭连接。随后的客户端关闭消息必须包括错误代码15=需要验证，子代码（八位字节2）包含所需完整性对象的C-Num=16，并且（八位字节3）包含所需完整性对象的C-Type=2。
The PEP initially opens a TCP connection with the PDP on the standard COPS port and sends a Client-Open message. This Client-Open message MUST have a Client-Type of 0.
PEP最初在标准COPS端口上打开与PDP的TCP连接，并发送客户端打开消息。此客户端打开消息的客户端类型必须为0。
The PDP SHOULD then reply with a Client-Accept message. In order to signal the PEP to start the TLS handshake, the PDP MUST include the Integrity-TLS object in the Client-Accept message.
PDP随后应回复客户机接受消息。为了向PEP发出启动TLS握手的信号，PDP必须在客户端接受消息中包含Integrity TLS对象。
Upon receiving the Client-Accept message with the Integrity-TLS object, the PEP SHOULD initiate the TLS handshake. If for any reason the PEP cannot initiate the handshake, it MUST close the connection.
在接收到带有Integrity TLS对象的Client Accept消息后，PEP应启动TLS握手。如果由于任何原因PEP无法启动握手，则必须关闭连接。
The message exchange is as follows:
消息交换如下：
C: Client-Open (Client-Type = 0)
S: Client-Accept (Client-Type = 0, Integrity-TLS)
<TLS handshake>
C/S: <...further messages...>
C: Client-Open (Client-Type = 0)
S: Client-Accept (Client-Type = 0, Integrity-TLS)
<TLS handshake>
C/S: <...further messages...>
After receiving the Client-Accept, the PEP MUST NOT send any messages until the TLS handshake is complete. Upon receiving any message from the PEP before the TLS handshake starts, the PDP MUST issue a Client-Close message with an error code 15= Authentication Required.
在接收到客户端Accept后，PEP不得发送任何消息，直到TLS握手完成。在TLS握手开始前收到PEP的任何消息后，PDP必须发出一条客户端关闭消息，错误代码为15=需要认证。
A PDP wishing to negotiate security with a PEP having an existing non-secure connection MUST send a Client-Close with the error code 15= Authentication required, with the Sub-code (octet 2) containing the required Integrity object's C-Num=16, and (octet 3) containing the required Integrity object's C-Type=2, and then wait for the PEP to reconnect. Upon receiving the Client-Open message, it SHOULD use the Client-Accept message to initiate security negotiation.
希望与具有现有非安全连接的PEP协商安全性的PDP必须发送一个客户端Close，错误代码为15=需要验证，子代码（八位组2）包含所需完整性对象的C-Num=16，并且（八位组3）包含所需完整性对象的C-Type=2，然后等待政治公众人物重新连接。在收到客户机打开消息后，它应该使用客户机接受消息来启动安全协商。
TLS provides facilities to securely close its connections. Reception of a valid closure alert assures an implementation that no further data will arrive on that connection. The TLS specification requires TLS implementations to initiate a closure alert exchange before closing a connection. It also permits TLS implementations to close connections without waiting to receive closure alerts from the peer, provided they send their own first. A connection closed in this way is known as an "incomplete close". TLS allows implementations to reuse the session in this case, but COPS/TLS makes no use of this capability.
TLS提供安全关闭其连接的设施。接收到有效的关闭警报可确保实现不会收到该连接上的进一步数据。TLS规范要求TLS实现在关闭连接之前启动关闭警报交换。它还允许TLS实现在不等待从对等方接收关闭警报的情况下关闭连接，前提是它们先发送自己的关闭警报。以这种方式关闭的连接称为“不完全关闭”。在这种情况下，TLS允许实现重用会话，但COPS/TLS没有使用此功能。
A connection closed without first sending a closure alert is known as a "premature close". Note that a premature close does not call into question the security of the data already received, but simply indicates that subsequent data might have been truncated. Because TLS is oblivious to COPS message boundaries, it is necessary to examine the COPS data itself (specifically the Message header) to determine whether truncation occurred.
未首先发送关闭警报而关闭的连接称为“过早关闭”。请注意，过早关闭不会对已接收数据的安全性产生疑问，而只是表示后续数据可能已被截断。因为TLS不知道COPS消息边界，所以有必要检查COPS数据本身（特别是消息头），以确定是否发生了截断。
PEP implementations MUST treat premature closes as errors and any data received as potentially truncated. The COPS protocol allows the PEP system to find out whether truncation took place. A PEP system detecting an incomplete close SHOULD recover gracefully.
PEP实施必须将过早关闭视为错误，接收到的任何数据都可能被截断。COPS协议允许PEP系统查明是否发生了截断。如果政治公众人物系统检测到未完成交割，则应正常恢复。
PEP systems SHOULD send a closure alert before closing the connection. PEPs unprepared to receive any more data MAY choose not to wait for the PDP system's closure alert and simply close the connection, thus generating an incomplete close on the PDP side.
PEP系统应在关闭连接之前发送关闭警报。未准备好接收更多数据的PEP可以选择不等待PDP系统的关闭警报，而只是关闭连接，从而在PDP端生成不完全关闭。
COPS permits a PEP to close the connection at any time, and requires PDPs to recover gracefully. In particular, PDPs SHOULD be prepared to receive an incomplete close from the PEP, since a PEP often shuts down for operational reasons unrelated to the transfer of policy information between the PEP and PDP.
COPS允许PEP随时关闭连接，并要求PDP正常恢复。特别是，由于政治公众人物经常因与政治公众人物和PDP之间的政策信息传输无关的运营原因而关闭，因此，PDP应做好接收政治公众人物不完全关闭的准备。
Implementation note: The PDP ordinarily expects to be able to signal the end of data by closing the connection. However, the PEP may have already sent the closure alert and dropped the connection.
实施说明：PDP通常希望能够通过关闭连接来发出数据结束的信号。但是，PEP可能已经发送了关闭警报并断开了连接。
PDP systems MUST attempt to initiate an exchange of closure alerts with the PEP system before closing the connection. PDP systems MAY close the connection after sending the closure alert, thus generating an incomplete close on the PEP side.
PDP系统必须在关闭连接之前尝试与PEP系统交换关闭警报。PDP系统可在发送关闭警报后关闭连接，从而在PEP端生成不完全关闭。
All PEP implementations of COPS/TLS MUST support an access control mechanism to identify authorized PDPs. This requirement provides a level of assurance that the policy arriving at the PEP is actually valid. PEP deployments SHOULD require the use of this access control mechanism for operation of COPS over TLS. When access control is enabled, the PEP implementation MUST NOT initiate COPS/TLS connections to systems not authorized as PDPs by the access control mechanism.
COP/TLS的所有PEP实施必须支持访问控制机制，以识别授权的PDP。这一要求提供了一定程度的保证，即政治公众人物收到的政策实际上是有效的。PEP部署应要求使用此访问控制机制来通过TLS运行COP。启用访问控制后，PEP实施不得启动与未经访问控制机制授权为PDP的系统的COP/TLS连接。
Similarly, PDP COPS/TLS implementations MUST support an access control mechanism permitting them to restrict their services to authorized PEP systems only. However, deployments MAY choose not to use an access control mechanism at the PDP, as organizations might not consider the types of policy being deployed as sensitive, and therefore do not need to incur the expense of managing credentials for the PEP systems. If access controls are used, however, the PDP implementation MUST terminate COPS/TLS connections from unauthorized PEP systems and log an error if an auditable logging mechanism is present.
类似地，PDP COP/TLS实现必须支持访问控制机制，允许它们将其服务仅限于授权的PEP系统。然而，部署可能不选择在PDP上使用访问控制机制，因为组织可能不认为部署的策略类型是敏感的，因此不必花费管理PEP系统的凭证的费用。但是，如果使用访问控制，PDP实施必须终止来自未经授权PEP系统的COPS/TLS连接，并在存在可审计日志机制的情况下记录错误。
Implementations of COPS/TLS MUST use X.509 v3 certificates conforming to [RFC3280] to identify PDP and PEP systems. COPS/TLS systems MUST perform certificate verification processing conforming to [RFC3280].
COP/TLS的实施必须使用符合[RFC3280]的X.509 v3证书来识别PDP和PEP系统。COPS/TLS系统必须执行符合[RFC3280]的证书验证处理。
If a subjectAltName extension of type dNSName or iPAddress is present in the PDP's certificate, it MUST be used as the PDP identity. If both types are present, dNSName SHOULD be used as the PDP identity. If neither type is present, the most specific Common Name field in the Subject field of the certificate SHOULD be used.
如果PDP证书中存在dNSName或iPAddress类型的subjectAltName扩展名，则必须将其用作PDP标识。如果两种类型都存在，则应将dNSName用作PDP标识。如果两种类型都不存在，则应使用证书主题字段中最具体的通用名称字段。
Matching is performed using the matching rules specified by [RFC3280]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName in the subjectAltName certificate extension), a match in any one of the provided identities is acceptable. Generally, the COPS system uses the first name for matching, except as noted below in the IP address checking requirements.
使用[RFC3280]指定的匹配规则执行匹配。如果证书中存在给定类型的多个标识（例如subjectAltName证书扩展中存在多个dNSName），则可以接受提供的任何一个标识中的匹配。通常，COPS系统使用第一个名称进行匹配，除非IP地址检查要求中有以下说明。
When PEP systems are not access controlled, the PDP does not need external knowledge of what the PEP's identity ought to be and so checks are neither possible nor necessary. In this case, there is no requirement for PEP systems to register with a certificate authority, and COPS over TLS uses one-way authentication, of the PDP to the PEP.
当政治公众人物系统不受访问控制时，PDP不需要外界知道政治公众人物的身份应该是什么，因此检查既不可能也不必要。在这种情况下，不要求PEP系统向证书颁发机构注册，而TLS上的COPS使用PDP对PEP的单向身份验证。
When PEP systems are access controlled, PEPs MUST be the subjects of end entity certificates [RFC3280]. In this case, COPS over TLS uses two-way authentication, and the PDP MUST perform the same identity checks for the PEPs as described above for the PDP.
当PEP系统受访问控制时，PEP必须是终端实体证书的主体[RFC3280]。在这种情况下，TLS上的COPS使用双向身份验证，PDP必须对PEP执行与上述PDP相同的身份检查。
When access controls are in effect at the PDP, PDP implementations MUST have a mechanism to securely acquire the trust anchor for each authorized Certification Authority (CA) that issues certificates to supported PEPs.
当访问控制在PDP上生效时，PDP实施必须具有一种机制，以安全地获取向受支持的PEP颁发证书的每个授权证书颁发机构（CA）的信任锚。
Generally, COPS/TLS requests are generated by the PEP consulting bootstrap policy information that identifies PDPs that the PEP is authorized to connect to. This policy provides the PEP with the hostname or IP address of the PDP. How this bootstrap policy information arrives at the PEP is outside the scope of this document. However, all PEP implementations MUST provide a mechanism to securely deliver or configure the bootstrap policy.
通常，COP/TLS请求由PEP咨询引导策略信息生成，该信息标识PEP有权连接的PDP。此策略为PEP提供PDP的主机名或IP地址。此引导策略信息如何到达政治公众人物不在本文档范围内。但是，所有PEP实现必须提供一种机制来安全地交付或配置引导策略。
All PEP implementations MUST be able to securely acquire the trust anchor for each authorized Certification Authority (CA) that issues PDP certificates. Also, the PEPs MUST support a mechanism to securely acquire an access control list (ACL) or filter identifying the set of authorized PDPs associated with each CA. Deployments must take care to avoid circular dependencies in accessing trust anchors
所有PEP实现都必须能够安全地获取每个颁发PDP证书的授权证书颁发机构（CA）的信任锚。此外，PEP必须支持安全获取访问控制列表（ACL）或过滤器的机制，以识别与每个CA关联的授权PDP集。部署必须注意避免访问信任锚中的循环依赖
and ACLs. At a minimum, trust anchors and ACLs may be installed manually.
和ACL。信任锚和ACL至少可以手动安装。
PEP deployments that participate in multiple domains, such as those on mobile platforms, MAY use different CAs and access control lists in each domain.
参与多个域（如移动平台上的域）的PEP部署可能在每个域中使用不同的CA和访问控制列表。
If the PDP hostname or IP address is available via the bootstrap policy, the PEP MUST check it against the PDP's identity as presented in the PDP's TLS Certificate message.
如果PDP主机名或IP地址通过引导策略可用，则PEP必须根据PDP的TLS证书消息中显示的PDP身份进行检查。
In some cases, the bootstrap policy will identify the authorized PDP only by an IP address of the PDP system. In this case, the subjectAltName MUST be present in the certificate, and it MUST include an iPAddress format matching the expected name of the policy server.
在某些情况下，引导策略将仅通过PDP系统的IP地址识别授权PDP。在这种情况下，subjectAltName必须出现在证书中，并且必须包含与策略服务器的预期名称匹配的iPAddress格式。
If the hostname of the PDP does not match the identity in the certificate, a PEP on a user-oriented system MUST either notify the user (PEP systems MAY afford the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. PEPs on unattended systems MUST log the error to an appropriate audit log (if available) and MUST terminate the connection with a bad certificate error. Unattended PEP systems MAY provide a configuration setting that disables this check, but then MUST provide a setting that enables it.
如果PDP的主机名与证书中的标识不匹配，则面向用户的系统上的PEP必须通知用户（PEP系统在任何情况下都可以为用户提供继续连接的机会）或使用错误的证书终止连接。无人值守系统上的PEP必须将错误记录到适当的审核日志（如果可用）中，并且必须使用错误证书终止连接。无人值守PEP系统可提供禁用此检查的配置设置，但必须提供启用此检查的设置。
Implementations MUST support the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite. All other cipher suites are optional.
实施必须支持TLS\U RSA\U和\U 3DES\U EDE\U CBC\U SHA密码套件。所有其他密码套件都是可选的。
The PEP and PDP SHOULD be backward compatible with peers that have not been modified to support COPS/TLS. They SHOULD handle errors generated in response to the Integrity-TLS object.
PEP和PDP应与尚未修改以支持COP/TLS的对等机向后兼容。它们应该处理响应Integrity TLS对象而生成的错误。
The IANA has added the following C-Num, C-Type combination for the Integrity-TLS object to the registry at http://www.iana.org/assignments/cops-parameters:
IANA已将Integrity TLS对象的以下C-Num、C-Type组合添加到位于的注册表中http://www.iana.org/assignments/cops-parameters:
0x10 0x02 Message Integrity, Integrity-TLS [RFC4261]
0x10 0x02消息完整性，完整性TLS[RFC4261]
For Client-Type 0, the IANA has added the following Flags value for the Integrity-TLS object:
对于客户端类型0，IANA为Integrity TLS对象添加了以下标志值：
0x01 = StartTLS
0x01 = StartTLS
Further, for Client-Type 0, the IANA has added the following text for Error Sub-Codes:
此外，对于客户端类型0，IANA为错误子代码添加了以下文本：
Error Code: 15 Error Sub-Code: Octet 2: C-Num of the Integrity object Octet 3: C-Type of the supported/preferred Integrity object or Zero.
错误代码：15错误子代码：八位字节2：完整性对象的C-Num八位字节3：支持/首选完整性对象的C-Type或零。
Error-Code Error-SubCode Description
Octet 2 Octet 3
---------------------------------------------------
15 16 0 No security
15 16 2 Integrity-TLS supported/preferred
Error-Code Error-SubCode Description
Octet 2 Octet 3
---------------------------------------------------
15 16 0 No security
15 16 2 Integrity-TLS supported/preferred
Further values for the Flags field and the reserved field can only be assigned by IETF Consensus rule, as defined in [RFC2434].
根据[RFC2434]中的定义，标志字段和保留字段的其他值只能由IETF一致性规则分配。
A COPS PDP and PEP MUST check the results of the TLS negotiation to see whether an acceptable degree of authentication and privacy have been achieved. If the negotiation has resulted in unacceptable algorithms or key lengths, either side MAY choose to terminate the connection.
COPS PDP和PEP必须检查TLS协商的结果，以确定是否已达到可接受的身份验证和隐私程度。如果协商导致不可接受的算法或密钥长度，任何一方都可以选择终止连接。
A man-in-the-middle attack can be launched by deleting the Integrity-TLS object or altering the Client-Open or Client-Accept messages. If security is required, the PEP and PDP bootstrap policy must specify this, and PEP and PDP implementations should reject Client-Open or Client-Accept messages that fail to include an Integrity-TLS object.
中间人攻击可以通过删除Integrity TLS对象或更改客户端打开或客户端接受消息来发起。如果需要安全性，PEP和PDP引导策略必须对此进行指定，PEP和PDP实施应拒绝客户端打开或客户端接受未包含完整性TLS对象的消息。
This document freely plagiarizes and adapts Eric Rescorla's similar document [RFC2818] that specifies how HTTP runs over TLS.
本文档免费抄袭并改编了Eric Rescorla的类似文档[RFC2818]，该文档指定了HTTP如何在TLS上运行。
Discussions with David Durham, Scott Hahn, and Ylian Sainte-Hillaire also lead to improvements in this document.
与David Durham、Scott Hahn和Ylian Sainte Hillaire的讨论也导致了本文档的改进。
The authors wish to thank Uri Blumenthal for doing a thorough security review of the document.
作者希望感谢Uri Blumenthal对文档进行了彻底的安全审查。
[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月。
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[RFC2748]达勒姆，D.，博伊尔，J.，科恩，R.，赫尔佐格，S.，拉詹，R.，和A.萨斯特里，“共同开放政策服务协议”，RFC 27482000年1月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753]Yavatkar，R.，Pendarakis，D.，和R.Guerin，“基于政策的准入控制框架”，RFC 2753，2000年1月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC2595]Newman，C.，“将TLS与IMAP、POP3和ACAP一起使用”，RFC2595，1999年6月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
Authors' Addresses
作者地址
Amol Kulkarni Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97214 USA
阿莫尔·库尔卡尼英特尔公司美国希尔斯堡第25大道东北2111号，邮编：97214
EMail: amol.kulkarni@intel.com
EMail: amol.kulkarni@intel.com
Jesse R. Walker Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97214 USA
杰西·R·沃克英特尔公司2111美国希尔斯伯勒东北25大道2111号，邮编：97214
EMail: jesse.walker@intel.com
EMail: jesse.walker@intel.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。