Network Working Group M. Euchner
Request for Comments: 4650 September 2006
Category: Standards Track
HMAC-Authenticated Diffie-Hellman
for 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 Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document describes a lightweight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) protocol MIKEY, as defined in RFC 3830. In particular, this variant deploys the classic Diffie-Hellman key agreement protocol for key establishment featuring perfect forward secrecy in conjunction with a keyed hash message authentication code for achieving mutual authentication and message integrity of the key management messages exchanged. This protocol addresses the security and performance constraints of multimedia key management in MIKEY.
この文書では、特にRFC 3830.に定義されているように、この変形は完璧な特色鍵確立のための古典的なのDiffie-Hellman鍵合意プロトコルを展開し、マルチメディア、インターネット・キーイング（MIKEY）プロトコルMIKEYための軽量のポイント・ツー・ポイントの鍵管理プロトコルのバリアントを記述するメッセージが交換鍵管理の相互認証やメッセージの整合性を達成するための鍵付きハッシュメッセージ認証コードと一緒に前進の秘密保持。このプロトコルは、MIKEYでマルチメディアキー管理のセキュリティとパフォーマンス制約に対処しています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Definitions ................................................5
1.2. Abbreviations ..............................................6
1.3. Conventions Used in This Document ..........................7
2. Scenario ........................................................7
2.1. Applicability ..............................................7
2.2. Relation to GKMARCH ........................................8
3. DHHMAC Security Protocol ........................................8
3.1. TGK Re-keying .............................................10
4. DHHMAC Payload Formats .........................................10
4.1. Common Header Payload (HDR) ..............................11
4.2. Key Data Transport Payload (KEMAC) ........................12
4.3. ID Payload (ID) ...........................................12
4.4. General Extension Payload .................................12
5. Security Considerations ........................................13
5.1. Security Environment ......................................13
5.2. Threat Model ..............................................13
5.3. Security Features and Properties ..........................15
5.4. Assumptions ...............................................19
5.5. Residual Risk .............................................20
5.6. Authorization and Trust Model .............................21
6. Acknowledgments ................................................21
7. IANA Considerations ............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................22
Appendix A. Usage of MIKEY-DHHMAC in H.235 ........................25
There is work done in IETF to develop key management schemes. For example, IKE [12] is a widely accepted unicast scheme for IPsec, and the MSEC WG is developing other schemes, addressed to group communication [17], [18]. For reasons discussed below, there is, however, a need for a scheme with low latency, suitable for demanding cases such as real-time data over heterogeneous networks and small interactive groups.
鍵管理スキームを開発するためにIETFで行われた作業があります。例えば、IKE [12] IPsecのための広く受け入れられているユニキャスト方式であり、そしてMSEC WGは、他の方式を開発して、グループ通信宛[17]、[18]。以下に説明する理由のために、そのような異種のネットワークおよび小インタラクティブグループにわたってリアルタイムデータとしてケースを要求するのに適した低遅延でスキームの必要性は、しかし、そこです。
As pointed out in MIKEY (see [2]), secure real-time multimedia applications demand a particular adequate lightweight key management scheme that takes care to establish dynamic session keys securely and efficiently in a conversational multimedia scenario.
MIKEYで指摘したように、セキュアなリアルタイム・マルチメディア・アプリケーションが会話のマルチメディアシナリオで安全かつ効率的ダイナミックなセッションキーを確立するために世話をする、特定の十分な軽量鍵管理スキームを要求する（[2]参照）。
In general, MIKEY scenarios cover peer-to-peer, simple one-to-many, and small-sized groups. MIKEY in particular describes three key management schemes for the peer-to-peer case that all finish their task within one roundtrip:
一般に、MIKEYシナリオは、単純な1対多ピアツーピアピア、および小型のグループを覆います。特にMIKEYは、すべてが1つの往復以内に作業を終えピア・ツー・ピアのケースのための3つの鍵管理方式について説明します。
- a symmetric key distribution protocol (MIKEY-PS) based on pre-shared master keys
- 事前共有マスターキーに基づく対称鍵分配プロトコル（MIKEY-PS）
- a public-key encryption-based key distribution protocol (MIKEY-PK and reverse-mode MIKEY-RSA-R [33]) assuming a public-key infrastructure with RSA-based (Rivest, Shamir and Adleman) private/public keys and digital certificates
- 公開鍵暗号に基づく鍵配布プロトコル（MIKEY-PKおよびリバースモードMIKEY-RSA-R [33]）RSAベース（リベスト、シャミアおよびエーデルマン）公開鍵/秘密鍵と公開鍵インフラストラクチャを仮定しデジタル証明書
- a Diffie-Hellman key agreement protocol (MIKEY-DHSIGN) deploying digital signatures and certificates.
- デジタル署名および証明書の配備のDiffie-Hellman鍵合意プロトコル（MIKEY-DHSIGN）。
All of these three key management protocols are designed so that they complete their work within just one roundtrip. This requires depending on loosely synchronized clocks and deploying timestamps within the key management protocols.
彼らはただ1つの往復以内に自分の仕事を完了するように、これらの3つの主要な管理プロトコルのすべてが設計されています。これは、緩やかに同期したクロックに依存し、鍵管理プロトコル内のタイムスタンプを配備する必要があり。
However, it is known [6] that each of the three key management schemes has its subtle constraints and limitations:
しかし、知られている[6] 3つの主要な管理スキームのそれぞれは、その微妙な制約および制限を有すること。
- The symmetric key distribution protocol (MIKEY-PS) is simple to implement; however, it was not intended to scale to support any configurations beyond peer-to-peer, simple one-to-many, and small-size (interactive) groups, due to the need for mutually pre-assigned shared master secrets.
- 対称鍵分配プロトコル（MIKEY-PS）は、実施が簡単です。しかしながら、ピア・ツー・ピア、単純な多一、小サイズを超える任意の構成互いに予め割り当てられた共有のマスター秘密の必要性に起因する（対話式）基を、サポートするように拡張することを意図していませんでした。
Moreover, the security provided does not achieve the property of perfect forward secrecy; i.e., compromise of the shared master secret would render past and even future session keys susceptible to compromise.
また、提供されるセキュリティは完全転送秘密の特性を達成しません。すなわち、共有のマスター秘密の妥協は妥協の影響を受けやすく、過去も未来のセッション鍵をレンダリングします。
Further, the generation of the session key happens just at the initiator. Thus, the responder has to fully trust the initiator to choose a good and secure session secret; the responder is able neither to participate in the key generation nor to influence that process. This is considered a specific limitation in less trusted environments.
さらに、セッション鍵の生成は、ちょうどイニシエータで起こります。このように、レスポンダは完全に良いと安全なセッションの秘密を選択するイニシエータを信頼する必要があります。応答者は、鍵生成に参加することも、そのプロセスに影響を与えるためにもないことです。これは、信頼性の低い環境では、特定の制限と考えられています。
- The public-key encryption scheme (MIKEY-PK and MIKEY-RSA-R [33]) depends upon a public-key infrastructure that certifies the private-public keys by issuing and maintaining digital certificates. While such key management schemes provide full scalability in large networked configurations, public-key infrastructures are still not widely available, and, in general, implementations are significantly more complex.
- 公開鍵暗号化方式（MIKEY-PKとMIKEY-RSA-R [33]）は、デジタル証明書を発行し、維持することによって、プライベート公開鍵を証明する公開鍵インフラストラクチャに依存します。そのようなキー管理方式は、大規模なネットワーク化された構成で完全なスケーラビリティを提供しているが、公開鍵インフラストラクチャは、一般的には、実装はかなり複雑です、まだ広く利用可能ではない、と。
Further, additional roundtrips and computational processing might be necessary for each end system in order to ascertain verification of the digital certificates. For example, typical operations in the context of a public-key infrastructure may involve extra network communication handshakes with the public-key infrastructure and with certification authorities and may typically involve additional processing steps in the end systems. These operations would include validating digital certificates (RFC 3029, [24]), ascertaining the revocation status of digital certificates (RFC 2560, [23]), asserting certificate policies, construction of certification path(s) ([26]), requesting and obtaining necessary certificates (RFC 2511, [25]), and management of certificates for such purposes ([22]). Such steps and tasks all result in further delay of the key agreement or key establishment phase among the end systems, which negatively affects setup time. Any extra PKI handshakes and processing are not in the scope of MIKEY, and since this document only deploys symmetric security mechanisms, aspects of PKI, digital certificates, and related processing are not further covered in this document.
さらに、追加のラウンドトリップおよび計算処理は、デジタル証明書の検証を確認するために、各エンド・システムのために必要であるかもしれません。例えば、公開鍵インフラストラクチャの文脈における典型的な動作は、公開鍵インフラストラクチャを有すると証明当局と余分なネットワーク通信のハンドシェイクを含んでもよいし、一般的にエンドシステムに追加の処理ステップを含んでもよいです。これらの操作は、デジタル証明書（RFC 3029 [24]）を検証するデジタル証明書（RFC 2560 [23]）の失効状態を確認、証明書ポリシーをアサートし、認証パス（S）（[26]）の構築、要求含むであろうそして、必要な証明書を取得する（RFC 2511 [25]）、およびそのような目的のための証明書の管理（[22]）。このような手順およびタスク負のセットアップ時間に影響を与えるエンドシステム間でキー契約またはキー確立フェーズのさらなる遅延、中にすべての結果。余分なPKIハンドシェイク処理はMIKEYの範囲ではなく、この文書は、対称的なセキュリティメカニズム、PKIの態様、デジタル証明書、及び関連する処理をさらに本書で覆われていない展開以来。
Finally, as in the symmetric case, the responder depends completely upon the initiator's choosing good and secure session keys.
最後に、対称の場合のように、レスポンダは完全にイニシエータの選択は良いと安全なセッション・キーに依存します。
- The third MIKEY-DHSIGN key management protocol deploys the Diffie-Hellman key agreement scheme and authenticates the exchange of the Diffie-Hellman half-keys in each direction by using a digital signature. This approach has the same advantages and deficiencies as described in the previous section in terms of a public-key infrastructure.
- 第MIKEY-DHSIGN鍵管理プロトコルは、ディフィー・ヘルマン鍵合意スキームを展開し、デジタル署名を使用して、各方向におけるディフィー・ヘルマン半キーの交換を認証します。このアプローチは、公開鍵インフラストラクチャの観点で、前のセクションで説明したのと同じ利点と欠点を有します。
However, the Diffie-Hellman key agreement protocol is known for its subtle security strengths in that it is able to provide full perfect forward secrecy (PFS) and further have to both parties actively involved in session key generation. This special security property (despite the somewhat higher computational costs) makes Diffie-Hellman techniques attractive in practice.
しかし、のDiffie-Hellman鍵合意プロトコルは、完全な完全転送秘密（PFS）を提供し、さらに積極的にセッション鍵の生成に関与し、両当事者に持つことができるという点で、その微妙なセキュリティの強さで知られています。 （やや高い計算コストにもかかわらず）この特別なセキュリティプロパティは、実際には魅力のDiffie-Hellman技術になります。
In order to overcome some of the limitations as outlined above, a special need has been recognized for another efficient key agreement protocol variant in MIKEY. This protocol variant aims to provide the capability of perfect forward secrecy as part of a key agreement with low latency without dependency on a public-key infrastructure.
上記で概説したように制限のいくつかを克服するために、特別な必要性はマイキーで別の効率的な鍵合意プロトコルバリアント認識されてきました。このプロトコルの変種は、公開鍵インフラに依存せずに低遅延での鍵合意の一環として、完全転送秘密の機能を提供することを目的とします。
This document describes a fourth lightweight key management scheme for MIKEY that could somehow be seen as a synergetic optimization between the pre-shared key distribution scheme and the Diffie-Hellman key agreement.
この文書では、何らかの形で事前共有鍵配送方式およびDiffie-Hellman鍵の間に相乗最適化として見ることができるMIKEYのための第四軽量な鍵管理方式が記載されています。
The idea of the protocol in this document is to apply the Diffie-Hellman key agreement, but rather than deploy a digital signature for authenticity of the exchanged keying material, it instead uses a keyed-hash for symmetrically pre-assigned shared secrets. This combination of security mechanisms is called the HMAC-authenticated Diffie-Hellman (DH) key agreement for MIKEY (DHHMAC).
この文書に記載されているプロトコルのアイデアは、ディフィー・ヘルマン鍵合意を適用することであるが、交換鍵材料の真正性のデジタル署名を展開するのではなく、その代わりに対称的に事前に割り当てられた共有の秘密のためのキー付きハッシュを使用します。セキュリティ・メカニズムのこの組み合わせは、MIKEY（DHHMAC）のためのHMAC-認証されたDiffie-Hellmanの（DH）キー契約を呼ばれます。
The DHHMAC variant closely follows the design and philosophy of MIKEY and reuses MIKEY protocol payload components and MIKEY mechanisms to its maximum benefit and for best compatibility.
DHHMAC変異体は密接MIKEYの設計哲学に従う、その最大利益のために、最高の互換性のためMIKEYプロトコルペイロードコンポーネントとMIKEYメカニズムを再利用します。
Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond a point-to-point constellation; thus, both MIKEY Diffie-Hellman protocols do not support group-based keying for any group size larger than two entities.
MIKEYのDiffie-Hellmanプロトコルのような、DHHMACは、ポイントツーポイントコンステレーションを越えて拡張しません。このように、両方のMIKEYのDiffie-Hellmanプロトコルは、2つのエンティティよりも大きな任意のグループサイズのためにグループベースのキーイングをサポートしていません。
The definitions and notations in this document are aligned with MIKEY; see [2] sections 1.3 - 1.4.
この文書の定義や表記はMIKEYと整列しています。 1.4 - [2]のセクション1.3を参照してください。
All large integer computations in this document should be understood as being mod p within some fixed group G for some large prime p; see [2] section 3.3. However, the DHHMAC protocol is also applicable generally to other appropriate finite, cyclical groups as well.
この文書に記載されているすべての大整数計算は、いくつかの大きな素数pに対して、いくつかの固定されたグループG内のmod Pであると理解されるべきです。 [2]のセクション3.3を参照。しかし、DHHMACプロトコルは同様に、他の適当な有限の、周期的なグループに適用可能です。
It is assumed that a pre-shared key s is known by both entities (initiator and responder). The authentication key auth_key is derived from the pre-shared secret s using the pseudo-random function PRF; see [2] sections 4.1.3 and 4.1.5.
事前共有鍵Sは両方のエンティティ（イニシエータとレスポンダ）により知られているものとします。認証鍵AUTH_KEYは、擬似ランダム関数PRFを用いて、事前共有秘密Sに由来します。 [2]のセクション4.1.3および4.1.5を参照。
In this text, [X] represents an optional piece of information. Generally throughout the text, X SHOULD be present unless certain circumstances MAY allow X to be optional and not to be present, thereby potentially resulting in weaker security. Likewise, [X, Y] represents an optional compound piece of information where the pieces X and Y either SHOULD both be present or MAY optionally both be absent. {X} denotes zero or more occurrences of X.
このテキストでは、[X]は、情報の任意の部分を表します。特定の状況、それによって潜在的に弱いセキュリティをもたらす、Xは任意であり、かつ存在することはないことを可能にする場合を除き、一般にテキスト全体、Xは、存在しなければなりません。同様に、[X、Y]は片XおよびYの両方が存在するか、両方が存在しなくてもいてもよいいずれかの情報の任意の化合物の部分を表します。 {X}はXの0回以上の繰り返しを表します
auth_key Pre-shared authentication key, PRF-derived from pre-shared key s. DH Diffie-Hellman DHi Public Diffie-Hellman half key g^(xi) of the Initiator DHr Public Diffie-Hellman half key g^(xr) of the Responder DHHMAC HMAC-authenticated Diffie-Hellman DoS Denial-of-service G Diffie-Hellman group HDR MIKEY common header payload HMAC Keyed Hash Message Authentication Code HMAC-SHA1 HMAC using SHA1 as hash function (160-bit result) IDi Identity of initiator IDr Identity of receiver IKE Internet Key Exchange IPsec Internet Protocol Security MIKEY Multimedia Internet KEYing MIKEY-DHHMAC MIKEY Diffie-Hellman key management protocol using HMAC MIKEY-DHSIGN MIKEY Diffie-Hellman key agreement protocol MIKEY-PK MIKEY public-key encryption-based key distribution protocol MIKEY-PS MIKEY pre-shared key distribution protocol p Diffie-Hellman prime modulus PKI Public-key Infrastructure PRF MIKEY pseudo-random function (see [2] section 4.1.3) RSA Rivest, Shamir, and Adleman s Pre-shared key SDP Session Description Protocol SOI Son-of-IKE, IKEv2 SP MIKEY Security Policy (Parameter) Payload T Timestamp TEK Traffic Encryption Key TGK MIKEY TEK Generation Key, as the common Diffie-Hellman shared secret TLS Transport Layer Security xi Secret, (pseudo) random Diffie-Hellman key of the Initiator xr Secret, (pseudo) random Diffie-Hellman key of the Responder
事前共有鍵sからPRF由来AUTH_KEY事前共有認証キー、。レスポンダDHHMAC HMAC認証のDiffie-HellmanのDoS攻撃サービス拒否GのDiffie-の開始DHRパブリックディフィー・ヘルマン半分鍵g ^（XR）のDHディフィー・ヘルマンDHI公開ディフィー・ヘルマン半分鍵g ^（XI）ハッシュ関数（160ビットの結果）としてSHA1を使用HellmanグループHDR MIKEY共通ヘッダのペイロードHMAC鍵付きハッシュメッセージ認証コードHMAC、SHA1 HMAC受信IKEインターネットキー交換のIPsecインターネットプロトコルセキュリティMIKEYマルチメディアインターネットキーイングMIKEY-の開始IDRアイデンティティのIDiをアイデンティティHMAC MIKEY-DHSIGN MIKEYのDiffie-Hellman鍵合意プロトコルMIKEY-PK MIKEY公開鍵暗号に基づく鍵配布プロトコルMIKEY-PS MIKEY事前共有鍵配布プロトコルPのDiffie-HellmanプライムモジュラスPKIを使用してDHHMAC MIKEYのDiffie-Hellman鍵管理プロトコル公開鍵インフラストラクチャPRF MIKEYの擬似ランダム関数RSA Rivest氏、Shamir、およびAdlemanのS事前共有キーSDPセッション記述プロトコルSOI息子・オブ・IKE、IKEv2のSP MIKEYセキュリティポリシー（パラ（[2]セクション4.1.3を参照してください）メートル）ペイロードTタイムスタンプTEKトラフィック暗号化キーTGK MIKEY TEK世代キー、共通のDiffie-HellmanはイニシエータXR秘密、（擬似）ランダムのDiffie-の秘密TLSトランスポートレイヤセキュリティXIの秘密、（擬似）ランダムのDiffie-Hellman鍵を共有してレスポンダのHellman鍵
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
The HMAC-authenticated Diffie-Hellman key agreement protocol (DHHMAC) for MIKEY addresses the same scenarios and scope as the other three key management schemes in MIKEY address.
MIKEYためのHMAC認証のDiffie-Hellman鍵合意プロトコル（DHHMAC）はMIKEYアドレスの他の3つの主要な管理方式と同じシナリオと範囲に対処します。
DHHMAC is applicable in a peer-to-peer group where no access to a public-key infrastructure can be assumed to be available. Rather, pre- shared master secrets are assumed to be available among the entities in such an environment.
DHHMACは、公開鍵インフラストラクチャへのアクセスが利用可能であると仮定することができないピア・ツー・ピア・グループに適用可能です。そうではなく、事前共有マスタ秘密は、そのような環境におけるエンティティの間で利用可能であると仮定されます。
In a pair-wise group, it is assumed that each client will be setting up a session key for its outgoing links with its peer using the DH-MAC key agreement protocol.
ペアワイズグループでは、各クライアントがDH-MAC鍵合意プロトコルを使用して、その相手との出力リンクのためのセッションキーを設定することを想定しています。
As is the case for the other three MIKEY key management protocols, DHHMAC assumes, at least, loosely synchronized clocks among the entities in the small group.
他の三つのMIKEY鍵管理プロトコルの場合のように、DHHMACは、少なくとも、緩く小グループ内のエンティティ間でクロックを同期化、前提。
To synchronize the clocks in a secure manner, some operational or procedural means are recommended. MIKEY-DHHMAC does not define any secure time synchronization measures; however, sections 5.4 and 9.3 of [2] provide implementation guidance on clock synchronization and timestamps.
安全な方法でクロックを同期するには、いくつかの操作または手続き手段が推奨されています。 MIKEY-DHHMACは、任意の安全な時刻同期の措置を定義していません。しかしながら、セクション5.4および9.3 [2]クロック同期とタイムスタンプの適用指針を提供します。
MIKEY-DHHMAC and the other MIKEY key management protocols are intended for application-level key management and are optimized for multimedia applications with real-time session setup and session management constraints.
MIKEY-DHHMACおよびその他のMIKEY鍵管理プロトコルは、アプリケーションレベルの鍵管理のために意図されており、リアルタイムのセッションのセットアップおよびセッション管理の制約とマルチメディア・アプリケーション向けに最適化されています。
As the MIKEY-DHHMAC key management protocol terminates in one roundtrip, DHHMAC is applicable for integration into two-way handshake session or call signaling protocols such as
MIKEY-DHHMAC鍵管理プロトコルは、1回の往復で終了するように、DHHMACは双方向ハンドシェイクセッションまたは例えばコールシグナリングプロトコルへの統合のために適用可能です
a) SIP [13] and SDP, where the encoded MIKEY messages are encapsulated and transported in SDP containers of the SDP offer/answer see RFC 3264 [27]) handshake, as described in [4]; and
A）SIP [13]及び[4]記載のようにエンコードされたMIKEYメッセージは、カプセル化され、RFC 3264 [27]）ハンドシェイクを参照SDPオファー/アンサーSDPの容器で輸送されるSDP、。そして
b) H.323 (see [15]), where the encoded MIKEY messages are transported in the H.225.0 fast start call signaling handshake. Appendix A outlines the usage of MIKEY-DHHMAC within H.235.
符号化されたMIKEYメッセージはハンドシェークシグナリングH.225.0ファストスタートコールで輸送されるB）323（[15]参照）。付録Aは、H.235内のマイキー・DHHMACの使用方法の概要を説明します。
MIKEY-DHHMAC is offered as an option to the other MIKEY key management variants (MIKEY-pre-shared, MIKEY-public-key and MIKEY-DH-SIGN) for all those cases where DHHMAC has its particular strengths (see section 5).
MIKEY-DHHMACはDHHMACは、その特定の強みを持っているすべてのこれらのケースのために他のMIKEY鍵管理バリアント（マイキー・事前共有、MIKEY-公開鍵とMIKEY-DH-SIGN）（セクション5を参照）にオプションとして提供されています。
The Group key management architecture (GKMARCH) [19] describes a generic architecture for multicast security group key management protocols. In the context of this architecture, MIKEY-DHHMAC may operate as a registration protocol; see also [2] section 2.4. The main entities involved in the architecture are a group controller/key server (GCKS), the receiver(s), and the sender(s). Due to the pair-wise nature of the Diffie-Hellman operation and the 1-roundtrip constraint, usage of MIKEY-DHHMAC rules out any deployment as a group key management protocol with more than two group entities. Only the degenerate case with two peers is possible where, for example, the responder acts as the group controller.
グループ鍵管理アーキテクチャ（GKMARCH）[19]は、マルチキャストセキュリティグループ鍵管理プロトコルのための一般的なアーキテクチャについて説明します。このアーキテクチャの文脈では、MIKEY-DHHMACは、登録プロトコルとして動作してもよいです。 [2]セクション2.4も参照。アーキテクチャに関与する主エンティティは、グループコントローラ/鍵サーバ（GCKS）、受信機（複数可）、及び送信側（S）です。原因のDiffie-Hellman操作のペアワイズ性質および1-往復制約に、MIKEY-DHHMACの使用は、二つ以上のグループエンティティとグループ鍵管理プロトコルなどの任意の配置を除外する。 2つだけのピアと縮退ケースが可能である場合、例えば、グループコントローラとしてレスポンダ作用します。
Note that MIKEY does not provide re-keying in the GKMARCH sense, only updating of the keys by normal unicast messages.
MIKEYのみ、通常のユニキャストメッセージによってキーの更新、GKMARCHの意味での再入力を提供しないことに注意してください。
The following figure defines the security protocol for DHHMAC:
次の図は、DHHMACのためのセキュリティプロトコルを定義します。
Initiator Responder
イニシエータレスポンダ
I_message = HDR, T, RAND, [IDi], IDr,
{SP}, DHi, KEMAC
-----------------------> R_message = HDR, T,
[IDr], IDi, DHr,
DHi, KEMAC
<----------------------
Figure 1: HMAC-authenticated Diffie-Hellman key-based exchange, where xi and xr are (pseudo) randomly chosen, respectively, by the initiator and the responder.
図1：XIおよびXRが（疑似）ランダムイニシエータとレスポンダにより、それぞれ、選択されたHMAC認証のDiffie-Hellman鍵ベースの交換、。
The DHHMAC key exchange SHALL be done according to Figure 1. The initiator chooses a (pseudo) random value, xi, and sends an HMACed message including g^(xi) and a timestamp to the responder. It is recommended that the initiator SHOULD always include the identity payloads IDi and IDr within the I_message; unless the receiver can defer the initiator's identity by some other means, IDi MAY optionally be omitted. The initiator SHALL always include the recipient's identity.
DHHMAC鍵交換は、開始剤は、（擬似）ランダム値、XIを選択し、およびg ^（XI）とレスポンダにタイムスタンプを含むHMACedメッセージを送信し、図1に従って実施されねばなりません。イニシエータは、常にアイデンティティペイロードI_message内IDiとし、IDRを含むべきであることをお勧めします。受信機は、いくつかの他の手段によって、イニシエータのアイデンティティを延期することができない限り、IDIは、必要に応じて省略されるかもしれません。イニシエータは、常に受信者の身元を含まなければなりません。
The group parameters (e.g., the group G) are a set of parameters chosen by the initiator. Note that like in the MIKEY protocol, both sender and receiver explicitly transmit the Diffie-Hellman group G within the Diffie-Hellman payload DHi or DHr through an encoding (e.g., OAKLEY group numbering; see [2] section 6.4). The actual group parameters g and p, however, are not explicitly transmitted but can be deduced from the Diffie-Hellman group G. The responder chooses a (pseudo) random positive integer, xr, and sends an HMACed message including g^(xr) and the timestamp to the initiator. The responder SHALL always include the initiator's identity IDi regardless of whether the I_message conveyed any IDi. It is RECOMMENDED that the responder SHOULD always include the identity payload IDr within the R_message; unless the initiator can defer the responder's identity by some other means, IDr MAY optionally be left out.
グループパラメータ（例えば、グループG）がイニシエータによって選択されたパラメータのセットです。 MIKEYプロトコルのようなお、送信者と受信者の両方が明示的に符号化を介してのDiffie-HellmanペイロードDHIまたはDHR内のDiffie-HellmanグループGを送信する（例えば、オークリーグループ番号[2]のセクション6.4を参照）。実際のグループは、Gパラメータpは、しかし、明示的に伝達されずのDiffie-HellmanグループGから推定することができる応答は、（擬似）ランダムな正の整数、XRを選択し、およびg ^（XR）を含むHMACedメッセージを送信します。イニシエータへのタイムスタンプ。レスポンダは関係なく、常にI_messageは、任意のIDiとを伝えたかどうかの創始者の身元IDiとを含むものとします。応答者が常にR_message内のIDペイロードIDRを含めることが推奨されます。イニシエータは、いくつかの他の手段によって、応答者の身元を延期することができない限り、IDRは、必要に応じて残してもよいです。
Both parties then calculate the TGK as g^(xi * xr).
両当事者は、その後、G ^（XIの*のXR）としてTGKを計算します。
The HMAC authentication provides authentication of the DH half-keys and is necessary to avoid man-in-the-middle attacks.
HMAC認証はDH半鍵の認証を提供し、man-in-the-middle攻撃を回避するために必要です。
This approach is less expensive than digitally signed Diffie-Hellman in that both sides compute one exponentiation and one HMAC first, then one HMAC verification, and finally another Diffie-Hellman exponentiation.
両面一の累乗と一つHMAC最初、そしてあるHMAC検証し、最後に別のDiffie-Hellman累乗を計算するという点で、このアプローチは、デジタル署名されたディフィー・ヘルマンよりも安価です。
With off-line pre-computation, the initial Diffie-Hellman half-key MAY be computed before the key management transaction and thereby MAY further reduce the overall roundtrip delay, as well as the risk of denial-of-service attacks.
オフライン事前計算では、初期のDiffie-Hellmanのハーフの鍵は、鍵管理トランザクションの前に計算され、それによって、さらに全体の往復遅延だけでなく、サービス拒否攻撃のリスクを減らすことができます。
Processing of the TGK SHALL be accomplished as described in MIKEY [2] section 4.
MIKEY [2]のセクション4で説明したようにTGKの処理が達成されなければなりません。
The computed HMAC result SHALL be conveyed in the KEMAC payload field where the MAC fields holds the HMAC result. The HMAC SHALL be computed over the entire message, excluding the MAC field using auth_key; see also section 4.2.
計算されたHMAC結果はMACフィールドはHMAC結果を保持KEMACペイロードフィールドで搬送されるものとします。 HMACはAUTH_KEYを使用してMACフィールドを除く、メッセージ全体にわたって計算しなければなりません。また、セクション4.2を参照してください。
TGK re-keying for DHHMAC generally proceeds as described in [2] section 4.5. Specifically, Figure 2 provides the message exchange for the DHHMAC update message.
[2]のセクション4.5に記載したようにDHHMAC用TGK再キーイングは、一般的に進みます。具体的に、図2はDHHMAC更新メッセージのためのメッセージ交換を提供します。
Initiator Responder
イニシエータレスポンダ
I_message = HDR, T, [IDi], IDr,
{SP}, [DHi], KEMAC
-----------------------> R_message = HDR, T,
[IDr], IDi,
[DHr, DHi], KEMAC
<----------------------
Figure 2: DHHMAC update message
図2：DHHMAC更新メッセージ
TGK re-keying supports two procedures:
TGK再入力は二つの手順をサポートしています。
a) True re-keying by exchanging new and fresh Diffie-Hellman half-keys. For this, the initiator SHALL provide a new, fresh DHi, and the responder SHALL respond with a new, fresh DHr and the received DHi.
新しい、新鮮なのDiffie-Hellmanのハーフ鍵を交換することによりa）の真の再入力。このため、イニシエータは新しい、新鮮なDHIを提供するものとし、応答者は新しい、新鮮DHRと受信DHIで応答しなければなりません。
b) Non-key related information update without including any Diffie-Hellman half-keys in the exchange. Such a transaction does not change the actual TGK but updates other information such as security policy parameters. To update the non-key related information only, [DHi] and [DHr, DHi] SHALL be left out.
交換の任意のDiffie-Hellmanの半キーを含まないB）非キー関連情報更新。このようなトランザクションは、このようなセキュリティポリシーのパラメータとして、実際のTGKが、アップデート、他の情報は変更されません。のみ、[DHI]及び[DHR、DHI]が除外されるものと非キー関連情報を更新します。
This section specifies the payload formats and data type values for DHHMAC; see also [2] section 6, for a definition of the MIKEY payloads.
このセクションでは、DHHMACのペイロードフォーマットとデータ型の値を指定します。 MIKEYペイロードの定義については、また[2]のセクション6を参照。
This document does not define new payload formats but re-uses MIKEY payloads for DHHMAC as referenced:
この文書は、新しいペイロードフォーマットを定義していませんが、参照としてDHHMACためMIKEYペイロードを再使用しています：
* Common header payload (HDR); see section 4.1 and [2] section 6.1.
*共通ヘッダペイロード（HDR）。セクション4.1と[2]のセクション6.1を参照してください。
* SRTP ID sub-payload; see [2] section 6.1.1.
* SRTP IDサブペイロード。 [2]のセクション6.1.1を参照。
* Key data transport payload (KEMAC); see section 4.2 and [2] section 6.2.
*主なデータ転送ペイロード（KEMAC）。セクション4.2および[2]のセクション6.2を参照。
* DH data payload; see [2] section 6.4.
* DHデータペイロード。 [2]セクション6.4を参照してください。
* Timestamp payload; see [2] section 6.6.
*タイムスタンプペイロード。 [2]のセクション6.6を参照。
* ID payload; [2] section 6.7.
* IDペイロード。 [2]のセクション6.7。
* Security Policy payload (SP); see [2] section 6.10.
*セキュリティポリシーのペイロード（SP）; [2]のセクション6.10を参照してください。
* RAND payload (RAND); see [2] section 6.11.
* RANDペイロード（RAND）。 [2]のセクション6.11を参照してください。
* Error payload (ERR); see [2] section 6.12.
*エラーペイロード（ERR）。 [2]のセクション6.12を参照してください。
* General Extension Payload; see [2] section 6.15.
*一般的な拡張ペイロード。 [2]のセクション6.15を参照してください。
Referring to [2] section 6.1, the following data types SHALL be used for DHHMAC:
[2]セクション6.1を参照して、以下のデータ型がDHHMACのために使用されなければなりません。
Data type | Value | Comment
-------------------------------------------------------------
DHHMAC init | 7 | Initiator's DHHMAC exchange message
DHHMAC resp | 8 | Responder's DHHMAC exchange message
Error | 6 | Error message; see [2] section 6.12
Table 4.1.a
表4.1.a
Note: A responder is able to recognize the MIKEY DHHMAC protocol by evaluating the data type field as 7 or 8. This is how the responder can differentiate between MIKEY and MIKEY DHHMAC.
注：応答者は、これは、レスポンダはMIKEYとMIKEY DHHMAC区別することができる方法である7または8のようなデータ型のフィールドを評価することによってMIKEY DHHMACプロトコルを認識することができます。
The next payload field SHALL be one of the following values:
次のペイロードフィールドは、次の値のいずれかでなければなりません。
Next payload| Value | Section
----------------------------------------------------------------
Last payload| 0 | -
KEMAC | 1 | section 4.2 and [2] section 6.2
DH | 3 | [2] section 6.4
T | 5 | [2] section 6.6
ID | 6 | [2] section 6.7
SP | 10 | [2] section 6.10
RAND | 11 | [2] section 6.11
ERR | 12 | [2] section 6.12
General Ext.| 21 | [2] section 6.15
Table 4.1.b
テーブル4.1.b
Other defined next payload values defined in [2] SHALL not be applied to DHHMAC.
[2]で定義された他の定義された次ペイロード値はDHHMACに適用してはなりません。
In case of a decoding error or of a failed HMAC authentication verification, the responder SHALL apply the Error payload data type.
復号エラーのまたは失敗HMAC認証検証の場合、レスポンダはエラー・ペイロード・データ・タイプを適用しなければなりません。
DHHMAC SHALL apply this payload for conveying the HMAC result along with the indicated authentication algorithm. When used in conjunction with DHHMAC, KEMAC SHALL not convey any encrypted data; thus, Encr alg SHALL be set to 2 (NULL), Encr data len SHALL be set to 0, and Encr data SHALL be left empty. The AES key wrap method (see [16]) SHALL not be applied for DHHMAC.
DHHMACは、示された認証アルゴリズムとともにHMAC結果を搬送するため、このペイロードを適用しなければなりません。 DHHMACと組み合わせて使用すると、KEMACは、任意の暗号化されたデータを伝達してはなりません。 ENCR ALG 2（NULL）に設定されなければならない、したがって、ENCRデータlenが0に設定されなければならない、とENCRデータを空のままにすることがSHALL。 AESキーラップ方法は、（[16]参照）DHHMACに適用してはなりません。
For DHHMAC, this key data transport payload SHALL be the last payload in the message. Note that the Next payload field SHALL be set to Last payload. The HMAC is then calculated over the entire MIKEY message, excluding the MAC field using auth_key as described in [2] section 5.2, and then stored within the MAC field.
DHHMACの場合、このキーデータ転送ペイロードは、メッセージの最後のペイロードされなければなりません。次のペイロードフィールド最終ペイロードに設定されなければならないことに注意してください。 HMACは、その後、[2]のセクション5.2に記載され、そしてその後、MACフィールド内に格納されているようにAUTH_KEY使用MACフィールドを除く、全体MIKEYメッセージに対して計算されます。
MAC alg | Value | Comments
------------------------------------------------------------------
HMAC-SHA-1 | 0 | Mandatory, Default (see [3])
NULL | 1 | Very restricted use; see
| [2] section 4.2.4
Table 4.2.a
表4.2.a
HMAC-SHA-1 is the default hash function that MUST be implemented as part of the DHHMAC. The length of the HMAC-SHA-1 result is 160 bits.
HMAC-SHA-1は、DHHMACの一部として実装する必要があり、デフォルトのハッシュ関数です。 HMAC-SHA-1の結果の長さは160ビットです。
For DHHMAC, this payload SHALL only hold a non-certificate-based identity.
DHHMACのために、このペイロードは唯一の非証明書ベースのアイデンティティを保持するものとします。
For DHHMAC, to avoid bidding-down attacks, this payload SHALL list all key management protocol identifiers of a surrounding encapsulation protocol, such as SDP [4]. The General Extension Payload SHALL be integrity protected with the HMAC using the shared secret.
DHHMACため、入札ダウン攻撃を回避するために、このペイロードは、SDPのような周囲のカプセル化プロトコルのすべてのキー管理プロトコル識別子を列挙しなければならない[4]。一般的な拡張ペイロードは、共有秘密鍵を使用してHMACで保護インテグリティされなければなりません。
Type | Value | Comments SDP IDs | 1 | List of SDP key management IDs (allocated for use in [4]); see also [2] section 6.15.
タイプ|バリュー|コメントSDPのID | 1 | SDP鍵管理IDのリスト（使用のために割り当てられた[4]）。参照[2]のセクション6.15。
Table 4.4.a
表4.4.a
This document addresses key management security issues throughout. For a comprehensive explanation of MIKEY security considerations, please refer to MIKEY [2] section 9.
この文書では、全体の鍵管理のセキュリティ問題に対処しています。 MIKEYのセキュリティに関する考慮事項の包括的な説明については、MIKEY [2]のセクション9を参照してください。
In addition, this document addresses security issues according to [7], where the following security considerations apply in particular to this document:
また、この文書は、[7]、次のセキュリティの考慮事項は、この文書に特に適用場所に応じてセキュリティ問題に対処します。
The DHHMAC security protocol described in this document focuses primarily on communication security; i.e., the security issues concerned with the MIKEY DHHMAC protocol. Nevertheless, some system security issues are also of interest that are not explicitly defined by the DHHMAC protocol, but that should be provided locally in practice.
このドキュメントで説明DHHMACセキュリティプロトコルは、主に通信セキュリティに焦点を当てて。すなわち、MIKEY DHHMACプロトコルに関するセキュリティ問題。それにもかかわらず、いくつかのシステムのセキュリティ上の問題も明示的DHHMACプロトコルによって定義されていない関心のあるが、それは実際にはローカルに提供されるべきです。
The system that runs the DHHMAC protocol entity SHALL provide the capability to generate (pseudo) random numbers as input to the Diffie-Hellman operation (see [8]). Furthermore, the system SHALL be capable of storing the generated (pseudo) random data, secret data, keys, and other secret security parameters securely (i.e., confidential and safe from unauthorized tampering).
DHHMACプロトコルエンティティを実行するシステムは、（[8]参照）のDiffie-Hellman操作への入力として（擬似）乱数を生成する能力を提供しなければなりません。さらに、システムは、生成された（擬似）ランダムデータ、秘密データ、キー、および安全（すなわち、機密および不正改ざんから安全な）他の秘密のセキュリティパラメータを格納することができるものでなければなりません。
The threat model, to which this document adheres, covers the issues of end-to-end security in the Internet generally, without ruling out the possibility that MIKEY DHHMAC can be deployed in a corporate, closed IP environment. This also includes the possibility that MIKEY DHHMAC can be deployed on a hop-by-hop basis with some intermediate trusted "MIKEY DHHMAC proxies" involved.
この文書が付着すると脅威モデルは、MIKEY DHHMACが企業に展開することができるという可能性を除外せずに、IP環境を閉じて、一般的にインターネットでのエンドツーエンドのセキュリティの問題について説明します。また、これはMIKEY DHHMACが関与し、いくつかの中間の信頼された「MIKEY DHHMACプロキシ」とホップバイホップベースで展開することができるという可能性を含んでいます。
Since DHHMAC is a key management protocol, the following security threats are of concern:
DHHMACは、鍵管理プロトコルであるので、次のセキュリティ上の脅威が懸念されます。
* Unauthorized interception of plain TGKs: For DHHMAC, this threat does not occur since the TGK is not actually transmitted on the wire (not even in encrypted fashion).
*平野TGKsの無断傍受：TGKが実際にワイヤ上で送信されていないためDHHMACの場合、この脅威が発生していない（いなくても、暗号化された方法で）。
* Eavesdropping of other, transmitted keying information: DHHMAC protocol does not explicitly transmit the TGK at all. Instead, by using the Diffie-Hellman "encryption" operation, which conceals the secret (pseudo) random values, only partial information (i.e., the DH half-key) for construction of the TGK is transmitted. It is fundamentally assumed that availability of such Diffie-Hellman half-keys to an eavesdropper does not result in any substantial security risk; see 5.4. Furthermore, the DHHMAC carries other data such as timestamps, (pseudo) random values, identification information or security policy parameters; eavesdropping of any such data is not considered to yield any significant security risk.
*その他、送信キーイング情報の盗聴：DHHMACプロトコルは、明示的にすべてのTGKを送信しません。その代わりに、秘密の（擬似）乱数値、部分的にしか情報を隠蔽ディフィー・ヘルマン「暗号化」動作を使用することによって（すなわち、DH半キー）TGKの構築のために送信されます。これは、基本的に、実質的なセキュリティ上のリスクを生じさせない盗聴者に、このようなのDiffie-Hellmanのハーフ鍵の利用可能性を想定しています。 5.4を参照してください。さらに、DHHMACは、タイムスタンプ、（擬似）乱数値、識別情報またはセキュリティポリシーのパラメータのような他のデータを運びます。どのようなデータの盗聴は、重大なセキュリティリスクをもたらすとは考えられません。
* Masquerade of either entity: This security threat must be avoided, and if a masquerade attack would be attempted, appropriate detection means must be in place. DHHMAC addresses this threat by providing mutual peer entity authentication.
*いずれかのエンティティのマスカレード：このセキュリティ脅威は避けなければならない、となりすまし攻撃が試みられる場合には、適切な検出手段は、所定の位置になければなりません。 DHHMACは、相互のピアエンティティの認証を提供することにより、この脅威に対処しています。
* Man-in-the-middle attacks: Such attacks threaten the security of exchanged, non-authenticated messages. Man-in-the-middle attacks usually come with masquerade and or loss of message integrity (see below). Man-in-the-middle attacks must be avoided and, if present or attempted, must be detected appropriately. DHHMAC addresses this threat by providing mutual peer entity authentication and message integrity.
* man-in-the-middle攻撃：このような攻撃は交換し、非認証メッセージのセキュリティを脅かします。 man-in-the-middle攻撃は、通常、仮面舞踏会及びあるいはメッセージの完全性の損失が付属しています（下記参照）。 man-in-the-middle攻撃を避けなければならないと、存在または試行した場合、適切に検出されなければなりません。 DHHMACは、相互のピアエンティティ認証やメッセージの整合性を提供することにより、この脅威に対処しています。
* Loss of integrity: This security threat relates to unauthorized replay, deletion, insertion, and manipulation of messages. Although any such attacks cannot be avoided, they must at least be detected. DHHMAC addresses this threat by providing message integrity.
*完全性の損失：このセキュリティ脅威は、不正再生、削除、挿入、およびメッセージの操作に関するものです。どのような攻撃を回避することはできないが、それらは、少なくとも検出されなければなりません。 DHHMACは、メッセージの整合性を提供することにより、この脅威に対処しています。
* Bidding-down attacks: When multiple key management protocols, each of a distinct security level, are offered (such as those made possible by SDP [4]), avoiding bidding-down attacks is of concern. DHHMAC addresses this threat by reusing the MIKEY General Extension Payload mechanism, where all key management protocol identifiers are to be listed within the MIKEY General Extension Payload.
*入札ダウン攻撃：複数のキー管理プロトコル、異なるセキュリティレベルのそれぞれが、提供されている（例えば、SDPによって可能になるものと[4]）、入札ダウン攻撃を回避することが懸念されます。 DHHMACは、すべての鍵管理プロトコル識別子は、MIKEY一般的な拡張ペイロード内にリストされるMIKEY一般的な拡張ペイロードメカニズムを、再利用することで、この脅威に対処しています。
Some potential threats are not within the scope of this threat model:
いくつかの潜在的な脅威は、この脅威モデルの範囲内ではありません。
* Passive and off-line cryptanalysis of the Diffie-Hellman algorithm: Under certain reasonable assumptions (see 5.4, below), it is widely believed that DHHMAC is sufficiently secure and that such attacks are infeasible, although the possibility of a successful attack cannot be ruled out.
*パッシブおよびDiffie-Hellmanアルゴリズムのオフライン解読：一定の合理的な仮定（以下、5.4を参照）の下では、広くDHHMACが十分に安全であると攻撃が成功する可能性があることはできませんが、このような攻撃は、実行不可能であるとすると考えられています除外する。
* Non-repudiation of the receipt or of the origin of the message: These are not requirements within the context of DHHMAC in this environment, and thus related countermeasures are not provided at all.
*領収書のか、メッセージの発信元の否認防止：これらは、この環境でDHHMACのコンテキスト内で要件ではありませんので、関連対策は全く提供されていません。
* Denial-of-service or distributed denial-of-service attacks: Some considerations are given on some of those attacks, but DHHMAC does not claim to provide full countermeasure against any of those attacks. For example, stressing the availability of the entities is not thwarted by means of the key management protocol; some other local countermeasures should be applied. Further, some DoS attacks are not countered, such as interception of a valid DH- request and its massive instant duplication. Such attacks might at least be countered partially by some local means that are outside the scope of this document.
*サービス拒否または分散サービス拒否攻撃：いくつかの考慮事項は、これらの攻撃のいくつかに与えられているが、DHHMACは、これらの攻撃のいずれかに対する完全な対策を提供することを主張しません。例えば、鍵管理プロトコルによって阻止されていないエンティティの利用可能性を強調し、いくつかの他の地域の対策が適用されるべきです。さらに、いくつかのDoS攻撃は、有効なDH-要求の傍受とその巨大なインスタント重複として、対抗されていません。このような攻撃は、少なくともこの文書の範囲外にあるいくつかの地元の手段によって部分的に相殺されるかもしれません。
* Identity protection: Like MIKEY, identity protection is not a major design requirement for MIKEY-DHHMAC, either; see [2]. No security protocol is known so far that is able to provide the objectives of DHHMAC as stated in section 5.3, including identity protection within just a single roundtrip. MIKEY-DHHMAC trades identity protection for better security for the keying material and shorter roundtrip time. Thus, MIKEY-DHHMAC does not provide identity protection on its own but may inherit such property from a security protocol underneath that actually features identity protection.
*アイデンティティの保護：同様MIKEY、アイデンティティ保護はMIKEY-DHHMACのための主要な設計要件ではなく、どちらか。 [2]を参照してください。いいえセキュリティプロトコルを1つだけ往復内のアイデンティティ保護など、5.3節で述べたようDHHMACの目的を提供することができるという、これまでに知られていません。 MIKEY-DHHMACは鍵のための優れたセキュリティと短い往復時間のためのID保護の売買を行っています。このように、MIKEY-DHHMACは、独自のアイデンティティ保護を提供していませんが、それは実際にはアイデンティティ保護を備えて下にセキュリティプロトコルから、このような性質を継承することができます。
The DHHMAC security protocol (see section 3) and the TGK re-keying security protocol (see section 3.1) provide the option not to supply identity information. This option is only applicable if some other means are available to supply trustworthy identity information; e.g., by relying on secured links underneath MIKEY that supply trustworthy identity information some other way. However, it is understood that without identity information, the MIKEY key management security protocols might be subject to security weaknesses such as masquerade, impersonation, and reflection attacks, particularly in end-to-end scenarios where no other secure means of assured identity information are provided.
DHHMACセキュリティプロトコル（セクション3を参照）、TGK再キーイングセキュリティプロトコル（セクション3.1を参照）識別情報を提供しないオプションを提供します。いくつかの他の手段は、信頼できるアイデンティティ情報を提供するために利用されている場合、このオプションはのみ適用されます。例えば、信頼できる識別情報にいくつかの他の方法を提供MIKEYの下に保護されたリンクに依存することによって。しかし、識別情報なしで、MIKEY鍵管理セキュリティプロトコルは、特に確実な識別情報の他の安全な手段はないエンドツーエンドのシナリオでは、このようななりすまし、偽装、および反射攻撃などのセキュリティ上の弱点を受けるかもしれないことが理解されます提供。
Leaving identity fields optional (if doing so is possible) thus should not be seen as a privacy method, either, but rather as a protocol optimization feature.
（そうすることが可能である場合）、オプションのアイデンティティフィールドを残しては、このようにではなく、プロトコルの最適化機能など、いずれか、プライバシーの方法として見られるべきではありません。
With the security threats in mind, this document provides the following security features and yields the following properties:
心の中でセキュリティ上の脅威では、この文書には、次のセキュリティ機能を提供し、次のプロパティが得られます。
* Secure key agreement with the establishment of a TGK at both peers: This is achieved using an authenticated Diffie-Hellman key management protocol.
*両方のピアにTGKの確立と鍵の合意を確保：これは、認証されたDiffie-Hellman鍵管理プロトコルを使用して達成されます。
* Peer-entity authentication (mutual): This authentication corroborates that the host/user is authentic in that possession of a pre-assigned secret key is proven using keyed HMAC. Authentication occurs on the request and on the response message; thus authentication is mutual.
*ピア・エンティティ認証（相互）：この認証は、ホスト/ユーザーが事前に割り当てられた秘密鍵は鍵付きHMACを使用して証明されたの所持して本物であることを確証します。認証リクエストに応じて、応答メッセージに発生します。したがって認証は相互です。
The HMAC computation corroborates for authentication and message integrity of the exchanged Diffie-Hellman half-keys and associated messages. The authentication is absolutely necessary in order to avoid man-in-the-middle attacks on the exchanged messages in transit and, in particular, on the otherwise non-authenticated exchanged Diffie-Hellman half-keys.
HMACの計算は、交換のDiffie-Hellmanのハーフキーおよびそれに関連するメッセージの認証やメッセージの整合性のための確証します。認証は、輸送中に交換されるメッセージのman-in-the-middle攻撃を避けるために絶対に必要であると、特に、そうでない場合は非認証にディフィー・ヘルマン半鍵を交換しました。
Note: This document does not address issues regarding authorization; this feature is not provided explicitly. However, DHHMAC authentication means support and facilitate realization of authorization means (local issue).
注意：この文書は、認証に関する問題に対処しません。この機能は、明示的に提供されていません。しかし、DHHMAC認証がサポートを意味し、認証手段（ローカル問題）の実現を促進します。
* Cryptographic integrity check: The cryptographic integrity check is achieved using a message digest (keyed HMAC). It includes the exchanged Diffie-Hellman half-keys but covers the other parts of the exchanged message as well. Both mutual peer entity authentication and message integrity provide effective countermeasures against man-in-the-middle attacks.
*暗号化整合性チェック：暗号整合性チェックは、メッセージダイジェスト（鍵付きHMAC）を使用して達成されます。これは、交換のDiffie-Hellmanの半キーを含むが、同様に交換メッセージの他の部分を覆っています。相互ピアエンティティ認証やメッセージの整合性の両方がman-in-the-middle攻撃に対して有効な対策を提供します。
The initiator may deploy a local timer that fires when the awaited response message did not arrive in a timely manner. This is intended to detect deletion of entire messages.
イニシエータは待望の応答メッセージがタイムリーに到着しなかったときに起動ローカルタイマーを配備することがあります。これは、メッセージ全体の削除を検出することを目的とします。
* Replay protection of the messages is achieved using embedded timestamps: In order to detect replayed messages, it is essential that the clocks among initiator and sender be roughly synchronized. The reader is referred to [2] section 5.4, and [2] section 9.3, which provide further considerations and give guidance on clock synchronization and timestamp usage. Should the clock synchronization be lost, end systems cannot detect replayed messages anymore, and the end systems cannot securely establish keying material. This may result in a denial-of-service; see [2] section 9.5.
*埋め込まれたタイムスタンプを使用して達成されるメッセージのリプレイ保護：再演メッセージを検出するためには、イニシエータと送信者の間でクロックがおおよそ同期させることが不可欠です。読者はさらなる考察を提供し、クロック同期とタイムスタンプの使用に関するガイダンスを与える[2]のセクション5.4、及び[2]のセクション9.3、と呼ばれます。クロック同期が失われるべき、エンドシステムはもう再演メッセージを検出することができない、とエンドシステムはしっかりと鍵材料を確立することはできません。これは、サービス拒否をもたらすことができます。 [2]のセクション9.5を参照。
* Limited DoS protection: Rapid checking of the message digest allows verifying the authenticity and integrity of a message before launching CPU intensive Diffie-Hellman operations or starting other resource consuming tasks. This protects against some denial-of-service attacks: malicious modification of messages and spam attacks with (replayed or masqueraded) messages. DHHMAC probably does not explicitly counter sophisticated distributed, large-scale denial-of-service attacks that compromise system availability, for example. Some DoS protection is provided by inclusion of the initiator's identity payload in the I_message. This allows the recipient to filter out those (replayed) I_messages that are not targeted for him and to avoid creating unnecessary MIKEY sessions.
*限定のDoS保護：ダイジェストはCPUに負荷をかけのDiffie-Hellmanオペレーションを起動するか、他のリソースのかかる作業を開始する前に、メッセージの信憑性と整合性を検証することができますメッセージの迅速なチェック。これは、いくつかのサービス拒否攻撃からの保護：（再生またはマスカレード）メッセージでメッセージとスパム攻撃の悪質な変更を。 DHHMACはおそらく、例えば妥協のシステムの可用性、ということではない明示的にカウンター洗練された分散、大規模なDoS攻撃を行います。いくつかのDoS保護がI_messageのイニシエータのアイデンティティペイロードを含めることによって提供されます。これは、受信者が彼のために標的にされていないと、不必要なMIKEYセッションを作成しないように、これらの（リプレイ）I_messagesをフィルタリングすることができます。
* Perfect-forward secrecy (PFS): Other than the MIKEY pre-shared and public-key-based key distribution protocols, the Diffie-Hellman key agreement protocol features a security property called perfect forward secrecy. That is, even if the long-term pre-shared key is compromised at some point in time, this does not compromise past or future session keys.
*パーフェクト・転送秘密（PFS）：MIKEY事前共有と公開鍵ベースの鍵配送プロトコル以外に、のDiffie-Hellman鍵合意プロトコルは、完全転送秘密と呼ばれるセキュリティプロパティを備えています。それは長期的な事前共有鍵がある時点で侵害されたとしても、これは過去や未来のセッションキーを損なわない、です。
Neither the MIKEY pre-shared nor the MIKEY public-key protocol variants are able to provide the security property of perfect-forward secrecy. Thus, none of the other MIKEY protocols is able to substitute the Diffie-Hellman PFS property.
マイキー事前共有もMIKEY公開鍵プロトコルの変異体は、完全なフォワード秘密のセキュリティプロパティを提供することができますどちらも。したがって、他のMIKEYプロトコルのいずれも、ディフィー - ヘルマンPFSのプロパティを置換することができません。
As such, DHHMAC and digitally signed DH provide a far superior security level to that of the pre-shared or public-key-based key distribution protocol in that respect.
このように、DHHMACおよびデジタル署名されたDHは、その点における事前共有または公開鍵ベースの鍵配布プロトコルのものにはるかに優れたセキュリティレベルを提供します。
* Fair, mutual key contribution: The Diffie-Hellman key management protocol is not a strict key distribution protocol per se, in which the initiator distributes a key to its peers. Actually, both parties involved in the protocol exchange are able to contribute to the common Diffie-Hellman TEK traffic generating key equally. This reduces the risk of either party cheating or unintentionally generating a weak session key. This makes the DHHMAC a fair key agreement protocol. One may view this property as an additional distributed security measure that increases security robustness over that of the case where all the security depends just on the proper implementation of a single entity.
*フェア、相互鍵寄与：のDiffie-Hellman鍵管理プロトコルは、イニシエータがそのピアの鍵を配布する、それ自体の厳密な鍵配布プロトコルではありません。実際には、プロトコル交換に関わる両当事者が平等に共通のDiffie-HellmanのTEKトラフィック生成キーに貢献することができます。これは、パーティの不正行為または意図せずに弱いセッション鍵を生成するいずれかのリスクを低減します。これはDHHMAC公正鍵合意プロトコルになります。一つは、すべてのセキュリティは、単に単一のエンティティの適切な実装に依存する場合とにわたってセキュリティの堅牢性を増加させる追加の分散セキュリティ対策として、このプロパティを見ることができます。
For Diffie-Hellman key agreement to be secure, each party SHALL generate its xi or xr values using a strong, unpredictable pseudo-random generator if a source of true randomness is not available. Further, these values xi or xr SHALL be kept private. It is RECOMMENDED that these secret values be destroyed once the common Diffie-Hellman shared secret key has been established.
Diffie-Hellman鍵が安全であるためには、各当事者は、真の乱数の発生源が利用できない場合、強力な、予測不可能な擬似乱数生成器を使用して、そのXIまたはXRの値を生成しなければなりません。さらに、これらの値のXIまたはXRは、専用保管されなければなりません。共通のDiffie-Hellmanの秘密鍵が確立された共有の後にこれらの秘密の値が破壊されることが推奨されます。
* Efficiency and performance: Like the MIKEY-public key protocol, the MIKEY DHHMAC key agreement protocol securely establishes a TGK within just one roundtrip. Other existing key management techniques, such as IPsec-IKE [12], IPsec-IKEv2 [14], TLS [11], and other schemes, are not deemed adequate in addressing those real-time and security requirements sufficiently; they all use more than a single roundtrip. All the MIKEY key management protocols are able to complete their task of security policy parameter negotiation, including key-agreement or key distribution, in one roundtrip. However, the MIKEY pre-shared and MIKEY public-key protocol are both able to complete their task even in a half-roundtrip when the confirmation messages are omitted.
*効率とパフォーマンス：MIKEY-公開鍵プロトコルと同様に、MIKEY DHHMAC鍵合意プロトコルは安全にちょうど1往復以内TGKを確立します。このようなIPsecでIKEのような他の既存の鍵管理技術、[12]、IPsecでのIKEv2 [14]、TLS [11]、及び他の方式は、十分にこれらのリアルタイムおよびセキュリティ要件に対処する上で適切とみなされていません。それらはすべて、単一の往復以上のものを使用します。すべてのMIKEY鍵管理プロトコルは、1回の往復で、キー契約またはキーの配布を含め、セキュリティポリシーのパラメータの交渉の彼らのタスクを完了することができます。しかし、MIKEY事前共有とMIKEY公開鍵プロトコルは、両方の確認メッセージが省略されたときに半往復でも、自分のタスクを完了することができます。
Using HMAC in conjunction with a strong one-way hash function (such as SHA1) may be achieved more efficiently in software than expensive public-key operations. This yields a particular performance benefit of DHHMAC over signed DH or the public-key encryption protocol.
（例えばSHA1など）の強力な一方向ハッシュ関数と一緒にHMACを使用すると、高価な公開鍵操作よりも、ソフトウェアでより効率的に達成することができます。これは、署名DHや公開鍵暗号プロトコルを介しDHHMACの特定のパフォーマンス上の利点が得られます。
If a very high security level is desired for long-term secrecy of the negotiated Diffie-Hellman shared secret, longer hash values may be deployed, such as SHA256, SHA384, or SHA512 provide, possibly in conjunction with stronger Diffie-Hellman groups. This is left as for further study.
非常に高いセキュリティレベルをネゴシエートディフィー - ヘルマンの長期秘密のために共有秘密が望まれる場合、より長いハッシュ値は、例えばSHA256、SHA384、またはSHA512ように、展開することができる可能性が強いのDiffie-Hellmanグループと一緒に、提供します。これは、さらなる研究のためとして残されています。
For the sake of improved performance and reduced roundtrip delay, either party may pre-compute its public Diffie-Hellman half-key off-line.
性能向上のためと減少往復遅延については、いずれの当事者もオフラインでその公共のDiffie-Hellmanの半分のキーをあらかじめ計算します。
On the other side and under reasonable conditions, DHHMAC consumes more CPU cycles than the MIKEY pre-shared key distribution protocol. The same might hold true quite likely for the MIKEY public-key distribution protocol (depending on choice of the private and public key lengths). As such, it can be said that DHHMAC provides sound performance when compared with the other MIKEY protocol variants.
反対側にかつ合理的な条件の下で、DHHMACはMIKEYの事前共有鍵配布プロトコルよりも多くのCPUサイクルを消費します。 （秘密鍵と公開鍵の長さの選択に応じて）MIKEY公開鍵配布プロトコルのために非常に可能性が当てはまるかもしれません同じ。このように、他のMIKEYプロトコル変異体と比較した場合DHHMAC音性能を提供するということができます。
The use of optional identity information (with the constraints stated in section 5.2) and optional Diffie-Hellman half-key fields provides a means to increase performance and shorten the consumed network bandwidth.
（セクション5.2で述べた制約を持つ）、オプションの識別情報とオプションのDiffie-Hellmanの半キーフィールドの使用は、パフォーマンスを向上させ、消費されるネットワーク帯域幅を短くするための手段を提供します。
* Security infrastructure: This document describes the HMAC-authenticated Diffie-Hellman key agreement protocol, which completely avoids digital signatures and the associated public-key infrastructure, as would be necessary for the X.509 RSA public-key-based key distribution protocol or the digitally signed Diffie-Hellman key agreement protocol as described in MIKEY. Public-key infrastructures may not always be available in certain environments, nor may they be deemed adequate for real-time multimedia applications when additional steps are taken for certificate validation and certificate revocation methods with additional roundtrips into account.
*セキュリティインフラ：このドキュメントはX.509 RSA公開鍵ベースの鍵配布プロトコルのために必要であるように、完全にデジタル署名および関連する公開鍵インフラストラクチャを回避するHMAC認証のDiffie-Hellman鍵合意プロトコルを記述またはMIKEYに記載されているように、デジタルのDiffie-Hellman鍵合意プロトコルに署名しました。公開鍵インフラストラクチャは、常に一定の環境では使用できない可能性があり、また、追加の手順がアカウントに追加往復して証明書の検証と証明書失効方法のために採取されたとき、彼らは、リアルタイムのマルチメディア・アプリケーションのための十分なとみなすことができます。
DHHMAC does not depend on PKI, nor do implementations require PKI standards. Thus, it is believed to be much simpler than the more complex PKI facilities.
DHHMACはPKIに依存しない、また実装はPKI規格を必要とします。したがって、より複雑なPKI施設よりもはるかに簡単であると考えられています。
DHHMAC is particularly attractive in those environments where provisioning of a pre-shared key has already been accomplished.
DHHMACは、事前共有鍵のプロビジョニングが既に達成されてきたこれらの環境で特に魅力的です。
* NAT-friendliness: DHHMAC is able to operate smoothly through firewall/NAT devices as long as the protected identity information of the end entity is not an IP/transport address.
* NATフレンドリー：DHHMACは限りエンドエンティティの保護された識別情報は、IP /トランスポートアドレスではないとして、ファイアウォール/ NATデバイスを介してスムーズに動作することができます。
* Scalability: Like the MIKEY signed Diffie-Hellman protocol, DHHMAC does not scale to any larger configurations beyond peer-to-peer groups.
*スケーラビリティ：MIKEYは、ディフィー - ヘルマンプロトコルに署名したと同様に、DHHMACは、ピア・ツー・ピア・グループを越えた大規模な構成に拡張しません。
This document states a couple of assumptions upon which the security of DHHMAC significantly depends. The following conditions are assumed:
この文書では、DHHMACのセキュリティが大幅に依存する仮定のカップルを述べています。以下の条件を想定しています。
* The parameters xi, xr, s, and auth_key are to be kept secret.
*パラメータxiを、XR、S、及びAUTH_KEYは秘密にしておくべきです。
* The pre-shared key s has sufficient entropy and cannot be effectively guessed.
*事前共有鍵sが十分エントロピーを有しており、効果的に推測することはできません。
* The pseudo-random function (PRF) is secure, yields the pseudo-random property, and maintains the entropy.
擬似ランダム関数（PRF）は安全である*、疑似ランダム性をもたらし、そしてエントロピーを維持します。
* A sufficiently large and secure Diffie-Hellman group is applied.
*十分に大きく、固定のDiffie-Hellmanグループが適用されます。
* The Diffie-Hellman assumption holds saying basically that even with knowledge of the exchanged Diffie-Hellman half-keys and knowledge of the Diffie-Hellman group, it is infeasible to compute the TGK or to derive the secret parameters xi or xr. The latter is also called the discrete logarithm assumption. Please see [6], [9], or [10] for more background information regarding the Diffie-Hellman problem and its computational complexity assumptions.
*のDiffie-Hellman仮定でも、交換のDiffie-HellmanのハーフキーおよびDiffie-Hellmanグループの知識の知識を持って、TGKを計算したり、秘密のパラメータXIまたはXRを導き出すために実行不可能であることを基本的に言って保持しています。後者はまた、離散対数仮定と呼ばれます。見てください、[6]、[9]、または[10]のDiffie-Hellman問題とその計算の複雑さの仮定に関する詳細な背景情報について。
* The hash function (SHA1) is secure; i.e., it is computationally infeasible to find a message that corresponds to a given message digest, or to find two different messages that produce the same message digest.
*ハッシュ関数（SHA1）は安全です。すなわち、消化、又は同一のメッセージダイジェストを生成する2つの異なるメッセージを見つけるために与えられたメッセージに対応するメッセージを見つけることが計算上不可能です。
* The HMAC algorithm is secure and does not leak the auth_key. In particular, the security depends on the message authentication property of the compression function of the hash function H when it is applied to single blocks (see [5]).
* HMACアルゴリズムは安全であるとAUTH_KEYを漏洩しません。具体的には、セキュリティは、それが単一のブロックに適用されるとき、ハッシュ関数Hの圧縮関数のメッセージ認証特性に依存（参照[5]）。
* A source capable of producing sufficiently many bits of (pseudo) randomness is available.
*（擬似）乱数の十分に多くのビットを生成することができるソースが利用可能です。
* The system upon which DHHMAC runs is sufficiently secure.
* DHHMACが実行される時にシステムが十分に安全です。
Although these detailed assumptions are non-negligible, security experts generally believe that all these assumptions are reasonable and that the assumptions made can be fulfilled in practice with little or no expenses.
これらの詳細な仮定は無視できないですが、セキュリティ専門家は、一般的に、すべてのこれらの仮定が妥当であると考えていると仮定は、ほとんど、あるいはまったく費用を実際に満たすことができるという。
The mathematical and cryptographic assumptions of the properties of the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the HMAC algorithm, and the SHA1 algorithms have been neither proven nor disproven at this time.
PRF、のDiffie-Hellmanアルゴリズム（離散対数仮定）、HMACアルゴリズム、およびSHA1アルゴリズムの性質の数学と暗号化の仮定は証明もなく、この時点では反証されているどちらも。
Thus, a certain residual risk remains, which might threaten the overall security at some unforeseeable time in the future.
このように、一定の残存リスクは、将来のある予測できない時点で全体のセキュリティを脅かす可能性がある、残っています。
The DHHMAC would be compromised as soon as any of the listed assumptions no longer hold.
DHHMACはすぐにリストされた仮定のいずれかが、もはや保持するよう損なわれることになります。
The Diffie-Hellman mechanism is a generic security technique that is not only applicable to groups of prime order or of characteristic two. This is because of the fundamental mathematical assumption that the discrete logarithm problem is also a very hard one in general groups. This enables Diffie-Hellman to be deployed also for GF(p)*, for sub-groups of sufficient size, and for groups upon elliptic curves. RSA does not allow such generalization, as the core mathematical problem is a different one (large integer factorization).
Diffie-Hellmanメカニズムは素の特性や2のグループにのみ適用されない一般的なセキュリティ技術です。これは、離散対数問題は、一般的なグループでは非常に難しいものであるとの基本的な数学的な仮定です。これは、GF（p）*ために、十分なサイズのサブグループのために、及び楕円曲線時グループにも展開されるようにディフィー - ヘルマンを可能にします。コア数学的問題は、別のもの（大整数因数分解）であるようにRSAは、そのような一般化を可能にしません。
RSA asymmetric keys tend to become increasingly lengthy (1536 bits and more) and thus very computationally intensive. Nevertheless, Elliptic Curve Diffie-Hellman (ECDH) allows key lengths to be cut down substantially (say 170 bits or more) while maintaining at least the security level and providing even more significant performance benefits in practice. Moreover, it is believed that elliptic-curve techniques provide much better protection against side channel attacks due to the inherent redundancy in the projective coordinates. For all these reasons, one may view elliptic-curve-based Diffie-Hellman as being more "future-proof" and robust against potential threats than RSA is. Note that Elliptic Curve Diffie-Hellman variants of MIKEY are defined in [31].
RSA非対称鍵は、（1536ビット以上）、したがって、非常に計算集約ますます長くなる傾向があります。少なくともセキュリティレベルを維持し、実際にはさらに多くの顕著な性能上の利点を提供しながら、それにもかかわらず、楕円曲線ディフィ - ヘルマン（ECDH）は（170ビット以上を言う）キーの長さが実質的に削減することが可能になります。また、楕円曲線技術は、射影座標に固有の冗長性によるサイドチャネル攻撃に対するより良い保護を提供すると考えられています。すべてのこれらの理由のために、一つは複数の「将来性」とRSAはより潜在的な脅威に対してロバストであるように、楕円曲線に基づくディフィー・ヘルマンを見ることができます。 MIKEYの楕円曲線のDiffie-Hellman変異体は[31]で定義されることに留意されたいです。
HMAC-SHA1 is a key security mechanism within DHHMAC on which the overall security of MIKEY DHHMAC depends. MIKEY DHHMAC uses HMAC-SHA1 in combination with the classic Diffie-Hellman key agreement scheme. HMAC-SHA1 is a keyed one-way hash function that involves a secret in its computation. DHHMAC applies HMAC-SHA1 for protection of the MIKEY payload. Likewise, the pseudo-random function PRF within MIKEY [2] uses the HMAC-SHA1 mechanism as a key derivation function. While certain attacks have been reported against SHA1 and MD5 (see [29]), with current knowledge (see [29], [30]), no attacks have been reported against the HMAC-SHA1 security mechanism. In fact, [32] proves that HMAC possesses the property of a pseudo-random function PRF assuming solely that the (SHA1) hash function is a pseudo-random function. [32] also provides evidence that HMAC is robust against collision attacks on the underlying hash function. It is believed that MIKEY DHHMAC should be considered secure enough for the time being. Thus, there is no need to change the underlying security mechanism within the MIKEY DHHMAC protocol.
HMAC-SHA1は、MIKEY DHHMACの全体的なセキュリティが依存するDHHMAC内の主要なセキュリティメカニズムです。 MIKEY DHHMACは古典のDiffie-Hellman鍵共有方式との組み合わせでHMAC-SHA1を使用しています。 HMAC-SHA1は、その計算に秘密を必要とする鍵付き一方向ハッシュ関数です。 DHHMACはマイキーペイロードの保護のためにHMAC-SHA1を適用します。 MIKEY以内同様に、擬似乱数関数PRF [2]キー導出関数としてHMAC-SHA1メカニズムを使用します。特定の攻撃はSHA1およびMD5（[29]参照）に対して報告されているが、現在の知識（[30]、[29]参照）と、全く攻撃はHMAC-SHA1のセキュリティメカニズムに対して報告されていません。実際には、[32] HMACは、（SHA1）ハッシュ関数は、擬似ランダム関数であることを単に仮定した擬似ランダム関数PRFの特性を有することを証明しています。 [32]また、HMACは、基礎となるハッシュ関数の衝突攻撃に対して堅牢であるという証拠を提供します。 MIKEY DHHMACは、当分の間、十分に安全な考慮すべきであると考えられています。したがって、MIKEY DHHMACプロトコル内で基本的なセキュリティ・メカニズムを変更する必要はありません。
It is not recommended to deploy DHHMAC for any other use than that depicted in section 2. Any misapplication might lead to unknown, undefined properties.
任意の誤用が不明、未定義のプロパティにつながる可能性セクション2に示したもの以外の使用のためにDHHMACを展開することは推奨されません。
Basically, similar remarks on authorization as those stated in [2] section 4.3.2 hold also for DHHMAC. However, as noted before, this key management protocol does not serve full groups.
基本的に、[2]のセクション4.3.2に記載されたものとして許可に同様の発言はDHHMACにも保持します。しかし、前に述べたように、この鍵管理プロトコルは、完全なグループにサービスを提供しません。
One may view the pre-established shared secret as yielding some pre-established trust relationship between the initiator and the responder. This results in a much simpler trust model for DHHMAC than would be the case for some generic group key management protocol and potential group entities without any pre-defined trust relationship. In conjunction with the assumption of a shared key, the common group controller simplifies the communication setup of the entities.
一つは、イニシエータとレスポンダとの間のいくつかの予め確立された信頼関係をもたらすように事前に確立された共有秘密を見ることができます。これは、任意の事前定義された信頼関係なしに、いくつかの一般的なグループ鍵管理プロトコルと潜在的なグループのエンティティの場合よりもDHHMACのためのはるかに単純な信頼モデルになります。共有鍵の仮定に関連して、共通のグループコントローラは、エンティティの通信設定を簡略化します。
One may view the pre-established trust relationship through the pre-shared secret as some means for pre-granted, implied authorization. This document does not define any particular authorization means but leaves this subject to the application.
一つは、事前に付与された、暗黙の承認のためのいくつかの手段として、事前共有秘密を通じて事前に確立された信頼関係を見ることができます。この文書は、特定の認証手段を定義しますが、アプリケーションにこの主題を残していません。
This document incorporates kindly, valuable review feedback from Steffen Fries, Hannes Tschofenig, Fredrick Lindholm, Mary Barnes, and Russell Housley and general feedback by the MSEC WG.
この文書では、親切にステファンのフライドポテト、ハンネスTschofenig、フレドリック・リンドホルム、メアリー・バーンズ、そしてラッセルHousley氏とMSEC WGによる一般的なフィードバックからの貴重なレビューのフィードバックを内蔵しています。
This document does not define its own new name spaces for DHHMAC, beyond the IANA name spaces that have been assigned for MIKEY; see [2] sections 10 and 10.1 and IANA MIKEY payload name spaces [37].
この文書では、MIKEYのために割り当てられているIANA名前空間を超えて、DHHMACのための独自の新しい名前空間を定義していません。 [37] [2]のセクション10と10.1とIANA MIKEYペイロード名前空間を参照してください。
In order to align Table 4.1.a with Table 6.1.a in [2], IANA is requested to add the following entries to their MIKEY Payload Name Space:
表の6.1.aと表4.1.aを整列させるために、[2]、IANAは、それらMIKEYペイロード名前空間に次のエントリを追加するために要求されます。
Data Type Value Reference
--------------- ----- ---------
DHHMAC init 7 RFC 4650
DHHMAC resp 8 RFC 4650
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[2] Arkko、J.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK.ノルウェー、 "MIKEY：マルチメディアインターネットキーイング"、RFC 3830、2004年8月。
[3] NIST, FIBS-PUB 180-2, "Secure Hash Standard", April 1995, http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2withchangenotice.pdf.
[3] NIST、FIBS-PUB 180-2、 "セキュアハッシュ標準"、1995年4月、http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2withchangenotice.pdf。
[4] 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.
[4] Arkko、J.、リンドホルム、F.、Naslund、M.、Norrman、K.、およびE.カララ、 "鍵管理拡張セッション記述プロトコル（SDP）、リアルタイムストリーミングプロトコル（RTSP）のための"、RFC 4567、2006年7月。
[5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[5] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[6] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of Applied Cryptography", CRC Press 1996.
[6] A.J.メネゼス、P.バンOorschot、S. A. Vanstone著： "応用暗号のハンドブック"、CRCプレス1996。
[7] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[7]、BCP 72、RFC 3552、2003年7月レスコラ、E.とB.コーバー、 "セキュリティの考慮事項の書き方RFCテキストのためのガイドライン"。
[8] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[8]イーストレーク第3、D.、クロッカー、S.、およびJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[9] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol", Designs, Codes, and Cryptography, Special Issue Public Key Cryptography, Kluwer Academic Publishers, vol. 19, pp. 147-171, 2000. ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps.
[9] Ueli M.マウラー、S.ウルフ：「ディフィー - ヘルマンプロトコル」、デザイン、コード、及び暗号、特集公開鍵暗号、Kluwerのアカデミック出版、体積19頁147から171まで、2000年ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps。
[10] Discrete Logarithms and the Diffie-Hellman Protocol, http://www.crypto.ethz.ch/research/ntc/dldh/.
[10]離散対数とディフィー・ヘルマンプロトコル、http://www.crypto.ethz.ch/research/ntc/dldh/。
[11] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[11]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[12] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[12]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[13]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[14]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[15] ITU-T Recommendation H.235.7: " H.323 Security framework: Usage of the MIKEY Key Management Protocol for the Secure Real Time Transport Protocol (SRTP) within H.235"; 9/2005.
[15] ITU-T勧告H.235.7：「H.323セキュリティフレームワーク：H.235内のセキュアリアルタイムトランスポートプロトコル（SRTP）用MIKEY鍵管理プロトコルの使用法」; 2005分の9。
[16] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[16] Schaad、J.とR. Housley氏、 "高度暗号化標準（AES）キーラップアルゴリズム"、RFC 3394、2002年9月。
[17] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[17] Baugher、M.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2003年7月。
[18] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[18]ハーニー、H.、メタ、U.、Colegrove、A.、およびG.グロス、 "GSAKMP：グループは、協会鍵管理プロトコルセキュア"、RFC 4535、2006年6月を。
[19] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005.
[19] Baugher、M.、カネッティ、R.、Dondeti、L.、およびF.リンドホルム、 "マルチキャストセキュリティ（MSEC）グループ鍵管理アーキテクチャ"、RFC 4046、2005年4月。
[20] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[20] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[21] ITU-T Recommendation H.235.0, " H.323 Security framework: Security framework for H-series (H.323 and other H.245 based) multimedia systems", (09/2005).
[21] ITU-T勧告H.235.0、 "H.323セキュリティフレームワーク：Hシリーズ（H.323および他のH.245ベースの）マルチメディアシステムのためのセキュリティフレームワーク"（09/2005）。
[22] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[22]アダムス、C.、ファレル、S.、Kause、T.、およびT. Mononen、 "インターネットX.509公開鍵基盤証明書管理プロトコル（CMP）"、RFC 4210、2005年9月。
[23] 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.
[23]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[24] Adams, C., Sylvester, P., Zolotarev, M., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols", RFC 3029, February 2001.
[24]アダムス、C.、シルベスター、P.、Zolotarev、M.、およびR. Zuccherato、 "インターネットX.509公開鍵インフラストラクチャデータの検証と認証サーバプロトコル"、RFC 3029、2001年2月。
[25] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
Schaad、J.、 "インターネットX.509公開鍵暗号基盤証明書要求メッセージ・フォーマット（CRMF）"、RFC 4211、2005年9月[25]。
[26] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building", RFC 4158, September 2005.
[26]クーパー、M.、Dzambasow、Y.、ヘッセン、P.、ジョセフ、S.、およびR.ニコラス、 "X.509のインターネット公開鍵は構造nfra：建物の証明のパス"、RFC 4158、2005年9月を。
[27] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[27]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[37] IANA MIKEY Payload Name Spaces per RFC 3830, see http://www.iana.org/assignments/mikey-payloads.
[37] RFC 3830あたりIANA MIKEYペイロード名前空間を、http://www.iana.org/assignments/mikey-payloads参照。
[29] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[29]ホフマン、P.とB.シュナイアー、 "インターネットプロトコルで暗号化ハッシュに対する攻撃"、RFC 4270、2005年11月。
[30] Bellovin, S.M. and E.K. Rescorla: "Deploying a New Hash Algorithm", October 2005, http://www.cs.columbia.edu/~smb/papers/new-hash.pdf.
[30] Bellovin氏、S。M.そして、E.K.レスコラ：2005年10月、http://www.cs.columbia.edu/~smb/papers/new-hash.pdf「新しいハッシュアルゴリズムを展開します」。
[31] Milne, A., Blaser, M., Brown, D., and L. Dondetti, "ECC Algorithms For MIKEY", Work in Progress, June 2005.
[31]ミルン、A.、ブレイザー、M.、ブラウン、D.、およびL. Dondetti、 "MIKEYについてECCアルゴリズム"、進歩、2005年6月ワーク。
[32] Bellare, M.: "New Proofs for NMAC and HMAC: Security Without Collision-Resistance", http://eprint.iacr.org/2006/043.pdf, November 2005.
[32]ベラー、M： "NMACとHMACのための新しい証明：衝突、抵抗なくセキュリティ"、http://eprint.iacr.org/2006/043.pdf、2005年11月。
[33] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "An additional mode of key Distribution in MIKEY: MIKEY-RSA-R", Work in Progress, August 2006.
[33] Ignjatic、D.、Dondeti、L.、Audet、F.、およびP.林、 "MIKEYにおける鍵配布の追加モード：MIKEY-RSA-R"、進歩、2006年8月に作業。
Appendix A. Usage of MIKEY-DHHMAC in H.235
H.235でのマイキー・DHHMACの付録A.使い方
This appendix provides informative overview how MIKEY-DHHMAC can be applied in some H.323-based multimedia environments. Generally, MIKEY is applicable for multimedia applications including IP telephony. [15] describes various use cases of the MIKEY key management protocols (MIKEY-PS, MIKEY-PK, MIKEY-DHSIGN and MIKEY-DHHMAC) with the purpose to establish TGK keying material among H.323 endpoints. The TGKs are then used for media encryption by applying SRTP [20]. Addressed scenarios include point-to-point with one or more intermediate gatekeepers (trusted or partially trusted) in between.
この付録では、MIKEY-DHHMACは、いくつかのH.323ベースのマルチメディア環境に適用する方法を有益な概要を説明します。一般的に、MIKEYは、IPテレフォニーなどのマルチメディア・アプリケーションに適用可能です。 [15] H.323エンドポイント間TGKキーイング材料を確立する目的で、MIKEY鍵管理プロトコル（MIKEY-PS、MIKEY-PK、MIKEY-DHSIGNとMIKEY-DHHMAC）の様々なユースケースが記載されています。 TGKsは次いでSRTP [20]を適用することによって、メディア暗号化のために使用されます。対処シナリオは、ポイントツーポイントの間における1つの以上の中間ゲートキーパー（トラステッドまたは部分的に信頼された）とを含みます。
One particular use case addresses MIKEY-DHHMAC to establish a media connection from an endpoint B calling (through a gatekeeper) to another endpoint A that is located within that same gatekeeper zone. While EP-A and EP-B typically do not share any auth_key a priori, some separate protocol exchange means are achieved outside the actual call setup procedure to establish an auth_key for the time while endpoints are being registered with the gatekeeper; such protocols exist [15] but are not shown in this document. The auth_key between the endpoints is being used to authenticate and integrity protect the MIKEY-DHHMAC messages.
一つの特定のユースケースは、同じゲートキーパーゾーン内に位置する別のエンドポイントAへ（ゲートキーパーを介して）エンドポイントBの呼び出しからのメディア接続を確立するために、MIKEY-DHHMACに対処します。 EP-AおよびEP-Bは、典型的には、任意AUTH_KEY先験的を共有していないが、いくつかの別個のプロトコル交換手段は、エンドポイントがゲートキーパに登録されている間に時間AUTH_KEYを確立するために、実際の呼設定手順の外に達成されます。そのようなプロトコルは、[15]存在するが、この文書に示されていません。エンドポイント間のAUTH_KEYは、認証と完全性MIKEY-DHHMACメッセージを保護するために使用されています。
To establish a call, it is assumed that endpoint B has obtained permission from the gatekeeper (not shown). Endpoint B as the caller builds the MIKEY-DHHMAC I_message (see section 3) and sends the I_message encapsulated within the H.323-SETUP to endpoint A. A routing gatekeeper (GK) would forward this message to endpoint B; in case of a non-routing gatekeeper, endpoint B sends the SETUP directly to endpoint A. In either case, H.323 inherent security mechanisms [21] are applied to protect the (encapsulation) message during transfer. This is not depicted here. The receiving endpoint A is able to verify the conveyed I_message and can compute a TGK. Assuming that endpoint A would accept the call, EP-A then builds the MIKEY-DHHMAC R_message and sends the response as part of the CallProceeding-to-Connect message back to the calling endpoint B (possibly through a routing gatekeeper). Endpoint B processes the conveyed R_message to compute the same TGK as the called endpoint A.
コールを確立するために、エンドポイントBは、ゲートキーパー（図示せず）からの許可を得ているものとします。エンドポイントBの発信者は、MIKEY-DHHMAC I_messageを構築し（セクション3を参照）、エンドポイントA.ルーティングゲートキーパー（GK）にH.323-SETUP内に封入I_messageはBをエンドポイントには、このメッセージを転送することになる送信するように、非ルーティング・ゲートキーパーの場合には、エンドポイントBは、いずれの場合においても、エンドポイントAに直接SETUPを送信し、H.323固有のセキュリティメカニズム[21]の転送中に（封入）メッセージを保護するために適用されます。これは、ここに描かれていません。受信エンドポイントAは、搬送I_messageを確認することができ、TGKを計算することができます。そのエンドポイントAと仮定すると、コールを受け入れる、EP-次いでMIKEY-DHHMAC R_messageを構築し、（おそらくルーティングゲートキーパーを介して）コールバックエンドポイントBへCallProceedingツー接続メッセージの一部として応答を送信します。端点Bと呼ばれるエンドポイントAと同じTGKを計算する搬送R_messageを処理します
1.) EP-B -> (GK) -> EP-A: SETUP(I_fwd_message [, I_rev_message]) 2.) EP-A -> (GK) -> EP-B: CallProceeding-to-CONNECT(R_fwd_message [, R_rev_message])
1）EP-B - >（GK） - > EP-A：SETUP（I_fwd_message【、I_rev_message]）2）EP-A - >（GK） - > EP-B：CallProceedingツーCONNECT（R_fwd_message [ 、R_rev_message]）
Notes: If it is necessary to establish directional TGKs for full-duplex links in both directions B->A and A->B, then the calling endpoint B instantiates the DHHMAC protocol twice: once in the direction B->A using I_fwd_message and another run in parallel in the direction A->B using I_rev_message. In that case, two MIKEY-DHHMAC I_messages are encapsulated within SETUP (I_fwd_message and I_rev_message) and two MIKEY-DHHMAC R_messages (R_fwd_message and R_rev_message) are encapsulated within CallProceeding-to-CONNECT. The I_rev_message corresponds with the I_fwd_message. Alternatively, the called endpoint A may instantiate the DHHMAC protocol in a separate run with endpoint B (not shown); however, this requires a third handshake to complete.
注：それは、両方向での全二重リンク用指向TGKsを確立するために必要であればB-> A及びA-> Bは、次いで、発呼側エンドポイントBはDHHMACプロトコルを二回インスタンス化：一旦方向B->使用I_fwd_messageおよびI_rev_messageを用い方向A-> Bに並列に別のラン。その場合、二つのMIKEY-DHHMAC I_messagesは、SETUP（I_fwd_messageとI_rev_message）と2つのMIKEY-DHHMAC R_messages（R_fwd_messageとR_rev_message）CallProceedingツーCONNECT内に封入されている内に封入されています。 I_rev_messageはI_fwd_messageに対応します。あるいは、被呼側エンドポイントAがエンドポイントB（図示せず）を有する別の実行でDHHMACプロトコルをインスタンス化することができます。しかし、これが完了するまでに第三のハンドシェイクが必要です。
For more details on how the MIKEY protocols may be deployed
with H.235, please refer to [15].
Author's Address
著者のアドレス
Martin Euchner Hofmannstr. 51 81359 Munich, Germany
マーティンEUCHNER Hofmannstr。 51 81359ミュンヘン、ドイツ
Phone: +49 89 722 55790 Fax: +49 89 722 62366 EMail: martin_euchner@hotmail.com
電話：+49 89 722 55790ファックス：+49 89 722 62366 Eメール：martin_euchner@hotmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、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 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 HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。