[要約] RFC 3594は、PacketCableセキュリティチケット制御サブオプションに関するものであり、DHCP CableLabsクライアント設定（CCC）オプションの一部です。このRFCの目的は、ケーブルネットワークのセキュリティを向上させるために、セキュリティチケット制御機能を提供することです。
Network Working Group P. Duffy
Request for Comments: 3594 Cisco Systems
Category: Standards Track September 2003
PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option
DHCP CableLabsクライアント構成（CCC）オプションのパケットセキュリティチケット制御サブオプション
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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document defines a new sub-option for the DHCP CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate security tickets stored in CCD non volatile memory (i.e., locally persisted security tickets).
このドキュメントでは、DHCP CableLabsクライアント構成（CCC）オプションの新しいサブオプションを定義します。この新しいサブオプションは、CABLELABSクライアントデバイス（CCD）を指示するために、CCDの非揮発性メモリに保存されているセキュリティチケット（つまり、局所的に持続したセキュリティチケット）を無効にします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [2]に記載されているように解釈される。
Definitions of terms/acronyms used throughout this document:
このドキュメント全体で使用される用語/頭字語の定義：
CCC - CableLabs Client Configuration option, described in [1].
CCC -[1]で説明されているCableLabsクライアント構成オプション。
CCD - CableLabs Client Device. A PacketCable MTA is an example of a CCD.
CCD -CableLabsクライアントデバイス。パケット可能なMTAは、CCDの例です。
STC - Security Ticket Control. The CCC sub-option described in this document.
STC-セキュリティチケット制御。このドキュメントで説明されているCCCサブオプション。
MTA - Media Terminal Adapter. The CCD specific to the PacketCable architecture.
MTA-メディア端末アダプター。Packetcableアーキテクチャに固有のCCD。
PacketCable - multimedia architecture developed by CableLabs. See [8] for full details.
PacketCable-ケーブルラブによって開発されたマルチメディアアーキテクチャ。詳細については、[8]を参照してください。
The CableLabs Client Configuration Option [1] defines several sub-options used to configure devices deployed into CableLabs architectures. These architectures implement the PacketCable Security Specification [4] (based on Kerberos V5 [5]), to support CCD authentication and establishment of security associations between CCDs and application servers.
CableLabsクライアント構成オプション[1]は、cablelabsアーキテクチャに展開されたデバイスの構成に使用されるいくつかのサブオプションを定義します。これらのアーキテクチャは、CCD認証とCCDとアプリケーションサーバー間のセキュリティ関連の確立をサポートするために、パケット可能なセキュリティ仕様[4]（Kerberos V5 [5]に基づく）を実装します。
CCDs are permitted to retain security tickets in local persistent storage. Thus a power-cycled CCD is enabled to avoid expensive ticket acquisition for locally persisted, non-expired tickets. This feature greatly reduces the security overhead of a deployment.
CCDは、地元の永続的なストレージにセキュリティチケットを保持することが許可されています。したがって、パワーサイクルのCCDが有効になり、地元で持続し、既存のないチケットの高価なチケットの買収を避けます。この機能により、展開のセキュリティオーバーヘッドが大幅に削減されます。
This sub-option allows the service provider to control the lifetime of tickets persisted locally on a CCD. The service provider requires this capability to support operational functions such as forcing re-establishment of security associations, remote testing, and remote diagnostic of CCDs.
このサブオプションにより、サービスプロバイダーは、CCDでローカルに持続するチケットの寿命を制御できます。サービスプロバイダーは、セキュリティ協会の再確立、リモートテスト、CCDのリモート診断などの運用機能をサポートするこの機能を必要とします。
It should be noted that, although based on the Kerberos V5 RFC [5], the PacketCable Security Specification is not a strict implementation of this RFC. See [4] for details of the PacketCable Security Specification.
Kerberos v5 RFC [5]に基づいていますが、パケット可能なセキュリティ仕様はこのRFCの厳格な実装ではないことに注意してください。パケット可能なセキュリティ仕様の詳細については、[4]を参照してください。
This sub-option defines a Ticket Control Mask (TCM) that instructs the CCD to validate/invalidate specific application server tickets. The sub-option is encoded as follows:
このサブオプションは、CCDに特定のアプリケーションサーバーチケットを検証/無効にするように指示するチケットコントロールマスク（TCM）を定義します。サブオプションは次のようにエンコードされます。
Code Len TCM
+-----+-----+-----+-----+
| 9 | 2 | m1 | m2 |
+-----+-----+-----+-----+
The length MUST be 2. The TCM field is encoded as an unsigned 16 bit quantity per network byte order. Each bit of the TCM is assigned to a specific server or server group. A bit value of 0 means the CCD MUST apply normal invalidation rules (defined in [4]) to the locally persisted ticket for the server/server group. A bit value of 1 means the CCD MUST immediately invalidate the locally persisted ticket for the server/server group.
長さは2でなければなりません。TCMフィールドは、ネットワークバイトごとに署名されていない16ビット数量としてエンコードされます。TCMの各ビットは、特定のサーバーまたはサーバーグループに割り当てられます。0のビット値は、CCDがサーバー/サーバーグループのローカルに持続したチケットに通常の無効化ルール（[4]で定義）を適用する必要があることを意味します。1のビット値は、CCDがサーバー/サーバーグループのローカルに持続したチケットをすぐに無効にする必要があることを意味します。
Bit #0 is the least significant bit of the field. The bit positions are assigned as follows:
ビット＃0は、フィールドの最も重要なビットです。ビット位置は次のように割り当てられます。
Bit #0 - the PacketCable Provisioning Server used by the CCD.
ビット＃0 -CCDが使用するPacketCable Provisioning Server。
Bit #1 - the group of all PacketCable Call Management Servers used by the CCD.
ビット＃1- CCDが使用するすべてのパケット可能なコール管理サーバーのグループ。
Bit #2 - #15. Reserved and MUST be set to 0.
ビット＃2-＃15。予約されており、0に設定する必要があります。
If a CCD does not locally store tickets, it MUST ignore this sub-option. Bit values not known to the CCD MUST be ignored.
CCDがチケットをローカルで保存していない場合、このサブオプションを無視する必要があります。CCDで知られていないビット値は無視する必要があります。
IANA has assigned a sub-option code to this sub-option from the "CableLabs Client Configuration" sub-option number space (maintained within the BOOTP-DHCP Parameters Registry).
IANAは、「CableLabsクライアント構成」サブオプション番号スペース（BOOTP-DHCPパラメーターレジストリ内で維持）からこのサブオプションにサブオプションコードをこのサブオプションに割り当てました。
IANA has also set-up a new registry and will maintain a new number space of "CableLabs Client Configuration Option Ticket Control Mask Bit Definitions", located in the BOOTP-DHCP Parameters Registry. The initial bit definitions are described in section 4 of this document. IANA will register future bit mask definitions via an "IETF Consensus" approval policy as described in RFC 2434 [3].
IANAはまた、新しいレジストリをセットアップしており、bootp-dhcpパラメーターレジストリにある「cablelabsクライアント構成オプションチケットコントロールマスクビット定義」の新しい番号スペースを維持します。最初のビット定義は、このドキュメントのセクション4で説明されています。IANAは、RFC 2434 [3]に記載されている「IETFコンセンサス」承認ポリシーを介して、将来のビットマスク定義を登録します。
Potential DHCP protocol attack exposure is discussed in section 7 of the DHCP protocol specification [6] and in Authentication for DHCP Messages [7]. Additional CCC attack exposure is discussed in [1].
潜在的なDHCPプロトコル攻撃への曝露については、DHCPプロトコル仕様[6]のセクション7およびDHCPメッセージの認証[7]で説明します。追加のCCC攻撃曝露については、[1]で説明しています。
The STC sub-option could be used to disrupt a CableLabs architecture deployment. In the specific case of PacketCable [8], a deployment could be disrupted if a large number of MTAs are reset/power cycled, initiate their provisioning flow [9], and are instructed by a malicious DHCP server to invalidate all security tickets. This could lead to a Denial of Service (DoS) condition as this large set of MTAs simultaneously attempt to authenticate and obtain tickets from the security infrastructure.
STCサブオプションを使用して、CableLabsアーキテクチャの展開を破壊できます。Packetcable [8]の特定のケースでは、多数のMTAがリセット/電源サイクルを行い、プロビジョニングフローを開始し[9]、悪意のあるDHCPサーバーからすべてのセキュリティチケットを無効にする場合、展開が破壊される可能性があります。これにより、この大規模なMTAのセットが同時にセキュリティインフラストラクチャからチケットを認証して取得しようとするため、サービスの拒否（DOS）条件につながる可能性があります。
However, the scenario described above is unlikely to occur. Within the cable delivery architecture required by the various CableLabs projects, the DHCP client is connected to a network through a cable modem and the CMTS (head-end router). The CMTS is explicitly configured with a set of valid DHCP server addresses to which DHCP requests are forwarded. Further, a correctly configured CMTS will only allow DHCP downstream traffic from specific DHCP server addresses.
ただし、上記のシナリオは発生する可能性は低いです。さまざまなCableLabsプロジェクトで必要なケーブル配信アーキテクチャ内で、DHCPクライアントはケーブルモデムとCMTS（ヘッドエンドルーター）を介してネットワークに接続されています。CMTSは、DHCPリクエストが転送される有効なDHCPサーバーアドレスのセットで明示的に構成されています。さらに、正しく構成されたCMTは、特定のDHCPサーバーアドレスからのDHCPダウンストリームトラフィックのみを許可します。
It should be noted that the downstream filtering of DHCP packets will not prevent spoofed DHCP servers behind the CMTS, but the network infrastructure behind the CMTS is assumed to be closely controlled by the service provider.
DHCPパケットのダウンストリームフィルタリングは、CMTSの背後にあるスプーフィングされたDHCPサーバーを妨げないことに注意する必要がありますが、CMTSの背後にあるネットワークインフラストラクチャは、サービスプロバイダーによって綿密に制御されると想定されています。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
[1] Beser, B. and P. Duffy, "DHCP Option for CableLabs Client Configuration", RFC 3495, March 2003.
[1] Beser、B。およびP. Duffy、「CableLabsクライアント構成のDHCPオプション」、RFC 3495、2003年3月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
[3] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、RFC 2434、1998年10月。
[4] "PacketCable Security Specification", PKT-SP-SEC-I09-030728, http://www.packetcable.com/downloads/specs/ PKT-SP-SEC-I09-030728.pdf
[4] 「Packetcableセキュリティ仕様」、PKT-SP-SEC-I09-030728、http：//www.packetcable.com/downloads/specs/ pkt-sp-sec-i09-030728.pdf
[5] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[5] Kohl、J。およびC. Neuman、「The Kerberos Network Authentication Service（V5）」、RFC 1510、1993年9月。
[6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[6] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[7] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001
[7] Droms、R。and W. Arbaugh、「DHCPメッセージの認証」、RFC 3118、2001年6月
[8] "PacketCable 1.0 Architecture Framework Technical Report", PKT-TR-ARCH-V01-991201, http://www.packetcable.com/downloads/specs/ pkt-tr-arch-v01-991201.pdf
[8] 「PacketCable 1.0アーキテクチャフレームワークテクニカルレポート」、PKT-TR-ARCH-V01-991201、http：//www.packetcable.com/dowdloads/specs/ pkt-tr-arch-v01-991201.pdf
[9] "PacketCable MTA Device Provisioning Specification", PKT-SP-PROV-I07-030728, http://www.packetcable.com/downloads/specs/ PKT-SP-PROV-I07-030728.pdf
[9] 「PacketCable MTAデバイスプロビジョニング仕様」、PKT-SP-PROV-I07-030728、http：//www.packetcable.com/dowdloads/specs/ pkt-sprov-i07-030728.pdf
The author would like to acknowledge the effort of all those who contributed to the development of the PacketCable Provisioning specifications:
著者は、パケット可能なプロビジョニング仕様の開発に貢献したすべての人々の努力を認めたいと思います。
Sumanth Channabasappa (Alopa Networks); Angela Lyda, Rick Morris, Rodney Osborne (Arris Interactive); Steven Bellovin and Chris Melle (AT&T); Eugene Nechamkin (Broadcom); John Berg, Maria Stachelek, Matt Osman, Venkatesh Sunkad (CableLabs); Klaus Hermanns, Azita Kia, Michael Thomas, Paul Duffy (Cisco); Deepak Patil (Com21); Jeff Ollis, Rick Vetter (General Instrument/Motorola); Roger Loots, David Walters (Lucent); Peter Bates (Telcordia); Patrick Meehan (Tellabs); Satish Kumar, Itay Sherman, Roy Spitzer (Telogy/TI), Aviv Goren (Terayon); Prithivraj Narayanan (Wipro), and Burcak Beser (Juniper Networks).
Sumanth Channabasappa（Alopa Networks）;アンジェラ・リダ、リック・モリス、ロドニー・オズボーン（Arris Interactive）;スティーブンベロビンとクリスメルル（AT＆T）;Eugene Nechamkin（Broadcom）;ジョン・バーグ、マリア・スタチェレク、マット・オスマン、ベンカティシュ・サンカド（ケーブルラブ）;Klaus Hermanns、Azita Kia、Michael Thomas、Paul Duffy（Cisco）;Deepak Patil（COM21）;ジェフ・オリス、リック・ベッター（一般的な楽器/モトローラ）;ロジャー・ルーツ、デビッド・ウォルターズ（ルーセント）;ピーターベイツ（テルコルディア）;パトリック・ミーハン（テラブス）;Satish Kumar、Itay Sherman、Roy Spitzer（Telogy/Ti）、Aviv Goren（Terayon）;Prithivraj Narayanan（Wipro）、およびBurcak Beser（ジュニパーネットワーク）。
Paul Duffy Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719
Paul Duffy Cisco Systems 1414 Massachusetts Avenue Boxborough、MA 01719
EMail: paduffy@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。