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
MIKEY-RSA-R: An Additional Mode of Key Distribution
in Multimedia Internet KEYing (MIKEY)
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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.
マルチメディアインターネットキーイング（MIKEY）仕様は、事前共有鍵、公開鍵、およびオプションのDiffie-Hellman鍵を使用してマルチメディアのシナリオ（例えば、SIPコールやリアルタイムストリーミングプロトコル（RTSP）セッション）に対処鍵配布ソリューションのいくつかのモードを説明します交換。公開鍵モードでは、イニシエータは、レスポンダの公開鍵でランダムキーを暗号化してレスポンダに送信します。多くの通信状況では、イニシエータはレスポンダの公開鍵を知らないかもしれない、またはいくつかのケースではレスポンダのIDを事前に（例えば、コールが転送します）。私たちは、このようなシナリオではうまく機能新しいMIKEYモードを提案します。また、このモードはMIKEYでグループ鍵管理のサポートを強化します。それは（すべてのメンバにグループキーを押して、グループ管理者とは対照的に）メンバーが開始したグループ鍵のダウンロードをサポートしています。この文書では、RSA-RモードでRFC 3830を更新します。
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
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.
事前共有キーモード（PSK）、公開鍵（RSA）モード、およびオプションのDiffie-Hellman交換（DHE）モード：MIKEYプロトコル[RFC3830]キー搬送または交換のための3つの異なる方法を有します。加えて、4つにモードの総数をもたらす任意DH-HMACモード[RFC4650]、があります。 MIKEYプロトコル設計のための主要な動機は、リアルタイム通信の低レイテンシ要件であるので、全ての交換は、1つの往復に半分に仕上げます。これは、鍵管理プロトコル自体のセキュリティパラメータ交渉の余地を提供しないことに注意してください。この文書では、我々はMIKEYモードが[RFC3830]で定義されており、[RFC4650]はいくつかの展開シナリオと一般的なユースケースに対処するには不十分であることに注意してください、と私たちはMIKEY-RSAリバースモードで、または単にMIKEY-RSAと呼ばれる新しいモードを提案します-R。この文書では、その仕様には、この新しいモードを追加してRFC 3830を更新します。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
Furthermore, this document reuses the terminology of the MIKEY specification [RFC3830].
また、この文書はMIKEY仕様[RFC3830]の用語を再利用します。
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.
冒頭で述べたように、MIKEY仕様および他の提案は、リアルタイム・アプリケーションのための効率的な鍵管理の4つの異なるモードを定義します。これらのモードは、（のDiffie-Hellman交換を使用してキーをダウンロード、又はキー合意）選択した認証方式（公開鍵または対称鍵ベースの共有）、または選択の鍵確立方法のいずれかで互いに異なります。私たちは、それぞれの長所と短所を含め、以下のこれらのモードをまとめたもの。私たちは、その後、これらのモードが使用できないか、非効率的であるユースケースを議論します。
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モードは、イニシエータとレスポンダは、オフラインの確立、共通の秘密鍵を持っていることが必要です。このモードでは、イニシエータは、TEKの生成キー（TGK）を選択し、PSKから派生鍵でそれを暗号化し、最初のメッセージ、すなわち、I_MESSAGEの一部としてレスポンダに送ります。 I_MESSAGEはPSKから派生する別のキーで保護タイムスタンプ、および完全性を保護リプレイです。へのレスポンダからオプションの確認メッセージ
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.
イニシエータは、相互認証を提供します。それが通信当事者間で共有鍵の事前確立を必要とするこのモードではうまくスケールしません。例えば、任意のユーザが大で、Enterpriseまたはインターネットで他のユーザーと通信することもできますユースケースを検討してください。 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モードでは、イニシエータは、TGKを選択して暗号化し、エンベロープキーで認証し、I_MESSAGEの一部としてレスポンダに送信します。イニシエータはI_MESSAGEでレスポンダの公開鍵で暗号化された封筒キーを備えています。 I_MESSAGEはリプレイタイムスタンプで保護され、イニシエータの公開鍵で署名されています。イニシエータのID、証明書（CERT）、およびレスポンダのIDはI_MESSAGEに含まれていてもよいです。イニシエータは、レスポンダのいくつかの公開鍵を知っている場合、それは、オプションのCHASHペイロードに使用するキーを示すことができます。イニシエータへのレスポンダからオプションの検証メッセージは、相互認証を提供します。イニシエータは、レスポンダのIDを知っていて、対応するCERT（あるいはMIKEYプロトコルのCERTは独立を得ることができます）場合はRSAモードではうまく動作します。 RFC 3830は、イニシエータが、それはレスポンダのCERTを持っていない場合には、一回の以上のラウンドトリップを使用して、ディレクトリエージェントからCERTを得ることができることを示唆しています。しかし、いくつかのケースでは、イニシエータはさえ事前にレスポンダのIDを知らないかもしれない、それのまたは他の理由ため、レスポンダの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)).
レスポンダのIDは、一方的に変更するために（例えば、転送）電話に典型的であるようにレスポンダが複数のIDを持つことができる場合に加えて、いくつかのアプリケーションは、可能にすることができます。そのような場合には、その他に、イニシエータは、相手がアイデンティティを確立し、イニシエータ、信頼できる第三者機関（例えば、認証局（CA））を介してそれを証明しましょうことをいとわないかもしれません。
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モードやMIKEYのDH-HMACモードでは、イニシエータがレスポンダの正確な同一性および/またはCERTへのアクセス権を持っていない場合に便利かもしれません。これらのモードでは、両当事者は、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.
要約すると、いくつかの通信シナリオで - イニシエータは、正しいIDおよび/またはレスポンダの証明書を持っていないかもしれない場合 - [RFC3830]または[RFC4650]に記載MIKEYモードのいずれもマルチメディアセッションキーに適した効率的ではありません確立。
In addition to the issues listed above, there are some types of applications that motivate the new MIKEY mode design proposed in this document.
上記の問題に加えて、この文書で提案された新しいMIKEYモード設計のやる気を引き出すアプリケーションのいくつかのタイプがあります。
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].
（PSKモードの場合のように）MIKEY-RSAモードでは、イニシエータは、セッションセキュリティポリシーを提案し、TGKを選択することに留意されたいです。しかし、イニシエータがレスポンダがセキュリティポリシーを指定し、TGKを送信できるようにしたいということも可能です。例えば、招集は、会議に出席するために人々のグループに招待状を送り、会議のシナリオの場合を考えてみましょう。招待者は、MIKEY I_MESSAGEを送信することにより、招集からグループキーマテリアルを要求するための手順は、その後かもしれません。このように、イニシエータとレスポンダのマイキー定義において、イニシエータは、材料をキーイングのためのレスポンダを求めています。この動作モードは、MSECグループ鍵管理アーキテクチャ[RFC4046]に沿ったものであることに留意されたいです。
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.
提案MIKEYモードは1回のフルラウンドトリップが必要です。イニシエータは、トラフィック鍵材料を送信するためにレスポンダを要求することを意図しレスポンダに署名したI_MESSAGEを送信します。 I_MESSAGEは、CERTへのイニシエータのCERTやリンク（URL）を含有してもよいし、同様にレスポンダの応答、R_MESSAGEは、レスポンダのCERTやそれへのリンクを含むかもしれません。 ResponderはR_MESSAGEで暗号化されたTGKを送信するためにI_MESSAGEにCERTからイニシエータの公開鍵を使用することができます。 R_MESSAGEを受信すると、イニシエータは、レスポンダが実際にそれが通信したい当事者であるかどうかを確認するためにR_MESSAGEでCERTを使用し、TGKを受け入れることができます。我々は、リバースモードで、または単にMIKEY-RSA-RとしてMIKEY-RSAとして、このプロトコルを指します。
The MIKEY-RSA-R mode exchange is defined as follows:
次のようにMIKEY-RSA-Rモード交換が定義されます。
Initiator Responder
--------- ---------
I_MESSAGE = HDR, T, [RAND], [IDi|CERTi], [IDr], {SP}, SIGNi
I_MESSAGE = HDR、T、[RAND]、[IDI |確認]、[IDR]、{SP}、ログイン
R_MESSAGE = HDR, [GenExt(CSB_ID)], T, [RAND], [IDr|CERTr], [SP], KEMAC, PKE, SIGNr
R_MESSAGE = HDR、[GenExt（CSB_ID）]、T [RAND]、[IDR | CERTr]、[SP]、KEMAC、PKE、SIGNR
Figure 1: MIKEY-RSA-R Unicast Mode
図1：MIKEY-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モードを使用して、グループ会議のために、メンバーは安全なセッション情報をダウンロードするには、グループキーサーバとMIKEYを開始する招待状を受け取ります。この場合、レスポンダは、グループの送信者またはグループ鍵サーバのいずれかです。グループメンバーは、グループポリシーを要求し、MIKEY RSA-Rイニシエータなどの材料をキーイング。イニシエータは、SPペイロードを送ってはいけません。具体的には、SPのペイロードは、セッションポリシーを伝えるために使用され、そしてGenExt（CSB-ID）、TGK、そして：レスポンダは、安全なグループポリシー並びにグループ鍵の導出に使用されるペイロードを配布するために必要なすべてのペイロードを送ります。 RANDペイロードレスポンダにより選択さR_Messageに含まれるセキュアリアルタイムトランスポートプロトコル（SRTP）セッションキーを計算するために使用されます。
MIKEY RSA-R for group communication:
グループ通信のためのMIKEY RSA-R：
Initiator Responder
--------- ---------
I_MESSAGE = HDR, T, [RAND], [IDi|CERTi], [IDr], SIGNi
I_MESSAGE = HDR、T、[RAND]、[IDI |確認]、[IDR]、ログイン
R_MESSAGE = HDR, GenExt(CSB_ID), T, RAND, [IDr|CERTr], SP, KEMAC, PKE, SIGNr
R_MESSAGE = HDR、GenExt（CSB_ID）、T、RAND、[IDR | CERTr]、SP、KEMAC、PKE、SIGNR
Figure 2: MIKEY-RSA-R in Group Mode
図2：グループモードでMIKEY-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ペイロードはオプションではありません。
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メッセージの構文解析は、RFC 3830.エラー処理のセクション5.2および5.3に記載されているセクション5.1.2で説明し、保護のガイドラインを再生さ以下ではRFC 3830.の5.4節では、我々はのコンポーネントを説明RSA-Rのメッセージ及びRFC 3830のものに加えて、メッセージ処理と解析ルールを指定します。
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 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.
MIKEY-RSA-RはTGKsをダウンロードするには、完全なラウンドトリップが必要です。 I_MESSAGEはMIKEY HDRおよび再生保護のためのタイムスタンプペイロードを持たなければなりません。 HDRフィールドには、ランダムにイニシエータによって選択されたCSB_ID（暗号化セッションバンドルID）が含まれています。応答は、このモードでは必須であるようにVビットは、「1」に設定され、応答者によって無視されなければなりません。イニシエータは、CSSサポートの数を示す必要があり、およびRTP / RTCPは、それが発信するストリームのためのCS IDマップタイプとCS ID情報フィールドを記入すべきです。ストリームの送信者がCS ID情報フィールドで運ばれるSSRCを選ぶためです。 RFC 3830.イニシエータはSSRC値を指定しないと例外のセクション6.1.1を参照してくださいすることはResponderがSSRCの衝突を回避するためにそれらを選択できるようにすることです。 RTPストリームを発信していないMIKEYメッセージのイニシエータは、サポートのCSの数として「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はSIGNiペイロードは、この署名を含むRFC 3830.に指定MIKEYメッセージに署名するための手順に従ってイニシエータによって署名されなければなりません。したがって、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.
MIKEY-RSA-Rモードがユニキャスト通信に使用される場合RANDペイロードはI_MESSAGEに含まれるべきです。ユニキャスト通信のためのI_MESSAGEでRANDペイロードを含めることを推奨する理由は、イニシエータ（CSB_IDに加えて）鍵導出プロセスにエントロピー貢献できるようにすることです。 RANDペイロードが含まれていない場合、イニシエータはMIKEY-RSAモードに（しかし、ロールの反転で）、実際には同様であるSRTP鍵生成、レスポンダ用品のすべてのエントロピーを供給するためにレスポンダに依存しますすべてのエントロピー。
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.
MIKEY-RSA-Rは、グループ鍵を確立するために使用される場合RANDペイロードが含まれていてもよいです。しかし、I_MESSAGEでRANDペイロードは、グループ通信の場合には、MIKEY鍵生成のために使用してはいけません。レスポンダはMIKEY-RSA-Rは、グループ通信のために使用される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.
IDiとし、CERTIが含まれるべきであるが、ピアがすでに開始当事者のIDを知っている（または他の方法で証明書を取得することができます）ことが期待されている場合、彼らは取り残されるかもしれません。例えば、これはIDをSIPから抽出された場合場合であってもよいです。 CERTIが含まれている場合、証明書の取り扱い、承認、およびポリシーについては、セクション4.3およびRFC 3830.の6.7を参照してください、それが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が複数のIDを持っている場合、イニシエータは、通信が望まれるとレスポンダの具体的なアイデンティティ、IDRを含むことができます。イニシエータのポリシーは、特定のアイデンティティを主張することができるもの以外の任意のエンティティからR_MESSAGEの受け入れを許可していない場合は、イニシエータはI_MESSAGEでIDRペイロードにその特定のアイデンティティを含まなければなりません。
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).
イニシエータはまた、サポートしているすべてのセキュリティポリシーを含むセキュリティポリシー（SP）のペイロード（複数可）を送るかもしれません。 Responderがポリシーのいずれかが含まれサポートされていない場合は、タイプ「無効SPpar」のエラーメッセージ（エラーなし。10）で応答すべきです。レスポンダは、一般的なセッション確立の失敗指示が適切と思われる他の手段（付加的なガイダンスについては、[RFC4567]のセクション4.1.2を参照）を介して通信される場合MIKEYにエラーメッセージを送信しないオプションを有しています。
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は（正確な定義は、RFC 3830のセクション5.2を参照）イニシエータの署名鍵を使用して、イニシエータのMIKEYメッセージ、I_MESSAGEを覆う署名です。署名は、請求イニシエータが実際にメッセージを生成したレスポンダを保証します。これも自動的にメッセージの整合性を提供します。
Upon receiving an I_MESSAGE of the RSA-R format, the Responder MUST respond with one of the following messages:
RSA-RフォーマットのI_MESSAGEを受信すると、レスポンダは、以下のいずれかのメッセージで応答しなければなりません。
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は、エラーメッセージ「メッセージがサポートされていないタイプ」（エラーなし。13）送るべきです。 RFC 3830.エラーのセクション5.1.2で指定されたエラー・メッセージのフォーマットはnoです。 13は、RFC 3830で定義されていない、などRFC 3830準拠の実装が返す（エラー番号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.
SIGNiを正しく検証することができ、タイムスタンプが最新である場合、O Responderは、R_MESSAGEを送らなければなりません。 SPのペイロードがI_MESSAGEに存在する場合レスポンダはレスポンダのローカルポリシーに合致する提案のセキュリティポリシーのいずれかを返さなければなりません。
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.
RANDペイロードがI_MESSAGEに存在する場合、O、両側はMIKEY鍵計算においてRAND値としてそのRANDペイロードを使用します。マルチキャストの場合には、RANDペイロードはI_MESSAGE中に存在する場合、レスポンダは、ペイロードを無視すべきです。いずれの場合においても、マルチキャスト通信用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エラーメッセージルールの残りの部分は、RFC 3830のセクション5.1.2に記載されているように、およびRFC 3830のセクション5.3で説明したようにメッセージ処理ルールがあります。
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.
R_MESSAGEにおけるHDRペイロードは、特に、HDRペイロード内CSB_IDはI_MESSAGEのHDRにおけるものと同じでなければなりませんRFC 3830.に記載の方法に従って形成されています。レスポンダは、CSSの数やCS IDのマップタイプとHDRペイロードの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を含む一般的な拡張ペイロードを含まなければなりません。新しいCSB_IDがR_MESSAGEに存在する場合、イニシエータとレスポンダは、キーマテリアル計算にその値を使用しなければなりません。さらに、CS IDのマップタイプとCS IDマップ情報は、レスポンダによって居住しなければなりません。 CSB_IDを運ぶ一般拡張ペイロードは、ユニキャスト通信の場合には存在してはなりません。
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中に存在してはなりません。グループ通信では、レスポンダは常にRANDペイロードを送信し、ユニキャスト通信では、イニシエータまたはレスポンダのいずれか（両方ではない）を生成し、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.
IDRとCERTrが含まれるべきであるが、ピアがすでに相手のIDを知っている（または他の方法で証明書を取得することができます）ことを期待することができたときに彼らが出て残してもよいです。例えば、これはIDをSIPから抽出された場合場合であってもよいです。証明書の処理、承認、およびポリシーについては、4.3節を参照してください。 CERTrが含まれている場合は、RFC 3830.、それは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は交渉中、安全なRTPセッションのセキュリティポリシーを指定するSPペイロードを含まなければなりません。具体的には、イニシエータは、複数のオプションを提供しているかもしれないが、Responderはセキュリティポリシーのパラメータごとに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 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.
KEMACペイロードは暗号化サブペイロードの組とMAC含ま：KEMAC = E（encr_keyを、IDR || {TGK}）||マック。 KEMACにおける最初のペイロード（IDR）がレスポンダのアイデンティティ（しない証明書が、一般的に証明書に指定されたものと同じID）です。次ペイロード（TGK）の各々は、ランダムにかつ独立レスポンダ（および可能な他の関連パラメータ、例えば、キー寿命）によって選択されたTGKを含みます。暗号化された部分は、その後KEMACペイロードにわたって計算されたMACが続きます。 encr_keyとAUTH_KEYは、セクション4.1.4で指定された封筒キー、env_key、由来しています。 RFC 3830.のペイロードの定義は、RFC 3830のセクション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.
レスポンダ暗号化と完全性は、ランダムにまたは擬似ランダムに選択されたエンベロープ鍵から導出鍵でTGKを保護し、イニシエータの公開鍵でエンベロープ鍵自体を暗号化します。 PKE = E（PKI、env_key）：PKEペイロードは暗号化されたエンベロープキー、env_keyが含まれています。 PKIはイニシエータの公開鍵を示しています。 RFC 3830で提案されているように、なお、エンベロープキーがキャッシュされ、再入力のための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.
（SIGNRペイロード自体を除く）R_MESSAGE || IDiと|| IDR || T.
Note that the added identities and timestamp are identical to those transported in the ID and T payloads.
加えアイデンティティとタイムスタンプがIDとTペイロードに搬送されたものと同一であることに留意されたいです。
In addition to the processing rules in RFC 3830, the following rules apply to processing of the R_MESSAGE of MIKEY RSA-R mode.
RFC 3830の処理ルールに加えて、次の規則が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ペイロードが含まれていた場合、イニシエータは黙っRANDペイロードを含むR_MESSAGEを捨てなければなりません。 I_MESSAGEは、RANDペイロードが含まれていなかった場合は同様に、イニシエータは黙っ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は静かに捨てなければなりません。
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.
証明書のペイロードが存在する場合、表6.7.b [RFC3830]からのX.509v3証明書URLタイプはRSA-Rモードでのデフォルトの方法で、実施されなければなりません。 [RFC2585] RFC 2585で指定された証明書をフェッチするHTTPのURLがサポートされなければなりません。デバイスは、FTPのURLをサポートする必要はありません。 URLからデータを取得するとき、DERエンコードされたX.509証明書を使用してアプリケーション/ PKIX-CERTのMIMEタイプをサポートしなければなりません。
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.
RFC 2560 [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ユーザエージェントなど）の通信ピアは、自分自身にまたは証明書にプロビジョニングされたルートパスにそのIDおよび「.cerの」拡張子を追加することによって、居住証明書ファイルを指すURLを作成することもできます。他の方法もまた、ローカルポリシーの対象に使用されるかもしれません。
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つの新しいメッセージタイプ（RFC 3830の表6.1A）、エラーなし（RFC 3830の表6.12）、および一般的な拡張ペイロード（RFC 3830の表6.15）を導入します。ここでは、これらの追加を指定します。
Modified Table 6.1a from RFC 3830:
RFC 3830から変更された表の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)
Figure 3: Table 6.1a from RFC 3830 (Revised)
図3：RFC 3830から表6.1A（改訂）
Modified Table 6.12 from RFC 3830:
RFC 3830から変更された表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)
Figure 4: Table 6.12 from RFC 3830 (Revised)
図4：RFC 3830から表6.12（改訂）
Modified Table 6.15 from RFC 3830:
RFC 3830から変更された表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)
Figure 5: Table 6.15 from RFC 3830 (Revised)
図5：RFC 3830から表6.15（改訂）
MIKEY-RSA-R mode and RSA mode are both very useful: deciding on which mode to use depends on the application.
MIKEY-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がMIKEY I_MESSAGEが送られた先のものとは異なる当事者であり得ることを信じる理由があるときRSA-Rモードが便利です。これは、セッションまたはコールを再ターゲットまたは転送することができ、電話やマルチメディアアプリケーションでは非常に一般的です。セキュリティポリシーは、イニシエータがレスポンダがあることが判明するかもしれ誰が見てのためにある程度の柔軟性を残して、それを可能にすると、セッションを続行するか中止する決定を下す前に、適切な場合があります。このような場合には、イニシエータのRSA-Rメッセージの主な目的は、レスポンダにその公開鍵/証明書を提示し、そのアイデンティティを提示するレスポンダを待つことです。
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のシナリオがあります。これは、レスポンダがキーディストリビュータであり、開始剤は、鍵のダウンロードを開始するレスポンダに連絡会議に適用可能です。 GDOI [RFC3547]、GSAKMP [RFC4535]で指定され、これはグループキーのダウンロードモデルと非常によく似ていることに注意してください、とGKDPは[GKDP]プロトコルは（も参照[RFC4046]）。キャッチは、しかし、参加エンティティは、彼らが限りその会議グループが懸念されるとしてよく知られているアドレスに連絡する必要があることを知らなければならないということです。彼らは唯一、必ずしもそのCERTをレスポンダのアドレスを必要とすることに注意してください。グループメンバーがレスポンダのCERTを持っている場合は、害はありません。彼らは単にI_MESSAGEを構成するCERTは必要ありません。
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.
イニシエータは、レスポンダのアイデンティティとCERTを知っているとき、RSAモードが便利です。鍵交換は、（セキュアモードへの非セキュアモードから切り替える例えば、）レスポンダと確立されたセッションで起こっている場合、ポリシーは、確立するだけ適切であるようなものである場合、このモードも有用ですイニシエータによってターゲットにされるレスポンダとMIKEYセッション。
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 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).
RSA-Rモードを簡単にデザインをやる気仮定の下で、3者通話をサポートしていないかもしれません。余分なメッセージは、RFC 3830.に指定されたMIKEY-RSA方式に比べて必要な場合があり、AはBとCに話をしたいと考えていますが、BさんやCさんCERTを持っていないことを考えてみましょう。 Bに連絡し、Bが3方向通話のためのキーを供給することを要求することがあります。 BはCのCERTを知っている場合、その後、Bは単純でない場合はCにTGKを送信する（RFC 3830で定義されている）MIKEY-RSAモードを使用することができますさて、その後、解決策は簡単ではありません。例えば、Aは3ウェイの交換を開始する効果で、TGKを取得するためにBや自分自身を連絡するCを頼むかもしれません。各セッションの一端は、単一にトラフィックを混合ブリッジであり、何ら問題は（それが3ポイントツーポイントセッションのように見えるがないその場合、3方向通話は、典型的には、ブリッジを使用して実装されていることに留意すべきですストリーム）。
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.
私たちは、為替のセキュリティプロパティの簡単な概要を提供します。 I_MESSAGEとR_MESSAGE：2件のメッセージがあります。 I_MESSAGEはTGKを選択するためにレスポンダを要求イニシエータによって署名された要求は、マルチメディア（例えば、セキュアRTPまたはSRTP [RFC3711]）セッションを保護するために使用されます。
The message is signed, which assures the Responder that the claimed Initiator has indeed generated the message. This automatically provides message integrity as well.
メッセージは、特許請求イニシエータが実際にメッセージを生成したレスポンダを保証した、署名されます。これも自動的にメッセージの整合性を提供します。
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.
生成されMIKEY仕様の文脈で解釈するとき要求がライブであることをレスポンダとしない再生を保証I_MESSAGE、タイムスタンプがあります。間接的に、これはまたI_MESSAGE自体が署名しなければならないということでサービス拒否（DoS）攻撃の拒否に対する保護を提供します。 Responderは、しかし、イニシエータの署名とタイムスタンプを検証しなければならないので、重要なコンピューティングリソースを費やすだろう。最近受信し、検証要求をキャッシュすることでこれを緩和することが可能です。
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でレスポンダの公開鍵で暗号化された何のペイロードがないと、この方法では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はMIKEY-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モードを使用する場合、レスポンダはMIKEY I_MESSAGEが送信されたのとは別の当事者であってもよいです。どのMIKEY I_MESSAGEが送信されたパーティから変更した場合レスポンダのアイデンティティが（そのローカルポリシーに基づいて）受け入れ可能であることを確認するために、イニシエータの責任である、と結果に基づいて適切なアクションを実行します。いくつかのケースでは、強く認証することができた場合レスポンダのアイデンティティを受け入れることが適切であろう。他のケースでは、ブラックリストまたはホワイトリストが適切であり得ます。
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.
ユニキャストとマルチキャストの両方のストリームをネゴシエートする必要がある場合には、グループモードでMIKEY-RSA-Rの複数のインスタンスではなく、単一のインスタンスを使用することが推奨されます。これは、カウンタモードとの潜在的なキーの再利用を避けるためです。
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.
MIKEY-RSAまたはPSKモードでは、イニシエータは、TGKを選択し、Responderは、キーを受け入れるかどうかのオプションがあります。ユニキャスト通信用のRSA-Rモードでは、動作の推奨モードは、イニシエータとレスポンダは、TEK（RANDイニシエータからレスポンダとからTGK）を生成する際にランダムな情報を寄与するためのものです。グループ通信のために、送信者（MIKEYレスポンダ）はTGK及びRANDを選択します。 TEKは、レスポンダによって送信されたデータを保護するので、それは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.
したがって、ユニキャスト通信の場合には、RSA-Rモードでは、イニシエータならびにTEK生成処理にエントロピー貢献するレスポンダを可能にすることでRSA方式よりもわずかに良好です。これは、追加メッセージを犠牲にしています。先に述べたようにしかし、新しいモードは、シンプルなプロビジョニングを可能にするために、追加のメッセージが必要です。
MIKEY requires clock synchronization, and a secure network clock synchronization protocol SHOULD be used, e.g., [ISO3] or secure NTP [NTPv4].
MIKEYは、クロック同期を必要とし、セキュアなネットワーククロック同期プロトコルが使用されるべきであり、例えば、[ISO3]又はNTP [NTPv4]確保します。
RFC 3830 has additional notes on the security properties of the MIKEY protocol, key derivation functions, and other components.
RFC 3830はMIKEYプロトコル、鍵導出機能、およびその他のコンポーネントのセキュリティ特性に関する追加のノートを有しています。
The following IANA assignments were added to the MIKEY registry:
以下のIANAの割り当てはMIKEYレジストリに追加されました。
Added to "Error payload name spaces:"
追加しました「エラーのペイロード名前空間：」
Unsupported message type ------- 13
Added to "Common Header payload name spaces:"
追加し、「共通ヘッダのペイロード・ネームスペース：」
RSA-R I_MSG ------------- 9
RSA-R R_MSG ------------- 10
Added to "General Extensions payload name spaces:"
追加し、「一般的な拡張機能ペイロード名前空間：」
CSB_ID ----------------- 4
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、カレン・ジェニングス、とのVesa Lehtovirtaに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、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.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、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"、RFC 2585、1999年5月。
[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.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、RFC 3830、2004年8月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[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）グループ鍵管理アーキテクチャ"、RFC 4046、2005年4月。
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
[RFC4650] EUCHNER、M.、 "マルチメディアインターネットキーイングのためのHMAC-認証済みのDiffie-Hellmanの（MIKEY）"、RFC 4650、2006年9月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]はハーニー、H.、メタ、U.、Colegrove、A.、およびG.グロスは、：RFC 4535、2006年6月、 "GSAKMPグループは、協会の鍵管理プロトコルをセキュア"。
[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.、Naslund、M.、Norrman、K.、およびE.カララ、 "鍵管理拡張セッション記述プロトコル（SDP）、リアルタイムストリーミングプロトコル（RTSP）のための"、RFC 4567、2006年7月。
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)", RFC 4442, March 2006.
[RFC4442]フライドポテト、S.およびH. Tschofenig、 "ブートストラップ時限効率的なストリーム損失トレラント認証（TESLA）"、RFC 4442、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、RFC 4563、2006年6月 "マルチメディア、インターネットキーイングで一般拡張ペイロード（MIKEY）のためのキーのID情報タイプ"。
[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 / IEC 18014情報技術 - セキュリティ技術 - タイムスタンピングサービス、パート1-3"、2002年。
Authors' Addresses
著者のアドレス
Dragan Ignjatic Polycom 1000 W. 14th Street North Vancouver, BC V7P 3P3 Canada
ドラガンIgnjaticポリコム1000年W.第14回ストリートノースバンクーバー、BC V7P 3P3カナダ
Phone: +1 604 982 3424 EMail: dignjatic@polycom.com
電話：+1 604 982 3424 Eメール：dignjatic@polycom.com
Lakshminath Dondeti QUALCOMM 5775 Morehouse drive San Diego, CA 92121 US
92121のLakshminath Dandetiクアルコム5775 Morehuseドライブサンディエゴ、
Phone: +1 858 845 1267 EMail: ldondeti@qualcomm.com
電話：+1 858 845 1267 Eメール：ldondeti@qualcomm.com
Francois Audet Nortel 4655 Great America Parkway Santa Clara, CA 95054 US
フランソワAudetノーテル4655グレートアメリカパークウェイサンタクララ、カリフォルニア州95054米国
Phone: +1 408 495 3756 EMail: audet@nortel.com
電話：+1 408 495 3756 Eメール：audet@nortel.com
Ping Lin Nortel 250 Sidney St. Belleville, Ontario K8P3Z3 Canada
Pingの林ノーテル250シドニー・セントベルヴィル、オンタリオ州K8P3Z3カナダ
Phone: +1 613 967 5343 EMail: linping@nortel.com
電話：+1 613 967 5343 Eメール：linping@nortel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。