Network Working Group L. Dondeti, Ed.
Request for Comments: 4909 QUALCOMM, Inc.
Category: Informational D. Castleford
France Telecom
F. Hartung
Ericsson Research
June 2007
Network Working Group L. Dondeti, Ed.
Request for Comments: 4909 QUALCOMM, Inc.
Category: Informational D. Castleford
France Telecom
F. Hartung
Ericsson Research
June 2007
Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport
开放移动联盟BCAST LTKM/STKM传输的多媒体互联网密钥（MIKEY）通用扩展有效负载
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document specifies a new Multimedia Internet KEYing (MIKEY) General Extension payload (RFC 3830) to transport the short-term key message (STKM) and long-term key message (LTKM) payloads defined in the Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast (BCAST) group's Service and Content protection specification.
本文档规定了一种新的多媒体互联网密钥（MIKEY）通用扩展有效载荷（RFC 3830），用于传输开放移动联盟（OMA）浏览器和内容（BAC）广播（BCAST）组的服务和内容保护规范中定义的短期密钥消息（STKM）和长期密钥消息（LTKM）有效载荷。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. MIKEY General Extension for OMA BCAST Usage . . . . . . . . . . 3
4. Interoperability Considerations . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. MIKEY General Extension for OMA BCAST Usage . . . . . . . . . . 3
4. Interoperability Considerations . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
The Multimedia Internet Keying (MIKEY) protocol specification [1] defines a General Extension payload to allow possible extensions to MIKEY without having to allocate a new payload type. The General Extension payload can be used in any MIKEY message and is part of the authenticated/signed data part. There is an 8-bit type field in that payload. The type code assignment is IANA-managed, and RFC 3830 requires IETF consensus for assignments from the public range of 0-240.
多媒体互联网键控（MIKEY）协议规范[1]定义了一个通用扩展有效负载，允许对MIKEY进行可能的扩展，而无需分配新的有效负载类型。通用扩展有效负载可用于任何MIKEY消息，并且是经过身份验证/签名的数据部分的一部分。该有效负载中有一个8位类型字段。类型代码分配由IANA管理，RFC 3830要求IETF就0-240范围内的公共分配达成一致意见。
The Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast (BCAST) group's Service and Content Protection specification [2] specifies the use of a short-term key message (STKM) and a long-term key message (LTKM) that carry attributes related to Service and Content protection. Note that any keys associated with the attributes are part of the MIKEY KEMAC payload. This document specifies the use of the General Extension payload of MIKEY to carry the LTKMs or STKMs.
开放移动联盟（OMA）的浏览器和内容（BAC）广播（BCAST）集团的服务和内容保护规范[2]规定了短期密钥消息（STKM）和长期密钥消息（LTKM）的使用，这两种消息具有与服务和内容保护相关的属性。请注意，与属性关联的任何键都是MIKEY KEMAC有效负载的一部分。本文件规定了使用MIKEY的通用扩展有效载荷来承载LTKMs或STKMs。
RFC 3830 [1], the MIKEY General Extension payload defined in [3], and the 3rd Generation Partnership Project (3GPP)'s Multimedia Broadcast/ Multicast Service (MBMS) document [4] specify the transport of MIKEY messages via unicast or broadcast and the OMA specifications use either for transport of MIKEY messages.
RFC 3830[1]、[3]中定义的MIKEY General Extension payload和第三代合作伙伴关系项目（3GPP）的多媒体广播/多播服务（MBMS）文档[4]规定了通过单播或广播传输MIKEY消息，OMA规范用于传输MIKEY消息。
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 [5].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。
OMA BCAST STKM/LTKM MIKEY General Extension: We refer to the General Extension type -- 5 -- as the OMA BCAST STKM/LTKM MIKEY General Extension .
OMA BCAST STKM/LTKM MIKEY通用扩展：我们将通用扩展类型——5——称为OMA BCAST STKM/LTKM MIKEY通用扩展。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! OMA BCAST S/LTKM Subtype (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! OMA BCAST S/LTKM Subtype (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: OMA BCAST MIKEY General Extension
图1:OMA BCAST MIKEY通用扩展
Section 6.1 of RFC 3830 specifies the first three fields of the General Extension Payload and defines a variable length Data field. This document specifies the use of Type 5 for OMA BCAST Service and Content Protection using the Smartcard Profile. The contents of the variable length data field are defined below.
RFC 3830第6.1节规定了一般扩展有效载荷的前三个字段，并定义了可变长度数据字段。本文档指定使用智能卡配置文件将类型5用于OMA BCAST服务和内容保护。可变长度数据字段的内容定义如下。
Subtype: 8 bits. This field indicates the type of the OMA BCAST payload. In this specification, only two values are specified: LTKM (1), and STKM (2).
子类型：8位。此字段指示OMA BCAST有效负载的类型。在本规范中，仅规定了两个值：LTKM（1）和STKM（2）。
Subtype Specific Data: Variable length. The contents of this field are defined in Section 6 of the OMA BCAST Service and Content Protection specification [2].
子类型特定数据：可变长度。该字段的内容在OMA BCAST服务和内容保护规范[2]的第6节中定义。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Subtype ! Subtype specific data (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Subtype ! Subtype specific data (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: STKM/LTKM Subtype Payload
图2:STKM/LTKM子类型有效载荷
This document specifies the use of MIKEY General Extension Payload Type 5 and a couple of subtype values (1 and 2), one each for OMA BCAST Service and Content protection's STKM and LTKM payloads. Interoperability considerations span several standards bodies, with OMA BCAST 1.0 enabler compliance being the key aspect; as such, it is up to the OMA test planning to verify the interoperability and compliance of OMA BCAST 1.0 implementations. This payload type assignment does not change MIKEY beyond RFC 3830 [1] and RFC 4563 [3].
本文档规定了MIKEY General Extension有效负载类型5和两个子类型值（1和2）的使用，分别用于OMA BCAST服务和内容保护的STKM和LTKM有效负载。互操作性考虑跨越多个标准机构，OMA BCAST 1.0启用码合规性是关键方面；因此，由OMA测试计划来验证OMA BCAST 1.0实现的互操作性和遵从性。此有效负载类型分配不会改变RFC 3830[1]和RFC 4563[3]之外的MIKEY。
According to RFC 3830, the general extension payload can be used in any MIKEY message and is part of the authenticated/signed data part. The parameters proposed to be included in the OMA BCAST MIKEY General Extension payload (listed in Section 3) need only to be integrity protected, which is already allowed by the MIKEY specification. The OMA BCAST MIKEY General Extension Payload SHALL be integrity protected. Furthermore, keys or any parameters that require confidentiality MUST NOT be included in the General Extension Payload. If keys or other confidential data are to be transported via the General Extension Payload, such data MUST be encrypted and encapsulated independently. Finally, note that MIKEY already provides replay protection and that protection covers the General Extension Payload also.
根据rfc3830，通用扩展有效载荷可以在任何MIKEY消息中使用，并且是认证/签名数据部分的一部分。建议包含在OMA BCAST MIKEY General Extension有效载荷中的参数（在第3节中列出）只需要完整性保护，这是MIKEY规范已经允许的。OMA BCAST MIKEY通用扩展有效载荷应受到完整性保护。此外，需要保密的密钥或任何参数不得包含在通用扩展有效负载中。如果要通过通用扩展有效载荷传输密钥或其他机密数据，则必须单独对此类数据进行加密和封装。最后，请注意，MIKEY已经提供了重播保护，该保护还包括一般扩展负载。
IANA has allocated a new General Extension Type from the "General Extensions payload name spaces" in the IANA registry at http://www.iana.org/assignments/mikey-payloads for use by OMA BCAST. Furthermore, IANA maintains a list of corresponding subtypes (0-255) as follows:
IANA已从位于的IANA注册表中的“通用扩展有效负载名称空间”中分配了新的通用扩展类型http://www.iana.org/assignments/mikey-payloads 供OMA BCAST使用。此外，IANA维护了相应子类型（0-255）的列表，如下所示：
0 ... Reserved
0 ... 含蓄的
1 ... LTKM
1.LTKM
2 ... STKM
2.STKM
3 ... 191 (maintained by IANA and assigned by IETF Review [6])
3.191（由IANA维护并由IETF评审[6]指定）
192 ... 255 (Private use)
192 ... 255（私人使用）
Many thanks to Jari Arkko, Piron Laurent, and Steffen Fries for their reviews and suggestions for improvement.
非常感谢Jari Arkko、Piron Laurent和Steffen Fries的评论和改进建议。
[1] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[1] Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[2] Open Mobile Alliance, "Service and Content Protection for Mobile Broadcast Services", OMA TS-BCAST_SvcCntProtection-V1_0- 20070529-C, 2007, <http://www.openmobilealliance.org/ release_program/bcast_v1_0.html>.
[2] 开放式移动联盟，“移动广播服务的服务和内容保护”，OMA TS-BCAST_SvcCntProtection-V1_0-20070529-C，2007年<http://www.openmobilealliance.org/ 发布程序/bcast\u v1\u 0.html>。
[3] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006.
[3] Carrara，E.，Lehtovirta，V.，和K.Norrman，“多媒体互联网密钥（MIKEY）中通用扩展有效载荷的密钥ID信息类型”，RFC 4563，2006年6月。
[4] 3GPP, "3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS)", 3GPP TS 33.246 6.6.0, March 2006.
[4] 3GPP，“3G安全；多媒体广播/多播服务（MBMS）的安全”，3GPP TS 33.246 6.6.0，2006年3月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", Work in Progress, March 2007.
[6] Narten，T.和H.Alvestrand，“在RFCs中编写IANA考虑事项部分的指南”，正在进行的工作，2007年3月。
Authors' Addresses
作者地址
Lakshminath Dondeti (editor) QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA
Lakshminath Dondeti（编辑）高通公司5775 Morehouse Dr San Diego，CA USA
Phone: +1 858-845-1267
EMail: ldondeti@qualcomm.com
Phone: +1 858-845-1267
EMail: ldondeti@qualcomm.com
David Castleford France Telecom 4, rue du Clos Courtel 35512 Cesson Sevigne Cedex, France
David Castleford法国电信4号，法国塞森塞维尼塞德克斯路35512号
Phone: + 33 (0)2 99 12 49 27
EMail: david.castleford@orange-ftgroup.com
Phone: + 33 (0)2 99 12 49 27
EMail: david.castleford@orange-ftgroup.com
Frank Hartung Ericsson Research Ericsson Allee 1 52134 Herzogenrath, Germany
Frank Hartung Ericsson Research爱立信Allee 1 52134 Herzogenrath，德国
Phone: +49 2407 575389
EMail: frank.hartung@ericsson.com
Phone: +49 2407 575389
EMail: frank.hartung@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。