RFC 4909 - Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport 日本語訳

URL : https://tools.ietf.org/html/rfc4909
タイトル : RFC 4909 - オープン・モバイル・アライアンスBCAST LTKM / STKM輸送のためのマルチメディアインターネットキーイング（MIKEY）一般的な拡張ペイロード
翻訳編集 : 自動生成

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

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.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（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）のブラウザで定義された短期キーメッセージ（STKM）と長期キーメッセージ（LTKM）ペイロードを運ぶために指定し、コンテンツ（BAC）ブロードキャスト（BCAST）グループのサービスおよびコンテンツ保護仕様。

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

1. はじめに

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には、0〜240の公開範囲から割り当てのIETFコンセンサスを必要とします。

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ペイロードの一部であることに注意してください。この文書では、LTKMsまたはSTKMsを運ぶためにMIKEYの一般的な拡張ペイロードの使用を指定します。

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.

[3]で定義されたRFC 3830 [1]、MIKEY一般拡張ペイロード、および第3世代パートナーシッププロジェクト（3GPP）のマルチメディアブロードキャスト/マルチキャストサービス（MBMS）文書[4]ユニキャストまたはブロードキャストを介しMIKEYメッセージのトランスポートを指定しますそして、OMAの仕様は、MIKEYメッセージの輸送のためのいずれかを使用します。

2. Terminology

2.用語

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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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一般延長として。

3. MIKEY General Extension for OMA BCAST Usage

OMAのBCASTの使用のための3 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)      ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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は、一般的な拡張ペイロードの最初の3つのフィールドを指定し、可変長データフィールドを定義します。この文書は、OMA BCASTサービスとスマートカードプロファイルを使用したコンテンツ保護のためのタイプ5の使用を指定します。可変長データフィールドの内容を以下に定義します。

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ペイロードのタイプを示します。本明細書では、唯一の2つの値が指定されている：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サービスの第6節およびコンテンツ保護規格で定義されている[2]。

                         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サブタイプペイロード

4. Interoperability Considerations

4.相互運用性に関する注意事項

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一般的な拡張ペイロードタイプ5とサブタイプ値（1と2）のカップル、OMA BCASTサービス及びコンテンツ保護のSTKMとLTKMペイロードに1つずつの使用を指定します。相互運用性の考慮事項は、OMA BCAST 1.0イネーブラコンプライアンスは重要な側面であることを、いくつかの標準化団体にまたがります。このように、それは、OMA BCAST 1.0実装の相互運用性とコンプライアンスを検証するためのOMAのテスト計画次第です。このペイロードタイプの割り当ては、RFC 3830を超えMIKEYを変更しない[1]およびRFC 4563 [3]。

5. Security Considerations

5.セキュリティについての考慮事項

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.

RFC 3830によれば、一般的な拡張ペイロードは任意MIKEYメッセージで使用され、認証/署名されたデータ部分の一部であることができます。パラメータは既にMIKEY仕様によって許可される完全性保護、であることのみが必要（セクション3に記載されている）OMA BCAST MIKEY一般拡張ペイロードに含めることを提案しました。 OMA BCAST MIKEY一般的な拡張ペイロードは、完全性保護されなければなりません。さらに、キーまたは機密性を必要とするすべてのパラメータは、一般的な拡張ペイロードに含んではいけません。キーまたは他の機密データは、一般的な拡張ペイロードを介して輸送される場合、そのようなデータは暗号化され、独立して、カプセル化されなければなりません。最後に、MIKEYが既に再生保護を提供し、その保護はまた、一般的な拡張ペイロードをカバーすることに注意してください。

6. IANA Considerations

6. IANAの考慮事項

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は、OMA BCASTで使用するためにhttp://www.iana.org/assignments/mikey-payloadsでIANAレジストリ内の「一般的な拡張機能ペイロード名前空間」から、新たな一般的な拡張タイプを割り当てています。次のようにまた、IANAは、対応するサブタイプ（0〜255）のリストを維持します。

0 ... Reserved

0 ...予約

1 ... LTKM

2 ... STKM

3 ... 191 (maintained by IANA and assigned by IETF Review [6])

3 ... 191（IANAによって維持及びIETF Reviewによって割り当てられた[6]）

192 ... 255 (Private use)

192 ... 255（私的使用）

7. Acknowledgments

7.謝辞

Many thanks to Jari Arkko, Piron Laurent, and Steffen Fries for their reviews and suggestions for improvement.

改善のための彼らのレビューと提案のためのヤリArkko、ピロンローラン、とステファンのフライドポテトに感謝します。

8. References

8.参照文献

8.1. Normative References

8.1. 引用規格

[1] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.

[1] Arkko、J.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK.ノルウェー、 "MIKEY：マルチメディアインターネットキーイング"、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/ release_program / bcast_v1_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]カララ、E.、Lehtovirta、V.、およびK. Norrman、 "マルチメディアインターネットキーイング（マイキー）での一般的な拡張ペイロードのためのキーの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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

8.2. Informative References

8.2. 参考文献

[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 Dandeti（編集）クアルコム、これ。 5775 Morehuse博士サンディエゴ、それかどうか

Phone: +1 858-845-1267 EMail: ldondeti@qualcomm.com

電話：+1 858-845-1267電子メール：ldondeti@qualcomm.com

David Castleford France Telecom 4, rue du Clos Courtel 35512 Cesson Sevigne Cedex, France

デビッド・キャッスルフランステレコム4、RUEデュクロCourtel 35512セッソンセヴィニエセデックス、フランス

Phone: + 33 (0)2 99 12 49 27 EMail: david.castleford@orange-ftgroup.com

電話：+ 33（0）2 99 12 49 27 Eメール：david.castleford@orange-ftgroup.com

Frank Hartung Ericsson Research Ericsson Allee 1 52134 Herzogenrath, Germany

フランク・アルトゥングエリクソン研究エリクソンアリー1 52134 Herzogenrathの、ドイツ

Phone: +49 2407 575389 EMail: frank.hartung@ericsson.com

電話：+49 2407 575389 Eメール：frank.hartung@ericsson.com

Full Copyright Statement

完全な著作権声明

著作権（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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。