[要約] RFC 4738は、Multimedia Internet KEYing（MIKEY）における鍵配布の追加モードであるMIKEY-RSA-Rについての要約です。このRFCの目的は、MIKEYプロトコルにおける鍵配布のセキュリティと効率を向上させることです。
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)
Mikey-RSA-R：マルチメディアインターネットキーイング（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).
Copyright（c）The IETF Trust（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）セッション）に対処するキーディストリビューションソリューションのいくつかのモードについて説明します。交換。Public-Keyモードでは、イニシエーターはResponderの公開キーを使用してランダムキーを暗号化し、Responderに送信します。多くの通信シナリオでは、イニシエーターは、レスポンダーの公開鍵、または場合によってはレスポンダーのID（たとえば、コール転送）を事前に知らない場合があります。このようなシナリオでうまく機能する新しいマイキーモードを提案します。このモードは、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.
Mikeyプロトコル[RFC3830]には、キートランスポートまたはエクスチェンジの3つの異なる方法があります。プレシェアレアリングキーモード（PSK）、パブリックキー（RSA）モード、およびオプションのDiffie-Hellman Exchange（DHE）モードです。さらに、オプションのDH-HMACモード[RFC4650]もあり、モードの総数が4になります。マイキープロトコル設計の主な動機は、リアルタイム通信の低遅延要件であり、したがって、すべての交換は半分から1回の往復で終了します。これにより、主要な管理プロトコル自体のセキュリティパラメーター交渉の余地がないことに注意してください。このドキュメントでは、[RFC3830]および[RFC4650]で定義されているMikeyモードは、いくつかの展開シナリオと一般的なユースケースに対処するには不十分であることに注意してください。-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].
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 Exchangeを使用したキーダウンロードまたはキー契約）のいずれかで互いに異なります。以下のこれらのモードを要約しています。その利点と欠点を含めます。次に、これらのモードが使用できない、または非効率的なユースケースについて説明します。
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 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.
PSKモードでは、イニシエーターとレスポンダーがオフラインで確立された共通のシークレットキーを持つ必要があります。このモードでは、イニシエーターはTEK世代キー（TGK）を選択し、PSKから派生したキーで暗号化し、最初のメッセージの一部、つまりi_messageの一部としてレスポンダーに送信します。i_messageはタイムスタンプでリプレイされ、PSKから派生した別のキーで保護されている完全性があります。レスポンダーからイニシエーターへのオプションの検証メッセージは、相互認証を提供します。このモードは、コミュニケーションの間に共有キーの事前確立が必要であるため、うまく拡張しません。たとえば、ユーザーが企業やインターネット全体の他のユーザーと通信したい場合のユースケースを検討してください。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にResponderの公開キーで暗号化されたエンベロープキーが含まれています。i_messageはタイムスタンプでリプレイされ、イニシエーターの公開キーで署名されています。イニシエーターのID、証明書（CERT）、およびレスポンダーのIDは、i_messageに含まれる場合があります。イニシエーターがレスポンダーのいくつかのパブリックキーを知っている場合、オプションのチャッシュペイロードで使用されるキーを示すことができます。レスポンダーからイニシエーターへのオプションの検証メッセージは、相互認証を提供します。RSAモードは、イニシエーターがResponderのIDと対応するCERTを知っている場合に適切に機能します（またはMikeyプロトコルとは無関係に証明書を取得できます）。RFC 3830は、イニシエーターがレスポンダーの証明書を持っていない場合、1つ以上の往復を使用してディレクトリエージェントから証明書を取得できることを示唆しています。ただし、場合によっては、イニシエーターはレスポンダーのIDを事前に知らないことさえできず、そのためまたは他の理由により、レスポンダーの証明書を取得できません。
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.
MikeyのDHモードまたはDH-HMACモードは、イニシエーターがResponderの正確なIDおよび/または証明書にアクセスできない場合に役立つ可能性があります。これらのモードでは、2つの当事者が認証されたDH交換に参加してTGKを導き出します。マイナス面では、DHモードは、RSAおよびPSKモードと比較して、計算および通信オーバーヘッドが高くなっています。さらに重要なことは、これらのモードはグループキーの分布に適さないことです。DH-HMACモードでは、可能なすべての通信エンティティ間のPSKの確立が必要であるため、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]で説明されているマイキーモードはいずれも、マルチメディアセッションキーに適していて効率的です確率。
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].
Mikey-RSAモード（PSKモードの場合と同様）では、イニシエーターがセッションセキュリティポリシーを提案し、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へのリンク（URL）が含まれている場合があり、同様にレスポンダーの応答であるR_Messageには、レスポンダーの証明書またはそれへのリンクが含まれている場合があります。レスポンダーは、i_messageの証明書からイニシエーターの公開キーを使用して、暗号化されたTGKをR_Messageで送信できます。R_MESSAGEを受信すると、イニシエーターはR_MESSAGEの証明書を使用して、レスポンダーが実際に通信したいパーティーであるかどうかを確認し、TGKを受け入れることができます。このプロトコルは、リバースモードのMikey-RSA、または単にMikey-RSA-Rと呼びます。
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
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を開始するための招待状を受け取り、安全なセッション情報をダウンロードします。この場合、レスポンダーはグループ送信者またはグループキーサーバーのいずれかです。グループメンバーは、マイキーRSA-Rイニシエーターとしてグループポリシーとキーイングマテリアルを要求します。イニシエーターは、SPペイロードを送信してはなりません。レスポンダーは、グループキーの派生で使用される安全なグループポリシーと、SPペイロードを使用してセッションポリシーを伝えるために使用され、Genext（CSB-ID）、TGK、およびTGK、およびTGK、およびレスポンダーによって選択され、R_Messageに含まれるRANDペイロードは、安全なリアルタイムトランスポートプロトコル（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 | certi]、[idr]、signi
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は、TGKをダウンロードするために完全な往復を必要とします。i_messageには、リプレイ保護のためにマイキーHDRとタイムスタンプペイロードが必要です。HDRフィールドには、イニシエーターがランダムに選択したCSB_ID（Crypto Session Bundle ID）が含まれています。このモードでは応答が必須であるため、Vビットは「1」に設定し、対応者によって無視する必要があります。イニシエーターは、サポートされているCSSの数を示し、発信するRTP/RTCPストリームのCS IDマップタイプとCS ID情報フィールドに記入する必要があります。これは、ストリームの送信者がCS ID情報フィールドに運ばれるSSRCを選択したためです。RFC 3830のセクション6.1.1を参照してください。SSRC値を指定していないイニシエーターの例外は、SSRCの衝突を避けるためにレスポンダーがそれらを選択できるようにすることです。RTPストリームを発信しないMikeyメッセージの開始者は、サポートされている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は、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ペイロードが含まれていない場合、イニシエーターはレスポンダーに依存して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 Key Generationに使用してはなりません。レスポンダーは、Mikey-RSA-Rがグループ通信に使用される場合、TGKからの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から抽出された場合に当てはまります。証明書の取り扱い、承認、およびポリシーについては、RFC 3830のセクション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.
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）ペイロードを送信することもできます。レスポンダーが含まれるポリシーのいずれもサポートしていない場合、「無効なsppar」のタイプのエラーメッセージ（エラー番号10）で返信する必要があります。レスポンダーには、一般的なセッションの確立障害表示が適切であると見なされ、他の手段を介して通信された場合、マイキーでエラーメッセージを送信しないオプションがあります（追加ガイダンスについては[RFC4567]のセクション4.1.2を参照）。
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は、イニシエーターの署名キーを使用して、イニシエーターのマイキーメッセージであるi_messageをカバーする署名です（正確な定義については、RFC 3830のセクション5.2を参照）。署名は、要求されたイニシエーターが実際にメッセージを生成したことをレスポンダーに保証します。これにより、メッセージの整合性も自動的に提供されます。
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 対応者は、受信したマイキーメッセージを正しく解析できない場合、エラーメッセージ「メッセージタイプがサポートされていない」（エラー番号13）を送信する必要があります。エラーメッセージ形式は、RFC 3830のセクション5.1.2で指定されているとおりです。エラー番号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.
o 対応者は、シグニを正しく検証でき、タイムスタンプが最新の場合、R_Messageを送信する必要があります。i_messageにSPペイロードが存在する場合、レスポンダーは、レスポンダーのローカルポリシーに一致する提案されたセキュリティポリシーの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 i_messageにRANDペイロードが存在する場合、双方はMikeyキー計算の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ペイロードは、RFC 3830で説明されている手順に従って形成されます。具体的には、HDRペイロードのCSB_IDは、i_messageのHDRのものと同じでなければなりません。レスポンダーは、CSSの数と、HDRペイロードの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を使用する必要があります。したがって、グループキーの確立の場合、レスポンダーには、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を参照してください。RFC3830の場合。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.
R_MessageにSPペイロードが含まれる場合があります。SPペイロードがi_messageにある場合、R_Messageには、交渉中の安全なRTPセッションのセキュリティポリシーを指定するSPペイロードを含める必要があります。より具体的には、イニシエーターは複数のオプションを提供している可能性がありますが、レスポンダーはセキュリティポリシーパラメーターごとに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です（証明書ではなく、一般に証明書で指定されたIDと同じID）。次のそれぞれのペイロード（TGK）には、レスポンダー（および可能な他の関連パラメーターなど、重要な寿命など）によってランダムかつ独立して選択されたTGKが含まれます。次に、暗号化された部品の後にMacが続き、Kemacペイロードで計算されます。encr_keyとauth_keyは、セクション4.1.4で指定されているように、Envelopeキーである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ペイロードには、暗号化されたエンベロープキー、env_key：pke = e（pki、env_key）が含まれています。PKIは、イニシエーターの公開キーを示します。RFC 3830で示唆されているように、エンベロープキーはキャッシュされ、再キーイングのPSKとして使用される可能性があることに注意してください。
To compute the signature that goes in the SIGNr payload, the Responder MUST sign:
SIGNRペイロードに入る署名を計算するには、応答者が署名する必要があります。
R_MESSAGE (excluding the SIGNr payload itself) || IDi || IDr || T.
r_message（sightrペイロード自体を除く）||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 CERTタイプがRSA-Rモードのデフォルトメソッドであり、実装する必要があります。RFC 2585 [RFC2585]で指定されている証明書を取得するHTTP URLをサポートする必要があります。FTP URLをサポートするためにデバイスは必要ありません。URLからデータを取得する場合、x.509証明書を使用したアプリケーション/PKIX-CERT MIMEタイプDER-ENCODEDをサポートする必要があります。
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ユーザーエージェントなど）は、証明書ファイルを指すURLを作成するか、IDと「.cer」拡張機能を証明書にプロビジョニングしたルートパスに追加することを選択できます。地域のポリシーに従って、他の方法も使用できます。
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）、エラーNO（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.
RSA-Rモードは、ResponderがMikey I_Messageが送信されたパーティーとは異なるパーティーであると信じる理由がある場合に役立ちます。これは、セッションまたは通話をリターゲティングまたは転送できるテレフォニーおよびマルチメディアアプリケーションで非常に一般的です。セキュリティポリシーが許可されている場合、セッションを継続または中止するという決定を下す前に、イニシエーターがレスポンダーが誰であるかを確認するための柔軟性を残してください。そのような場合、イニシエーターの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]も参照）。ただし、参加者は、その会議グループに関する限り、よく知られている住所に連絡する必要があることを知っている必要があることです。レスポンダーの住所のみが必要であり、必ずしもその証明書ではないことに注意してください。グループメンバーがレスポンダーの証明書を持っている場合、害はありません。彼らは単に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.
RSAモードは、イニシエーターがレスポンダーの身元と証明書を知っている場合に役立ちます。このモードは、レスポンダーとの確立されたセッションでキーエクスチェンジが行われている場合（たとえば、非セキュアモードからセキュアモードに切り替える場合）、およびポリシーがそのような場合、それがそのような場合にのみ適切である場合にも役立ちます。イニシエーターが対象とするレスポンダーとのマイキーセッション。
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の証明書を持っていないことを考慮してください。AはBに接触し、3ウェイコールのキーを提供することを要求するかもしれません。BがCのCERTを知っている場合、BはMikey-RSAモード（RFC 3830で定義されている）を使用してTGKをCに送信するだけで、解決策は簡単ではありません。たとえば、AにCにBまたはそれ自体に接触してTGKを取得するように依頼する場合があります。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.
Exchangeのセキュリティプロパティの簡単な概要を提供します。i_messageとr_messageの2つのメッセージがあります。i_messageは、マルチメディア（セキュアRTPまたはSRTP [RFC3711]など）セッションを保護するために使用するTGKを選択するためにResponderに使用するように応答者に要求するイニシエーターによる署名された要求です。
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.
i_messageにはタイムスタンプがあります。これは、マイキー仕様のコンテキストで生成および解釈されると、リクエストがリプレイではなくライブであることをレスポンダーに保証します。間接的に、これはI_Message自体に署名する必要があるという点で、サービス拒否（DOS）攻撃に対する保護も提供します。ただし、レスポンダーは、イニシエーターの署名とタイムスタンプを検証する必要があるため、重要なコンピューティングリソースを費やす必要があります。最近受信および検証されたリクエストをキャッシュすることにより、これを軽減することができます。
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のResponderの公開鍵によって暗号化されたペイロードがないため、Public-Keyメソッドではなく、DHメソッドのDOS保護特性に基本的に等しいことに注意してください。IDRがi_messageに含まれていない場合、レスポンダーはメッセージを受け入れ、悪意のあるリクエストのために応答（および状態）が作成されます。
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モードを使用する場合、レスポンダーはマイキー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を選択し、レスポンダーにはキーを受け入れるかどうかを選択できます。ユニキャスト通信のRSA-Rモードでは、推奨される動作モードは、イニシエーターとレスポンダーがTEK（イニシエーターからのRANDとRESPONDERからTGK）を生成する際にランダムな情報を提供することです。グループ通信の場合、送信者（Mikey Responder）が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モードはRSAモードよりもわずかに優れています。これにより、イニシエーターとレスポンダーがTEK生成プロセスにエントロピーを提供できるようになります。これには、追加のメッセージが犠牲になります。ただし、前述のように、新しいモードでは、より簡単なプロビジョニングを可能にするために追加のメッセージが必要です。
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.
このドキュメントの以前のバージョンのレビューをしてくれたマーク・ボーサー、ステフェン・フライス、ラス・ヒューズリー、カレン・ジェニングス、ヴェサ・レトビルタに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「X.509インターネット公開キーインフラオンライン証明書ステータスプロトコル」、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. Hoffman、「インターネット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.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、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.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、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.、McGrew、D.、Naslund、M.、Carrara、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.、Canetti、R.、Dondeti、L。、およびF. Lindholm、「マルチキャストセキュリティ（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-Authenticated Diffie-Hellman for Multimedia Internet Keying（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] Harney、H.、Meth、U.、Colegrove、A。、およびG. Gross、 "GSAKMP：Group Secure Association Key Management Protocol"、RFC 4535、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.、Lindholm、F.、Naslund、M.、Norrman、K。、およびE. Carrara、「セッション説明プロトコル（SDP）およびリアルタイムストリーミングプロトコル（RTSP）のキー管理拡張機能」、RFC4567、2006年7月。
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)", RFC 4442, March 2006.
[RFC4442] Fries、S。and 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] Carrara、E.、Lehtovirta、V。、およびK. Norrman、「マルチメディアインターネットキーイング（Mikey）の一般的な拡張ペイロードの重要なID情報タイプ」、2006年6月、RFC 4563。
[NTPv4] Burbank, J., "The Network Time Protocol Version 4 Protocol Specification", Work in Progress, May 2006.
[NTPV4] Burbank、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
ドラガン・イグナジャティック・ポリコム1000 W. 14th Street North Vancouver、BC V7P 3p3カナダ
Phone: +1 604 982 3424
EMail: dignjatic@polycom.com
Lakshminath Dondeti QUALCOMM 5775 Morehouse drive San Diego, CA 92121 US
Lakshminath Dondeti Qualcomm 5775 Morehouse Drive San Diego、CA 92121 US
Phone: +1 858 845 1267
EMail: ldondeti@qualcomm.com
Francois Audet Nortel 4655 Great America Parkway Santa Clara, CA 95054 US
フランソワ・オーデット・ノーテル4655グレート・アメリカ・パークウェイ・サンタ・クララ、カリフォルニア州95054米国
Phone: +1 408 495 3756
EMail: audet@nortel.com
Ping Lin Nortel 250 Sidney St. Belleville, Ontario K8P3Z3 Canada
Ping Lin Nortel 250 Sidney St. Belleville、オンタリオK8p3Z3カナダ
Phone: +1 613 967 5343
EMail: linping@nortel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。