[要約] RFC 4650は、マルチメディアインターネットキーイング（MIKEY）のためのHMAC認証付きDiffie-Hellman鍵交換プロトコルを定義しています。この文書の目的は、リアルタイムマルチメディアセッションのための効率的かつ安全な鍵管理メカニズムを提供することにあります。MIKEYは、特にVoIP（Voice over IP）やビデオ会議などのリアルタイムアプリケーションでの使用を目的としています。このRFCは、MIKEYの基本プロトコルを拡張し、追加の認証と鍵交換オプションを提供することで、セキュリティと柔軟性を向上させます。関連するRFCには、RFC 3830（MIKEYの基本仕様）やRFC 4567（MIKEYとSRTPの統合に関するガイドライン）などがあります。
Network Working Group M. Euchner
Request for Comments: 4650 September 2006
Category: Standards Track
HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)
マルチメディアインターネットキーイング（Mikey）のHMAC-AuthenticatedDiffie-Hellman
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).
Copyright（c）The Internet Society（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で定義されているマルチメディアインターネットキーイング（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対Many、および小型のグループをカバーしています。特に、マイキーは、すべてが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
- RSAベースの（Rivest、Shamir、Adleman）プライベート/パブリックキーとデジタルを備えたパブリックキーインフラストラクチャを想定した、パブリックキー暗号化ベースのキーディストリビューションプロトコル（Mikey-PKおよびリバースモードMikey-RSA-R [33]）証明書
- 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.
これら3つの主要な管理プロトコルはすべて、1回の往復で作業を完了するように設計されています。これには、ゆるく同期したクロックに応じて、主要な管理プロトコル内にタイムスタンプを展開する必要があります。
However, it is known [6] that each of the three key management schemes has its subtle constraints and limitations:
ただし、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）は簡単に実装できます。ただし、相互に割り当てられた共有マスターシークレットが必要なため、ピアツーピア、シンプルな1対多、および小型（インタラクティブ）グループを超えた構成をサポートすることを目的としたものではありませんでした。
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]）の確認、証明書ポリシーの主張、認定パスの構築（[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.
- 3番目のMikey-DHSign Key Management Protocolは、Diffie-Hellman Key契約スキームを展開し、デジタル署名を使用して各方向のDiffie-Hellmanのハーフキーの交換を認証します。このアプローチには、パブリックキーインフラストラクチャの観点から前のセクションで説明されているのと同じ利点と欠陥があります。
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.
上記のように制限のいくつかを克服するために、Mikeyの別の効率的なキー契約プロトコルバリアントに対して特別なニーズが認識されています。このプロトコルバリアントは、パブリックキーインフラストラクチャに依存せずに低レイテンシとの重要な合意の一部として、完全な前方秘密の能力を提供することを目的としています。
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.
このドキュメントでは、マイキー向けの4番目の軽量のキー管理スキームについて説明します。これは、事前共有キーディストリビューションスキームとdiffie-hellmanキー契約との間の相乗的最適化と見なされることができます。
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).
このドキュメントのプロトコルのアイデアは、diffie-hellmanキー契約を適用することですが、交換されたキーイング素材の信頼性のためにデジタル署名を展開するのではなく、代わりに対称的に割り当てられた共有秘密にキー付きハッシュを使用します。セキュリティメカニズムのこの組み合わせは、Mikey（DHHMAC）のHMAC-Authedicated 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と一致しています。[2]セクション1.3-1.4を参照してください。
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.
事前共有キーは両方のエンティティ（イニシエーターとレスポンダー）で既知であると想定されています。認証キーAUTH_KEYは、擬似ランダム関数PRFを使用した事前共有秘密から派生しています。[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のゼロ以上の出現を示します。
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
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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-Authenticed 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.
他の3つのMikey Key Managementプロトコルの場合と同様に、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は、安全な時間同期測定を定義していません。ただし、[2]のセクション5.4および9.3は、時計の同期とタイムスタンプに関する実装ガイダンスを提供します。
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 Key Managementプロトコルは、アプリケーションレベルのキー管理を目的としており、リアルタイムセッションのセットアップとセッション管理の制約を備えたマルチメディアアプリケーション向けに最適化されています。
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]およびSDP。エンコードされたMikeyメッセージがカプセル化され、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.
b) H.323（[15]を参照）。エンコードされたMikeyメッセージは、H.225.0 Fast Start Call Signaling Handshakeで転送されます。付録Aは、H.235内のMikey-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 Key Managementバリアント（Mikey-Pre-Shared、Mikey-Public-Key、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）、受信機、および送信者です。Diffie-Hellman操作のペアごとの性質と1ラウンドトリップの制約により、Mikey-DHHMACの使用は、2つ以上のグループエンティティを持つグループキー管理プロトコルとしての展開を除外します。たとえば、レスポンダーがグループコントローラーとして機能する場合、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：HMAC-authenticated Diffie-Hellmanキーベースの交換。XiとXRは、それぞれイニシエーターとレスポンダーによってランダムに選択されます（擬似）。
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キー交換は、図1に従って行うものとします。イニシエーターは（擬似）ランダム値XIを選択し、g^（xi）とタイムスタンプを含むhmacedメッセージをレスポンダーに送信します。イニシエーターには、i_message内にIDIとIDRの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 Payload DHIまたはDHR内のDiffie-Hellman Group Gを明示的に送信します（たとえば、Oakley Group Numbering; [2]セクション6.4を参照）。ただし、実際のグループパラメーターGとPは明示的に送信されませんが、Diffie-HellmanグループGから推測できます。レスポンダーは（擬似）ランダムなポジティブ整数XRを選択し、G^（XR）を含むHMacedメッセージを送信します。イニシエーターへのタイムスタンプ。Responderには、i_messageがIDIを伝えたかどうかに関係なく、常にイニシエーターのIDIを含めるものとします。レスポンダーは、常にr_message内にIDペイロードIDRを含めることをお勧めします。イニシエーターが他の手段でレスポンダーのアイデンティティを延期できない限り、IDRはオプションで除外される場合があります。
Both parties then calculate the TGK as g^(xi * xr).
両当事者は、TGKをg^（xi * xr）として計算します。
The HMAC authentication provides authentication of the DH half-keys and is necessary to avoid man-in-the-middle attacks.
HMAC認証は、DHハーフキーの認証を提供し、中間の攻撃を避けるために必要です。
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.
このアプローチは、最初に1つの指数と1つのHMAC、次に1つのHMAC検証、そして最後に別のDiffie-Hellmanの指数を計算するという点で、デジタルで署名された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.
TGKの処理は、Mikey [2]セクション4に記載されているように達成されるものとします。
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.
DHHMACのために再キーリングするTGKは、[2]セクション4.5で説明されているように、一般に進行します。具体的には、図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再キーイングは2つの手順をサポートしています。
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.
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.
b) Diffie-Hellmanのハーフキーを交換に含めることなく、非キー関連情報の更新。このようなトランザクションは、実際の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のペイロード形式とデータ型値を指定します。マイキーペイロードの定義については、[2]セクション6も参照してください。
This document does not define new payload formats but re-uses MIKEY payloads for DHHMAC as referenced:
このドキュメントは、新しいペイロード形式を定義するものではありませんが、参照されているようにDHHMACのマイキーペイロードを再利用します。
* 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.
注：レスポンダーは、データ型フィールドを7または8として評価することにより、Mikey DHHMACプロトコルを認識できます。これが、ResponderがMikeyとMikey DHHMACを区別する方法です。
The next payload field SHALL be one of the following values:
次のペイロードフィールドは、次の値の1つでなければなりません。
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アルグは2（null）に設定され、ENCRデータレンは0に設定され、ENCRデータは空のままになります。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で説明されているようにauth_keyを使用してMacフィールドを除外し、Macフィールド内に保存され、MAKEYメッセージ全体で計算されます。
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の場合、このペイロードは、非認証ベースのIDのみを保持するものとします。
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 IDS |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.
このドキュメントは、全体を通して主要な管理セキュリティの問題に対処しています。マイキーセキュリティの考慮事項の包括的な説明については、マイキー[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プロトコルエンティティを実行するシステムは、diffie-hellman操作への入力として（pseudo）乱数を生成する能力を提供するものとします（[8]を参照）。さらに、システムは、生成された（擬似）ランダムデータ、秘密データ、キー、およびその他の秘密のセキュリティパラメーターを安全に保存できるものとします（つまり、不正な改ざんから機密および安全性）。
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.
この文書が順守する脅威モデルは、マイキーDHHMACを企業のクローズドIP環境に展開できる可能性を排除することなく、インターネットのエンドツーエンドのセキュリティの問題を一般的にカバーしています。これには、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).
* プレーンTGKの不正な傍受：DHHMACの場合、TGKは実際にはワイヤー上に送信されないため、この脅威は発生しません（暗号化された方法でも）。
* 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を明示的に送信しません。代わりに、秘密（擬似）ランダム値を隠すDiffie-Hellmanの「暗号化」操作を使用することにより、TGKの構築のための部分情報のみ（つまり、DHハーフキー）のみが送信されます。盗聴者へのこのような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.
* 中間の攻撃：そのような攻撃は、交換された、認識されていないメッセージのセキュリティを脅かします。中間の攻撃には通常、仮面舞踏会やメッセージの完全性の喪失が伴います（以下を参照）。中間の攻撃は避けられ、存在または試みられた場合は適切に検出する必要があります。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 General Extensionペイロード内にリストされるMikey General Extensionペイロードメカニズムを再利用することにより、この脅威に対処します。
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.
* 領収書またはメッセージの起源の非repudiation：これらは、この環境での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はそれらの攻撃のいずれかに対して完全な対策を提供すると主張していません。たとえば、エンティティの可用性を強調することは、主要な管理プロトコルによって阻止されません。他のいくつかのローカル対策を適用する必要があります。さらに、有効なDH要求の傍受やその大規模な即時複製など、一部のDOS攻撃は反論されません。このような攻撃は、少なくともこのドキュメントの範囲外のいくつかのローカルな手段によって部分的に反論される可能性があります。
* 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.
* アイデンティティ保護：マイキーと同様に、アイデンティティ保護は、マイキー-DHHMACの主要な設計要件でもありません。[2]を参照してください。これまでのところ、セクション5.3に記載されているようにDHHMACの目的を提供できるセキュリティプロトコルは、単一の往復内のID保護を含めます。Mikey-DHHMACは、キーイングマテリアルのセキュリティを改善し、往復時間を短縮するためにアイデンティティ保護を交換します。したがって、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を参照）は、ID情報を提供しないオプションを提供します。このオプションは、信頼できるアイデンティティ情報を提供するために他の手段が利用可能である場合にのみ適用されます。たとえば、信頼できるアイデンティティ情報を他の方法で提供するマイキーの下にあるセキュリティで保護されたリンクに依存することにより。ただし、ID情報がなければ、Mikey Key Managementセキュリティプロトコルは、特に保証されたアイデンティティ情報の他の安全な手段がないエンドツーエンドシナリオでは、仮面舞踏会、なりすまし、反射攻撃などのセキュリティの弱点の対象となる可能性があると理解されています。提供された。
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のハーフキーと関連するメッセージの認証とメッセージの整合性のために裏付けられています。認証は、輸送中の交換されたメッセージ、特に他の方法では認知されていない交換されたDiffie-Hellmanのハーフキーに対する中間の攻撃を避けるために絶対に必要です。
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のハーフキーが含まれていますが、交換されたメッセージの他の部分もカバーしています。相互のピアエンティティ認証とメッセージの整合性の両方が、中間の攻撃に対する効果的な対策を提供します。
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保護は、i_messageにイニシエーターのIDペイロードを含めることにより提供されます。これにより、受信者は、彼をターゲットにされていない（再生された）i_messageを除外し、不必要なマイキーセッションの作成を避けることができます。
* 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.
* Perfect-forward Secrecy（PFS）：Mikey Pre-SharedおよびPublic-Keyベースのキーディストリビューションプロトコルを除いて、Diffie-Hellman Key Ammartionプロトコルは、Perfect Forward Escrecyと呼ばれるセキュリティプロパティを備えています。つまり、長期的な事前に共有されたキーがある時点で妥協されたとしても、これは過去または将来のセッションキーを損なうものではありません。
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 Pre-SharedもMikey Public-Key Protocolバリアントも、完璧な秘密のセキュリティプロパティを提供することはできません。したがって、他のMikeyプロトコルはどれも、Diffie-Hellman 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-Public Key Protocolと同様に、Mikey DHHMACキー契約プロトコルは、わずか1つの往復内でTGKを安全に確立します。IPSEC-YIK [12]、IPSEC-kikev2 [14]、TLS [11]、およびその他のスキームなどの他の既存の主要な管理手法は、リアルタイムおよびセキュリティ要件に十分に対処するのに適切ではないと見なされません。それらはすべて、1回以上の丸いトリップを使用しています。すべてのMikey Key Managementプロトコルは、1つの往復で、キーアグリーメントやキーディストリビューションを含むセキュリティポリシーパラメーターネゴシエーションのタスクを完了することができます。ただし、Mikey Pre-SharedとMikey Public-Keyプロトコルは、確認メッセージが省略されている場合でも、ハーフラウンドトリップでもタスクを完了することができます。
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.
交渉されたdiffie-hellmanの共有秘密の長期的な秘密に非常に高いセキュリティレベルが望まれる場合、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はマイキーの事前共有キーディストリビューションプロトコルよりも多くのCPUサイクルを消費します。同じことが、Mikey Public-Key Distribution Protocol（プライベートおよび公開キーの長さの選択に応じて）に当てはまる可能性が非常に高い場合があります。そのため、DHHMACは、他のMikeyプロトコルバリアントと比較すると、音のパフォーマンスを提供すると言えます。
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.
オプションのID情報（セクション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 Public-Keyベースのキーディストリビューションプロトコルに必要なデジタル署名と関連するパブリックキーインフラストラクチャを完全に回避するHMAC-Authsected Diffie-Hellman Key契約プロトコルについて説明します。マイキーで説明されているように、デジタルで署名された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は、最終エンティティの保護されたID情報がIP/トランスポートアドレスではない限り、ファイアウォール/NATデバイスを介してスムーズに動作することができます。
* Scalability: Like the MIKEY signed Diffie-Hellman protocol, DHHMAC does not scale to any larger configurations beyond peer-to-peer groups.
* スケーラビリティ：Mikeyが署名したDiffie-Hellmanプロトコルのように、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.
* 恥ずかしさのキーは十分なエントロピーを持ち、効果的に推測することはできません。
* 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の仮定によると、Juffie-hellmanのハーフキーとDiffie-Hellmanグループの知識に関する知識があるとしても、TGKを計算するか、秘密のパラメーターXIまたはXRを導き出すことは不可能です。後者は、離散対数仮定とも呼ばれます。Diffie-Hellmanの問題とその計算の複雑さの仮定に関するより多くの背景情報については、[6]、[9]、または[10]を参照してください。
* 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のグループに適用できるだけでなく、一般的なセキュリティ手法です。これは、離散対数問題が一般的なグループでも非常に難しい問題であるという根本的な数学的仮定のためです。これにより、diffie-hellmanは、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ビット以上）、したがって非常に計算的に集中的になります。それにもかかわらず、楕円曲線Diffie-Hellman（ECDH）により、少なくともセキュリティレベルを維持し、実際にさらに重要なパフォーマンスの利点を提供しながら、キーの長さを大幅に削減できます（たとえば170ビット以上）。さらに、楕円形のカーブ技術は、射影座標に固有の冗長性により、サイドチャネル攻撃に対するより良い保護を提供すると考えられています。これらすべての理由により、楕円曲線ベースのdiffie-hellmanは、RSAよりも潜在的な脅威に対してより「将来の防止」であり、堅牢であると見なすことがあります。マイキーの楕円曲線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は、HMAC-Sha1を使用して、古典的なDiffie-Hellman Key Asmional Schemeと組み合わせて使用しています。HMAC-SHA1は、計算に秘密を含むキー付き一元配置ハッシュ関数です。DHHMACは、マイキーペイロードを保護するためにHMAC-SHA1を適用します。同様に、Mikey [2]内の擬似ランダム関数PRFは、HMAC-SHA1メカニズムを重要な導出関数として使用します。SHA1およびMD5に対して特定の攻撃が報告されていますが（[29]、[29]、[30]を参照）、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.
このドキュメントには、Steffen Fries、Hannes Tschofenig、Fredrick Lindholm、Mary Barnes、Russell 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用の独自の新しい名前スペースを定義するものではありません。[2]セクション10および10.1およびIana Mikeyのペイロード名スペース[37]を参照してください。
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:
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]
[2] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[2]
[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、「Secure Hash Standard」、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.、Lindholm、F.、Naslund、M.、Norrman、K。、およびE. Carrara、「セッション説明プロトコル（SDP）およびリアルタイムストリーミングプロトコル（RTSP）のキー管理拡張機能」、RFC 4567、7月2006年。
[5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[5] Krawczyk、H.、Bellare、M。、およびR. Canetti、「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.Menezes、P。VanOorschot、S。A。Vanstone：「適用された暗号化のハンドブック」、CRC Press 1996。
[7] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[7] Rescorla、E。and B. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[8] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[8] Eastlake 3rd、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性の推奨」、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. Maurer、S。Wolf：「The Diffie-Hellman Protocol」、デザイン、コード、および暗号化、特別号公開鍵暗号、Kluwer Academic Publishers、vol。19、pp。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] ディスクリート対数とdiffie-hellmanプロトコル、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[12] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[12] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[14] Kaufman、C。、「Internet Key Exchange（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 Key Management Protocolの使用";9/2005。
[16] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[16] Schaad、J。およびR. Housley、「Advanced Encryption Standard（AES）Key Lap Algorithm」、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.、Weis、B.、Hardjono、T。、およびH. Harney、「解釈のグループ領域」、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] Harney、H.、Meth、U.、Colegrove、A。、およびG. Gross、「GSAKMP：Group Secure Association Key Management Protocol」、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.、Canetti、R.、Dondeti、L。、およびF. Lindholm、「マルチキャストセキュリティ（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.、McGrew、D.、Naslund、M.、Carrara、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ベース）マルチメディアシステム」、（2005年9月）。
[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] Adams、C.、Farrell、S.、Kause、T。、およびT. Mononen、「Internet 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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S。、およびC. Adams、「X.509インターネット公開キーインフラオンライン証明書ステータスプロトコル」、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] Adams、C.、Sylvester、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.
[25] Schaad、J。、「インターネットX.509公開キーインフラストラクチャ証明書リクエストメッセージフォーマット（CRMF）」、RFC 4211、2005年9月。
[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] Cooper、M.、Dzambasow、Y.、Hesse、P.、Joseph、S。、およびR. Nicholas、「インターネットX.509公開キーインフラストラクチャ：認証パスビルディング」、RFC 4158、2005年9月。
[27] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[27] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[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] Hoffman、P。and B. Schneier、「インターネットプロトコルにおける暗号化に対する攻撃」、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] ベロビン、S.M。E.K.Rescorla：「新しいハッシュアルゴリズムの展開」、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] Milne、A.、Blaser、M.、Brown、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] Bellare、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. Lin、「Mikeyの重要な分布の追加モード：Mikey-RSA-R」、2006年8月、進行中の作業。
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.
この付録は、いくつかのH.323ベースのマルチメディア環境でMikey-DHHMACを適用する方法に有益な概要を提供します。一般的に、MikeyはIPテレフォニーを含むマルチメディアアプリケーションに適用できます。[15]は、Mikey Key Management Protocols（Mikey-PS、Mikey-PK、Mikey-Dhsign、Mikey-Dhhmac）のさまざまなユースケースを説明しています。TGKは、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.
特定のユースケースの1つは、mikey-dhhmacに扱い、エンドポイントB呼び出し（ゲートキーパー）から同じゲートキーパーゾーン内にある別のエンドポイントAへのメディア接続を確立します。EP-AとEP-Bは通常、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がゲートキーパーから許可を得ていると想定されています（図示せず）。発信者がMikey-DHHMAC I_Messageを構築し（セクション3を参照）、EndPoint BはH.323セットアップ内でカプセル化されたi_messageをエンドポイントAに送信します。非ルーティングゲートキーパーの場合、エンドポイントBはセットアップをエンドポイントAに直接送信します。どちらの場合も、h.323固有のセキュリティメカニズム[21]が適用され、転送中に（カプセル化）メッセージを保護します。これはここに描かれていません。受信エンドポイントAは、伝えられたi_messageを検証することができ、TGKを計算できます。エンドポイントAが呼び出しを受け入れると仮定すると、EP-Aはmikey-dhhmac r_messageを構築し、コールプロコントゥコネクトメッセージの一部として呼び出しエンドポイントBに戻ります（おそらくルーティングゲートキーパーを介して）。エンドポイントBは、伝達されたR_MESSAGEを処理して、呼び出されたエンドポイントAと同じTGKを計算します。
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])
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.
注：B-> aおよびA- b-> bの両方の方向にフルダプレックスリンクの方向TGKを確立する必要がある場合、呼び出しエンドポイントBはDHHMACプロトコルを2回インスタンス化します。I_REV_MESSAGEを使用してA-> bの方向に並行して別の実行。その場合、セットアップ（i_fwd_messageおよびi_rev_message）内で2つのmikey-dhhmac i_messagesがカプセル化され、2つのmikey-dhhmac r_messages（r_fwd_messageとr_rev_message）がコールプロッコネクト内でカプセル化されています。i_rev_messageはi_fwd_messageに対応します。あるいは、呼び出されたエンドポイントAは、エンドポイントBを使用して別の実行でDHHMACプロトコルをインスタンス化する場合があります（図示せず）。ただし、これには3番目の握手が必要です。
For more details on how the MIKEY protocols may be deployed with H.235, please refer to [15].
MikeyプロトコルをH.235で展開する方法の詳細については、[15]を参照してください。
Author's Address
著者の連絡先
Martin Euchner Hofmannstr. 51 81359 Munich, Germany
Martin Euchner Hofmannstr。51 81359ミュンヘン、ドイツ
Phone: +49 89 722 55790
Fax: +49 89 722 62366
EMail: martin_euchner@hotmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。