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)
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.
この文書は、インターネット上で一般的なオープンポリシーサービス（COPS）接続を確保するためにトランスポート層セキュリティ（TLS）を使用する方法について説明します。
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]はインターネットにおけるポリシー施行点（PEP）のセットに集中ポリシー決定ポイント（PDP）からクリアテキストのポリシー情報を配布するために設計されました。 COPSは、展開されたポリシーのホップごとの整合性を保護するために、独自のセキュリティメカニズムを提供します。しかし、敏感なアプリケーションのためのCOPSの用途（例えば、セキュリティポリシー分布のいくつかのタイプ）は、データの機密性などの追加のセキュリティ対策を必要とします。一部の組織では、セキュリティポリシーの一部またはすべてを非表示にすることが必要見つけるため、このようなモバイルプラットフォームなどのデバイスへのポリシーの配布は、ドメインの境界を越えることができますので、これは、例えば、あります。
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は、1次元および双方向認証、動的なセッションキー、およびデータ・ストリームのプライバシーと整合性の両方のためのメカニズムを提供します。
This document describes how to use COPS over TLS. "COPS over TLS" is abbreviated COPS/TLS.
この文書では、TLS上でCOPSを使用する方法について説明します。 "TLSオーバーCOPSは、" COPS / TLSを省略しています。
Glossary
用語集
COPS - Common Open Policy Service. See [RFC2748].
COPS - 共通オープンポリシーサービス。 [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].
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）上でCOPSを使用する方法に類似した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].
第1の方法では、プロトコルの安全なバージョンはまた、既知のポートが割り当てられます。両方のためのよく知られたポート番号を持つのこの戦略は、安全で、安全でないバージョンでは、「別々のポート」として知られています。セキュリティを必要とするクライアントは、単に、よく知られたセキュアポートに接続することができます。この方法は、既存の安全でない実装に必要な変更なしで、実装が容易です。欠点は、しかし、新しいポートはそれぞれ安全な実装のために必要とされるため、それは、うまくスケールしないということです。このアプローチには多くの問題は、[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.
このセクションでは、/ TLSをCOPSをサポートするために必要な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のIntegrityオブジェクトは、TLSネゴシエーションを開始するPDPとPEPで使用されています。このオブジェクトはクライアントのオープンまたはClient-受諾メッセージに含まれるべきです。これは、任意の他のCOPSメッセージに含まれてはなりません。
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.
フラグ：0×01 = StartTLSを、このフラグは、メッセージの送信者がTLSハンドシェイクを開始することを望むことを示す16ビット。
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.
このオブジェクトを含む任意のメッセージのクライアントタイプは、COPS接続レベルのセキュリティをネゴシエートするために使用される0クライアントタイプ0でなければなりませんとのみ接続確立フェーズの間に使用されなければなりません。詳細については、[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-民、および（オクテット3）未知のオブジェクトのC-タイプを含むが含まれています。 PEP又はPDPがTLSをサポートしていない場合、指定されたC-numが16なければならず、C型これは、インテグリティオブジェクトのTLSバージョンが知られていないことを実証している2でなければなりません。
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は、Client-オープンに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型/必要なPDPを指定しなければなりません整合オブジェクトと（オクテット3）のためにC-民= 16の値を含む場合。サーバはCOPS-セキュリティの任意の形式をサポートしていない場合、それは、Integrityオブジェクトのいかなるタイプがサポートされていないことを意味する、代わりにゼロに16のサブコード（オクテット2）及び（オクテット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は、Client-Acceptメッセージを介してネゴシエーションを開始することができながら、PEPは、クライアントオープンメッセージを介してネゴシエーションを開始することができます。
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は、Client-オープンメッセージを使用して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:
保全対象のC型がイン含有すること以外は整合-TLSオブジェクトを実行するために、[RFC2748]のセクション3.7で定義されたクライアント-Acceptメッセージの内容は、変更する必要はないことに注意することは今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.
クライアント-Acceptメッセージのこの新しい形式は置き換えられないか、時代遅れ続けることができ、既存のクライアント-Acceptメッセージのフォーマットは、非セキュアCOPSセッションの交渉のために使用されることにも注意してください。
Upon receiving the appropriate Client-Accept message, the PEP SHOULD initiate the TLS handshake.
適切なクライアント-Acceptメッセージを受信すると、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：クライアントのオープン（クライアントタイプ= 0、整合性-TLS）S：クライアント受け入れる（クライアントタイプ= 0、整合性-TLS）<TLSハンドシェイク> C / S：<...さらにメッセージ...>
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との安全な接続をオープンしたくない、それは、Client-閉じるメッセージで応答し、接続を閉じる必要があります。クライアント閉じるメッセージは、サブコード（オクテット2）インテグリティオブジェクトのC-numの16に設定し、サーバの対応するC型に設定さ（オクテット3）を用いて、必要なエラー・コード15 =認証を含まなければなりません好適な整合性タイプ、または全くセキュリティのためのゼロ。
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.
クライアント受け入れインテグリティ-TLSオブジェクトが欠落している場合、メッセージは接続を閉じなければなりませんで整合-TLSオブジェクトを必要PEP。その後クライアントクローズメッセージが必要なインテグリティオブジェクトのC-民= 16、及び必要なインテグリティオブジェクトのC型を含む（オクテット3）を含むサブコード（オクテット2）と15 =認証が必要なエラーコードを含まなければなりません= 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は、[クライアント-Acceptメッセージで応答すべきです。 TLSハンドシェイクを開始するためにPEPを通知するために、PDPは、Client-Acceptメッセージに整合-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.
整合-TLSオブジェクトとクライアント-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：クライアントのオープン（クライアントタイプ= 0）S：クライアント受け入れる（クライアントタイプ= 0、整合性-TLS）<TLSハンドシェイク> C / S：<...さらにメッセージ...>
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.
TLSハンドシェイクが完了するまで、クライアント受け入れを受信した後、PEPは、すべてのメッセージを送ってはいけません。 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.
PDPは、クライアントを閉じる必要インテグリティオブジェクトの含むサブコード（オクテット2）と、15 =認証が必要なエラーコードをC-民= 16を送信しなければならない既存の非セキュア接続を有するPEPとセキュリティをネゴシエートすることを望みます、及び（オクテット3）必要なインテグリティオブジェクトのC型= 2を含有し、そしてその後、PEPは、再接続を待ちます。クライアントのオープンメッセージを受信すると、それはセキュリティネゴシエーションを開始するために、クライアント-Acceptメッセージを使用すべきです。
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.
接続は、第1の閉鎖警戒「時期尚早近い」として知られているを送信せずに閉じました。時期尚早近いが質問にすでに受信したデータのセキュリティを呼び出すことはありませんが、単に後続のデータが切り捨てられている可能性があることを示しています。 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システムが正常に回復すべきです。
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が必要です。 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の全てPEP実装は/ TLSは、許可のPDPを識別するためのアクセス制御メカニズムをサポートしなければなりません。この要件は、PEPに到着する政策が実際に有効であることを保証レベルを提供します。 PEPの展開は、TLSを超えるCOPSの動作については、このアクセス制御機構を使用することを要求すべきです。アクセス制御が有効になっている場合、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は、PDPとPEPシステムを識別するために、[RFC3280]に準拠したX.509 v3証明書を使用しなければなりません。 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またはIPアドレスのsubjectAltName拡張は、PDPの証明書に存在している場合、それはPDPのアイデンティティとして使用しなければなりません。両方のタイプが存在する場合、のdNSNameは、PDPのIDとして使用する必要があります。どちらのタイプが存在する場合、証明書のSubjectフィールドの中で最も特定のCommon Nameフィールドを使用する必要があります。
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）に存在する場合、提供される識別情報のいずれか1つに一致が許容されます。一般的に、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はPEPにPDPの一方向認証を使用します。
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はPDPについて上述したのPEPに同じ身元チェックを実行しなければなりません。
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.
一般的に、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）のためのトラストアンカーを取得できなければなりません。また、のPEPを確実にそれぞれの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アドレスは、ブートストラップポリシーを介して利用可能である場合にはPDPのTLS証明書メッセージに提示され、PEPは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は、証明書内に存在していなければなりません、そして、それは、ポリシーサーバの予想される名前と一致するIPアドレスの形式を含まなければなりません。
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_RSA_WITH_3DES_EDE_CBC_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は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型の組み合わせを追加しました。
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型：インテグリティオブジェクトオクテット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].
Flagsフィールドと予備フィールドためのさらなる値は唯一[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.
man-in-the-middle攻撃は、Integrity-TLSオブジェクトを削除するか、クライアントのオープンまたはClient-受諾メッセージを変更することによって起動することができます。セキュリティが必要な場合は、PEPとPDPブートストラップポリシーは、これを指定しなければならない、とPEPとPDPの実装は、Client-オープン拒絶またはIntegrity-TLSオブジェクトが含まれるように失敗したメッセージをクライアント受け入れなければなりません。
This document freely plagiarizes and adapts Eric Rescorla's similar document [RFC2818] that specifies how HTTP runs over TLS.
この文書は自由にplagiarizesとHTTPがTLS上でどのように実行するかを指定エリックレスコラの同様の文書[RFC2818]を適応します。
Discussions with David Durham, Scott Hahn, and Ylian Sainte-Hillaire also lead to improvements in this document.
デビッド・ダーラム、スコット・ハーン、そしてYlianサンティレールとの議論はまた、この文書の改善につながります。
The authors wish to thank Uri Blumenthal for doing a thorough security review of the document.
著者は、文書の徹底的なセキュリティレビューを行うためのウリブルーメンソールに感謝したいです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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. Sastry、 "COPS（共通オープンポリシーサービス）プロトコル"、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.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、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.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ、E.、 "TLSオーバーHTTP"、RFC 2818、2000年5月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC2595]ニューマン、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さんインテルコーポレーション2111 N.E.第25回アベニューヒルズボロ、OR 97214 USA
EMail: amol.kulkarni@intel.com
メールアドレス：amol.kulkarni@intel.com
Jesse R. Walker Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97214 USA
ジェシーR.ウォーカーインテルコーポレーション2111 N.E.第25回アベニューヒルズボロ、OR 97214 USA
EMail: jesse.walker@intel.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.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 Editor機能のための基金は現在、インターネット協会によって提供されます。