RFC4650 日本語訳
4650 HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing(MIKEY). M. Euchner. September 2006. (Format: TXT=63016 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Euchner Request for Comments: 4650 September 2006 Category: Standards Track
Euchnerがコメントのために要求するワーキンググループM.をネットワークでつないでください: 4650 2006年9月のカテゴリ: 標準化過程
HMAC-Authenticated Diffie-Hellman
for Multimedia Internet KEYing (MIKEY)
マルチメディアインターネットの合わせるHMACによって認証されたディフィー-ヘルマン(マイキー)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントは(マイキー)プロトコルマイキーを合わせるマルチメディアインターネットに軽量の二地点間かぎ管理プロトコル異形について説明します、RFC3830で定義されるように。 特に、この異形はメッセージが交換したかぎ管理の互いの認証とメッセージの保全を達成するための合わせられたハッシュメッセージ確認コードに関連して完全な前進の秘密保持を特徴とする主要な設立のために古典的なディフィー-ヘルマン主要な協定プロトコルを配布します。 このプロトコルは、セキュリティと性能がマイキーでのマルチメディアかぎ管理の規制であると扱います。
Euchner Standards Track [Page 1] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[1ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
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
1. 序論…2 1.1. 定義…5 1.2. 略語…6 1.3. このドキュメントで中古のコンベンション…7 2. シナリオ…7 2.1. 適用性…7 2.2. GKMARCHとの関係…8 3. DHHMACセキュリティは議定書を作ります…8 3.1. TGK再の合わせること…10 4. DHHMAC有効搭載量形式…10 4.1. 一般的なヘッダー有効搭載量(HDR)…11 4.2. 重要なデータは有効搭載量(KEMAC)を輸送します…12 4.3. ID有効搭載量(ID)…12 4.4. 一般拡大有効搭載量…12 5. セキュリティ問題…13 5.1. セキュリティ環境…13 5.2. 脅威モデル…13 5.3. セキュリティ機能と特性…15 5.4. 仮定…19 5.5. 残りのリスク…20 5.6. 承認と信頼はモデル化されます…21 6. 承認…21 7. IANA問題…22 8. 参照…22 8.1. 標準の参照…22 8.2. 有益な参照…22 H.235のマイキー-DHHMACの付録A.使用法…25
1. Introduction
1. 序論
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.
マイキーで指摘される、([2]) リアルタイムのマルチメディア応用要求がしっかりと、効率的にダイナミックなセッションキーを会話のマルチメディアシナリオに証明するために注意される特定の適切な軽量のかぎ管理体系であると機密保護するように確実にしてください。
In general, MIKEY scenarios cover peer-to-peer, simple one-to-many, and small-sized groups. MIKEY in particular describes three key
一般に、マイキーシナリオはピアツーピア、多くへの簡単なもの、および小さいサイズのグループを含んでいます。 マイキーは3キーについて特に説明します。
Euchner Standards Track [Page 2] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[2ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
management schemes for the peer-to-peer case that all finish their task within one roundtrip:
ピアツーピアケースの1つの往復旅行の中でそれらのタスクを終える管理体系すべて、:
- a symmetric key distribution protocol (MIKEY-PS) based on pre-
shared master keys
- あらかじめ共有されたマスターキーに基づく対称鍵分配プロトコル(マイキー-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、シャミル、およびAdleman)の兵卒/公開鍵とデジタル証明書がある公開鍵インフラストラクチャを仮定するマイキー-PKと逆モードマイキー-RSA-R[33])
- a Diffie-Hellman key agreement protocol (MIKEY-DHSIGN) deploying
digital signatures and certificates.
- デジタル署名と証明書を配布するディフィー-ヘルマンの主要な協定プロトコル(マイキー-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:
しかしながら、[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.
- 対称鍵分配プロトコル(マイキー-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.
- 公開鍵暗号化は計画されます。(マイキー-PKとマイキー-RSA-R[33])はデジタル証明書を発行して、維持することによって個人的な公開鍵を公認する公開鍵インフラストラクチャによります。 そのようなかぎ管理体系は大きいネットワークでつながれた構成に完全なスケーラビリティを提供しますが、公開鍵インフラストラクチャはまだ広く利用可能ではありません、そして、一般に、実装はかなり複雑です。
Euchner Standards Track [Page 3] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[3ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
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.
さらに、追加往復旅行とコンピュータの処理が、デジタル証明書の検証を確かめるのにそれぞれのエンドシステムに必要であるかもしれません。 例えば、公開鍵インフラストラクチャの文脈における典型的な操作は、付加的なネットワークコミュニケーション握手に公開鍵インフラストラクチャと証明当局にかかわって、追加処理ステップにエンドシステムに通常かかわるかもしれません; これらの操作は、デジタル証明書(RFC3029、24)を有効にするのを含んでいるでしょう、デジタル証明書(RFC2560、23)の取消し状態を確かめて、証明書方針を断言して、証明経路(26)の工事、必要な証明書(RFC2511、25)、およびそのような目的(22)のための証明書の管理を要求して、入手して。 そのようなステップとタスクはすべて、主要な協定のさらなる遅れかエンドシステムの中の主要な確立段階をもたらします。(否定的に、それは、準備時間に影響します)。 少しの付加的なPKI握手と処理もマイキーの範囲にありません、そして、このドキュメントが左右対称のセキュリティー対策を配布するだけであるので、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番目のマイキー-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.
しかしながら、完全な完全な前進の秘密保持(PFS)を提供して、さらに活発にセッションキー生成にかかわる双方に提供できて、ディフィー-ヘルマンの主要な協定プロトコルは微妙なセキュリティの強さで知られています。 この特別担保の特性(いくらか高いコンピュータのコストにもかかわらず)で、ディフィー-ヘルマンのテクニックは実際には魅力的になります。
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.
上に概説されているように限界のいくつかを克服するために、特別な必要性はマイキーの別の効率的な主要な協定プロトコル異形として認識されました。 このプロトコル異形は、低遅延との主要な協定の一部として公開鍵インフラストラクチャで依存なしで完全な前進の秘密保持の能力を提供することを目指します。
Euchner Standards Track [Page 4] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[4ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
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番目の軽量のかぎ管理体系について説明します。
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).
このドキュメントのプロトコルの考えがむしろ材料を合わせながら交換の信憑性のためのデジタル署名を配布するよりディフィーヘルマンキー協定を適用することであり、それは対称的にあらかじめ割り当てられた共有秘密キーに代わりに合わせられたハッシュを使用します。 セキュリティー対策のこの組み合わせはマイキー(DHHMAC)のためにHMACによって認証されたディフィー-ヘルマン(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異形は、密接にマイキーのデザインと哲学に従って、利益と最も良い互換性のためにマイキープロトコルペイロード成分とマイキーメカニズムを最大限に再利用します。
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.
マイキーディフィー-ヘルマンプロトコルのように、DHHMACは二地点間星座を超えて比例しません。 したがって、両方のマイキーディフィー-ヘルマンプロトコルは2つの実体より大きいどんなグループサイズのためのもサポートグループベースの合わせないことをします。
1.1. Definitions
1.1. 定義
The definitions and notations in this document are aligned with MIKEY; see [2] sections 1.3 - 1.4.
定義と記法は本書ではマイキーに並べられます。 [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の間、モッズpであるとして何らかの固定グループGの中で本書では理解されるべきです。 [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が両方の実体(創始者と応答者)によって知られていると思われます。 プレ共有秘密キーsから擬似ランダム機能PRFを使用することで認証の主要なauth_キーを得ます。 [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 SHOULD中で、ある事情がXが任意であり、存在していないのを許容しないかもしれないなら存在している、その結果、潜在的に結果として起こるコネ、 より弱いセキュリティ。 同様に、[X、Y]は断片のXとSHOULDのY両方が存在しているか、または任意にともに欠けるかもしれない任意の合成情報を表します。 XはXのゼロか、より多くの発生を指示します。
Euchner Standards Track [Page 5] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[5ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
1.2. Abbreviations
1.2. 略語
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
主要で、PRFによってあらかじめ共有されたキーsから派生させられたauth_キーPreによって共有された認証。 受信機IKEインターネットKey Exchangeの創始者IDr Identityのハッシュ関数(160ビットの結果)IDi IdentityとしてSHA1を使用するResponder DHHMAC HMACによって認証されたディフィー-ヘルマンサービスのDoS Denial Gディフィー-ヘルマングループHDR MIKEYの一般的なヘッダーペイロードHMAC Keyed Hashメッセージ立証コードHMAC-SHA1 HMACのInitiator DHr Publicディフィー-ヘルマン半分の主要なg^(xr)のDHディフィー-ヘルマンDHi Publicディフィー-ヘルマン半分の主要なg^(ξ); HMAC MIKEY-DHSIGN MIKEYのディフィー-ヘルマンの主要な協定プロトコルマイキー-PK MIKEYの公開鍵の暗号化ベースの主要な分配プロトコルマイキー-PS MIKEYを使用するIPsecインターネット・プロトコル・セキュリティーマイキーMultimediaインターネットKEYingマイキー-DHHMAC MIKEYディフィー-ヘルマンキー管理プロトコルが主要な分配プロトコルp主要なディフィー-ヘルマンの係数PKI Public主要なInfrastructure PRFマイキー擬似ランダム機能(2部4.1の.3を見る)RSA Rivestをあらかじめ共有しました; シャミル、およびIKEのAdleman s Preによって共有された主要なSDP Session記述プロトコルSOI Son、IKEv2 SPマイキーSecurity Policy(パラメタ)Payload T Timestamp TEK Traffic Encryption Key TGKマイキーTEK Generation Key、一般的なディフィーとして、ヘルマンは秘密のTLS Transport Layer SecurityξSecretを共有しました、Initiator xr Secretの(疑似な)無作為のディフィー-ヘルマンキー、Responderの(疑似な)無作為のディフィー-ヘルマンキー
Euchner Standards Track [Page 6] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[6ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
1.3. Conventions Used in This Document
1.3. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
2. Scenario
2. シナリオ
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.
もう片方の3かぎ管理がマイキーアドレスで計画されるとき、HMACによって認証されたディフィー-ヘルマンマイキーにとって、主要な協定プロトコル(DHHMAC)は同じシナリオと範囲を扱います。
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.
DHHMACは、そのままで、他の3つのマイキーかぎ管理プロトコルのためのこの件が実体の中で小さいグループで時計を少なくとも、緩く連動させたと仮定します。
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.
安全な方法で時計を連動させるように、いくつかの操作上の、または、手続き上の手段がお勧めです。 マイキー-DHHMACはどんな安全な時間同期化測定も定義しません。 しかしながら、[2]のセクション5.4と9.3は時計同期とタイムスタンプで実施要項を提供します。
2.1. Applicability
2.1. 適用性
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.
マイキー-DHHMACと他のマイキーかぎ管理プロトコルは、アプリケーションレベルかぎ管理のために意図して、マルチメディア応用のためにリアルタイムのセッションセットアップとセッション管理規制で最適化されます。
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
マイキー-DHHMACかぎ管理プロトコルが、ある往復旅行で終わるとき、両用握手セッションへの統合に、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、コード化されたマイキーメッセージがSDP申し出/答えのSDPコンテナでカプセル化されて、輸送されるところでRFC3264[27])握手を見てください、[4]で説明されるように。 そして
Euchner Standards Track [Page 7] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[7ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
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])を見てください。そこでは、コード化されたマイキーメッセージがH.225.0の速いスタート呼び出しシグナリング握手で輸送されます。 付録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).
DHHMACが特定の強さを持っている(セクション5を見てください)それらのすべてのケースのためにオプションとして他のマイキーかぎ管理異形(マイキー-公開鍵とマイキーDH-SIGN、マイキーはあらかじめ共有した)にマイキー-DHHMACを提供します。
2.2. Relation to GKMARCH
2.2. GKMARCHとの関係
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.
Groupかぎ管理アーキテクチャ(GKMARCH)[19]はマルチキャストセキュリティグループかぎ管理プロトコルのためにジェネリックアーキテクチャについて説明します。 このアーキテクチャの文脈では、マイキー-DHHMACは登録プロトコルとして作動するかもしれません。 また、[2] セクション2.4を見てください。 アーキテクチャにかかわる主な実体は、グループコントローラ/主要なサーバ(GCKS)と、受信機と、送付者です。 ディフィー-ヘルマンの操作と1往復の規制の組の賢明な本質のため、グループ重要管理が2つ以上のグループ実体で議定書を作るとき、マイキー-DHHMACの使用法はどんな展開も除外します。 例えば、応答者がグループコントローラとして務めるところで2人の同輩がいる堕落したケースだけが可能です。
Note that MIKEY does not provide re-keying in the GKMARCH sense, only updating of the keys by normal unicast messages.
マイキーが正常なユニキャストメッセージでGKMARCH意味における再の合わせるキーのアップデートだけを提供しないことに注意してください。
3. DHHMAC Security Protocol
3. DHHMACセキュリティプロトコル
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
<----------------------
I_メッセージ=HDR、T、底ならし革、[IDi]、IDr、SP、DHi、KEMAC----------------------->R_メッセージ=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: 創始者と応答者によって手当たりしだいにそれぞれ選ばれた状態でξとxrが(疑似)であるところでのHMACによって認証されたディフィー-ヘルマンのキーベースの交換。
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
DHHMACキーはSHALLを交換します。図1によると、します。 創始者は、(疑似な)無作為の値、ξを選んで、g^を含むHMACedメッセージ(ξ)とタイムスタンプを応答者に送ります。 創始者SHOULDがいつもアイデンティティを含んでいるのは、お勧めです。
Euchner Standards Track [Page 8] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[8ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
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.
I_の中のペイロードのIDiとIDrは通信します。 受信機がある他の手段で創始者のアイデンティティを延期できないなら、IDiは任意に省略されるかもしれません。 創始者SHALLはいつも受取人のアイデンティティを含んでいます。
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)は創始者によって選ばれた1セットのパラメタです。 マイキープロトコルでは、送付者と受信機の両方がディフィー-ヘルマンペイロードのDHiかDHrの中で明らかにコード化でディフィー-ヘルマングループGを伝えるように(例えば、オークリーのグループ付番; [2] セクション6.4を見てください)それに注意してください。 実際のグループパラメタgとpは、しかしながら、明らかに伝えられませんが、応答者が(疑似な)無作為の正の整数に選ぶディフィー-ヘルマングループG.、xrから推論できて、g^を含むHMACedメッセージ(xr)とタイムスタンプを創始者に送ります。 I_メッセージがどんなIDiも運んだかどうかにかかわらず応答者SHALLはいつも創始者のアイデンティティIDiを含んでいます。 応答者SHOULDがR_メッセージの中にいつもアイデンティティペイロードIDrを含んでいるのは、RECOMMENDEDです。 創始者がある他の手段で応答者のアイデンティティを延期できないなら、IDrは任意に置かれるかもしれません。
Both parties then calculate the TGK as g^(xi * xr).
そして、双方はg^としてTGKについて計算します(ξ*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、次に、1つのHMAC検証、および最終的に別のディフィー-ヘルマン羃法を計算するのでディフィー-ヘルマンであるとデジタルに署名されるほどこのアプローチは高価ではありません。
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.
オフラインプレ計算によると、初期のディフィー-ヘルマン半分キーは、かぎ管理トランザクションの前に計算されて、その結果、総合的な往復の遅れをさらに減少させるかもしれません、サービス不能攻撃のリスクと同様に。
Processing of the TGK SHALL be accomplished as described in MIKEY [2] section 4.
処理して、TGK SHALLでは、マイキー[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が船倉をさばくKEMACペイロード分野であったなら結果になるという計算されたHMAC結果SHALL。 HMAC SHALLが全体のメッセージに関して計算されて、MACを除いて使用auth_キーをさばいてください。 また、セクション4.2を見てください。
Euchner Standards Track [Page 9] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[9ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
3.1. TGK Re-keying
3.1. TGK再の合わせること
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のための[2] セクション4.5で説明されるようなTGK再の合わせかけること。 明確に、図2はDHHMACアップデートメッセージに交換処理を提供します。
Initiator Responder
創始者応答者
I_message = HDR, T, [IDi], IDr,
{SP}, [DHi], KEMAC
-----------------------> R_message = HDR, T,
[IDr], IDi,
[DHr, DHi], KEMAC
<----------------------
KEMAC、I_は=HDR、T、[IDi]、IDr、SP[DHi]を通信させます。----------------------->R_メッセージは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) 新しくて新鮮なディフィー-ヘルマン半分キーを交換することによって本当の再の合わせること。 これのために、創始者SHALLは新しくて、新鮮なDHiを提供します、そして、応答者SHALLは新しくて、新鮮な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) 交換にどんなディフィーヘルマン半分キーも含んでいなくて、非キーは情報最新版を関係づけました。 どんな変化にも実際のTGKをしませんが、そのようなトランザクションは安全保障政策パラメタなどのように他の情報をアップデートにします。 非主要な関連情報だけ、[DHi]、および[DHr、DHi]SHALLをアップデートするには、省かれてください。
4. DHHMAC Payload Formats
4. DHHMAC有効搭載量形式
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を見てください。
Euchner Standards Track [Page 10] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[10ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
* 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.
* セキュリティPolicyペイロード(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を見てください。
4.1. Common Header Payload (HDR)
4.1. 一般的なヘッダー有効搭載量(HDR)
Referring to [2] section 6.1, the following data types SHALL be used for DHHMAC:
[2]について言及すると、6.1、以下のデータ型SHALLは区分されます。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
データ型| 値| コメント------------------------------------------------------------- DHHMACイニット| 7 | 創始者のDHHMAC交換メッセージDHHMAC resp| 8 | 応答者のDHHMAC交換メッセージError| 6 | エラーメッセージ。 [2] セクション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プロトコルを認識できます。 これは応答者がどうマイキーとMIKEY DHHMACを区別できるかということです。
The next payload field SHALL be one of the following values:
次のペイロード分野SHALLに、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
次のペイロード| 値| セクション---------------------------------------------------------------- 最後のペイロード| 0 | - KEMAC| 1 | セクション4.2と[2]セクション6.2 DH| 3 | [2] セクション6.4T| 5 | [2] セクション6.6ID| 6 | [2] セクション6.7SP| 10 | [2] セクション6.10RAND| 11 | [2] セクション6.11ERR| 12 | [2]セクション6.12の司令官のExt| 21| [2] セクション6.15
Table 4.1.b
テーブル4.1.b
Other defined next payload values defined in [2] SHALL not be applied to DHHMAC.
もう一方は適用されていなくて、[2] SHALLでDHHMACと定義された次のペイロード値を定義しました。
Euchner Standards Track [Page 11] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[11ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
In case of a decoding error or of a failed HMAC authentication verification, the responder SHALL apply the Error payload data type.
解読誤りの場合には失敗したHMAC認証検証では、応答者SHALLはErrorペイロードデータ型を適用します。
4.2. Key Data Transport Payload (KEMAC)
4.2. 重要なデータ輸送有効搭載量(KEMAC)
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 SHALLは、示された認証アルゴリズムに伴うHMAC結果を伝えるためにこのペイロードを適用します。 DHHMACに関連して使用される場合、KEMAC SHALLは少しの暗号化されたデータも伝えません。 その結果、Encr alg SHALL、2(NULL)へのセットになってください、Encrデータlen SHALL、左が空であったなら、0、およびEncrデータSHALLにはセットがありますか? AESキーはメソッドを包装します。([16]) SHALLが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のために、この重要なデータ輸送ペイロードSHALLに、メッセージにおける最後のペイロードはそうですか? Nextペイロード分野SHALLがLastペイロードに用意ができていることに注意してください。 次に、HMACは全体のマイキーメッセージに関して計算されます、MAC分野の中の[2] セクション5.2で説明されて、次に、保存されているとして主要なauth_を使用することでMAC分野を除いて。
MAC alg | Value | Comments
------------------------------------------------------------------
HMAC-SHA-1 | 0 | Mandatory, Default (see [3])
NULL | 1 | Very restricted use; see
| [2] section 4.2.4
MAC alg| 値| コメント------------------------------------------------------------------ HMAC-SHA-1| 0 | 義務的であることで、デフォルトとしてください、([3])がヌルであることを見てください。| 1 | 非常に制限された使用。 見てください。| [2] セクション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ビットです。
4.3. ID Payload (ID)
4.3. ID有効搭載量(ID)
For DHHMAC, this payload SHALL only hold a non-certificate-based identity.
DHHMACに関しては、このペイロードSHALLは非証明書ベースのアイデンティティを保持するだけです。
4.4. General Extension Payload
4.4. 一般拡大有効搭載量
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に関しては、下に入札攻撃を避けるために、このペイロードSHALLは周囲のカプセル化プロトコルに関するすべてのかぎ管理プロトコル識別子をリストアップします、SDP[4]などのように。 司令官のExtension有効搭載量SHALL、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
Euchner Standards Track [Page 12] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[12ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
5. Security Considerations
5. セキュリティ問題
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]によると、このドキュメントは、セキュリティが問題であると扱います:(そこでは、以下のセキュリティ問題がこのドキュメントに特に適用されます)。
5.1. Security Environment
5.1. 治安環境
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プロトコル実体SHALLを実行するシステムはディフィー-ヘルマンの操作に入力されるように乱数を生成する(疑似な)能力を提供します。([8])を見てください。 その上、システムSHALL、しっかりと発生している(疑似な)無作為のデータ、機密データ、キー、および他の秘密のセキュリティパラメタを保存できてください(権限のない改ざんからすなわち、秘密の、そして、安全な)。
5.2. Threat Model
5.2. 脅威モデル
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.
一般に、脅威モデル(このドキュメントは付着する)はインターネットにおける終わりから終わりへのセキュリティの問題をカバーしています、法人の、そして、閉じているIP環境でMIKEY DHHMACを配布することができる可能性を除外しないで。 また、これはいくつかの中間的信じられた「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の権限のない妨害: 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
* 他の、そして、伝えられた合わせる情報の盗聴: DHHMACプロトコルは明らかに全くTGKを伝えません。 代わりに、ディフィー-ヘルマン「暗号化」操作を使用することによって、TGKの構造のための部分的な情報(すなわち、DH半分キー)だけが伝えられます。(操作は秘密(疑似な)の無作為の値を隠します)。 それはそのようなディフィー-ヘルマンのその有用性であると基本的に思われます。
Euchner Standards Track [Page 13] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[13ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
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.
立ち聞きする者の半分キーは少しのかなりのセキュリティリスクももたらしません。 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はマイキーの中に記載されているすべてのかぎ管理プロトコル識別子がことであるマイキーGeneralのExtension有効搭載量メカニズムを再利用するのによるこの脅威に一般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.
* ディフィー-ヘルマンアルゴリズムの受け身の、そして、オフラインの暗号文解読術: ある妥当な想定(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の文脈の中の要件ではありません、そして、このようにして関係づけられた対策は全く提供されません。
Euchner Standards Track [Page 14] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[14ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
* 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.
* アイデンティティ保護: マイキーのように、アイデンティティ保護はマイキー-DHHMACに、主要な設計の品質ではありません。 [2]を見てください。 セクション5.3の述べられるとしてのDHHMACの目的を提供できるどんなセキュリティプロトコルも今までのところ知られていません、まさしくただ一つの往復旅行の中にアイデンティティ保護を含んでいて。 マイキー-DHHMACは合わせることの材料と、より短い往復の間の、より良いセキュリティのためのアイデンティティ保護を交えます。 したがって、マイキー-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を見る)は、アイデンティティ情報を提供しないようにオプションを提供します。 ある他の手段が信頼できるアイデンティティ情報を提供するために利用可能である場合にだけ、このオプションは適切です。 例えば、マイキーの下の信頼できるアイデンティティ情報をある他の道に提供する機密保護しているリンクを当てにすることによって。 しかしながら、アイデンティティ情報がなければ、マイキーかぎ管理セキュリティプロトコルは仮面舞踏会や、ものまねや、反射攻撃などのセキュリティ弱点を受けることがあるかもしれないのが理解されています、特に終わりから終わりへの確実なアイデンティティ情報の他のどんな安全な手段も提供されないシナリオで。
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.
その結果、任意の状態で(そうするのが可能であるなら)アイデンティティ野原を出るのをプライバシーメソッドと考えるべきではありません、どちらか、しかし、むしろプロトコル最適化機能として。
5.3. Security Features and Properties
5.3. セキュリティ機能と特性
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の設立との主要な協定を保証してください: これは、認証されたディフィー-ヘルマンかぎ管理プロトコルを使用することで達成されます。
Euchner Standards Track [Page 15] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[15ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
* 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計算は交換の認証とメッセージの保全のためにディフィー-ヘルマン半分キーと関連メッセージを確証します。 認証が、トランジットにおける交換されたメッセージの上と、そして、特にそうでなければ、非認証された交換されたディフィー-ヘルマン半分キーの上に介入者攻撃を避けるのに絶対に必要です。
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)を使用することで達成されます。 それは、交換されたディフィー-ヘルマン半分キーを含んでいますが、また、交換されたメッセージの他の部分をカバーしています。 互いの同輩実体認証とメッセージの保全の両方が介入者攻撃に対して効果的な対策を提供します。
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
* 株式会社DoS保護: メッセージダイジェストの急速な照合で、CPUの徹底的なディフィー-ヘルマン計画に着手し始めるか、または他のリソースがタスクを消費し始める前に、メッセージの信憑性と保全について確かめます。 これが何らかの否定から守る、-、サービス攻撃について: メッセージとスパムの悪意がある変更は(再演するか、または仮装します)メッセージで攻撃されます。 DHHMACはたぶん明らかにシステム稼働率に感染する洗練された分配されて、大規模なサービス不能攻撃に対抗しません。
Euchner Standards Track [Page 16] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[16ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
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.
例。 I_メッセージでの創始者のアイデンティティペイロードの包含で何らかのDoS保護を提供します。 これで、受取人をそれら(再演される)から彼のために狙わないI_メッセージをフィルターにかけて、不要なマイキーセッションを作成するのを避けます。
* 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)を-前方に完成させてください: あらかじめ共有されて公開鍵ベースの主要なマイキー分配プロトコルを除いて、ディフィー-ヘルマンの主要な協定プロトコルは完全な前進の秘密保持と呼ばれるセキュリティの特性を特徴とします。 すなわち、長期のあらかじめ共有されたキーが時間内に何らかのポイントで感染されても、これは過去の、または、将来のセッションキーに感染しません。
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.
あらかじめ共有されたマイキーもマイキー公開鍵プロトコル異形も前方で完全な秘密保持のセキュリティ資産を提供できません。 したがって、他のマイキープロトコルのいずれもディフィー-ヘルマン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.
* 公正で、互いの主要な貢献: ディフィー-ヘルマンかぎ管理プロトコルは厳しい主要な分配がそういうものとして創始者が分配するコネについてa主要な状態で同輩に議定書の中で述べるということではありません。 実際に、プロトコル交換にかかわる双方は等しくキーを生成する一般的なディフィー-ヘルマン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.
安全になるディフィー-ヘルマンの主要な協定のために、各当事者SHALLは、そのξかxrが値であると本当の偶発性の源が利用可能でないなら強くて、予測できない疑似無作為のジェネレータを使用することで生成します。 さらに、これらはξかxr SHALLを評価します。個人的に保たれます。 一般的なディフィー-ヘルマン共有された秘密鍵がいったん設立されるとこれらの秘密の値が破壊されるのは、RECOMMENDEDです。
* 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
* 効率と性能: マイキー-公開鍵プロトコルのように、MIKEY DHHMACの主要な協定プロトコルはちょうど1つの往復旅行の中にしっかりとTGKを設立します。 IPsec-IKE[12]などの他の既存のかぎ管理のテクニック(IPsec-IKEv2[14]、TLS[11]、および他の体系)は、それらがリアルタイムとセキュリティ要件であると十分扱うのにおいて適切であると考えられません。 彼らは皆、ただ一つの往復旅行より以上を使用します。 すべてのマイキーかぎ管理プロトコルがそれらの安全保障政策パラメタに関するタスクを完成できます。
Euchner Standards Track [Page 17] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[17ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
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.
主要な協定か1つの往復旅行における主要な分配を含む交渉。 しかしながら、マイキーはあらかじめ共有しました、そして、確認メッセージが省略されるとき、マイキー公開鍵プロトコルはともに半分往復旅行さえにおけるそれらのタスクを完成できます。
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が提供します、ことによるとより強いディフィー-ヘルマングループに関連して。 これはさらなる研究のように残されます。
For the sake of improved performance and reduced roundtrip delay,
either party may pre-compute its public Diffie-Hellman half-key
off-line.
向上した性能と減少している往復の遅れのために、何れの当事者は公共のディフィー-ヘルマン半分主要なオフ系列をあらかじめ計算するかもしれません。
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サイクルを費やします。 同じくらいはマイキー公開鍵分配プロトコルにかなりありそうな状態で有効であるかもしれません(個人的、そして、公開鍵長さの選択によって)。 そのようなものとして、他のマイキープロトコル異形と比べると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で述べられている)と任意のディフィー-ヘルマン半分キーフィールドの使用は性能を増強して、消費されたネットワーク回線容量を短くする手段を提供します。
* 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の認証されたディフィー-ヘルマン主要な協定プロトコルについて説明します。(あって、それは、デジタル署名と関連公開鍵インフラストラクチャを完全に避けます)。 公開鍵インフラストラクチャはある環境でいつも利用可能であるかもしれないというわけではありません、そして、アカウントへの追加往復旅行で証明書合法化と証明書取消しメソッドに追加方法を取る場合、リアルタイムのマルチメディア応用に適切であるとそれらを考えませんように。
Euchner Standards Track [Page 18] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[18ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
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.
* スケーラビリティ: マイキーがディフィー-ヘルマンプロトコルに調印したように、DHHMACはピアツーピアグループを超えたどんなより大きい構成にも比例しません。
5.4. Assumptions
5.4. 仮定
This document states a couple of assumptions upon which the security of DHHMAC significantly depends. The following conditions are assumed:
このドキュメントはDHHMACのセキュリティがかなりよる2、3の仮定を述べます。 以下の条件は想定されます:
* The parameters xi, xr, s, and auth_key are to be kept secret.
* パラメタξ、xr、s、およびauth_キーは秘密にされることになっています。
* 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.
* 十分大きくて安全なディフィー-ヘルマングループは適用されています。
* 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.
* 交換されたディフィー-ヘルマン半分キーに関する知識とディフィー-ヘルマングループに関する知識でさえ、TGKを計算するか、または秘密のパラメタξかxrを引き出すのが実行不可能であると基本的に言いながら、ディフィー-ヘルマンの仮定は成立します。 また、後者は離散対数仮定と呼ばれます。 ディフィー-ヘルマン問題とその計算量仮定に関する、より多くの基礎的な情報のための[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_キーを漏らしません。 特に、セキュリティは、それがいつ単滑車に適用されるかにハッシュ関数Hの圧縮関数の通報認証所有地によります。([5])を見てください。
Euchner Standards Track [Page 19] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[19ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
* A source capable of producing sufficiently many bits of (pseudo)
randomness is available.
* (疑似な)偶発性の十分多くのビットを作り出すことができるソースは手があいています。
* The system upon which DHHMAC runs is sufficiently secure.
* DHHMACが稼働するシステムは十分安全です。
5.5. Residual Risk
5.5. 残存危険性
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の特性の数学の、そして、暗号の仮定、ディフィー-ヘルマンアルゴリズム(離散的なログ仮定)、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).
ディフィー-ヘルマンメカニズムは主要なオーダーか独特の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ビットとその他)でその結果、非常に計算上徹底的になる傾向があります。 それにもかかわらず、Elliptic Curveディフィー-ヘルマン(ECDH)は、少なくともセキュリティー・レベルを維持して、さらに重要な性能利益を習慣に提供している間、キー長が実質的(170ビット以上言う)に削られるのを許します。 そのうえ、楕円曲線のテクニックが固有の冗長によるサイドチャンネル攻撃に対するはるかに良い保護を射影の座標に提供すると信じられています。 これらのすべての理由で、RSAより潜在的な脅威に対して「未来の耐」で強健であるとして楕円形のカーブベースのディフィー・ヘルマンを見なすかもしれません。 マイキーのElliptic Curveディフィー-ヘルマン異形が[31]で定義されることに注意してください。
Euchner Standards Track [Page 20] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[20ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
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を使用します。 HMAC-SHA1は秘密に計算にかかわる合わせられた一方向ハッシュ関数です。 DHHMACはマイキーペイロードの保護のためにHMAC-SHA1を適用します。 同様に、マイキー[2]の中の擬似ランダム機能PRFは主要な派生機能としてHMAC-SHA1メカニズムを使用します。 [29])を見てください、現在の知識で。ある攻撃がSHA1とMD5に対して報告された、(([29] [30]) 攻撃が全くHMAC-SHA1セキュリティー対策に対して報告されていないのを確実にしてください。 事実上、[32]は、(SHA1)ハッシュ関数が擬似ランダム機能であると唯一仮定しながらHMACには擬似ランダム機能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を配布することが勧められません。 どんな誤用も未知の、そして、未定義の特性につながるかもしれません。
5.6. Authorization and Trust Model
5.6. 承認と信頼はモデル化されます。
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.
いくつかとしてのプレ共有秘密キーを通した関係があらかじめ与えられて、暗示している認可のために意味するプレ確立した信用を見るかもしれません。 このドキュメントは、どんな特定の認可手段も定義しませんが、アプリケーションを条件としてこれを残します。
6. Acknowledgments
6. 承認
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.
このドキュメントはMSEC WGでステファン・フリーズ、ハンネスTschofenig、Fredrickリンドホルム、メアリ・バーンズ、ラッセルHousley、および一般的なフィードバックから親切で、有益なレビューフィードバックを取り入れます。
Euchner Standards Track [Page 21] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[21ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
7. IANA Considerations
7. IANA問題
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].
このドキュメントはDHHMACのためにそれ自身の新しい名前空間を定義しません、マイキーのために割り当てられたIANA名前空間を超えて。 [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:
[2]でTable 6.1.aにTable 4.1.aを一直線にするために、IANAがそれらのマイキー有効搭載量Name Spaceに以下のエントリーを加えるよう要求されています:
Data Type Value Reference --------------- ----- --------- DHHMAC init 7 RFC 4650 DHHMAC resp 8 RFC 4650
データ型値の参照--------------- ----- --------- DHHMACイニット7RFC4650DHHMAC resp8RFC4650
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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.、ジーター、M.、およびK.Norrman、「マイキー:」 「マルチメディアインターネットの合わせる」RFC3830、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-PUB180-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.、ジーター、M.、Norrman、K.、およびE.カラーラ、「セッション記述のためのKey Management拡大は(SDP)とリアルタイムのストリーミングのプロトコル(RTSP)について議定書の中で述べます」、RFC4567、2006年7月。
[5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[5]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
8.2. Informative References
8.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] レスコラ、E.とB.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
[8] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[8] イーストレーク3番目、D.とクロッカー、S.とJ.シラー、「セキュリティのための偶発性推薦」RFC1750、1994年12月。
Euchner Standards Track [Page 22] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[22ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
[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.ヴォルフ: 「ディフィー-ヘルマンプロトコル」とDesigns、CodesとCryptography、Special Issue Public Key Cryptography、Kluwer Academic Publishers、vol.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] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[12] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[12] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[14] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、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)のためのマイキーKey Managementプロトコルの用法」。 9/2005.
[16] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES)
Key Wrap Algorithm", RFC 3394, September 2002.
[16]SchaadとJ.とR.Housley、「エー・イー・エス(AES)の主要な包装アルゴリズム」、RFC3394、2002年9月。
[17] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
Domain of Interpretation", RFC 3547, July 2003.
2003年7月の[17]BaugherとM.とウィスとB.とHardjono、T.とH.ハーニー、「解釈のグループドメイン」RFC3547。
[18] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
Group Secure Association Key Management Protocol", RFC 4535,
June 2006.
ハーニー、H.、メタンフェタミン、U.、コールグローブ、A.、およびG.が利益を上げる[18]、「GSAKMP:」 「グループの安全な協会Key Managementプロトコル」、RFC4535、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)はKey Management構造を分類します」、RFC4046、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.
2004年の[20]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[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 Recommendation H.235.0、「H.323 Security枠組み:」 「H-シリーズ(ベースのH.323と他のH.245)マルチメディア・システムのためのセキュリティフレームワーク」、(09/2005)。
Euchner Standards Track [Page 23] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[23ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年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] アダムス、C.、ファレル、S.、Kause、T.、およびT.Mononen、「インターネットX.509公開鍵暗号基盤証明書経営者側は(CMP)について議定書の中で述べます」、RFC4210、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.、ガリペリン、S.、およびC.アダムス、「X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態は議定書を作ります--OCSP」、RFC2560、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.、ゾロタリョフ、M.、R.Zuccherato、および「インターネットX.509公開鍵暗号基盤データ合法化と証明サーバプロトコル」、RFC3029(2001年2月)
[25] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211, September
2005.
J.、「インターネットX.509公開鍵暗号基盤証明書要求メッセージ形式(CRMF)」、RFC4211 2005年9月の[25]Schaad。
[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公開鍵基盤:」 「証明経路ビル」、RFC4158、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、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[37] IANA MIKEY Payload Name Spaces per RFC 3830, see
http://www.iana.org/assignments/mikey-payloads.
[37] RFC3830あたりのIANA MIKEY有効搭載量Name Spacesに、 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.シュナイアー、「暗号に対する攻撃はインターネットでプロトコルを論じ尽くす」RFC4270、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.、Blaser、M.、ブラウン、D.、およびL.Dondetti、「マイキーのための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.リン、「マイキーの主要なDistributionの追加モード:」 「マイキー-RSA-R」は進歩、2006年8月に働いています。
Euchner Standards Track [Page 24] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[24ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
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.
この付録はいくつかのH.323ベースのマルチメディア環境でどうマイキー-DHHMACを適用できるかを有益な概観に提供します。 一般に、IP電話技術を含むマルチメディア応用に、マイキーは適切です。 [15]はH.323終点の中でTGKの合わせる物質的にマイキーのケースが証明するために、目的がある管理プロトコル(マイキー-PS、マイキー-PK、マイキー-DHSIGN、およびマイキー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.
特定の使用がケースに入れる1つは、その同じ門番ゾーンの中に位置している別の終点Aに呼びながら(門番を通して)終点Bからメディア接続を証明するためにマイキー-DHHMACを記述します。 EP-AとEP-Bが先験的にどんなauth_キーも通常共有していない間、いくつかの別々のプロトコル交換手段が終点が門番に登録されている間、時に主要なauth_を証明するために実際の呼び出しセットアップ手順の外で達成されます。 [15] しかし、そのようなプロトコルは存在しています。本書では示されません。 終点の間で主要なauth_は認証することにおいて使用された状態です、そして、保全はマイキー-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が門番(目立たない)から許可を得たと思われます。 訪問者がマイキーDHHMAC I_メッセージ(セクション3を見る)を築き上げて、H.323-SETUPの中で終点のA.Aルーティング門番(GK)に要約されたI_メッセージを送るとき、終点Bはこのメッセージを終点Bに転送するでしょう。 非ルーティング門番の場合には、終点Bは直接終点A.InへのどちらのケースもSETUPに送って、H.323の固有のセキュリティー対策[21]は、転送の間、(カプセル化)メッセージを保護するために適用されます。 これはここに表現されません。 受信終点Aは、運ばれたI_メッセージについて確かめることができて、TGKを計算できます。 終点Aが呼び出しを受け入れると仮定して、EP-Aは呼んでいる終点B(ことによるとルーティング門番を通した)に次に、マイキーDHHMAC R_メッセージを築き上げて、接続するCallProceedingメッセージの一部として応答を送って戻します。 終点Bは呼ばれた終点Aと同じTGKを計算する運ばれたR_メッセージを処理します。
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: セットアップ(I_fwd_メッセージ[I_は_メッセージを回転させます]) 2.) EP-A->(GK) ->EP-B: 接続するCallProceeding(R_fwd_メッセージ[R_は_メッセージを回転させます])
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
注意: 指示B>AとA>Bの両方の完全な複式のリンクに方向のTGKsを設立するのが必要であるなら、呼んでいる終点Bは二度DHHMACプロトコルを例示します: _方向にかつてのB>Aの使用している私は、fwd_メッセージと別の走行です。
Euchner Standards Track [Page 25] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[25ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
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.
中では、I_回転_メッセージを使用することでA>Bに方向に沿ってください。 その場合、2つのマイキーDHHMAC I_メッセージがSETUPの中で要約されます、そして、(I_fwd_メッセージとI_回転_は通信します)2つのマイキーDHHMAC R_メッセージ(R_fwd_メッセージとR_回転_は通信する)がCallProceedingからCONNECTの中で要約されます。 I_回転_メッセージはI_fwd_メッセージに対応しています。 あるいはまた、呼ばれた終点Aは終点B(目立ちません)で別々の走行におけるDHHMACプロトコルを例示するかもしれません。 しかしながら、これは終了する3番目の握手を必要とします。
For more details on how the MIKEY protocols may be deployed
with H.235, please refer to [15].
マイキープロトコルがH.235と共にどう配備されるかもしれないかに関するその他の詳細について、[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 55790Fax: +49 89 722 62366 メール: martin_euchner@hotmail.com
Euchner Standards Track [Page 26] RFC 4650 HMAC-Authenticated Diffie-Hellman for MIKEY September 2006
Euchner規格がRFCを追跡する、[26ページ]4650がディフィー-ヘルマンをHMAC認証した、マイキー2006年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Euchner Standards Track [Page 27]
Euchner標準化過程[27ページ]
一覧
スポンサーリンク
