RFC4738 日本語訳
4738 MIKEY-RSA-R: An Additional Mode of Key Distribution in MultimediaInternet KEYing (MIKEY). D. Ignjatic, L. Dondeti, F. Audet, P. Lin. November 2006. (Format: TXT=43015 bytes) (Updates RFC3830) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Ignjatic
Request for Comments: 4738 Polycom
Updates: 3830 L. Dondeti
Category: Standards Track QUALCOMM
F. Audet
P. Lin
Nortel
November 2006
Ignjaticがコメントのために要求するワーキンググループD.をネットワークでつないでください: 4738のPolycomアップデート: 3830年のL.Dondetiカテゴリ: 標準化過程クアルコムF.Audet P.リンノーテル2006年11月
MIKEY-RSA-R: An Additional Mode of Key Distribution
in Multimedia Internet KEYing (MIKEY)
マイキー-RSA-R: マルチメディアインターネットの合わせることにおける、主要な分配の追加方法(マイキー)
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 IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
Abstract
要約
The Multimedia Internet Keying (MIKEY) specification describes several modes of key distribution solution that address multimedia scenarios (e.g., SIP calls and Real Time Streaming Protocol (RTSP) sessions) using pre-shared keys, public keys, and optionally a Diffie-Hellman key exchange. In the public-key mode, the Initiator encrypts a random key with the Responder's public key and sends it to the Responder. In many communication scenarios, the Initiator may not know the Responder's public key, or in some cases the Responder's ID (e.g., call forwarding) in advance. We propose a new MIKEY mode that works well in such scenarios. This mode also enhances the group key management support in MIKEY; it supports member-initiated group key download (in contrast to group manager pushing the group keys to all members). This document updates RFC 3830 with the RSA-R mode.
MultimediaインターネットKeying(マイキー)仕様はあらかじめ共有されたキーを使用することでマルチメディアシナリオ(例えば、SIP呼び出しとレアルTime Streamingプロトコル(RTSP)セッション)を記述する主要な分配対策のいくつかの様式、公開鍵、および任意にaディフィー-ヘルマン主要な交換について説明します。 公開カギモードで、InitiatorはResponderの公開鍵でランダムキーをコード化して、それをResponderに送ります。 多くのコミュニケーションシナリオでは、Initiatorはあらかじめ、Responderの公開鍵、またはいくつかの場合ResponderのID(例えば、自動転送)を知らないかもしれません。 私たちはそのようなシナリオでうまくいく新しいマイキーモードを提案します。 また、このモードはマイキーでグループかぎ管理サポートを機能アップします。 それはメンバーによって開始されたグループキーダウンロード(すべてのメンバーのグループキーを押しているグループのマネージャと対照して)を支持します。 このドキュメントはRSA-RモードでRFC3830をアップデートします。
Ignjatic, et al. Standards Track [Page 1] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology Used in This Document ..........................3
2. Motivation ......................................................3
2.1. Description of the MIKEY Modes .............................3
2.2. Use Case Motivating the Proposed Mode ......................5
3. A New MIKEY-RSA Mode: MIKEY-RSA-R ...............................5
3.1. Outline ....................................................5
3.2. Group Communication Using the MIKEY RSA-R Mode .............6
3.3. Preparing RSA-R Messages ...................................6
3.4. Components of the I_MESSAGE ................................6
3.5. Processing the I_MESSAGE ...................................8
3.6. Components of the R_MESSAGE ................................9
3.7. Processing the R_MESSAGE ..................................10
3.8. Certificate Handling ......................................10
3.9. Additions to RFC 3830 Message Types and Other Values ......11
3.9.1. Modified Table 6.1a from RFC 3830 ..................11
3.9.2. Modified Table 6.12 from RFC 3830 ..................12
3.9.3. Modified Table 6.15 from RFC 3830 ..................12
4. Applicability of the RSA-R and RSA Modes .......................13
4.1. Limitations ...............................................13
5. Security Considerations ........................................14
5.1. Impact of the Responder Choosing the TGK ..................15
5.2. Updates to Security Considerations in RFC 3830 ............15
6. IANA Considerations ............................................15
7. Acknowledgments ................................................16
8. References .....................................................16
8.1. Normative References ......................................16
8.2. Informative References ....................................16
1. 序論…3 1.1. このドキュメントで中古の用語…3 2. 動機…3 2.1. マイキーモードの記述…3 2.2. 提案されたモードを動機づけるケースを使用してください…5 3. 新しいマイキー-RSAモード: マイキーRSA R…5 3.1. 概説します。5 3.2. マイキーRSA-Rモードを使用して、コミュニケーションを分類してください…6 3.3. RSA-Rにメッセージを準備します…6 3.4. I_の部品は通信します…6 3.5. I_メッセージを……………………………処理します。8 3.6. R_メッセージの成分…9 3.7. R_メッセージを処理します…10 3.8. 取り扱いを証明してください…10 3.9. RFC3830メッセージタイプへの追加と他の値…11 3.9.1. RFC3830からテーブル6.1aを変更します…11 3.9.2. RFC3830からテーブル6.12を変更します…12 3.9.3. RFC3830からテーブル6.15を変更します…12 4. RSA-RとRSAモードの適用性…13 4.1. 制限…13 5. セキュリティ問題…14 5.1. TGKを選ぶ応答者の衝撃…15 5.2. RFC3830のセキュリティ問題に、アップデートします。15 6. IANA問題…15 7. 承認…16 8. 参照…16 8.1. 標準の参照…16 8.2. 有益な参照…16
Ignjatic, et al. Standards Track [Page 2] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[2ページ]。
1. Introduction
1. 序論
The MIKEY protocol [RFC3830] has three different methods for key transport or exchange: a pre-shared key mode (PSK), a public-key (RSA) mode, and an optional Diffie-Hellman exchange (DHE) mode. In addition, there is also an optional DH-HMAC mode [RFC4650], bringing the total number of modes to four. The primary motivation for the MIKEY protocol design is low-latency requirements of real-time communication, and thus all the exchanges finish in one-half to 1 roundtrip; note that this offers no room for security parameter negotiation of the key management protocol itself. In this document, we note that the MIKEY modes defined in [RFC3830] and [RFC4650] are insufficient to address some deployment scenarios and common use cases, and we propose a new mode called MIKEY-RSA in Reverse mode, or simply MIKEY-RSA-R. This document updates RFC 3830 with the addition of this new mode to that specification.
マイキープロトコル[RFC3830]には、主要な輸送か交換のための3つの異なった方法があります: あらかじめ共有された主要なモード(PSK)、公開カギ(RSA)モード、および任意のディフィー-ヘルマンは(DHE)モードを交換します。 さらに、また、モードの総数を4にもたらして、任意のDH-HMACモード[RFC4650]があります。 マイキープロトコルデザインに関する第一の動機は瞬時通信の低遅延要件です、そして、その結果、すべての交換が1つの往復旅行への半分で終わります。 これがかぎ管理プロトコル自体のセキュリティパラメタ交渉の余地を全く提供しないことに注意してください。 本書では、私たちは[RFC3830]と[RFC4650]で定義されたマイキーモードがシナリオの、そして、一般の使用がケースに入れる何らかの展開を記述するためには不十分であり、Reverseモード、または単にマイキー-RSA-Rでマイキー-RSAと呼ばれる新型を提案することに注意します。 このドキュメントはその仕様へのこの新型の追加でRFC3830をアップデートします。
1.1. Terminology 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 BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
Furthermore, this document reuses the terminology of the MIKEY specification [RFC3830].
その上、このドキュメントはマイキー仕様[RFC3830]の用語を再利用します。
2. Motivation
2. 動機
As noted in the introduction, the MIKEY specification and other proposals define four different modes of efficient key management for real-time applications. Those modes differ from each other in either the authentication method of choice (public-key, or symmetric shared key-based), or the key establishment method of choice (key download, or key agreement using a Diffie-Hellman exchange). We summarize these modes below, including their advantages and shortcomings. We then discuss the use cases where these modes are unusable or inefficient.
序論、マイキー仕様で同じくらい有名で他の提案はリアルタイムのアプリケーションのための効率的なかぎ管理の4つの異なった方法を定義します。 それらのモードが選択の認証方法で互いに異なっている、(公開カギ、左右対称である、キーベースで共有される、)、または、選択(主要なダウンロード、またはディフィー-ヘルマンの交換を使用する主要な協定)の主要な設立方法。 私たちは以下の彼らの利点と短所を含むこれらのモードをまとめます。 次に、私たちは使用について議論します。これらのモードが使用不可能であるか、または効率が悪いケース。
2.1. Description of the MIKEY Modes
2.1. マイキーモードの記述
The PSK mode requires that the Initiator and the Responder have a common secret key established offline. In this mode, the Initiator selects a TEK Generation Key (TGK), encrypts it with a key derived from the PSK, and sends it to the Responder as part of the first message, namely, I_MESSAGE. The I_MESSAGE is replay protected with timestamps, and integrity protected with another key derived from the PSK. An optional Verification message from the Responder to the
PSKモードは、InitiatorとResponderが一般的な秘密鍵をオフラインで設立させるのを必要とします。 このモードで、InitiatorはTEK Generation Key(TGK)を選択して、PSKから得られたキーでそれをコード化して、すなわち、最初のメッセージの一部、I_MESSAGEとしてそれをResponderに送ります。 I_MESSAGEはタイムスタンプで保護された再生です、そして、保全はPSKから得られた別のキーで保護されました。 任意のVerificationはResponderから通信します。
Ignjatic, et al. Standards Track [Page 3] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[3ページ]。
Initiator provides mutual authentication. This mode does not scale well as it requires pre-establishment of a shared key between communicating parties; for example, consider the use cases where any user may want to communicate to any other user in an Enterprise or the Internet at large. The RSA mode might be more suitable for such applications.
創始者は互いの認証を提供します。 パーティーを伝えることの間の共有されたキーをプレ設立に要求するとき、このモードはよく比例しません。 例えば、使用がどんなユーザもエンタープライズか全体のインターネットのいかなる他のユーザにも交信したがっているかもしれないケースであると考えてください。 RSAモードはそのようなアプリケーションにより適しているかもしれません。
In the RSA mode, the Initiator selects a TGK, encrypts and authenticates it with an envelope key, and sends it to the Responder as part of the I_MESSAGE. The Initiator includes the envelope key, encrypted with the Responder's public key, in the I_MESSAGE. The I_MESSAGE is replay protected with timestamps, and signed with the Initiator's public key. The Initiator's ID, Certificate (CERT), and the Responder's ID may be included in the I_MESSAGE. If the Initiator knows several public keys of the Responder, it can indicate the key used in the optional CHASH payload. An optional Verification message from the Responder to the Initiator provides mutual authentication. The RSA mode works well if the Initiator knows the Responder's ID and the corresponding CERT (or can obtain the CERT independent of the MIKEY protocol). RFC 3830 suggests that an Initiator, in the event that it does not have the Responder's CERT, may obtain the CERT from a directory agent using one or more roundtrips. However, in some cases, the Initiator may not even know the Responder's ID in advance, and because of that or for other reasons cannot obtain the Responder's CERT.
RSAモードで、InitiatorはTGKを選択して、封筒キーでそれをコード化して、認証して、I_MESSAGEの一部としてそれをResponderに送ります。 Initiatorは主要で、コード化されたI_MESSAGEにあるResponderの公開鍵で封筒を含んでいます。 I_MESSAGEはタイムスタンプで保護されて、Initiatorの公開鍵を契約された再生です。 InitiatorのID、Certificate(CERT)、およびResponderのIDはI_MESSAGEに含まれるかもしれません。 InitiatorがResponderのいくつかの公開鍵を知っているなら、それは任意のCHASHペイロードで使用されるキーを示すことができます。 ResponderからInitiatorまでの任意のVerificationメッセージは互いの認証を提供します。 InitiatorがResponderのIDと対応するCERT(または、マイキープロトコルの如何にかかわらずCERTを入手できる)を知っているなら、RSAモードはうまくいきます。 RFC3830は、ResponderのCERTを持っていない場合Initiatorがディレクトリエージェントから1つ以上の往復旅行を使用することでCERTを入手するかもしれないのを示します。 しかしながら、いくつかの場合、InitiatorはあらかじめResponderのIDを知ってさえいないかもしれなくて、それか他の理由にResponderのCERTを入手できません。
In addition to the case where the Responder may have several IDs, some applications may allow for the Responder's ID to change unilaterally, as is typical in telephony (e.g., forwarding). In those cases and in others, the Initiator might be willing to let the other party establish identity and prove it via an Initiator-trusted third party (e.g., a Certification Authority (CA)).
ResponderがいくつかのIDを持っているかもしれないケースに加えて、いくつかのアプリケーションが、ResponderのIDが一方的に、そのままで電話(例えば、推進)で典型的に変化するのを許容するかもしれません。 それらのケースの中と、そして、他のものでは、Initiatorは、相手にInitiator-信頼できる第三者機関(例えば、認証局(カリフォルニア))を通してアイデンティティを確立し、それを立証させても構わないと思っているかもしれません。
The DH mode or the DH-HMAC mode of MIKEY might be useful in cases where the Initiator does not have access to the Responder's exact identity and/or CERT. In these modes, the two parties engage in an authenticated DH exchange to derive the TGK. On the downside, the DH modes have higher computational and communication overhead compared to the RSA and the PSK modes. More importantly, these modes are unsuitable for group key distribution. The DH-HMAC mode also requires establishment of PSKs between all possible communicating entities and thus has similar scaling issues as any PSK-based key management protocol.
DHモードかマイキーのDH-HMACモードがInitiatorがResponderの正確なアイデンティティ、そして/または、CERTに近づく手段を持っていない場合で役に立つかもしれません。 これらのモードで、2回のパーティーが、TGKを引き出すことを認証されたDH交換に約束します。 下落傾向では、DHモードで、コンピュータとコミュニケーションの、より高いオーバーヘッドをRSAとPSKモードにたとえます。 より重要に、グループキー分配には、これらのモードは不適当です。 DH-HMACモードは、また、すべての可能な交信実体の間のPSKsを設立に要求して、その結果、どんなPSKを拠点とするかぎ管理も議定書を作るとき、同様のスケーリング問題を持っています。
In summary, in some communication scenarios -- where the Initiator might not have the correct ID and/or the CERT of the Responder -- none of the MIKEY modes described in [RFC3830] or [RFC4650] are suitable and efficient for multimedia session key establishment.
概要、Initiatorには正しいID、そして/または、ResponderのCERTがないかもしれないところのいくつかのコミュニケーションシナリオでは、マルチメディアのセッションの主要な設立には、[RFC3830]か[RFC4650]で説明されたマイキーモードのいずれも、適当であって、効率的ではありません。
Ignjatic, et al. Standards Track [Page 4] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[4ページ]。
2.2. Use Case Motivating the Proposed Mode
2.2. 提案されたモードを動機づけるケースを使用してください。
In addition to the issues listed above, there are some types of applications that motivate the new MIKEY mode design proposed in this document.
上に記載された問題に加えて、本書では提案された新しいマイキーモードデザインを動機づける何人かのタイプの利用があります。
Note that in the MIKEY-RSA mode (as in case of the PSK mode), the Initiator proposes the session security policy and chooses the TGK. However, it is also possible that the Initiator wants to allow the Responder to specify the security policy and send the TGK. Consider for example, the case of a conferencing scenario where the convener sends an invitation to a group of people to attend a meeting. The procedure then might be for the invitees to request group key material from the convener by sending a MIKEY I_MESSAGE. Thus, in the MIKEY definition of initiators and responders, the Initiator is asking the Responder for keying material. Note that this mode of operation is in line with the MSEC group key management architecture [RFC4046].
マイキー-RSAモード(PSKモードの場合に)で、Initiatorがセッション安全保障政策を提案して、TGKを選ぶことに注意してください。 しかしながら、また、Initiatorが、Responderが安全保障政策を指定して、TGKを送るのを許容したがっているのも、可能です。 例えば、考えてください、召集者がミーティングに出席するために人々のグループへの招待状を送る会議シナリオに関するケース。 そして手順は招待参加者が召集者からマイキーI_MESSAGEを送ることによってグループキーの材料を要求することであるかもしれません。 したがって、創始者と応答者のマイキー定義では、Initiatorは材料を合わせるのをResponderに求めています。 MSECグループかぎ管理構造[RFC4046]に沿ってこの運転モードがあることに注意してください。
3. A New MIKEY-RSA Mode: MIKEY-RSA-R
3. 新しいマイキー-RSAモード: マイキー-RSA-R
3.1. Outline
3.1. アウトライン
The proposed MIKEY mode requires 1 full roundtrip. The Initiator sends a signed I_MESSAGE to the intended Responder requesting the Responder to send the traffic keying material. The I_MESSAGE MAY contain the Initiator's CERT or a link (URL) to the CERT, and similarly the Responder's reply, R_MESSAGE, MAY contain the Responder's CERT or a link to it. The Responder can use the Initiator's public key from the CERT in the I_MESSAGE to send the encrypted TGK in the R_MESSAGE. Upon receiving the R_MESSAGE, the Initiator can use the CERT in the R_MESSAGE to verify whether the Responder is in fact the party that it wants to communicate to, and accept the TGK. We refer to this protocol as MIKEY-RSA in the reverse mode, or simply as MIKEY-RSA-R.
提案されたマイキーモードは1つの完全な往復旅行を必要とします。 Initiatorは交通に材料を合わせさせるようResponderに要求する意図しているResponderにサインされたI_MESSAGEを送ります。 I_MESSAGE MAYはInitiatorのCERTかリンク(URL)をCERTに含んでいます、そして、同様に、Responderの回答(R_MESSAGE)はResponderのCERTかそれへのリンクを含むかもしれません。 Responderは、R_MESSAGEでコード化されたTGKを送るのにI_MESSAGEでCERTからInitiatorの公開鍵を使用できます。 R_MESSAGEを受けると、Initiatorは、事実上、ResponderがそれがTGKを交信して、受け入れたがっているパーティーであるかどうか確かめるのにR_MESSAGEでCERTを使用できます。 私たちは逆のモードによるマイキー-RSA、または単にマイキー-RSA-Rとこのプロトコルを呼びます。
The MIKEY-RSA-R mode exchange is defined as follows:
マイキー-RSA-Rモード交換は以下の通り定義されます:
Initiator Responder --------- ---------
創始者応答者--------- ---------
I_MESSAGE = HDR, T, [RAND], [IDi|CERTi], [IDr], {SP}, SIGNi
I_メッセージ=HDR、T、[底ならし革]、[IDi| CERTi]、[IDr]、SP、SIGNi
R_MESSAGE = HDR, [GenExt(CSB_ID)], T, [RAND], [IDr|CERTr], [SP],
KEMAC, PKE, SIGNr
R_メッセージ=HDR、[GenExt(CSB_ID)]、T、[底ならし革]、[IDr| CERTr]、[SP]、KEMAC、PKE、SIGNr
Figure 1: MIKEY-RSA-R Unicast Mode
図1: マイキー-RSA-Rユニキャストモード
Ignjatic, et al. Standards Track [Page 5] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[5ページ]。
3.2. Group Communication Using the MIKEY RSA-R Mode
3.2. マイキーRSA-Rモードを使用するグループコミュニケーション
For group conferencing using MIKEY RSA-R mode, the members receive an invitation to initiate MIKEY with the group key server to download the secure session information. In this case, the Responder is either the group sender or group key server. Group members request group policy and keying material as MIKEY RSA-R Initiators. Initiators MUST NOT send the SP payload. The Responder sends all the payloads necessary to distribute the secure group policy as well as payloads used in the group key derivation: specifically, the SP payload is used to convey the session policy, and the GenExt(CSB-ID), TGK, and the RAND payloads selected by the Responder and included in the R_Message are used to compute the Secure Realtime Transport Protocol (SRTP) session keys.
MIKEY RSA-Rモードを使用するグループ会議のために、メンバーは安全なセッション情報をダウンロードするためにグループキーサーバでマイキーを開始する招待状を受けます。 この場合、Responderはグループの送付者かグループキーサーバです。グループのメンバーはマイキーRSA-R Initiatorsとしてグループ方針と合わせることの材料を要求します。 創始者はSPペイロードを送ってはいけません。 Responderはグループキー派生に使用されるペイロードと同様に安全なグループ方針を分配するのに必要なすべてのペイロードを送ります: 明確に、SPペイロードはセッション方針を伝えるのに使用されます、そして、GenExt(CSB-ID)、TGK、およびResponderによって選択されて、R_Messageに含まれたRANDペイロードは、Secure Realtime Transportプロトコル(SRTP)セッションキーを計算するのに使用されます。
MIKEY RSA-R for group communication:
グループコミュニケーションのためのMIKEY RSA-R:
Initiator Responder --------- ---------
創始者応答者--------- ---------
I_MESSAGE = HDR, T, [RAND], [IDi|CERTi], [IDr], SIGNi
I_メッセージ=HDR、T、[底ならし革]、[IDi| CERTi]、[IDr]、SIGNi
R_MESSAGE = HDR, GenExt(CSB_ID), T, RAND, [IDr|CERTr], SP,
KEMAC, PKE, SIGNr
R_メッセージ=HDR、GenExt(CSB_ID)、T、底ならし革、[IDr| CERTr]、SP、KEMAC、PKE、SIGNr
Figure 2: MIKEY-RSA-R in Group Mode
図2: グループモードによるマイキー-RSA-R
Note that the SP payload in the I_MESSAGE is not present. In the R_MESSAGE, the CSB_ID, RAND, and SP payloads are not optional.
I_MESSAGEのSPペイロードが存在していないことに注意してください。 R_MESSAGEでは、CSB_ID、RAND、およびSPペイロードは任意ではありません。
3.3. Preparing RSA-R Messages
3.3. RSA-Rにメッセージを準備します。
Preparation and parsing of RSA-R messages are as described in Sections 5.2 and 5.3 of RFC 3830. Error handling is described in Section 5.1.2 and replay protection guidelines are in Section 5.4 of RFC 3830. In the following, we describe the components of RSA-R messages and specify message processing and parsing rules in addition to those in RFC 3830.
RSA-Rメッセージの準備と構文解析がRFC3830のセクション5.2と5.3で説明されるようにあります。 エラー処理はセクション5.1.2で説明されます、そして、反復操作による保護ガイドラインがRFC3830のセクション5.4にあります。 以下では、私たちは、RSA-Rメッセージの成分について説明して、RFC3830のそれらに加えてメッセージ処理と構文解析規則を指定します。
3.4. Components of the I_MESSAGE
3.4. I_メッセージの成分
MIKEY-RSA-R requires a full roundtrip to download the TGKs. The I_MESSAGE MUST have the MIKEY HDR and the timestamp payload for replay protection. The HDR field contains a CSB_ID (Crypto Session Bundle ID) randomly selected by the Initiator. The V bit MUST be set to '1' and ignored by the Responder, as a response is MANDATORY in this mode. The Initiator SHOULD indicate the number of CSs supported, and SHOULD fill in the CS ID map type and CS ID info
マイキー-RSA-Rは、TGKsをダウンロードするために完全な往復旅行を必要とします。 I_MESSAGE MUSTには、反復操作による保護のためのMIKEY HDRとタイムスタンプペイロードがあります。 HDR分野はInitiatorによって手当たりしだいに選択されたCSB_ID(暗号Session Bundle ID)を含んでいます。 Vビットを'1'に設定されて、Responderは無視しなければなりません、このモードで応答がMANDATORYであるので。 Initiator SHOULDは、CSsの数が支持したのを示します、そして、SHOULDはCS ID地図タイプとCS IDインフォメーションに記入します。
Ignjatic, et al. Standards Track [Page 6] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[6ページ]。
fields for the RTP/RTCP streams it originates. This is because the sender of the streams chooses the SSRC that is carried in the CS ID info field; see Section 6.1.1 of RFC 3830. The exception to Initiators not specifying SSRC values is to allow the Responder to pick them to avoid SSRC collisions. Initiators of MIKEY messages that do not originate RTP streams MUST specify a '0' as the number of CSs supported. This typically applies to group communication and to the entities in the listen-only mode.
それが溯源するRTP/RTCPの流れのための分野。 これは流れの送付者がCS IDインフォメーション分野で運ばれるSSRCを選ぶからです。 .1セクション6.1RFC3830を見てください。 SSRC値を指定しないInitiatorsへの例外はResponderがSSRC衝突を避けるためにそれらを選ぶのを許容することです。 RTPの流れを溯源しないマイキーメッセージの創始者は支持されたCSsの数として'0'を指定しなければなりません。 これがグループコミュニケーションと、そして、実体に通常適用する、聴取、-単に、モード。
The I_MESSAGE MUST be signed by the Initiator following the procedure to sign MIKEY messages specified in RFC 3830. The SIGNi payload contains this signature. Thus, the I_MESSAGE is integrity and replay protected.
I_MESSAGE MUST、RFC3830で指定されたマイキーメッセージにサインするように手順に従うInitiatorによってサインされてください。 SIGNiペイロードはこの署名を含んでいます。 したがって、I_MESSAGEは保全です、そして、再生は保護されました。
The RAND payload SHOULD be included in the I_MESSAGE when MIKEY-RSA-R mode is used for unicast communication. The reason for recommending the inclusion of the RAND payload in the I_MESSAGE for unicast communication is to allow the Initiator to contribute entropy to the key derivation process (in addition to the CSB_ID). When the RAND payload is not included, the Initiator will be relying on the Responder to supply all the entropy for SRTP key generation, which is in fact similar (but with the reversal of roles) to the MIKEY-RSA mode, where the Responder supplies all the entropy.
RANDペイロードSHOULD、マイキー-RSA-Rモードがユニキャストコミュニケーションに使用されたらI_MESSAGEで含められてください。 ユニキャストコミュニケーションのためにI_MESSAGEでのRANDペイロードの包含を推薦する理由はInitiatorが主要な派生の過程(CSB_IDに加えた)にエントロピーを寄付するのを許容することです。 RANDペイロードが含まれていないとき、Initiatorは、すべてのエントロピーをSRTPキー生成に供給するためにResponderを当てにするでしょう。(事実上、キー生成はマイキー-RSAモードと同様です(しかし役割の逆転で))。そこでは、Responderがすべてのエントロピーを供給します。
The RAND payload MAY be included when MIKEY-RSA-R is used to establish group keys. However, the RAND payload in the I_MESSAGE MUST NOT be used for MIKEY key generation, in case of group communication. The Responder MUST include a RAND payload in the R_MESSAGE for TEK generation from a TGK when MIKEY-RSA-R is used for group communication.
マイキー-RSA-Rがグループキーを証明するのに使用されるとき、RANDペイロードは含まれるかもしれません。 しかしながら、RANDペイロード、I_MESSAGE MUST NOTでは、グループコミュニケーションの場合にマイキーキー生成に使用されてください。 マイキー-RSA-Rがグループコミュニケーションに使用されるとき、ResponderはTGKからのTEK世代のためにR_MESSAGEにRANDペイロードを含まなければなりません。
IDi and CERTi SHOULD be included, but they MAY be left out when it is expected that the peer already knows the Initiating party's ID (or can obtain the certificate in some other manner). For example, this could be the case if the ID is extracted from SIP. For certificate handling, authorization, and policies, see Sections 4.3 and 6.7 of RFC 3830. If CERTi is included, it MUST correspond to the private key used to sign the I_MESSAGE.
同輩が既に、InitiatingパーティーのID(または、ある他の方法による証明書を入手できる)を知ると予想されるとき、IDiとCERTi SHOULDが含まれていて、それらだけを省いてもよいです。 例えば、IDがSIPから抽出されるなら、これはそうであるかもしれません。 証明書取り扱い、認可、および方針に関しては、RFC3830のセクション4.3と6.7を見てください。 CERTiが含まれているなら、それはI_MESSAGEにサインするのに使用される秘密鍵に対応しなければなりません。
If the Responder has multiple identities, the Initiator MAY also include the specific identity, IDr, of the Responder with whom communication is desired. If the Initiator's policy does not allow acceptance of an R_MESSAGE from any entity other than one that can assert a specific identity, the Initiator MUST include that specific identity in an IDr payload in the I_MESSAGE.
また、Responderに複数のアイデンティティがあるなら、Initiatorは特定のアイデンティティ、コミュニケーションが望まれているResponderのIDrを含むかもしれません。 Initiatorの方針が特定のアイデンティティについて断言できるもの以外のどんな実体からもR_MESSAGEの承認を許容しないなら、InitiatorはI_MESSAGEのIDrペイロードにその特定のアイデンティティを含まなければなりません。
Ignjatic, et al. Standards Track [Page 7] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[7ページ]。
The Initiator MAY also send security policy (SP) payload(s) containing all the security policies that it supports. If the Responder does not support any of the policies included, it SHOULD reply with an Error message of type "Invalid SPpar" (Error no. 10). The Responder has the option not to send the Error message in MIKEY if a generic session establishment failure indication is deemed appropriate and communicated via other means (see Section 4.1.2 of [RFC4567] for additional guidance).
また、Initiatorはそれが支持するすべての安全保障政策を含む安全保障政策(SP)ペイロードを送るかもしれません。 Responderが、方針のどれかを含んでいるのを支持しないなら、それはErrorと共にタイプ「無効のSPpar」(誤りNo.10)について通信しますSHOULDが、返答する。 一般的なセッション設立失敗指示が適切であると考えられて、他の手段で伝えられるなら(追加指導に関して.2セクション4.1[RFC4567]を見てください)、ResponderはマイキーにErrorメッセージを送らないオプションを持っています。
SIGNi is a signature covering the Initiator's MIKEY message, I_MESSAGE, using the Initiator's signature key (see Section 5.2 of RFC 3830 for the exact definition). The signature assures the Responder that the claimed Initiator has indeed generated the message. This automatically provides message integrity as well.
SIGNiはInitiatorのマイキーメッセージをカバーする署名です、I_MESSAGE、Initiatorの署名キーを使用して(正確な定義に関してRFC3830のセクション5.2を見てください)。 署名は、本当に、要求されたInitiatorがメッセージを発生させたことをResponderに保証します。 これは自動的にまた、メッセージの保全を提供します。
3.5. Processing the I_MESSAGE
3.5. I_メッセージを処理します。
Upon receiving an I_MESSAGE of the RSA-R format, the Responder MUST respond with one of the following messages:
RSA-R形式のI_MESSAGEを受けると、Responderは以下のメッセージの1つで応じなければなりません:
o The Responder SHOULD send an Error message "Message type not
supported" (Error no. 13), if it cannot correctly parse the
received MIKEY message. Error message format is as specified in
Section 5.1.2 of RFC 3830. Error no. 13 is not defined in RFC
3830, and so RFC 3830 compliant implementations MAY return "an
unspecified error occurred" (Error no. 12).
o Responder SHOULDは「タイプが支持しなかったメッセージ」(誤りNo.13)をErrorメッセージに送ります、正しく受信されたマイキーメッセージを分析できないなら。 エラーメッセージ形式が.2セクション5.1RFC3830で指定されるようにあります。 誤りNo.13がRFC3830で定義されないので、RFC3830対応することの実現は「不特定の誤りは発生したこと」に(誤りNo.12)を返すかもしれません。
o The Responder MUST send an R_MESSAGE, if SIGNi can be correctly
verified and the timestamp is current; if an SP payload is present
in the I_MESSAGE the Responder MUST return one of the proposed
security policies that matches the Responder's local policy.
o 正しくSIGNiについて確かめることができるなら、ResponderはR_MESSAGEを送らなければなりません、そして、タイムスタンプはよく見られます。 SPペイロードがI_MESSAGEに存在しているなら、ResponderはResponderのローカルの方針に合っている提案された安全保障政策の1つを返さなければなりません。
o If a RAND payload is present in the I_MESSAGE, both sides use that
RAND payload as the RAND value in the MIKEY key computation. In
case of multicast, if a RAND payload is present in the I_MESSAGE,
the Responder SHOULD ignore the payload. In any case, the
R_MESSAGE for multicast communication MUST contain a RAND payload
and that RAND payload is used for key computation.
o RANDペイロードがI_MESSAGEに存在しているなら、RANDがマイキーキー計算で評価するように両側はそのRANDペイロードを使用します。 マルチキャストの場合には、RANDペイロードがI_MESSAGEに存在しているなら、Responder SHOULDはペイロードを無視します。 どのような場合でも、マルチキャストコミュニケーションのためのR_MESSAGEはRANDペイロードを含まなければなりません、そして、そのRANDペイロードは主要な計算に使用されます。
o The rest of the error message rules are as described in Section
5.1.2 of RFC 3830, and message processing rules are as described
in Section 5.3 of RFC 3830.
o 規則があるエラーメッセージの残りはセクション5.1で.2RFC3830について説明しました、そして、メッセージ処理規則がRFC3830のセクション5.3で説明されるようにあります。
Ignjatic, et al. Standards Track [Page 8] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[8ページ]。
3.6. Components of the R_MESSAGE
3.6. R_メッセージの成分
The HDR payload in the R_MESSAGE is formed following the procedure described in RFC 3830. Specifically, the CSB_ID in the HDR payload MUST be the same as the one in the HDR of the I_MESSAGE. The Responder MUST fill in the number of CSs and the CS ID map type and CS ID info fields of the HDR payload.
RFC3830で説明された手順に従って、R_MESSAGEのHDRペイロードは形成されます。 明確に、HDRペイロードのCSB_IDはI_MESSAGEのHDRのものと同じでなければなりません。 ResponderはHDRペイロードのCSsの数、CS ID地図タイプ、およびCS IDインフォメーション分野に記入しなければなりません。
For group communication, all the members MUST use the same CSB_ID and CS ID in computing the traffic keying material. Therefore, for group key establishment, the Responder MUST include a General Extension Payload containing a new CSB_ID in the R_MESSAGE. If a new CSB_ID is present in the R_MESSAGE, the Initiator and the Responder MUST use that value in key material computation. Furthermore, the CS ID map type and CS ID map info MUST be populated by the Responder. The General Extension Payload carrying a CSB_ID MUST NOT be present in case of unicast communication.
グループコミュニケーションのために、すべてのメンバーが材料を合わせる交通を計算する際に同じCSB_IDとCS IDを使用しなければなりません。 したがって、グループ重要設立のために、ResponderはR_MESSAGEに新しいCSB_IDを含む一般Extension有効搭載量を含まなければなりません。 新しいCSB_IDがR_MESSAGEに存在しているなら、InitiatorとResponderはキー材料計算にその値を使用しなければなりません。 その上、ResponderはCS ID地図タイプとCS ID地図インフォメーションに居住しなければなりません。 CSB_IDを運ぶ一般Extension有効搭載量はユニキャストコミュニケーションの場合に存在しているはずがありません。
The T payload is exactly the same as that received in the I_MESSAGE.
TペイロードはまさにI_MESSAGEに受け取られたそれと同じです。
If the I_MESSAGE did not include the RAND payload, it MUST be present in the R_MESSAGE. In case it has been included in the I_MESSAGE, it MUST NOT be present in the R_MESSAGE. In group communication, the Responder always sends the RAND payload and in unicast communication, either the Initiator or the Responder (but not both) generate and send the RAND payload.
I_MESSAGEがRANDペイロードを含んでいなかったなら、R_MESSAGEに存在していなければなりません。 I_MESSAGEに含まれていたといけないので、それはR_MESSAGEに存在しているはずがありません。 グループコミュニケーションでは、ResponderがいつもRANDペイロードを送って、ユニキャストコミュニケーションでは、InitiatorかResponder(ともにない)のどちらかがRANDペイロードを発生して、送ります。
IDr and CERTr SHOULD be included, but they MAY be left out when it can be expected that the peer already knows the other party's ID (or can obtain the certificate in some other manner). For example, this could be the case if the ID is extracted from SIP. For certificate handling, authorization, and policies, see Section 4.3. of RFC 3830. If CERTr is included, it MUST correspond to the private key used to sign the R_MESSAGE.
同輩が既に、相手のID(または、ある他の方法による証明書を入手できる)を知ると予想できるとき、IDrとCERTr SHOULDが含まれていて、それらだけを省いてもよいです。 例えば、IDがSIPから抽出されるなら、これはそうであるかもしれません。 証明書取り扱い、認可、および方針に関しては、RFC3830のセクション4.3を見てください。 CERTrが含まれているなら、それはR_MESSAGEにサインするのに使用される秘密鍵に対応しなければなりません。
An SP payload MAY be included in the R_MESSAGE. If an SP payload was in the I_MESSAGE, then the R_MESSAGE MUST contain an SP payload specifying the security policies of the secure RTP session being negotiated. More specifically, the Initiator may have provided multiple options, but the Responder MUST choose one option per Security Policy Parameter.
SPペイロードはR_MESSAGEに含まれるかもしれません。 SPペイロードがI_MESSAGEにあったなら、R_MESSAGE MUSTは交渉される安全なRTPセッションの安全保障政策を指定するSPペイロードを含んでいます。 より明確に、Initiatorは複数のオプションを提供したかもしれませんが、Responderは1Security Policy Parameterあたり1つのオプションを選ばなければなりません。
The KEMAC payload contains a set of encrypted sub-payloads and a MAC:
KEMAC = E(encr_key, IDr || {TGK}) || MAC. The first payload (IDr) in
KEMAC is the identity of the Responder (not a certificate, but
generally the same ID as the one specified in the certificate). Each
of the following payloads (TGK) includes a TGK randomly and
independently chosen by the Responder (and possible other related
KEMACペイロードは1セットのコード化されたサブペイロードとMACを含んでいます: KEMACはE(IDr| | encr_キー、TGK)と等しいです。|| Mac。 KEMACにおける最初のペイロード(IDr)はResponderのアイデンティティ(証明書ではなく、一般にものと同じIDが証明書で指定した)です。 それぞれの以下のペイロード(TGK)がResponderによって無作為に独自に選ばれたTGKを含んでいる、(可能なもう一方は関係しました。
Ignjatic, et al. Standards Track [Page 9] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[9ページ]。
parameters, e.g., the key lifetime). The encrypted part is then followed by a MAC, which is calculated over the KEMAC payload. The encr_key and the auth_key are derived from the envelope key, env_key, as specified in Section 4.1.4. of RFC 3830. The payload definitions are specified in Section 6.2 of RFC 3830.
パラメタ、例えば、主要な生涯) そして、コード化された部分はMACによって続かれています。(MACはKEMACペイロードの上計算されます)。 encr_キーとauth_キーはRFC3830について封筒キー、セクション4.1における指定されるとして主要なenv_から.4に引き出されます。 ペイロード定義はRFC3830のセクション6.2で指定されます。
The Responder encrypts and integrity protects the TGK with keys derived from a randomly or pseudo-randomly chosen envelope key, and encrypts the envelope key itself with the public key of the Initiator. The PKE payload contains the encrypted envelope key, env_key: PKE = E(PKi, env_key). PKi denotes the Initiator's public key. Note that, as suggested in RFC 3830, the envelope key MAY be cached and used as the PSK for re-keying.
または、Responderがコード化して、保全がキーが引き出しているTGKを保護する、無作為である、疑似である、無作為である、Initiatorの公開鍵で封筒キーを選んで、封筒キー自体をコード化します。 PKEペイロードは主要なコード化された封筒env_キーを含んでいます: PKEはE(PKi、env_キー)と等しいです。 PKiはInitiatorの公開鍵を指示します。 封筒キーが再の合わせるのにRFC3830に示されるようにPSKとしてキャッシュされて、使用されるかもしれないことに注意してください。
To compute the signature that goes in the SIGNr payload, the Responder MUST sign:
SIGNrペイロードに入る署名を計算するために、Responderはサインしなければなりません:
R_MESSAGE (excluding the SIGNr payload itself) || IDi || IDr || T.
R_MESSAGE(SIGNrペイロード自体を除いた)|| IDi|| IDr|| T。
Note that the added identities and timestamp are identical to those transported in the ID and T payloads.
加えられたアイデンティティとタイムスタンプがIDとTペイロードで輸送されたものと同じであることに注意してください。
3.7. Processing the R_MESSAGE
3.7. R_メッセージを処理します。
In addition to the processing rules in RFC 3830, the following rules apply to processing of the R_MESSAGE of MIKEY RSA-R mode.
RFC3830の処理規則に加えて、以下の規則はMIKEY RSA-RモードのR_MESSAGEの処理に適用されます。
If the I_MESSAGE contained a RAND payload, the Initiator MUST
silently discard an R_MESSAGE that contains a RAND payload.
Similarly, if the I_MESSAGE did not contain a RAND payload, the
Initiator MUST silently discard an R_MESSAGE that does not contain
a RAND payload.
I_MESSAGEがRANDペイロードを含んだなら、Initiatorは静かにRANDペイロードを含むR_MESSAGEを捨てなければなりません。 同様に、I_MESSAGEがRANDペイロードを含まなかったなら、Initiatorは静かにRANDペイロードを含まないR_MESSAGEを捨てなければなりません。
If the SP payload contains a policy not specified in the SP
message, if present, in the I_MESSAGE, such an R_MESSAGE MUST be
discarded silently.
SPペイロードが中で指定されなかった方針を含んでいるなら、SPは通信します、I_MESSAGE、そのようなR_MESSAGE MUSTでのプレゼントが静かに捨てられるなら。
3.8. Certificate Handling
3.8. 証明書取り扱い
If a Certificate payload is present, the X.509v3 URL Cert type from Table 6.7.b [RFC3830] is the default method in RSA-R mode and MUST be implemented. The HTTP URL to fetch a certificate as specified in RFC 2585 [RFC2585] MUST be supported. Devices are not required to support the FTP URLs. When retrieving data from the URL, application/pkix-cert MIME type with X.509 certificates DER-encoded MUST be supported.
Certificateペイロードが存在しているなら、Table 6.7.b[RFC3830]からのX.509v3URL CertタイプをRSA-Rモードによるデフォルトメソッドであり、実装しなければなりません。 RFC2585[RFC2585]の指定されるとしての証明書をとって来るHTTP URLをサポートしなければなりません。 デバイスは、FTPがURLであるとサポートするのに必要ではありません。 URLからのデータを検索するとき、X.509証明書があるpkix-本命MIMEの種類がDERコード化したアプリケーション/をサポートしなければなりません。
Ignjatic, et al. Standards Track [Page 10] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[10ページ]。
The RECOMMENDED way of doing certificate validation is by using OCSP as specified by RFC 2560 [RFC2560]. When OCSP is used and nextUpdate time is present in the response, it defines how long the certificate can be considered valid and cached. If OCSP is not supported or nextUpdate time is not present in the response, the certificate cache timeout is a matter of local policy.
証明書合法化をするRECOMMENDED方法は指定されるとしてのRFC2560[RFC2560]によるOCSPを使用することです。 OCSPが使用されていて、nextUpdate時間が応答で存在しているとき、それはどれくらい長い間証明書を有効であると考えて、キャッシュできるかを定義します。 OCSPがサポートされないか、またはnextUpdate時間が応答で存在していないなら、証明書キャッシュタイムアウトはローカルの方針の問題です。
The communicating peers (such as SIP User Agents for instance) MAY choose to create a URL pointing to certificate files residing on themselves or by appending their ID and a ".cer" extension to a provisioned root path to the certificate. Other methods MAY also be used, subject to local policy.
交信している同輩(例えば、SIP Userエージェントなどの)は、自分たちかそれらのIDを追加することによってある証明書ファイルと".cer"拡大を食糧を供給された根の経路に示すURLを証明書に作成するのを選ぶかもしれません。 また、他のメソッドはローカルの方針を条件として使用されるかもしれません。
3.9. Additions to RFC 3830 Message Types and Other Values
3.9. RFC3830メッセージタイプと他の値への追加
This document introduces two new message types (Table 6.1a of RFC 3830), an Error no (Table 6.12 of RFC 3830), and a general extension payload (Table 6.15 of RFC 3830). This section specifies those additions.
このドキュメントは2つの新しいメッセージタイプ(RFC3830のテーブル6.1a)、Errorノー(RFC3830のテーブル6.12)、および一般的な拡大ペイロード(RFC3830のテーブル6.15)を導入します。 このセクションはそれらの追加を指定します。
3.9.1. Modified Table 6.1a from RFC 3830
3.9.1. RFC3830からの変更されたテーブル6.1a
Modified Table 6.1a from RFC 3830:
RFC3830からの変更されたテーブル6.1a:
Data type | Value | Comment ------------------------------------------------------------------ Pre-shared | 0 | Initiator's pre-shared key message PSK ver msg | 1 | Verification message of a Pre-shared key msg Public key | 2 | Initiator's public-key transport message PK ver msg | 3 | Verification message of a public-key message D-H init | 4 | Initiator's DH exchange message D-H resp | 5 | Responder's DH exchange message Error | 6 | Error message DHHMAC init | 7 | DH HMAC message 1 DHHMAC resp | 8 | DH HMAC message 2 RSA-R I_MSG | 9 | Initiator's RSA-R public-key message (NEW) RSA-R R_MSG | 10 | Responder's RSA-R public-key message (NEW)
データ型| 値| コメント------------------------------------------------------------------ あらかじめ共有されます。| 0 | 創始者のあらかじめ共有された主要なメッセージPSK ver msg| 1 | Preによって共有された主要なmsg Publicキーに関する検証メッセージ| 2 | 創始者の公開鍵輸送メッセージPK ver msg| 3 | 公開鍵メッセージD-Hイニットに関する検証メッセージ| 4 | 創始者のDH交換メッセージD-H resp| 5 | 応答者のDH交換メッセージError| 6 | エラーメッセージDHHMACイニット| 7 | DH HMACメッセージ1DHHMAC resp| 8 | DH HMACメッセージ2RSA-R I_MSG| 9 | 創始者のRSA-R公開鍵メッセージ(NEW)RSA-R R_MSG| 10 | 応答者のRSA-R公開鍵メッセージ(新しい)です。
Figure 3: Table 6.1a from RFC 3830 (Revised)
図3: RFC3830からのテーブル6.1a(改訂されます)
Ignjatic, et al. Standards Track [Page 11] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[11ページ]。
3.9.2. Modified Table 6.12 from RFC 3830
3.9.2. 変更されたテーブル6.12 RFC3830から
Modified Table 6.12 from RFC 3830:
RFC3830からの変更されたテーブル6.12:
Error no | Value | Comment
-------------------------------------------------------
Auth failure | 0 | Authentication failure
Invalid TS | 1 | Invalid timestamp
Invalid PRF | 2 | PRF function not supported
Invalid MAC | 3 | MAC algorithm not supported
Invalid EA | 4 | Encryption algorithm not supported
Invalid HA | 5 | Hash function not supported
Invalid DH | 6 | DH group not supported
Invalid ID | 7 | ID not supported
Invalid Cert | 8 | Certificate not supported
Invalid SP | 9 | SP type not supported
Invalid SPpar | 10 | SP parameters not supported
Invalid DT | 11 | not supported Data type
Unspecified error | 12 | an unspecified error occurred
Unsupported | |
message type | 13 | unparseable MIKEY message (NEW)
誤りノー| 値| コメント------------------------------------------------------- Authの故障| 0 | 認証失敗Invalid TS| 1 | 無効のタイムスタンプInvalid PRF| 2 | Invalid MACであることはサポートされなかったPRF機能| 3 | Invalid EAであることはサポートされなかったMACアルゴリズム| 4 | Invalid HAであることはサポートされなかった暗号化アルゴリズム| 5 | Invalid DHであることはサポートされなかったハッシュ関数| 6 | Invalid IDであることはサポートされなかったDHグループ| 7 | Invalid CertであることはサポートされなかったID| 8 | Invalid SPであることは支えられなかった証明書| 9 | Invalid SPparであることはサポートされなかったSPタイプ| 10 | Invalid DTであることはサポートされなかったSPパラメタ| 11 | DataタイプUnspecified誤りであることはサポートされません。| 12 | 不特定の誤りの起こったUnsupported| | メッセージタイプ| 13 | 非分析可能マイキーメッセージ(新しい)です。
Figure 4: Table 6.12 from RFC 3830 (Revised)
図4: テーブル6.12 RFC3830から(改訂されます)
3.9.3. Modified Table 6.15 from RFC 3830
3.9.3. 変更されたテーブル6.15 RFC3830から
Modified Table 6.15 from RFC 3830:
RFC3830からの変更されたテーブル6.15:
Type | Value | Comments
---------------------------------------
Vendor ID | 0 | Vendor specific byte string
SDP IDs | 1 | List of SDP key mgmt IDs (allocated for use in
| | [RFC4567])
TESLA I-Key| 2 | [RFC4442]
Key ID | 3 | information on type and identity of keys
| | [RFC4563])
CSB_ID | 4 | Responder's modified CSB_ID (group mode)
タイプ| 値| コメント--------------------------------------- ベンダーID| 0 | ベンダーの特定のバイトストリングSDP ID| 1 | SDPの主要な管理ID(|使用| [RFC4567]のために、割り当てる)テスラI-キーのリスト| 2 | [RFC4442]主要なID| 3 | キーのタイプとアイデンティティの情報| | [RFC4563) CSB_ID| 4 | 応答者の変更されたCSB_ID(グループモード)
Figure 5: Table 6.15 from RFC 3830 (Revised)
図5: テーブル6.15 RFC3830から(改訂されます)
Ignjatic, et al. Standards Track [Page 12] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[12ページ]。
4. Applicability of the RSA-R and RSA Modes
4. RSA-RとRSAモードの適用性
MIKEY-RSA-R mode and RSA mode are both very useful: deciding on which mode to use depends on the application.
マイキー-RSA-RモードとRSAモードはともに非常に役に立ちます: どのモードを使用したらよいかを決めるのをアプリケーションによります。
The RSA-R mode is useful when you have reasons to believe that the Responder may be a different party than the one to which the MIKEY I_MESSAGE was sent. This is quite common in telephony and multimedia applications where the session or the call can be retargeted or forwarded. When the security policy allows it, leaving some flexibility for the Initiator to see who the Responder may turn out to be, before making the decision to continue or discontinue the session, may be appropriate. In such cases, the main objective of the Initiator's RSA-R message is to present its public key/ certificate to the Responder, and wait for a Responder to present its identity.
あなたにResponderがものより異なったパーティーであるかもしれないと信じる理由があるとRSA-Rモードが役に立つ、どれ、I_MESSAGEが送られたマイキー。 これはセッションか呼び出しを「再-狙」うか、または進めることができる電話とマルチメディア応用で全く一般的です。 安全保障政策がそれを許容するとき、Responderがセッションを続けているか、または中止するという決定をする前に、いるようにだれを出すかもしれないかを見るために何らかの柔軟性をInitiatorに残すのは適切であるかもしれません。 そのような場合、InitiatorのRSA-Rメッセージの主な目標は、公開鍵/証明書をResponderに提示して、Responderがアイデンティティを提示するのを待つことです。
The second scenario is when the Initiator already has the Responder's certificate but wants to allow the Responder to come up with all the keying material. This is applicable in conferences where the Responder is the key distributor and the Initiators contact the Responder to initiate key download. Notice that this is quite similar to the group key download model as specified in GDOI [RFC3547], GSAKMP [RFC4535], and GKDP [GKDP] protocols (also see [RFC4046]). The catch, however, is that the participating entities must know that they need to contact a well-known address as far as that conferencing group is concerned. Note that they only need the Responder's address, not necessarily its CERT. If the group members have the Responder's CERT, there is no harm; they simply do not need the CERT to compose the I_MESSAGE.
2番目のシナリオはInitiatorが、既にResponderの証明書を持ちますが、Responderがすべての合わせることの材料を思いつくのを許容したがっている時です。 これはResponderが主要なディストリビュータであり、Initiatorsが主要なダウンロードを開始するためにResponderに連絡するところで会議で適切です。 これがGDOI[RFC3547]、GSAKMP[RFC4535]、およびGKDP[GKDP]プロトコルの指定されるとしてのグループキーダウンロードモデルと全く同様であるのに注意してください(また、[RFC4046]を見てください)。 しかしながら、キャッチは参加実体が、その会議グループに関する限り、よく知られるアドレスに連絡するのが必要であることを知らなければならないということです。 彼らが必ずCERTではなく、Responderのアドレスを必要とするだけであることに注意してください。 グループのメンバーがResponderのCERTを持っているなら、害が全くありません。 CERTは彼らがI_MESSAGEを絶対に構成する必要はありません。
The RSA mode is useful when the Initiator knows the Responder's identity and CERT. This mode is also useful when the key exchange is happening in an established session with a Responder (for example, when switching from a non-secure mode to a secure mode), and when the policy is such that it is only appropriate to establish a MIKEY session with the Responder that is targeted by the Initiator.
InitiatorがResponderのアイデンティティとCERTを知っているとき、RSAモードは役に立ちます。 また、主要な交換がResponder(例えば非安全なモードから安全なモードに切り替わるとき)との確立したセッションだけ、Initiatorによって狙われるResponderとのマイキーセッションを確立するのが方針がそのようなものであるので適切であり時起こっているのに、このモードも役に立ちます。
4.1. Limitations
4.1. 制限
The RSA-R mode may not easily support 3-way calling, under the assumptions that motivated the design. An extra message may be required compared to the MIKEY-RSA mode specified in RFC 3830. Consider that A wants to talk to B and C, but does not have B's or C's CERT. A might contact B and request that B supply a key for a 3-way call. Now if B knows C's CERT, then B can simply use the MIKEY-RSA mode (as defined in RFC 3830) to send the TGK to C. If not, then the solution is not straightforward. For instance, A might
RSA-Rモードは容易にデザインを動機づけた仮定で3ウェイの呼ぶことをサポートしないかもしれません。 RFC3830で指定されたマイキー-RSAモードと比べて、付加的なメッセージが必要であるかもしれません。 Aには、BとCと話したいのですが、ビーズかCのCERTがないと考えてください。 Aは、Bに連絡して、3ウェイ呼び出しのためにそのB供給aキーを要求するかもしれません。 今、BがCのCERTを知っているならBがC.IfにTGKを送るのに、単に、マイキー-RSAモード(RFC3830で定義されるように)を使用できる、その時、ソリューションは簡単ではありません。 例えば、Aはそうするかもしれません。
Ignjatic, et al. Standards Track [Page 13] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[13ページ]。
ask C to contact B or itself to get the TGK, in effect initiating a 3-way exchange. It should be noted that 3-way calling is typically implemented using a bridge, in which case there are no issues (it looks like 3 point-to-point sessions, where one end of each session is a bridge mixing the traffic into a single stream).
事実上、3ウェイ交換を起こして、接触Bかそれ自体にCを招いて、TGKを手に入れてください。 3ウェイの呼ぶことがブリッジを使用することで通常実装されることに注意されるべきです、問題が全くどのケースにないかで(それはそれぞれのセッションの片端がただ一つのストリームにトラフィックを混ぜるブリッジである3つの二地点間セッションに似ています)。
5. Security Considerations
5. セキュリティ問題
We offer a brief overview of the security properties of the exchange. There are two messages: the I_MESSAGE and the R_MESSAGE. The I_MESSAGE is a signed request by an Initiator requesting the Responder to select a TGK to be used to protect multimedia (e.g., Secure RTP or SRTP [RFC3711]) sessions.
私たちは交換のセキュリティの特性の簡潔な概要を提供します。 2つのメッセージがあります: I_メッセージとR_は通信します。 I_MESSAGEはTGKがマルチメディア(例えば、Secure RTPかSRTP[RFC3711])セッションを保護するのに使用されるのを選択するようResponderに要求するInitiatorによる署名している要求です。
The message is signed, which assures the Responder that the claimed Initiator has indeed generated the message. This automatically provides message integrity as well.
メッセージ(本当に、要求されたInitiatorがメッセージを生成したことをResponderに保証する)は署名されます。 これは自動的にまた、メッセージの保全を提供します。
There is a timestamp in the I_MESSAGE, which when generated and interpreted in the context of the MIKEY specification assures the Responder that the request is live and not a replay. Indirectly, this also provides protection against a denial of service (DoS) attack in that the I_MESSAGE must itself be signed. The Responder, however, would have to verify the Initiator's signature and the timestamp, and thus would spend significant computing resources. It is possible to mitigate this by caching recently received and verified requests.
タイムスタンプが再生ではなく、I_MESSAGEにあります。(マイキー仕様の文脈で生成されて、解釈されると、MESSAGEは要求がライブであることをResponderに保証します)。 また、間接的に、これはI_MESSAGE必須自体が署名されるという中のサービス(DoS)攻撃の否定に対する保護を提供します。 しかしながら、ResponderはInitiatorの署名とタイムスタンプについて確かめなければならなくて、その結果、重要なコンピューティング資源を費やすでしょう。 最近、受け取られていていて確かめられた要求をキャッシュすることによってこれを緩和するのは可能です。
Note that the I_MESSAGE in this method basically equals DoS protection properties of the DH method and not the public-key method as there are no payloads encrypted by the Responder's public key in the I_MESSAGE. If IDr is not included in the I_MESSAGE, the Responder will accept the message and a response (and state) would be created for the malicious request.
I_MESSAGEのResponderの公開鍵によって暗号化されたペイロードが全くないときこのメソッドによるI_MESSAGEが基本的に公開鍵メソッドではなく、DHメソッドのDoS保護の特性と等しいことに注意してください。 IDrがI_MESSAGEに含まれていないと、Responderはメッセージを受け入れるでしょう、そして、応答(そして、状態)は悪意がある要求のために作成されるでしょう。
The R_MESSAGE is quite similar to the I_MESSAGE in the MIKEY-RSA mode and has all the same security properties.
R_MESSAGEはマイキー-RSAモードにおいてI_MESSAGEと全く同様であり、ちょうど同じセキュリティの特性を持っています。
When using the RSA-R mode, the Responder may be a different party than the one to which the MIKEY I_MESSAGE was sent. It is the responsibility of the Initiator to verify that the identity of the Responder is acceptable (based on its local policy) if it changes from the party to which the MIKEY I_MESSAGE was sent, and to take appropriate action based on the outcome. In some cases, it could be appropriate to accept a Responder's identity if it can be strongly authenticated; in other cases, a blacklist or a whitelist may be appropriate.
RSA-Rモードを使用して、いつまでResponderがものより異なったパーティーであるかもしれないか、どれ、I_MESSAGEが送られたマイキー。 パーティーから変化するならResponderのアイデンティティが許容できることを(ローカルの方針に基づいています)確かめるのが、Initiatorの責任である、どれ、マイキー、I_MESSAGEは送られて、結果に基づく動作を撮影に当てるか。 いくつかの場合、強くそれを認証できるなら、Responderのアイデンティティを受け入れるのは適切であるかもしれません。 他の場合では、ブラックリストかwhitelistが適切であるかもしれません。
Ignjatic, et al. Standards Track [Page 14] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[14ページ]。
When both unicast and multicast streams need to be negotiated, it is RECOMMENDED to use multiple instances of MIKEY-RSA-R rather than a single instance in group mode. This is to avoid potential key reuse with counter mode.
ユニキャストとマルチキャストストリームの両方が、交渉される必要があるとき、それはグループモードでただ一つのインスタンスよりむしろマイキー-RSA-Rの複数のインスタンスを使用するRECOMMENDEDです。 これは、カウンタモードで潜在的主要な再利用を避けるためのものです。
5.1. Impact of the Responder Choosing the TGK
5.1. TGKを選ぶ応答者の影響
In the MIKEY-RSA or PSK modes, the Initiator chooses the TGK, and the Responder has the option to accept the key or not. In the RSA-R mode for unicast communication, the RECOMMENDED mode of operation is for the Initiator and the Responder to contribute random information in generating the TEK (RAND from the Initiator and the TGK from the Responder). For group communication, the sender (MIKEY Responder) will choose the TGK and the RAND; note that it is in the interest of the sender to provide sufficient entropy to TEK generation since the TEK protects data sent by the Responder.
マイキー-RSAかPSKモードで、InitiatorはTGKを選びます、そして、Responderには、キーを受け入れるオプションがあります。 ユニキャストコミュニケーションのためのRSA-Rモードで、RECOMMENDED運転モードはInitiatorとResponderがTEK(ResponderからのInitiatorとTGKからのRAND)を生成する際に無作為の情報を寄付することです。 グループコミュニケーションのために、送付者(マイキーResponder)はTGKとRANDを選ぶでしょう。 それが送付者のためにあることに注意して、TEKがResponderによって送られたデータを保護するので、十分なエントロピーをTEK世代に提供してください。
Thus, in case of unicast communication, the RSA-R mode is slightly better than the RSA mode in that it allows the Initiator as well as the Responder to contribute entropy to the TEK generation process. This comes at the expense of the additional message. However, as noted earlier, the new mode needs the additional message to allow simpler provisioning.
したがって、ユニキャストコミュニケーションの場合に、Responderと同様にInitiatorがそれでTEK発生経過にエントロピーを寄付できるので、RSA-RモードはRSAモードよりわずかに良いです。 これは追加メッセージを犠牲にして来ます。 しかしながら、より早く注意されるように、新型は、より簡単な食糧を供給することを許す追加メッセージを必要とします。
5.2. Updates to Security Considerations in RFC 3830
5.2. RFC3830の問題をセキュリティにアップデートします。
MIKEY requires clock synchronization, and a secure network clock synchronization protocol SHOULD be used, e.g., [ISO3] or secure NTP [NTPv4].
マイキーは例えば、中古の、または、[ISO3]の、または、安全なNTPが[NTPv4]であったなら時計同期、および安全なネットワーク時計同期プロトコルSHOULDを必要とします。
RFC 3830 has additional notes on the security properties of the MIKEY protocol, key derivation functions, and other components.
RFC3830には、マイキープロトコル、主要な派生機能、および他のコンポーネントのセキュリティ所有地に関する補注があります。
6. IANA Considerations
6. IANA問題
The following IANA assignments were added to the MIKEY registry:
以下のIANA課題はマイキー登録に加えられました:
Added to "Error payload name spaces:"
加えられて、「誤りペイロードは空間を命名します」。
Unsupported message type ------- 13
サポートされないメッセージタイプ------- 13
Added to "Common Header payload name spaces:"
加えられて、「一般的なHeaderペイロードは空間を命名します」。
RSA-R I_MSG ------------- 9
RSA-R R_MSG ------------- 10
RSA-R I_エムエスジー------------- 9 RSA-R R_エムエスジー------------- 10
Ignjatic, et al. Standards Track [Page 15] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[15ページ]。
Added to "General Extensions payload name spaces:"
加えられて、「一般Extensionsペイロードは空間を命名します」。
CSB_ID ----------------- 4
CSB_ID----------------- 4
7. Acknowledgments
7. 承認
Many thanks to Mark Baugher, Steffen Fries, Russ Housley, Cullen Jennings, and Vesa Lehtovirta for their reviews of earlier version of this document.
彼らのこのドキュメントの以前のバージョンのレビューのためにマークBaugher、ステファン・フリーズ、ラスHousley、Cullenジョニングス、およびVesa Lehtovirtaをありがとうございます。
8. References
8. 参照
8.1. Normative References
8.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月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560] マイアーズ、M.、Ankney、R.、Malpani、A.、ガリペリン、S.、およびC.アダムス、「X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態は議定書を作ります--OCSP」、RFC2560、1999年6月。
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999.
[RFC2585] Housley、R.、およびP.ホフマン、「インターネットのX.509の公開鍵暗号基盤の操作上のプロトコル:」 「FTPとHTTP」(RFC2585)は1999がそうするかもしれません。
[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月。
8.2. Informative References
8.2. 有益な参照
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
2003年7月の[RFC3547]BaugherとM.とウィスとB.とHardjono、T.とH.ハーニー、「解釈のグループドメイン」RFC3547。
[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行進。
[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月。
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for
Multimedia Internet KEYing (MIKEY)", RFC 4650, September
2006.
[RFC4650]Euchner、M.、「マルチメディアインターネットへの(マイキー)を合わせるHMACによって認証されたディフィー-ヘルマン」、RFC4650、2006年9月。
Ignjatic, et al. Standards Track [Page 16] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[16ページ]。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006.
[RFC4535] ハーニー、H.、メタンフェタミン、U.、コールグローブ、A.、およびG.グロス、「GSAKMP:」 「グループの安全な協会Key Managementプロトコル」、RFC4535、2006年6月。
[GKDP] Dondeti, L., "GKDP: Group Key Distribution Protocol", Work
in Progress, March 2006.
[GKDP]Dondeti、L.、「GKDP:」 「グループの主要な分配プロトコル」、進行中の仕事、2006年3月。
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006.
[RFC4567] Arkko、J.、リンドホルム、F.、ジーター、M.、Norrman、K.、およびE.カラーラ、「セッション記述のためのKey Management拡大は(SDP)とリアルタイムのストリーミングのプロトコル(RTSP)について議定書の中で述べます」、RFC4567、2006年7月。
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed
Efficient Stream Loss-Tolerant Authentication (TESLA)",
RFC 4442, March 2006.
[RFC4442] フリーズとS.とH.Tschofenig、「調節された効率的なストリーム損失許容性がある認証(テスラ)を独力で進みます」、RFC4442、2006年3月。
[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] カラーラ、E.、Lehtovirta、V.、およびK.Norrman、「(マイキー)を合わせて、主要なID情報は一般拡大有効搭載量のためにマルチメディアインターネットでタイプします」、RFC4563、2006年6月。
[NTPv4] Burbank, J., "The Network Time Protocol Version 4 Protocol
Specification", Work in Progress, May 2006.
[NTPv4] バーバンク、J.、「ネットワーク時間プロトコルバージョン4プロトコル仕様」が進歩、2006年5月に働いています。
[ISO3] ISO, "ISO/IEC 18014 Information technology - Security
techniques - Time-stamping services, Part 1-3", 2002.
[ISO3]ISO、「ISO/IEC18014情報技術--セキュリティのテクニック--タイムスタンピングサービス、Part、13インチ、2002インチ。
Ignjatic, et al. Standards Track [Page 17] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[17ページ]。
Authors' Addresses
作者のアドレス
Dragan Ignjatic Polycom 1000 W. 14th Street North Vancouver, BC V7P 3P3 Canada
ドラガンIgnjatic Polycom1000W.第14通り紀元前のV7P 3P3ノースバンクーバー(カナダ)
Phone: +1 604 982 3424 EMail: dignjatic@polycom.com
以下に電話をしてください。 +1 3424年の604 982メール: dignjatic@polycom.com
Lakshminath Dondeti QUALCOMM 5775 Morehouse drive San Diego, CA 92121 US
Lakshminath Dondetiクアルコム5775のモアハウスはサンディエゴ、カリフォルニア 92121を米国に追い立てます。
Phone: +1 858 845 1267 EMail: ldondeti@qualcomm.com
以下に電話をしてください。 +1 1267年の858 845メール: ldondeti@qualcomm.com
Francois Audet Nortel 4655 Great America Parkway Santa Clara, CA 95054 US
フランソアAudetノーテル4655グレート・アメリカParkwayカリフォルニア95054サンタクララ(米国)
Phone: +1 408 495 3756 EMail: audet@nortel.com
以下に電話をしてください。 +1 3756年の408 495メール: audet@nortel.com
Ping Lin Nortel 250 Sidney St. Belleville, Ontario K8P3Z3 Canada
リンノーテル250シドニー通りオンタリオK8P3Z3ベルビル(カナダ)を確認してください。
Phone: +1 613 967 5343 EMail: linping@nortel.com
以下に電話をしてください。 +1 5343年の613 967メール: linping@nortel.com
Ignjatic, et al. Standards Track [Page 18] RFC 4738 MIKEY-RSA-R November 2006
Ignjatic、他 規格はマイキー-RSA-R2006年11月にRFC4738を追跡します[18ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(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, 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機能のための基金は現在、インターネット協会によって提供されます。
Ignjatic, et al. Standards Track [Page 19]
Ignjatic、他 標準化過程[19ページ]
一覧
スポンサーリンク
