[要約] RFC 4261は、COPSプロトコルをTLS上で使用するための仕様です。目的は、ネットワークポリシーの管理と制御を強化し、セキュリティを向上させることです。
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).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet.
このドキュメントでは、Transport Layer Security（TLS）を使用して、インターネット上の一般的なオープンポリシーサービス（COPS）接続を確保する方法について説明します。
This document also updates RFC 2748 by modifying the contents of the Client-Accept message.
このドキュメントは、クライアントacceptメッセージの内容を変更することにより、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
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）から一連のポリシー執行ポイント（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を介してCOPを使用する方法について説明します。「TLSを超えるCOP」は略語された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を使用したCOPの安全な実装。
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].
PEP-政策執行ポイント。ポリシークライアントとも呼ばれます。[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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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は非常に単純です。TCP（COPS/TCP）を介してCOPを使用する方法と同様のTLSを介したCOPSを使用します。接続の初期化に使用される特定の手順とは別に、COPS/TLSとCOPS/TCPの間に違いはありません。
There are two ways in which insecure and secure versions of the same protocol can be run simultaneously.
同じプロトコルの安全で安全なバージョンを同時に実行できる2つの方法があります。
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.
2番目の方法は、「上向き交渉」として知られています。この方法では、同じポートで実行されるプロトコルの安全で安全なバージョンが実行されます。クライアントはサーバーに接続し、どちらもお互いの機能を発見し、必要に応じてセキュリティ交渉を開始します。この方法では、通常、プロトコルが確保されるにはいくつかの変更が必要です。
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.
TLS整合性オブジェクトは、PDPとPEPによって使用され、TLS交渉を開始します。このオブジェクトは、クライアントオープンまたはクライアントacceptメッセージにのみ含める必要があります。他の警官メッセージに含めてはなりません。
0 1 2 3
0 1 2 3
+----------+----------+----------+----------+
| 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: 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.
エラーコード：13 =不明なCOPSオブジェクト：サブコード（Octet 2）には不明なオブジェクトのC-Numが含まれ、（Octet 3）は不明なオブジェクトのCタイプが含まれます。PEPまたはPDPがTLSをサポートしていない場合、指定されたC-Numは16でなければならず、C型は2でなければなりません。これは、整合性オブジェクトの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.
このエラーコードは、COPSプロトコルのTLS接続をサポートできない場合、セキュリティ関連の接続閉鎖を示すために、PEPまたはPDPのいずれかで使用する必要があります。
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.
サブコード（Octet 2）には、整合性オブジェクトのC-Num = 16値が含まれ、（Octet 3）が必要/優先整合性オブジェクトCタイプを指定する必要があります。サーバーがCOPSセキュリティの形式をサポートしていない場合、代わりにサブコード（Octet 2）を16に、（Octet 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によって開始される場合があります。PEPはクライアントオープンメッセージを介してネゴシエーションを開始できますが、PDPはクライアントacceptメッセージを介してネゴシエーションを開始できます。
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オブジェクトを含むクライアントacceptメッセージで応答する必要があります。
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で定義されているクライアントacceptメッセージの内容は変更する必要はありません。ただし、そこに含まれる整合性オブジェクトのc型がCタイプ= 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.
また、クライアントアセプトメッセージのこの新しい形式は、既存のクライアントacceptメッセージ形式を置き換えたり廃止したりしないことに注意してください。
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...>
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 =認証が必要で、サブコード（Octet 2）が整合性オブジェクトのC-Numで16に設定され、（Octet 3）はサーバーの優先整合性タイプに対応するCタイプに設定されています。
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オブジェクトが欠落している場合、クライアント-ACCEPTメッセージにIntegrity-TLSオブジェクトを必要とするPEPは、接続を閉じる必要があります。次のクライアントクロースメッセージには、必要な整合性オブジェクトのc-num = 16を含むサブコード（Octet 2）と、必要な整合性オブジェクトのcタイプ= 2を含む（オクテット3）を含むエラーコード15 =認証が必要です。
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はクライアントacceptメッセージで返信する必要があります。TLSの握手を開始するためにPEPに信号を送るために、PDPにはクライアントacceptメッセージに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オブジェクトを使用してクライアントアセプトメッセージを受信すると、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...>
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は、必要な整合性オブジェクトのC-Num = 16を含むサブコード（Octet 2）を含むサブコード（Octet 2）を含むエラーコード15 =認証をクライアントクローズに送信する必要があります。クライアントオープンメッセージを受信すると、クライアントアセプトメッセージを使用してセキュリティネゴシエーションを開始する必要があります。
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に忘れているため、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システムは、優雅に回復するはずです。
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.
警官は、PEPがいつでも接続を閉じることを許可し、PDPは優雅に回復する必要があります。特に、PEPはPEPとPDP間のポリシー情報の転送とは関係のない運用上の理由で頻繁にシャットダウンするため、PDPはPEPから不完全なクローズを受け取るために準備する必要があります。
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.
COPS/TLSのすべてのPEP実装は、認可されたPDPを特定するためのアクセス制御メカニズムをサポートする必要があります。この要件は、PEPに到達するポリシーが実際に有効であるというレベルの保証を提供します。PEPの展開には、TLSを介したCOPの動作のためにこのアクセス制御メカニズムを使用する必要があります。アクセス制御が有効になっている場合、PEP実装は、アクセス制御メカニズムによってPDPとして許可されていないシステムへのCOPS/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 COPS/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].
COPS/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.
型DNSNAMEまたはiPaddressのsubjectaltname拡張がPDPの証明書に存在する場合、PDP IDとして使用する必要があります。両方のタイプが存在する場合、DNSNAMEをPDP IDとして使用する必要があります。どちらのタイプも存在しない場合、証明書の主題フィールドで最も具体的な一般名フィールドを使用する必要があります。
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]で指定されたマッチングルールを使用して、マッチングが実行されます。特定のタイプの複数のIDが証明書に存在する場合（たとえば、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.
PEPシステムがアクセス制御されていない場合、PDPはPEPのアイデンティティがどうあるべきかについての外部知識を必要としないため、チェックは不可能でも不要です。この場合、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システムがアクセス制御されている場合、PEPSはEnd Entity証明書の対象でなければなりません[RFC3280]。この場合、TLSを介したCOPSは双方向認証を使用し、PDPはPDPについて上記のPEPSに対して同じIDチェックを実行する必要があります。
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実装には、サポートされているPEPSに証明書を発行する認定認定機関（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.
一般に、COPS/TLSリクエストは、PEPが接続する権限を与えられているPDPを識別するPEPコンサルティングブートストラップポリシー情報によって生成されます。このポリシーは、PDPのホスト名またはIPアドレスをPEPに提供します。このブートストラップポリシー情報がPEPにどのように到達するかは、このドキュメントの範囲外です。ただし、すべての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 and ACLs. At a minimum, trust anchors and ACLs may be installed manually.
すべてのPEP実装は、PDP証明書を発行する認可された認定機関（CA）ごとに信託アンカーを安全に取得できる必要があります。また、PEPSは、各CAに関連付けられた認定PDPのセットを識別するためのアクセス制御リスト（ACL）を安全に取得するメカニズムをサポートする必要があります。展開は、信頼のアンカーと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アドレスがBootstrapポリシーを介して利用可能である場合、PEPはPDPのTLS証明書メッセージに示されているように、PDPのIDに対してそれを確認する必要があります。
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.
場合によっては、Bootstrapポリシーは、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のホスト名が証明書のIDと一致しない場合、ユーザー指向のシステムのPEPは、ユーザーに通知する必要があります（PEPシステムは、いずれの場合でもユーザーに接続を継続する機会を提供する可能性があります）、または悪い証明書エラーで接続を終了する必要があります。無人システムのPEPSは、エラーを適切な監査ログにログ（利用可能な場合）に記録する必要があり、悪い証明書エラーで接続を終了する必要があります。無人のPEPシステムは、このチェックを無効にする構成設定を提供する場合がありますが、それを有効にする設定を提供する必要があります。
Implementations MUST support the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite. All other cipher suites are optional.
実装は、tls_rsa_with_3des_ede_cbc_sha cipherスイートをサポートする必要があります。他のすべての暗号スイートはオプションです。
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は、COPS/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は、http://www.iana.org/assignments/cops-parametersのレジストリに整合性TLSオブジェクトの次のC-Num、C-Typeの組み合わせを追加しました：
0x10 0x02 Message Integrity, Integrity-TLS [RFC4261] For Client-Type 0, the IANA has added the following Flags value for the Integrity-TLS object:
0x10 0x02メッセージの整合性、Integrity-TLS [RFC4261]クライアントタイプ0の場合、IANAはIntegrity-TLSオブジェクトに次のフラグ値を追加しました。
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 Octet 3：cタイプのサポート/優先整合性オブジェクトまたはゼロ。
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]で定義されているように、Flagsフィールドと予約フィールドのさらなる値は、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.
Man-in-the-Middle攻撃は、Integrity-TLSオブジェクトを削除するか、クライアントオープンまたはクライアントacceptメッセージを変更することで起動できます。セキュリティが必要な場合、PEPおよびPDPブートストラップポリシーはこれを指定する必要があり、PEPとPDPの実装は、Integrity-TLSオブジェクトを含めることができないクライアントオープンまたはクライアントアクセプトメッセージを拒否する必要があります。
This document freely plagiarizes and adapts Eric Rescorla's similar document [RFC2818] that specifies how HTTP runs over TLS.
このドキュメントは、HTTPがTLSをどのように実行するかを指定するEric Rescorlaの同様のドキュメント[RFC2818]を自由に盗用して適応させます。
Discussions with David Durham, Scott Hahn, and Ylian Sainte-Hillaire also lead to improvements in this document.
デビッド・ダーラム、スコット・ハーン、イリアン・サン・ヘイレールとの議論も、この文書の改善につながります。
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] Durham、D.、Boyle、J.、Cohen、R.、Herzog、S.、Rajan、R.、およびA. Sastry、「The Cops（Common Open Policy Service）Protocol」、RFC 2748、2000年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 3280、2002年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」、RFC 2246、1999年1月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC2595] Newman、C。、「IMAP、POP3およびACAPでTLSを使用」、RFC 2595、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
Amol Kulkarni Intel Corporation 2111 N.E.25th Avenue Hillsboro、または97214 USA
EMail: amol.kulkarni@intel.com
Jesse R. Walker Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97214 USA
Jesse R. Walker Intel Corporation 2111 N.E.25th Avenue Hillsboro、または97214 USA
EMail: jesse.walker@intel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.ietf.org/IPRでIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。