RFC4909 日本語訳
4909 Multimedia Internet KEYing (MIKEY) General Extension Payload forOpen Mobile Alliance BCAST LTKM/STKM Transport. L. Dondeti, Ed., D.Castleford, F. Hartung. June 2007. (Format: TXT=12228 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Dondeti, Ed. Request for Comments: 4909 QUALCOMM, Inc. Category: Informational D. Castleford France Telecom F. Hartung Ericsson Research June 2007
ワーキンググループL.Dondeti、エドをネットワークでつないでください。コメントのために以下を要求してください。 4909年のクアルコムInc.カテゴリ: 情報のD.のカッスルフォードフランステレコムF.ハルトゥングエリクソン研究2007年6月
Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport
開いているモバイル同盟BCAST LTKM/STKM輸送のために一般拡大有効搭載量を合わせる(マイキー)マルチメディアインターネット
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).
IETFが信じる著作権(C)(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.
このドキュメントは、オープンのモバイルAlliance(OMA)のブラウザとContent(BAC)放送(BCAST)グループのServiceとContent保護仕様に基づき定義された短期的な主要なメッセージ(STKM)と長い主要なメッセージ(LTKM)ペイロードを輸送するために、新しいMultimediaインターネットKEYing(マイキー)Extension司令官ペイロード(RFC3830)を指定します。
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 OMA BCAST用法. . . . . . . . . . 3 4のためのマイキーGeneralの拡大。 相互運用性問題. . . . . . . . . . . . . . . . 3 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 4 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 4 7。 承認. . . . . . . . . . . . . . . . . . . . . . . . 4 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 5 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 5
Dondeti, et al. Informational [Page 1] RFC 4909 OMA BCAST MIKEY General Extension June 2007
Dondeti、他 情報の[1ページ]RFC4909OMA BCASTマイキー一般拡大2007年6月
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.
MultimediaインターネットKeying(マイキー)プロトコル仕様[1]は、新しいペイロードタイプを割り当てる必要はなくて可能な拡大をマイキーに許すために一般Extensionペイロードを定義します。 一般Extensionペイロードは、どんなマイキーメッセージでも使用できて、認証されたかサインされたデータ部分の一部です。 そのペイロードには8ビットのタイプ分野があります。 タイプコード課題はIANAによって管理されています、そして、RFC3830は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.
オープンのモバイルAlliance(OMA)のブラウザとContent(BAC)放送(BCAST)グループのServiceとContent Protection仕様[2]はServiceに関連する属性とContent保護を運ぶ短期的な主要なメッセージ(STKM)と長い主要なメッセージ(LTKM)の使用を指定します。 属性に関連しているどんなキーもMIKEY KEMACペイロードの一部であることに注意してください。 このドキュメントは、LTKMsかSTKMsを運ぶためにマイキーの一般Extensionペイロードの使用を指定します。
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.
RFC3830[1]、Extensionペイロードが[3]で定義したマイキー司令官、および第3Generation Partnership Project(3GPP)のMultimedia Broadcast/マルチキャストService(MBMS)ドキュメント[4]は、ユニキャストでマイキーメッセージの輸送を指定するか、または放送されます、そして、OMA仕様はマイキーメッセージの輸送にどちらかを使用します。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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マイキーGeneralの拡大: 私たちは5歳の一般ExtensionタイプをOMA BCAST STKM/LTKM MIKEYの司令官のExtensionに差し向けます。
Dondeti, et al. Informational [Page 2] RFC 4909 OMA BCAST MIKEY General Extension June 2007
Dondeti、他 情報の[2ページ]RFC4909OMA BCASTマイキー一般拡大2007年6月
3. MIKEY General Extension for OMA BCAST Usage
3. OMA BCAST用法のためのマイキーGeneralの拡大
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マイキーGeneralの拡大
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.
RFC3830のセクション6.1は、一般Extension有効搭載量の最初の3つの分野を指定して、可変長Data分野を定義します。 このドキュメントは、Smartcard Profileを使用することでType5のOMA BCAST ServiceとContent Protectionの使用を指定します。 可変長データ・フィールドの内容は以下で定義されます。
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).
Subtype: 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].
Subtypeの特定のデータ: 可変長。 この分野の内容はOMA BCAST ServiceとContent Protection仕様[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の特定のデータ(可変長)~+++++++++++++++++++++++++++++++++
Figure 2: STKM/LTKM Subtype Payload
図2: STKM/LTKM Subtype有効搭載量
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].
このドキュメントはマイキーExtension有効搭載量Type5司令官と2、3の「副-タイプ」値(1と2)の使用、OMA BCAST Service、Content保護のSTKM、およびLTKMペイロードのためのそれぞれものを指定します。 相互運用性問題は特徴であるOMA BCAST1.0イネーブラコンプライアンスでいくつかの標準化団体にかかっています。 そういうものとして、OMA BCASTの相互運用性とコンプライアンスについて確かめるのを計画しながらOMAに、1.0の実現がテストされているということです。 このペイロードタイプ課題はRFC3830[1]とRFC4563[3]を超えてマイキーを変えません。
Dondeti, et al. Informational [Page 3] RFC 4909 OMA BCAST MIKEY General Extension June 2007
Dondeti、他 情報の[3ページ]RFC4909OMA BCASTマイキー一般拡大2007年6月
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.
RFC3830によると、一般的な拡大ペイロードは、どんなマイキーメッセージでも使用できて、認証されたかサインされたデータ部分の一部です。 パラメタは、マイキー仕様で既に許されている保護された保全だけであるOMA BCAST MIKEYの一般Extensionペイロード(セクション3では、記載されている)の必要性に含まれているよう提案しました。 OMA BCAST MIKEYの司令官のExtension有効搭載量SHALL、保護された保全になってください。 その上、一般Extension有効搭載量に秘密性を必要とするキーかどんなパラメタも含んではいけません。 キーか他の秘密のデータが一般Extension有効搭載量で輸送されることであるなら、独自にそのようなデータをコード化されて、要約しなければなりません。 最終的に、マイキーが既に反復操作による保護を提供して、保護が一般Extension有効搭載量もカバーすることに注意してください。
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登録の「一般Extensionsペイロード名前空間」から新しい司令官のExtension Typeを割り当てました。その上、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 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、ピロン・ローラン、およびステファン・フリーズをありがとうございます。
Dondeti, et al. Informational [Page 4] RFC 4909 OMA BCAST MIKEY General Extension June 2007
Dondeti、他 情報の[4ページ]RFC4909OMA BCASTマイキー一般拡大2007年6月
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.、ジーター、M.、およびK.Norrman、「マイキー:」 「マルチメディアインターネットの合わせる」RFC3830、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- 20070529C、モバイルAllianceと、「モバイル放送サービスのためのサービスと満足している保護」を開いてください、そして、2007、<http://www.openmobilealliance.org/は_プログラム/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情報は一般拡大有効搭載量のためにマルチメディアインターネットでタイプします」、RFC4563、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 t、33.246、6.6、.0、3月2006日
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
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] 「RFCsにIANA問題部に書くためのガイドライン」というNarten、T.、およびH.Alvestrandは進歩、2007年3月に働いています。
Dondeti, et al. Informational [Page 5] RFC 4909 OMA BCAST MIKEY General Extension June 2007
Dondeti、他 情報の[5ページ]RFC4909OMA BCASTマイキー一般拡大2007年6月
Authors' Addresses
作者のアドレス
Lakshminath Dondeti (editor) QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA
モアハウスサンディエゴ博士、Lakshminath Dondeti(エディタ)クアルコムInc.5775カリフォルニア米国
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、CessonセビニェCedex、悔悟du Clos Courtel35512フランス
Phone: + 33 (0)2 99 12 49 27 EMail: david.castleford@orange-ftgroup.com
以下に電話をしてください。 + 33(0)2 99 12 49 27メール: david.castleford@orange-ftgroup.com
Frank Hartung Ericsson Research Ericsson Allee 1 52134 Herzogenrath, Germany
研究エリクソン並木道1 52134Herzogenrath、率直なハルトゥングエリクソンドイツ
Phone: +49 2407 575389 EMail: frank.hartung@ericsson.com
以下に電話をしてください。 +49 2407 575389はメールされます: frank.hartung@ericsson.com
Dondeti, et al. Informational [Page 6] RFC 4909 OMA BCAST MIKEY General Extension June 2007
Dondeti、他 情報の[6ページ]RFC4909OMA BCASTマイキー一般拡大2007年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Dondeti, et al. Informational [Page 7]
Dondeti、他 情報[7ページ]
一覧
スポンサーリンク