Network Working Group A. Jerichow, Ed.
Request for Comments: 5410 Nokia Siemens Networks
Obsoletes: 4909 L. Piron
Category: Informational Nagravision S.A.
January 2009
Network Working Group A. Jerichow, Ed.
Request for Comments: 5410 Nokia Siemens Networks
Obsoletes: 4909 L. Piron
Category: Informational Nagravision S.A.
January 2009
Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0
开放移动联盟BCAST 1.0的多媒体互联网密钥（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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document specifies a new Multimedia Internet KEYing (MIKEY) General Extension payload to transport the short-term key message (STKM) and long-term key message (LTKM) payloads as well as the management data LTKM reporting message and parental control message payloads defined in the Open Mobile Alliance's (OMA) Broadcast (BCAST) group's Service and Content protection specification.
本文件规定了一种新的多媒体互联网密钥（MIKEY）通用扩展有效载荷，用于传输短期密钥消息（STKM）和长期密钥消息（LTKM）有效载荷以及开放移动联盟（OMA）广播（BCAST）中定义的管理数据LTKM报告消息和家长控制消息有效载荷集团的服务和内容保护规范。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MIKEY General Extension for OMA BCAST Usage . . . . . . . . . . 3
4. Interoperability Considerations . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Changes since RFC 4909 . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MIKEY General Extension for OMA BCAST Usage . . . . . . . . . . 3
4. Interoperability Considerations . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Changes since RFC 4909 . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
The Multimedia Internet KEYing (MIKEY) protocol specification (RFC 3830 [RFC3830]) 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）协议规范（RFC 3830[RFC3830]）定义了通用扩展有效载荷，以允许对MIKEY进行可能的扩展，而无需分配新的有效载荷类型。通用扩展有效负载可用于任何MIKEY消息，并且是经过身份验证/签名的数据部分的一部分。该有效负载中有一个8位类型字段。类型代码分配由IANA管理，RFC 3830要求IETF就0-240范围内的公共分配达成一致意见。
The Open Mobile Alliance's (OMA) Broadcast (BCAST) group's Service and Content Protection specification [SPCP] specifies the use of a short-term key message (STKM), a long-term key message (LTKM), an LTKM reporting message, and a parental control message that carry attributes related to Service and Content protection. Note that any keys associated with the attributes, such as the Parental Control Pincode if present, are part of the MIKEY KEMAC payload.
开放移动联盟（OMA）广播（BCAST）集团的服务和内容保护规范[SPCP]规定了短期密钥消息（STKM）、长期密钥消息（LTKM）、LTKM报告消息和带有与服务和内容保护相关属性的家长控制消息的使用。请注意，与属性相关的任何键（如存在家长控制Pincode）都是MIKEY KEMAC有效负载的一部分。
This document specifies the use of the General Extension payload of MIKEY to carry the messages mentioned above, as well as protection of the credentials using mechanisms supported by MIKEY with modifications in [RFC3830].
本文档规定了使用MIKEY的通用扩展有效载荷来承载上述消息，以及使用MIKEY支持的机制保护凭证，并在[RFC3830]中进行了修改。
RFC 3830 [RFC3830], the MIKEY General Extension payload defined in RFC 4563 [RFC4563], and the 3rd Generation Partnership Project (3GPP)'s Multimedia Broadcast/ Multicast Service (MBMS) document [3GPP.33.246] specify the transport of MIKEY messages via unicast or broadcast; the OMA BCAST specifications use either for transport of MIKEY messages.
RFC 3830[RFC3830]、RFC 4563[RFC4563]中定义的MIKEY通用扩展有效载荷以及第三代合作伙伴项目（3GPP）的多媒体广播/多播服务（MBMS）文件[3GPP.33.246]规定了通过单播或广播传输MIKEY消息；OMA BCAST规范用于传输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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
OMA BCAST MIKEY General Extension: We refer to the General Extension type -- 5 -- as the OMA BCAST MIKEY General Extension.
OMA BCAST MIKEY通用扩展：我们将通用扩展类型-5称为OMA BCAST MIKEY通用扩展。
The OMA BCAST Type (Type 5) formats the MIKEY General Extension payload as follows:
OMA BCAST类型（类型5）将MIKEY General Extension有效负载格式化如下：
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 Payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! OMA BCAST Data 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 Payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! OMA BCAST Data Subtype (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: OMA BCAST MIKEY General Extension
图1:OMA BCAST MIKEY通用扩展
Next Payload and Length are defined in Section 6.15 of [RFC3830].
[RFC3830]第6.15节定义了下一个有效载荷和长度。
Type (8 bits): identifies the type of the General Extension Payload (see Section 6.15 of [RFC3830]). This document adds a new type. It specifies the use of Type 5 for OMA BCAST Service and Content Protection using the Smartcard Profile.
类型（8位）：标识通用扩展有效载荷的类型（见[RFC3830]第6.15节）。此文档添加了一个新类型。它指定使用智能卡配置文件将类型5用于OMA BCAST服务和内容保护。
Type | Value | Comments
------------------------------------------------------------------
OMA BCAST | 5 | information on type and identity of messages
Type | Value | Comments
------------------------------------------------------------------
OMA BCAST | 5 | information on type and identity of messages
Figure 2: Definition of the OMA BCAST MIKEY General Extension Payload
图2:OMA BCAST MIKEY通用扩展负载的定义
OMA BCAST Data Subtype (variable length): defines a variable length Data field. This field is formed by subtype-payloads. The contents of the variable length OMA BCAST Data Subtype field are defined below.
OMA BCAST数据子类型（可变长度）：定义可变长度数据字段。此字段由子类型有效载荷构成。可变长度OMA BCAST数据子类型字段的内容定义如下。
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 3: STKM/LTKM/LTKM Reporting/Parental Control Subtype Payload
Figure 3: STKM/LTKM/LTKM Reporting/Parental Control Subtype Payload
Subtype: 8 bits. This field indicates the subtype of the OMA BCAST payload. In this specification, four values are specified: LTKM (1), STKM (2), LTKM Reporting (3), and Parental Control (4).
子类型：8位。此字段表示OMA BCAST有效负载的子类型。本规范中规定了四个值：LTKM（1）、STKM（2）、LTKM报告（3）和家长控制（4）。
Subtype Specific Data: Variable length.
子类型特定数据：可变长度。
OMA BCAST Data Subtype | Value | Comment
-----------------------------------------------------------
LTKM | 1 | Long Term Key Message
STKM | 2 | Short Term Key Message
LTKM Reporting | 3 | LTKM Reporting Message
Parental Control | 4 | Parental Control Message
OMA BCAST Data Subtype | Value | Comment
-----------------------------------------------------------
LTKM | 1 | Long Term Key Message
STKM | 2 | Short Term Key Message
LTKM Reporting | 3 | LTKM Reporting Message
Parental Control | 4 | Parental Control Message
Figure 4: Subtype Definitions for OMA BCAST Messages
图4:OMA BCAST消息的子类型定义
The contents of the OMA BCAST Data Subtype payload field are defined in Section 6 of the OMA BCAST Service and Content Protection specification [SPCP].
OMA BCAST数据子类型有效负载字段的内容在OMA BCAST服务和内容保护规范[SPCP]第6节中定义。
This document specifies the use of MIKEY General Extension payload Type 5 and four subtype values: 1 and 2 for OMA BCAST Service and Content protection's LTKM and STKM payloads (respectively), 3 for LTKM Reporting payload, and 4 for Parental Control payload. 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 [RFC3830] and RFC 4563 [RFC4563].
本文档规定使用MIKEY General Extension有效负载类型5和四个子类型值：1和2分别用于OMA BCAST服务和内容保护的LTKM和STKM有效负载，3用于LTKM报告有效负载，4用于家长控制有效负载。互操作性考虑跨越多个标准机构，OMA BCAST 1.0启用码合规性是关键方面；因此，由OMA测试计划来验证OMA BCAST 1.0实现的互操作性和遵从性。此有效负载类型分配不会改变RFC 3830[RFC3830]和RFC 4563[RFC4563]以外的MIKEY。
According to RFC 3830 [RFC3830], 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
根据RFC 3830[RFC3830]，通用扩展有效载荷可用于任何MIKEY消息中，并且是认证/签名数据部分的一部分。建议包含在OMA BCAST MIKEY General Extension有效载荷中的参数（在第3节中列出）只需要完整性保护，这是MIKEY规范已经允许的。OMA BCAST MIKEY通用扩展有效载荷应
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 also covers the General Extension payload.
受到完整性保护。此外，需要保密的密钥或任何参数不得包含在通用扩展有效负载中。如果要通过通用扩展有效载荷传输密钥或其他机密数据，则必须单独对此类数据进行加密和封装。最后，请注意，MIKEY已经提供了重播保护，该保护还包括一般扩展负载。
IANA has allocated an OMA BCAST MIKEY General Extension Type --5-- from the "General Extensions payload name space" for use by OMA BCAST as requested by RFC 4909 [RFC4909]. Furthermore, IANA has created a name space for the OMA BCAST payload subtype values defined in [RFC4909] and has assigned the following subtype values from this name space: LTKM (1), STKM (2).
IANA已根据RFC 4909[RFC4909]的请求，从“通用扩展有效负载名称空间”中分配了OMA BCAST MIKEY General Extension Type-5，供OMA BCAST使用。此外，IANA为[RFC4909]中定义的OMA BCAST有效载荷子类型值创建了一个名称空间，并从该名称空间分配了以下子类型值：LTKM（1）、STKM（2）。
IANA has allocated two new subtypes from the OMA BCAST payload subtype name space.
IANA已从OMA BCAST有效负载子类型名称空间中分配了两个新的子类型。
The subtypes are as follows:
子类型如下所示：
Subtype Name: LTKM Reporting
子类型名称：LTKM报告
Value: 3
价值：3
and
和
Subtype Name: Parental Control
子类型名称：家长控制
Value: 4
价值：4
OMA BCAST Service and Content Protection specification [SPCP] contains messages that were created since RFC 4909 was written. This document only adds the necessary assignments to support these new messages. No modifications are made on values assigned by RFC 4909 [RFC4909].
OMA BCAST服务和内容保护规范[SPCP]包含自编写RFC 4909以来创建的消息。本文档仅添加必要的分配以支持这些新消息。未对RFC 4909[RFC4909]分配的值进行任何修改。
Many thanks to the authors of RFC 4909 [RFC4909] for allowing us to obsolete their RFC.
非常感谢RFC 4909[RFC4909]的作者允许我们淘汰他们的RFC。
[3GPP.33.246] 3GPP, "3G Security; Security of Multimedia Broadcast/ Multicast Service (MBMS)", 3GPP TS 33.246 6.12.0, October 2007.
[3GPP.33.246]3GPP，“3G安全；多媒体广播/多播服务（MBMS）的安全”，3GPP TS 33.246 6.12.012007年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[RFC4563] 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.
[RFC4563]Carrara，E.，Lehtovirta，V.，和K.Norrman，“多媒体互联网键控（MIKEY）中通用扩展有效载荷的密钥ID信息类型”，RFC 4563，2006年6月。
[SPCP] Open Mobile Alliance, "Service and Content Protection for Mobile Broadcast Services", OMA-TS-BCAST_SvcCntProtection-V1_0, <http://www.openmobilealliance.org>.
[SPCP]开放式移动联盟，“移动广播服务的服务和内容保护”，OMA-TS-BCAST\U SvcCntProtection-V1\U 0<http://www.openmobilealliance.org>.
[RFC4909] Dondeti, L., Castleford, D., and F. Hartung, "Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport", RFC 4909, June 2007.
[RFC4909]Dondeti，L.，Castleford，D.，和F.Hartung，“开放移动联盟BCAST LTKM/STKM传输的多媒体互联网键控（MIKEY）通用扩展有效载荷”，RFC 49092007年6月。
Authors' Addresses
作者地址
Anja Jerichow (editor) Nokia Siemens Networks Martinstr. 76 81541 Munich Germany
Anja Jerichow（编辑）诺基亚西门子网络公司。76 81541德国慕尼黑
Phone: +49 89 636-45868
EMail: anja.jerichow@nsn.com
Phone: +49 89 636-45868
EMail: anja.jerichow@nsn.com
Laurent Piron Nagravision S.A. Case Postale 134 1033 Cheseaux Switzerland
Laurent Piron Nagravision S.A.案例邮资134 1033瑞士Cheseaux
Phone: +41 21 732 05 37
EMail: laurent.piron@nagravision.com
Phone: +41 21 732 05 37
EMail: laurent.piron@nagravision.com