RFC4909 日本語訳

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ページ]