Network Working Group P. Duffy
Request for Comments: 3594 Cisco Systems
Category: Standards Track September 2003
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）选项的PacketCable安全票证控制子选项
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）选项定义了一个新的子选项。此新的子选项将用于指示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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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客户端设备。打包电缆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体系结构中的设备的子选项。这些体系结构实现了PacketCable安全规范[4]（基于Kerberos V5[5]），以支持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:
此子选项定义一个票证控制掩码（TCM），用于指示CCD验证/失效特定的应用程序服务器票证。子选项的编码如下所示：
Code Len TCM
+-----+-----+-----+-----+
| 9 | 2 | m1 | m2 |
+-----+-----+-----+-----+
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
长度必须为2。TCM字段编码为每个网络字节顺序的无符号16位数量。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已从“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协议规范[6]第7节和DHCP消息的身份验证[7]中讨论了潜在的DHCP协议攻击暴露。[1]中讨论了额外的CCC攻击暴露。
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服务器指示使所有安全票证无效，则部署可能会中断。这可能会导致拒绝服务（DoS）情况，因为这一大组MTA同时尝试从安全基础架构进行身份验证和获取票证。
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
然而，上述情况不太可能发生。在各种CableLabs项目所需的电缆传输体系结构中，DHCP客户端通过电缆连接到网络
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.
调制解调器和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数据包的下游过滤不会阻止CMT后面的伪造DHCP服务器，但是CMT后面的网络基础设施被认为是由服务提供商密切控制的。
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 Security Specification", 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，“Kerberos网络身份验证服务（V5）”，RFC15101993年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消息的身份验证”，RFC31182001年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 Architecture Framework Technical Report",
PKT-TR-ARCH-V01-991201,
http://www.packetcable.com/downloads/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 Device Provisioning Specification",
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).
Sumanth Channabasapa（Alopa网络）；安吉拉·利达、里克·莫里斯、罗德尼·奥斯本（阿里斯互动）；Steven Bellovin和Chris Melle（AT&T）；尤金·内查姆金（博通）；约翰·伯格、玛丽亚·斯塔切莱克、马特·奥斯曼、文卡特什·桑卡德（有线实验室）；克劳斯·赫尔曼斯、阿齐塔·基亚、迈克尔·托马斯、保罗·达菲（思科）；迪帕克帕蒂尔（Com21）；Jeff Ollis，Rick Vetter（通用仪器/摩托罗拉）；罗杰·罗伯茨，大卫·沃尔特斯（朗讯）；彼得·贝茨（特尔科迪亚）；帕特里克·米汉（特拉布）；萨蒂什·库马尔、伊泰·谢尔曼、罗伊·斯皮策（Telogy/TI）、阿维夫·戈伦（Terayon）；Prithivraj Narayanan（Wipro）和Burcak Beser（Juniper Networks）。
Paul Duffy Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719
马萨诸塞州伯斯堡马萨诸塞大道1414号保罗·达菲思科系统公司，邮编01719
EMail: paduffy@cisco.com
EMail: 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编辑功能的资金目前由互联网协会提供。