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
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.
著作権（C）インターネット協会（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）オプションの新しいサブオプションを定義します。この新しいサブオプションが（すなわち、ローカルセキュリティチケットを持続）CCD不揮発性メモリに格納されたセキュリティチケットを無効にするためにCableLabsのクライアント素子（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[2]。
Definitions of terms/acronyms used throughout this document:
本書で使用される用語/頭字語の定義：
CCC - CableLabs Client Configuration option, described in [1].
CCC - で説明CableLabsのクライアント構成オプション、[1]。
CCD - CableLabs Client Device. A PacketCable MTA is an example of a CCD.
CCD - のCableLabsクライアントデバイス。 PacketCableの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の - CableLabsのが開発したマルチメディアアーキテクチャ。完全な詳細については、[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のアーキテクチャに展開デバイスを構成するために使用されるいくつかのサブオプションを定義します。これらのアーキテクチャは、[4]（ケルベロスV5 [5]に基づく）PacketCableのセキュリティ仕様を実装CCD認証とのCCDとアプリケーションサーバとの間のセキュリティアソシエーションの確立をサポートします。
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]、PacketCableのセキュリティ仕様は、このRFCの厳密な実装ではないことに留意すべきです。 PacketCableのセキュリティ仕様の詳細については、[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
TCMフィールドは、ネットワークバイトオーダーあたりの符号なし16ビット数として符号化される2.長さでなければなりません。 TCMの各ビットは、特定のサーバーまたはサーバーグループに割り当てられています。 0のビット値は、CCDは、局所的に（[4]で定義された）通常の無効化ルールを適用しなければならないことを意味します
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.
サーバー/サーバーグループのチケットを持続しました。 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のプロビジョニングサーバー。
Bit #1 - the group of all PacketCable Call Management Servers used by the CCD.
ビット＃1 - CCDで使用されるすべてのPacketCable通話管理サーバーのグループ。
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は（BOOTP、DHCPパラメータレジストリ内に維持）「CableLabsのクライアントの設定」のサブオプション番号空間から、このサブオプションのサブオプションコードが割り当てられています。
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に記載されています。 RFC 2434に記載されるようにIANA [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プロトコル仕様のセクション7に記載されている[6]、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のアーキテクチャの展開を破壊するために使用することができます。 MTAは多数のリセット/電源が再投入された場合のPacketCableの特定の場合には、[8]、展開が[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サーバアドレスのセットで構成されています。さらに、正しく設定CMTSは、特定の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.ダフィー、 "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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（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.と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/downloads/specs/ PKT-TR-アーチ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/downloads/specs/ PKT-SP-PROV-I07-030728.pdf
The author would like to acknowledge the effort of all those who contributed to the development of the PacketCable Provisioning specifications:
著者は、PacketCableのプロビジョニング仕様の発展に貢献したすべての人々の努力に感謝します：
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).
スーマンスChannabasappa（Alopaネットワーク）。アンジェラリダ、リック・モリス、ロドニー・オズボーン（ARRISインタラクティブ）。スティーブンBellovin氏とクリス・メレ（AT＆T）。ユージンNechamkin（ブロード）。ジョン・バーグ、マリアStachelek、マット・オスマン、ベンカテッシュSunkad（CableLabsに）;クラウスHermanns、Azita起亜、マイケル・トーマス、ポール・ダフィー（シスコ）。ディーパックパティル（COM21）。ジェフOllis、リック・フェッター（一般的なインストゥルメント/モトローラ）。ロジャーLoots、デビッド・ウォルターズ（ルーセント）。ピーター・ベイツ（Telcordiaの）;パトリック・ミーハン（テラブス）。サティシュ・クマール、イタイシャーマン、ロイスピッツァー（Telogy / TI）、テルアビブGoren（Terayon）。 Prithivrajナラヤナン（ウィプロ）、およびBurcak Beser（ジュニパーネットワークス）。
Paul Duffy Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719
ポール・ダフィーシスコシステムズ1414年マサチューセッツアベニューボックスボロー、MA 01719
EMail: paduffy@cisco.com
メールアドレス：paduffy@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。