RFC4563 日本語訳
4563 The Key ID Information Type for the General Extension Payload inMultimedia Internet KEYing (MIKEY). E. Carrara, V. Lehtovirta, K.Norrman. June 2006. (Format: TXT=20464 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Carrara
Request for Comments: 4563 KTH
Category: Standards Track V. Lehtovirta
K. Norrman
Ericsson
June 2006
コメントを求めるワーキンググループE.カラーラの要求をネットワークでつないでください: 4563年のKTHカテゴリ: 標準化過程V.Lehtovirta K.Norrmanエリクソン2006年6月
The Key ID Information Type for the General Extension Payload in
Multimedia Internet KEYing (MIKEY)
マルチメディアインターネットの合わせることにおける一般拡大有効搭載量のための主要なID情報タイプ(マイキー)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This memo specifies a new Type (the Key ID Information Type) for the General Extension Payload in the Multimedia Internet KEYing (MIKEY) Protocol. This is used in, for example, the Multimedia Broadcast/Multicast Service specified in the Third Generation Partnership Project.
このメモはMultimediaインターネットKEYing(マイキー)プロトコルで新しいType(Key ID情報Type)を一般Extension有効搭載量に指定します。 これは例えばThird Generation Partnership Projectで指定されたMultimedia Broadcast/マルチキャストServiceで使用されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Rationale .......................................................2
3. Relations to MIKEY and GKMARCH ..................................3
4. The Key ID Information Type for the General Extension Payload ...4
5. Empty Map Type Definition for the CS ID Map Type ................5
6. Transport Considerations ........................................5
7. Security Considerations .........................................5
8. IANA Considerations .............................................7
9. Acknowledgements ................................................7
10. References .....................................................8
10.1. Normative References ......................................8
10.2. Informative References ....................................8
1. 序論…2 1.1. このドキュメントで中古のコンベンション…2 2. 原理…2 3. マイキーとGKMARCHとの関係…3 4. 一般拡大有効搭載量のための主要なID情報タイプ…4 5. Cs ID地図タイプのための地図型定義を空にしてください…5 6. 問題を輸送してください…5 7. セキュリティ問題…5 8. IANA問題…7 9. 承認…7 10. 参照…8 10.1. 標準の参照…8 10.2. 有益な参照…8
Carrara, et al. Standards Track [Page 1] RFC 4563 Key ID for General Extension Payload June 2006
カラーラ、他 規格は有効搭載量2006年6月に一般拡大のためにRFC4563の主要なIDを追跡します[1ページ]。
1. Introduction
1. 序論
The Third Generation Partnership Project (3GPP) is currently involved in the development of a multicast and broadcast service, the Multimedia Broadcast/Multicast Service (MBMS), and its security architecture [MBMS].
Third Generation Partnership Project(3GPP)は現在、マルチキャストの、そして、放送サービスの開発、Multimedia Broadcast/マルチキャストService(MBMS)、およびそのセキュリティー体系[MBMS]にかかわります。
[MBMS] requires the use of the Multimedia Internet KEYing (MIKEY) Protocol [RFC3830] to convey the keys and related security parameters needed to secure multimedia that is multicast or broadcast.
パラメタがマルチメディアがそれであると機密保護するために必要とした関連するセキュリティは、[MBMS]はキーを運ぶためにMultimediaインターネットKEYing(マイキー)プロトコル[RFC3830]の使用を必要として、マルチキャストか放送です。
One of the requirements that MBMS puts on security is the ability to perform frequent updates of the keys. The rationale behind this is that it will be costly for subscribers to re-distribute the decryption keys to non-subscribers. The cost for re-distributing the keys using the unicast channel should be higher than the cost of purchasing the keys for this scheme to have an effect. To implement this, MBMS uses a three-level key management, to distribute group keys to the clients, and be able to re-key by pushing down a new group key. As illustrated in the section below, MBMS has the need to identify which types of keys are involved in the MIKEY message and their identity.
MBMSがセキュリティを置くという要件の1つはキーの履行能力の頻繁なアップデートです。 これの後ろの原理は加入者が非加入者の復号化キーを再配付するのが、高価であるということです。 ユニキャストチャンネルを使用することでキーを再配付するための費用は、この体系には効果があるようにキーを購入する費用より高いはずです。 これを実装するなら、MBMSは、クライアントのグループキーを分配して、新しいグループを押し下げることによって再主要なキーにできるのに3レベルのかぎ管理を使用します。 下のセクションで例証されるように、MBMSにはどのタイプのキーがマイキーメッセージと彼らのアイデンティティにかかわるかを特定する必要があります。
This memo specifies a new Type for the General Extension Payload in MIKEY, to identify the type and identity of keys involved.
このメモは、キーのかかわったタイプとアイデンティティを特定するためにマイキーで一般Extension有効搭載量に新しいTypeを指定します。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Rationale
2. 原理
An application where this extension is used is MBMS key management. The key management solution adopted by MBMS uses three-level key management. The keys are used in the way described below. "Clients" refers to the clients who have subscribed to a given multicast/broadcast service.
この拡大が使用されているアプリケーションはMBMSかぎ管理です。 MBMSによって採用されたかぎ管理解決は3レベルのかぎ管理を使用します。 キーは以下に述べられた方法で使用されます。 「クライアント」は与えられたマルチキャスト/放送サービスに加入したクライアントを示します。
* The MBMS User Key (MUK), a point-to-point key between the multicast
server and each client.
* MBMS User Key(MUK)、マルチキャストサーバと各クライアントの間で主要なポイントツーポイント。
* The MBMS Service Key (MSK), a group key between the multicast
server and all the clients.
* MBMS Service Key(MSK)、マルチキャストサーバとすべてのクライアントの間で主要なグループ。
* The MBMS Traffic Key (MTK), a group traffic key between the
multicast server and all clients.
* MBMS Traffic Key(MTK)、マルチキャストサーバとすべてのクライアントの間で主要なグループトラフィック。
Carrara, et al. Standards Track [Page 2] RFC 4563 Key ID for General Extension Payload June 2006
カラーラ、他 規格は有効搭載量2006年6月に一般拡大のためにRFC4563の主要なIDを追跡します[2ページ]。
The Traffic Keys are the keys that are regularly updated.
Trafficキーズは定期的にアップデートされるキーです。
The point-to-point MUK (first-level key) is shared between the multicast server and the client via means defined by MBMS [MBMS]. The MUK is used as a pre-shared key to run MIKEY with the pre-shared key method [RFC3830], and to deliver (point-to-point) the MSK. The same MSK is pushed to all the clients, to be used as a (second-level) group key.
二地点間MUK(最初に、レベルキー)はマルチキャストサーバとクライアントの間でMBMSによって定義された手段で共有されます[MBMS]。 MUKは、あらかじめ共有された主要なメソッド[RFC3830]でマイキーを車で送って、(ポイントツーポイント)にMSKを提供するのにあらかじめ共有されたキーとして使用されます。 同じMSKは、(2番目の平ら)のグループキーとして使用されるためにすべてのクライアントに押されます。
Then, the MSK is used to push to all the clients an MTK (third-level key), the actual group key that is used for the protection of the media traffic. For example, the MTK could be the master key for the Secure Real-time Transport Protocol (SRTP) [RFC3711] in the streaming case.
そして、MSKは、MTK(第3レベルキー)(メディアトラフィックの保護に使用される実際のグループキー)をすべてのクライアントに押すのに使用されます。 例えば、MTKはストリーミングの場合におけるSecureレアル-時間Transportプロトコル(SRTP)[RFC3711]のためのマスターキーであるかもしれません。
A Key Domain identifier defines the domain where the group keys are valid or applicable. For example, it may define a specific service provider.
Key Domain識別子はグループキーが有効であるか、または適切であるドメインを定義します。 例えば、それは特定のサービスプロバイダーを定義するかもしれません。
To allow the key distribution described above, an indication of the type and identity of keys being carried in a MIKEY message is needed. This indication is carried in a new Type of the General Extension Payload in MIKEY.
上で説明された主要な分配を許すために、タイプのしるしとマイキーメッセージで運ばれるキーのアイデンティティが必要です。 この指示はマイキーで一般Extension有効搭載量の新しいTypeで運ばれます。
It is necessary to specify what Crypto Session ID (CS ID) map type is associated with a given key. There are cases (for example, the download case in MBMS) where the required parameters are signalled in-band (each downloaded Digital Rights Management Content Format object [DCF] contains the necessary parameters needed by the receiver to process it). Since the parameters are not transported by MIKEY, this implies that a CS ID map type needs to be registered to the "empty map", as defined in Table 3, which is to be used when the map/policy information is conveyed outside of MIKEY.
どんなCrypto Session ID(CS ID)地図がタイプされるかを指定するのが与えられたキーに関連しているのが必要です。 そこに、バンドにはケース(例えば、MBMSのダウンロードケース)が必要なパラメタが合図されるところにありますか?(それぞれのダウンロードされたDigital Rights Management Content Formatオブジェクト[DCF]はそれを処理するために受信機によって必要とされた必要なパラメタを含んでいます) パラメタがマイキーによって輸送されないので、これは、CS ID地図タイプが、「空の地図」に登録される必要であるのを含意します、Table3(地図/方針情報がマイキーの外に伝えられるとき、使用されていることになっています)で定義されるように。
3. Relations to MIKEY and GKMARCH
3. マイキーとGKMARCHとの関係
According to [RFC3830], MIKEY is a registration protocol that supports re-keying for unicast in the terms of the MSEC Group Key Management Architecture [RFC4046]. MBMS uses MIKEY both as a registration protocol and a re-key protocol, and the specified extension implements the necessary additions to [RFC3830] that allows MIKEY to function both as a unicast and multicast re-key protocol in the MBMS setting.
[RFC3830]に従って、マイキーはMSEC Group Key Management Architecture[RFC4046]の用語によるユニキャストのための再の合わせることをサポートする登録プロトコルです。 ともに登録プロトコルと再キーが議定書を作るようにMBMSはマイキーを使用します、そして、指定された拡大はユニキャストとマルチキャスト再キーがMBMS設定でともに議定書を作るようにマイキーが機能できる[RFC3830]に必要な追加を実装します。
Carrara, et al. Standards Track [Page 3] RFC 4563 Key ID for General Extension Payload June 2006
カラーラ、他 規格は有効搭載量2006年6月に一般拡大のためにRFC4563の主要なIDを追跡します[3ページ]。
4. The Key ID Information Type for the General Extension Payload
4. 一般拡大有効搭載量のための主要なID情報タイプ
The General Extension payload in MIKEY is defined in Section 6.15 of [RFC3830]. The General Extension payload type (Key ID Information) defined in the present document is not restricted to MBMS. Applications using this General Extension payload type may define new Key ID types, and these applications MUST define the semantics and usage of the Key ID Type sub-payloads according to Section 8. The MBMS use of the Key ID Type sub-payloads, defined in Table 2, is specified in [MBMS].
マイキーの一般Extensionペイロードは[RFC3830]のセクション6.15で定義されます。 現在のドキュメントで定義された一般Extensionペイロードタイプ(主要なID情報)はMBMSに制限されません。この一般Extensionペイロードタイプを使用するアプリケーションは新しいKey IDタイプを定義するかもしれません、そして、これらのアプリケーションはセクション8に従ったサブペイロードのKey ID Typeの意味論と使用法を定義しなければなりません。 Table2で定義されたKey ID TypeサブペイロードのMBMS使用は[MBMS]で指定されます。
The Key ID Information Type (Type 3) formats the General Extension payload as follows:
Key ID情報Type(3をタイプする)は以下の一般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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key ID Information ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ペイロード..ID..情報
Figure 1. The Key ID Information General Extension Payload
図1。 情報の主要なID一般拡大有効搭載量
Next Payload and Length are defined in Section 6.15 of [RFC3830].
次の有効搭載量とLengthは[RFC3830]のセクション6.15で定義されます。
* Type (8 bits): identifies the type of the General Extension
Payload [RFC3830]. This memo adds Type 3 to the ones already
defined in [RFC3830].
* タイプしてください(8ビット): 一般Extension有効搭載量[RFC3830]のタイプを特定します。 このメモは[RFC3830]で既に定義されたものにType3を加えます。
Type | Value | Comments ------------------------------------------------------------ Key ID | 3 | information on type and identity of keys
タイプ| 値| コメント------------------------------------------------------------ 主要なID| 3 | キーのタイプとアイデンティティの情報
Table 1. Definition of the New General Extension Payload
1を見送ってください。 新しい一般拡大有効搭載量の定義
* Key ID Information (variable length): the general payload data
transporting the type and identifier of a key. This field is
formed by Key ID Type sub-payloads as specified below.
* 主要なID情報(可変長): キーに関するタイプと識別子を輸送する一般的なペイロードデータ。 この分野は以下で指定されるとしてのサブペイロードのKey ID Typeによって形成されます。
The Key ID Type sub-payload is formatted as follows:
Key ID Typeサブペイロードは以下の通りフォーマットされます:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Key ID Type ! Key ID Length ! Key ID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
主要..ID..タイプ..キー..ID..長さ..主要..ID
Figure 2. The Key ID Type Sub-payload
図2。 主要なIDタイプサブペイロード
Carrara, et al. Standards Track [Page 4] RFC 4563 Key ID for General Extension Payload June 2006
カラーラ、他 規格は有効搭載量2006年6月に一般拡大のためにRFC4563の主要なIDを追跡します[4ページ]。
* Key ID Type (8 bits): describes the type of the key ID.
Predefined types are listed in Table 2.
* 主要なID Type(8ビット): 主要なIDのタイプについて説明します。 事前に定義されたタイプはTable2に記載されています。
Key ID Type | Value | Comment
-----------------------------------------------------------
MBMS Key Domain ID | 0 | ID of the group key domain
MBMS Service Key ID | 1 | ID of the group key
MBMS Traffic Key ID | 2 | ID of the group traffic key
主要なIDタイプ| 値| コメント----------------------------------------------------------- MBMSの主要なDomain ID| 0 | グループキードメインMBMS Service Key IDのID| 1 | グループキーMBMS Traffic Key IDのID| 2 | グループトラフィックキーのID
Table 2. Type definitions for Key IDs
2を見送ってください。 Key IDのための型定義
* Key ID Length (8 bits): describes the length of the Key ID
field in octets.
* 主要なID Length(8ビット): 八重奏における、Key ID分野の長さについて説明します。
* Key ID (variable length): defines the identity of the key.
* キーID(可変長): キーのアイデンティティを定義します。
Note that there may be more than one Key ID Type sub-payload in an extension, and that the overall length (i.e., the sum of lengths of all Key ID Type sub-payloads) of the Key ID information field cannot exceed 2^16 - 1 octets.
Key ID情報フィールドの全長(すなわち、すべてのKey ID Typeサブペイロードの長さの合計)は2^16を超えることができません--拡大におけるサブペイロードの1Key ID Typeがあるかもしれなくて、1八重奏に注意してください。
5. Empty Map Type Definition for the CS ID Map Type
5. Cs ID地図タイプに、空の地図型定義
When the security policy information is conveyed outside of MIKEY, the CS ID map type is set to a value defined in Table 3 to indicate "empty map". In this case, there MUST NOT be any Security Policy payload present in the message.
安全保障政策情報がマイキーの外に伝えられるとき、CS ID地図タイプは「空の地図」を示すようにTable3で定義された値に用意ができています。 この場合、メッセージの現在のどんなSecurity Policyペイロードもあるはずがありません。
CS ID map type | Value | Comments
-------------------------------------------------------------
Empty map | 1 | Used when the map/policy information
| | is conveyed outside of MIKEY
CS ID地図タイプ| 値| コメント------------------------------------------------------------- 空の地図| 1 | 地図/方針情報であるときに、使用されます。| | マイキーの外まで運ばれます。
Table 3. Definition of the CS ID Map Type.
3を見送ってください。 Cs ID地図タイプの定義。
6. Transport Considerations
6. 輸送問題
As specified in Section 7 of [RFC3830], the underlying transport of the MIKEY protocol has to be defined for each type of transport. When the Key-ID payload is used with MBMS, the transport is UDP, and the usage of MIKEY over UDP in the MBMS setting is defined in [MBMS].
[RFC3830]のセクション7で指定されるように、マイキープロトコルの基本的な輸送はそれぞれのタイプの輸送のために定義されなければなりません。 Key-IDペイロードがMBMSと共に使用されるとき、輸送はUDPです、そして、MBMS設定のUDPの上のマイキーの使用法は[MBMS]で定義されます。
7. Security Considerations
7. セキュリティ問題
The usage of MIKEY for updating the traffic encryption key (MTK) in the broadcast manner, described in Section 2, deviates from the way MIKEY [RFC3830] was originally designed. There are two main points that are related to the security of the described usage.
セクション2で説明された放送方法でトラフィック暗号化キー(MTK)をアップデートするためのマイキーの使用法はマイキー[RFC3830]が元々設計された方法から逸れます。 説明された用法のセキュリティに関連する2つの要点があります。
Carrara, et al. Standards Track [Page 5] RFC 4563 Key ID for General Extension Payload June 2006
カラーラ、他 規格は有効搭載量2006年6月に一般拡大のためにRFC4563の主要なIDを追跡します[5ページ]。
First, the delivery of the MTK is not source origin authenticated, but rather protected by a group MAC, keyed by the group key (MSK). The threat this raises is that users that are part of the group are able to send fake MTK messages to other group members. The origin of the MTK messages is a node inside the core network, and the trust model used in MBMS is that only trusted traffic is allowed to be sent (from within the operator's network) on the MBMS bearers. However, there is always the risk that traffic is injected on the air interface between the base stations and the user equipment. It is possible for members of the group (i.e., with access to the MSK) to spoof MTK updates to other members of the group. 3GPP decided that the technical difficulties and costs involved in performing such an attack are large enough compared to the expected gain for the attacker, that the risk was deemed acceptable. Note that, since the delivery of the MTK is not source origin authenticated, there is nothing gained by adding source origin authentication to the RTP streams (e.g., using SRTP-TESLA [RFC4383]). Hence, the current use of the specified extension is not compatible with SRTP-TESLA, which requires source origin authentication of the integrity key.
まず最初に、MTKの配送は認証されましたが、グループキー(MSK)によって合わせられたグループMACによってむしろ保護された発生源ではありません。 これが上げる脅威はグループの一部であるユーザがにせのMTKメッセージを他のグループのメンバーに送ることができるということです。 MTKメッセージの発生源はコアネットワークでノードです、そして、MBMSで使用される信頼モデルは信じられたトラフィックだけがMBMS運搬人で送ることができるという(オペレータのネットワークから)ことです。 リスクがいつもあります。トラフィックは基地局とユーザ設備との注入された放送されたインタフェースです。 グループ(すなわち、MSKへのアクセスがある)のメンバーがグループの他のメンバーへのアップデートをMTKに偽造するのは、可能です。 3GPPは、攻撃者のために予想された利得と比べて、そのような攻撃を実行するのに伴われる技術的困難とコストが十分大きく、危険が許容できると考えられたと決めました。 何もRTPストリーム(例えば、SRTP-テスラ[RFC4383]を使用する)に発生源認証を加えることによって獲得されたものがMTKの配送が認証された発生源でないのでないことに注意してください。 したがって、指定された拡張子の現在の使用はSRTP-テスラと互換性がありません。(テスラは、保全キーの発生源認証を必要とします)。
Note that in MBMS the MSK is protected end-to-end, from the multicast server to the clients, using a client-unique key MUK, but the MTK is delivered under protection by the group key MSK, so source origin authentication is not achieved.
MSKはMBMSに、保護された終わりから終わりです、クライアントユニークキーMUKを使用してマルチキャストサーバからクライアントまで、しかし、MTKが発生源認証が達成されないようにグループの主要なMSKが保護で提供されることに注意してください。
Secondly, the delivery of the MTK is separated from the delivery of the security policy. The security policy is delivered with the MSK. The delivery of the MTKs is assumed to be frequent (some scenarios require the delivery of MTKs to be as frequent as a few seconds apart). This would imply that the cost (in terms of bandwidth) would be very high if the security policy was delivered together with each MTK. Furthermore, the security policy parameters of the streaming session are not anticipated to change during the session, even though there would be an update of the MTK. It was decided in 3GPP that there was no need for updating the policy during an ongoing session, and that the cost of allowing such a feature, only to be on the safe side, would be too high. On the other hand, updating the security policy during an ongoing session would be possible by updating the MSK.
第二に、MTKの配送は安全保障政策の配送と切り離されます。 安全保障政策はMSKと共に提供されます。 MTKsの配送が頻繁であると思われます(いくつかのシナリオが離れて数秒と同じくらい頻繁であるMTKsの配送を必要とします)。 これは、安全保障政策が各MTKと共に提供されるなら費用(帯域幅に関する)が非常に高いのを含意するでしょう。 その上、ストリーミングのセッションの安全保障政策パラメタはセッションの間、変化するように予期されません、MTKのアップデートがあるでしょうが。 3GPPでは、進行中のセッションの間、方針をアップデートする必要は全くなくて、そのような特徴を許容する費用が安全策を取ってだけ高過ぎると決められました。 他方では、進行中のセッションの間、安全保障政策をアップデートするのはMSKをアップデートすることによって、可能でしょう。
The Empty map type used when the security policy is delivered in band relies on the security provided by DCF [DCF], and MIKEY is, in this case, only used to provide the master key for the DCF processing.
安全保障政策がバンドで提供されるとき使用されるEmpty地図タイプはDCF[DCF]によって提供されたセキュリティを当てにします、そして、マイキーは、この場合DCF処理のためのマスターキーを提供するのに使用されるだけです。
Carrara, et al. Standards Track [Page 6] RFC 4563 Key ID for General Extension Payload June 2006
カラーラ、他 規格は有効搭載量2006年6月に一般拡大のためにRFC4563の主要なIDを追跡します[6ページ]。
8. IANA Considerations
8. IANA問題
According to Section 10 of RFC 3830, IETF consensus is required to register values in the range 0-240 in the Type namespace of the MIKEY General Extension Payload and the CS ID map type namespace of the Common Header Payload.
RFC3830のセクション10によると、IETFコンセンサスが、マイキーGeneralのExtension有効搭載量のType名前空間とCommon Header有効搭載量のCS ID地図タイプ名前空間における範囲0-240に値を示すのに必要です。
A new value in the MIKEY General Extension Payload Type name space has been registered for this purpose. The registered value for Key ID is 3 according to Section 4.
Extension有効搭載量Typeがスペースに任命するマイキー司令官の新しい値はこのために示されました。 セクション4によると、Key IDへの登録された値は3です。
Also, the value 1 has been registered for the Empty map in the existing CS ID map namespace of the Common Header Payload, as specified in Table 3, in Section 5.
また、値1はCommon Header有効搭載量の既存のCS ID地図名前空間におけるEmpty地図のために示されました、Table3で指定されるように、セクション5で。
The new name space for the following field in the Key ID information sub-payload (from Sections 4 and 5) has been established and will be managed by IANA:
Key ID情報サブペイロード(セクション4と5からの)の以下の分野へのスペースという新しい名前は、確立されて、IANAによって管理されるでしょう:
* Key ID Type
* 主要なIDタイプ
The IANA has registered the pre-defined types of Table 2 for this namespace. IANA will also manage the definition of additional values in the future. Values in the range 0-240 for each name space SHOULD be approved by the process of IETF consensus, and values in the range 241-255 are reserved for Private Use, according to [RFC2434].
IANAはこの名前空間のためにTable2の事前に定義されたタイプを示しました。 また、IANAは将来、加算値の定義を管理するでしょう。 承認されていて、それぞれのための範囲0-240の値はIETFコンセンサスのプロセスでスペースをSHOULDと命名します、そして、範囲241-255の値は兵士のUseのために予約されます、[RFC2434]に従って。
9. Acknowledgements
9. 承認
We would like to thank Fredrik Lindholm.
フレドリック・リンドホルムに感謝申し上げます。
Carrara, et al. Standards Track [Page 7] RFC 4563 Key ID for General Extension Payload June 2006
カラーラ、他 規格は有効搭載量2006年6月に一般拡大のためにRFC4563の主要なIDを追跡します[7ページ]。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、カラーラ、E.、リンドホルム、F.、ジーター、M.、およびK.Norrman、「マイキー:」 「マルチメディアインターネットの合わせる」RFC3830、2004年8月。
[MBMS] 3GPP TS 33.246, "Technical Specification 3rd Generation
Partnership Project; Technical Specification Group
Services and System Aspects; Security; Security of
Multimedia Broadcast/Multicast Service".
[MBMS]3GPP t33.246、「仕様書の第3世代パートナーシッププロジェクト」。 仕様書グループサービスとシステム局面。 セキュリティ。 「マルチメディア放送/マルチキャストサービスのセキュリティ。」
10.2. Informative References
10.2. 有益な参照
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3711] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[DCF] Open Mobile Alliance, OMA-DRM-DCF-V2_0-20050329-C, "DRM
Content Format V2.0", Candidate Version 2.0 - 29 March
2005.
[DCF]開いているモバイル同盟、OMA-DRM-DCF-V2_0-20050329C、「DRM内容はV2.0"、候補バージョン2.0をフォーマットします--2005年3月29日。」
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383, February
2006.
[RFC4383] BaugherとM.とE.カラーラ、「安全なリアルタイムのトランスポート・プロトコル(SRTP)における調節された効率的なストリーム損失許容性がある認証(テスラ)の使用」、RFC4383、2006年2月。
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005.
[RFC4046] Baugher、M.、カネッティ、R.、Dondeti、L.、およびF.リンドホルム、「マルチキャストセキュリティ(msec)はKey Managementアーキテクチャを分類します」、RFC4046、2005年4月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Carrara, et al. Standards Track [Page 8] RFC 4563 Key ID for General Extension Payload June 2006
カラーラ、他 規格は有効搭載量2006年6月に一般拡大のためにRFC4563の主要なIDを追跡します[8ページ]。
Authors' Addresses
作者のアドレス
Elisabetta Carrara Royal Institute of Technology Stockholm Sweden
Elisabettaカラーラの王立の工科大学ストックホルムスウェーデン
EMail: carrara@kth.se
メール: carrara@kth.se
Vesa Lehtovirta Ericsson Research 02420 Jorvas Finland
Vesa Lehtovirtaエリクソンの研究02420Jorvasフィンランド
Phone: +358 9 2993314 EMail: vesa.lehtovirta@ericsson.com
以下に電話をしてください。 +358 9 2993314 メール: vesa.lehtovirta@ericsson.com
Karl Norrman Ericsson Research SE-16480 Stockholm Sweden
カール・Norrmanエリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 4044502 EMail: karl.norrman@ericsson.com
以下に電話をしてください。 +46 8 4044502 メール: karl.norrman@ericsson.com
Carrara, et al. Standards Track [Page 9] RFC 4563 Key ID for General Extension Payload June 2006
カラーラ、他 規格は有効搭載量2006年6月に一般拡大のためにRFC4563の主要なIDを追跡します[9ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Carrara, et al. Standards Track [Page 10]
カラーラ、他 標準化過程[10ページ]
一覧
スポンサーリンク
