RFC3830 日本語訳
3830 MIKEY: Multimedia Internet KEYing. J. Arkko, E. Carrara, F.Lindholm, M. Naslund, K. Norrman. August 2004. (Format: TXT=145238 bytes) (Updated by RFC4738) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Arkko
Request for Comments: 3830 E. Carrara
Category: Standards Track F. Lindholm
M. Naslund
K. Norrman
Ericsson Research
August 2004
Arkkoがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3830年のE.カラーラカテゴリ: 標準化過程F.リンドホルムM.ジーターK.Norrmanエリクソン研究2004年8月
MIKEY: Multimedia Internet KEYing
マイキー: マルチメディアインターネットの合わせること
Status of this Memo
この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 (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real- time Transport Protocol is described in detail.
このドキュメントはリアルタイムのアプリケーション(ピアツーピアコミュニケーションとグループコミュニケーションのための)に使用できるかぎ管理体系について説明します。 特に、Secureレアルが時間Transportプロトコルであるとサポートする使用は詳細に説明されます。
Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols.
リアルタイムのマルチメディア応用のためのセキュリティプロトコルは現れ始めました。 これはかぎ管理解決がこれらのプロトコルをサポートする必要性を早めました。
Arkko, et al. Standards Track [Page 1] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Existing Solutions . . . . . . . . . . . . . . . . . . . 4
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.3. Definitions. . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Abbreviations. . . . . . . . . . . . . . . . . . . . . . 6
1.5. Outline. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Scenarios. . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 8
2.3. System Overview. . . . . . . . . . . . . . . . . . . . . 8
2.4. Relation to GKMARCH. . . . . . . . . . . . . . . . . . . 10
3. Basic Key Transport and Exchange Methods . . . . . . . . . . . 10
3.1. Pre-shared Key . . . . . . . . . . . . . . . . . . . . . 12
3.2. Public-Key Encryption. . . . . . . . . . . . . . . . . . 13
3.3. Diffie-Hellman Key Exchange. . . . . . . . . . . . . . . 14
4. Selected Key Management Functions. . . . . . . . . . . . . . . 15
4.1. Key Calculation. . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Assumptions. . . . . . . . . . . . . . . . . . . 16
4.1.2. Default PRF Description. . . . . . . . . . . . . 17
4.1.3. Generating keys from TGK . . . . . . . . . . . . 18
4.1.4. Generating keys for MIKEY Messages from
an Envelope/Pre-Shared Key . . . . . . . . . . . 19
4.2 Pre-defined Transforms and Timestamp Formats . . . . . . . 19
4.2.1. Hash Functions . . . . . . . . . . . . . . . . . 19
4.2.2. Pseudo-Random Number Generator and PRF . . . . . 20
4.2.3. Key Data Transport Encryption. . . . . . . . . . 20
4.2.4. MAC and Verification Message Function. . . . . . 21
4.2.5. Envelope Key Encryption. . . . . . . . . . . . . 21
4.2.6. Digital Signatures . . . . . . . . . . . . . . . 21
4.2.7. Diffie-Hellman Groups. . . . . . . . . . . . . . 21
4.2.8. Timestamps . . . . . . . . . . . . . . . . . . . 21
4.2.9. Adding New Parameters to MIKEY . . . . . . . . . 22
4.3. Certificates, Policies and Authorization . . . . . . . . 22
4.3.1. Certificate Handling . . . . . . . . . . . . . . 22
4.3.2. Authorization. . . . . . . . . . . . . . . . . . 23
4.3.3. Data Policies. . . . . . . . . . . . . . . . . . 24
4.4. Retrieving the Data SA . . . . . . . . . . . . . . . . . 24
4.5. TGK Re-Keying and CSB Updating . . . . . . . . . . . . . 25
5. Behavior and Message Handling. . . . . . . . . . . . . . . . . 26
5.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.1. Capability Discovery . . . . . . . . . . . . . . 26
5.1.2. Error Handling . . . . . . . . . . . . . . . . . 27
5.2. Creating a Message . . . . . . . . . . . . . . . . . . . 28
5.3. Parsing a Message. . . . . . . . . . . . . . . . . . . . 29
5.4. Replay Handling and Timestamp Usage. . . . . . . . . . . 30
6. Payload Encoding . . . . . . . . . . . . . . . . . . . . . . . 32
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 既存のソリューション. . . . . . . . . . . . . . . . . . . 4 1.2。 記号法のコンベンション. . . . . . . . . . . . . . . . . 4 1.3。 定義。 . . . . . . . . . . . . . . . . . . . . . . 4 1.4. 略語。 . . . . . . . . . . . . . . . . . . . . . 6 1.5. 概説します。 . . . . . . . . . . . . . . . . . . . . . . . . 6 2. 基本的な概要. . . . . . . . . . . . . . . . . . . . . . . . 7 2.1。 シナリオ。 . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. 目標. . . . . . . . . . . . . . . . . . . . . . 8 2.3を設計してください。 システム概要。 . . . . . . . . . . . . . . . . . . . . 8 2.4. GKMARCHとの関係。 . . . . . . . . . . . . . . . . . . 10 3. 基本的な主要な輸送と交換メソッド. . . . . . . . . . . 10 3.1。 あらかじめ共有されたキー. . . . . . . . . . . . . . . . . . . . . 12 3.2。 公開鍵暗号化。 . . . . . . . . . . . . . . . . . 13 3.3. ディフィー-ヘルマンの主要なExchange。 . . . . . . . . . . . . . . 14 4. 選択されたKey Managementは機能します。 . . . . . . . . . . . . . . 15 4.1. 主要な計算。 . . . . . . . . . . . . . . . . . . . . 16 4.1.1. 仮定。 . . . . . . . . . . . . . . . . . . 16 4.1.2. デフォルトPRF記述。 . . . . . . . . . . . . 17 4.1.3. TGK. . . . . . . . . . . . 18 4.1.4からキーを生成します。 マイキーMessagesのために.194.2プレEnvelope/Shared KeyのPreによって定義されたTransformsとTimestamp Formatsからキーを生成する、.194.2、.1 ハッシュ関数. . . . . . . . . . . . . . . . . 19 4.2.2。 疑似乱数生成器とPRF. . . . . 20 4.2.3。 重要なデータは暗号化を輸送します。 . . . . . . . . . 20 4.2.4. MACと検証メッセージは機能します。 . . . . . 21 4.2.5. 封筒の主要な暗号化。 . . . . . . . . . . . . 21 4.2.6. デジタル署名. . . . . . . . . . . . . . . 21 4.2.7。 ディフィー-ヘルマンは分類します。 . . . . . . . . . . . . . 21 4.2.8. タイムスタンプ. . . . . . . . . . . . . . . . . . . 21 4.2.9。 マイキー. . . . . . . . . 22 4.3に新しいパラメタを加えます。 証明書、方針、および承認. . . . . . . . 22 4.3.1。 取り扱. . . . . . . . . . . . . . 22 4.3い.2を証明してください。 承認。 . . . . . . . . . . . . . . . . . 23 4.3.3. データ方針。 . . . . . . . . . . . . . . . . . 24 4.4. SA.244.5にデータを検索します。 TGK再の合わせるのとCSBアップデート. . . . . . . . . . . . . 25 5。 振舞いとメッセージハンドリング。 . . . . . . . . . . . . . . . . 26 5.1. 一般。 . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1.1. 能力発見. . . . . . . . . . . . . . 26 5.1.2。 エラー処理. . . . . . . . . . . . . . . . . 27 5.2。 メッセージ. . . . . . . . . . . . . . . . . . . 28 5.3を作成します。 メッセージを分析します。 . . . . . . . . . . . . . . . . . . . 29 5.4. 取り扱いとタイムスタンプ用法を再演してください。 . . . . . . . . . . 30 6. 有効搭載量コード化. . . . . . . . . . . . . . . . . . . . . . . 32
Arkko, et al. Standards Track [Page 2] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[2ページ]。
6.1. Common Header Payload (HDR). . . . . . . . . . . . . . . 32
6.1.1. SRTP ID. . . . . . . . . . . . . . . . . . . . . 35
6.2. Key Data Transport Payload (KEMAC) . . . . . . . . . . . 36
6.3. Envelope Data Payload (PKE). . . . . . . . . . . . . . . 37
6.4. DH Data Payload (DH) . . . . . . . . . . . . . . . . . . 38
6.5. Signature Payload (SIGN) . . . . . . . . . . . . . . . . 39
6.6. Timestamp Payload (T). . . . . . . . . . . . . . . . . . 39
6.7. ID Payload (ID) / Certificate Payload (CERT) . . . . . . 40
6.8. Cert Hash Payload (CHASH). . . . . . . . . . . . . . . . 41
6.9. Ver msg payload (V). . . . . . . . . . . . . . . . . . . 42
6.10. Security Policy Payload (SP) . . . . . . . . . . . . . . 42
6.10.1. SRTP Policy. . . . . . . . . . . . . . . . . . . 44
6.11. RAND Payload (RAND). . . . . . . . . . . . . . . . . . . 45
6.12. Error Payload (ERR). . . . . . . . . . . . . . . . . . . 46
6.13. Key Data Sub-Payload . . . . . . . . . . . . . . . . . . 46
6.14. Key Validity Data. . . . . . . . . . . . . . . . . . . . 48
6.15. General Extension Payload. . . . . . . . . . . . . . . . 50
7. Transport Protocols. . . . . . . . . . . . . . . . . . . . . . 50
8. Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.1. Simple One-to-Many . . . . . . . . . . . . . . . . . . . 51
8.2. Small-Size Interactive Group . . . . . . . . . . . . . . 51
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 52
9.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 52
9.2. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . 54
9.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 55
9.4. Identity Protection. . . . . . . . . . . . . . . . . . . 55
9.5. Denial of Service. . . . . . . . . . . . . . . . . . . . 56
9.6. Session Establishment. . . . . . . . . . . . . . . . . . 56
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 57
10.1. MIME Registration. . . . . . . . . . . . . . . . . . . . 59
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 59
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.1. Normative References . . . . . . . . . . . . . . . . . . 60
12.2. Informative References . . . . . . . . . . . . . . . . . 61
Appendix A. - MIKEY - SRTP Relation. . . . . . . . . . . . . . . . 63
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 66
6.1. 一般的なヘッダー有効搭載量(HDR)。 . . . . . . . . . . . . . . 32 6.1.1. SRTPアイダホ州 . . . . . . . . . . . . . . . . . . . . 35 6.2. 重要なデータは有効搭載量(KEMAC). . . . . . . . . . . 36 6.3を輸送します。 封筒データ有効搭載量(PKE)。 . . . . . . . . . . . . . . 37 6.4. DHデータ有効搭載量(DH。). . . . . . . . . . . . . . . . . . 38 6.5 署名有効搭載量(サイン。). . . . . . . . . . . . . . . . 39 6.6 タイムスタンプ有効搭載量(T)。 . . . . . . . . . . . . . . . . . 39 6.7. ID有効搭載量(ID)/証明書有効搭載量(本命。). . . . . . 40 6.8 本命ハッシュ有効搭載量(CHASH)。 . . . . . . . . . . . . . . . 41 6.9. Ver msgペイロード(V)。 . . . . . . . . . . . . . . . . . . 42 6.10. 安全保障政策有効搭載量(SP). . . . . . . . . . . . . . 42 6.10.1。 SRTP方針。 . . . . . . . . . . . . . . . . . . 44 6.11. 底ならし革有効搭載量(底ならし革)。 . . . . . . . . . . . . . . . . . . 45 6.12. 誤り有効搭載量(間違えます)。 . . . . . . . . . . . . . . . . . . 46 6.13. 重要なデータサブ有効搭載量. . . . . . . . . . . . . . . . . . 46 6.14。 主要な正当性データ。 . . . . . . . . . . . . . . . . . . . 48 6.15. 一般拡大有効搭載量。 . . . . . . . . . . . . . . . 50 7. プロトコルを輸送してください。 . . . . . . . . . . . . . . . . . . . . . 50 8. グループ. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 8.1。 簡単な多くへの1.518.2。 小型インタラクティブグループ. . . . . . . . . . . . . . 51 9。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 52 9.1. 一般。 . . . . . . . . . . . . . . . . . . . . . . . . 52 9.2. 主要な生涯. . . . . . . . . . . . . . . . . . . . . . 54 9.3。 タイムスタンプ. . . . . . . . . . . . . . . . . . . . . . . 55 9.4。 アイデンティティ保護。 . . . . . . . . . . . . . . . . . . 55 9.5. サービス妨害。 . . . . . . . . . . . . . . . . . . . 56 9.6. セッション設立。 . . . . . . . . . . . . . . . . . 56 10. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 57 10.1. 登録をまねてください。 . . . . . . . . . . . . . . . . . . . 59 11. 承認。 . . . . . . . . . . . . . . . . . . . . . . . 59 12. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 60 12.1。 引用規格. . . . . . . . . . . . . . . . . . 60 12.2。 有益な参照. . . . . . . . . . . . . . . . . 61付録A.--マイキー--SRTP関係。 . . . . . . . . . . . . . . . 63作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 65の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 66
1. Introduction
1. 序論
There has recently been work to define a security protocol for the protection of real-time applications running over RTP, [SRTP]. However, a security protocol needs a key management solution to exchange keys and related security parameters. There are some fundamental properties that such a key management scheme has to fulfill to serve streaming and real-time applications (such as unicast and multicast), particularly in heterogeneous (mix of wired and wireless) networks.
最近、RTP、[SRTP]をひくリアルタイムのアプリケーションの保護のためにセキュリティプロトコルを定義するために、仕事がありました。 しかしながら、セキュリティプロトコルは、キーと関連するセキュリティパラメタを交換するためにかぎ管理解決を必要とします。 そのようなかぎ管理体系がストリーミングの、そして、リアルタイムのアプリケーション(ユニキャストやマルチキャストなどの)に役立つように実現させなければならないいくつかの基本財産があります、特に種々雑多な(ワイヤードでワイヤレスのミックス)ネットワークで。
Arkko, et al. Standards Track [Page 3] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[3ページ]。
This document describes a key management solution that addresses multimedia scenarios (e.g., SIP [SIP] calls and RTSP [RTSP] sessions). The focus is on how to set up key management for secure multimedia sessions such that requirements in a heterogeneous environment are fulfilled.
このドキュメントはマルチメディアがシナリオ(例えば、SIP[SIP]呼び出しとRTSP[RTSP]セッション)であると扱うかぎ管理解決について説明します。 異機種混在環境における要件が実現するようにどう安全なマルチメディアセッションのためのかぎ管理を設立するかに関して焦点があります。
1.1. Existing Solutions
1.1. 既存のソリューション
There is work done in the IETF to develop key management schemes. For example, IKE [IKE] is a widely accepted unicast scheme for IPsec, and the MSEC WG is developing other schemes to address group communication [GDOI, GSAKMP]. However, for reasons discussed below, there is a need for a scheme with lower latency, suitable for demanding cases such as real-time data over heterogeneous networks and small interactive groups.
かぎ管理体系を開発するためにIETFで行われた仕事があります。 例えば、IKE[IKE]はIPsecが広く受け入れられたユニキャスト体系です、そして、MSEC WGはグループコミュニケーションが[GDOI、GSAKMP]であると扱うために他の体系を開発しています。 しかしながら、以下で議論した理由で、体系の必要が下側の潜在と共にあります、異機種ネットワークと小さい対話的なグループの上のリアルタイムデータなどのケースを要求するのに、適当です。
An option in some cases might be to use [SDP], as SDP defines one field to transport keys, the "k=" field. However, this field cannot be used for more general key management purposes, as it cannot be extended from the current definition.
オプションはいくつかの場合、[SDP]を使用することであるかもしれません、SDPがキーを輸送するために1つの分野を定義するとき、「k=」分野。 しかしながら、より一般的なかぎ管理目的にこの分野を使用できません、現在の定義からそれを広げることができないのに従って。
1.2. Notational Conventions
1.2. 記号法のコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
1.3. Definitions
1.3. 定義
(Data) Security Protocol: the security protocol used to protect the actual data traffic. Examples of security protocols are IPsec and SRTP.
(データ)セキュリティは議定書を作ります: セキュリティプロトコルは以前はよく実際のデータ通信量を保護していました。 セキュリティプロトコルに関する例は、IPsecとSRTPです。
Data Security Association (Data SA): information for the security protocol, including a TEK and a set of parameters/policies.
データ機密保護協会(データSA): TEKと1セットのパラメタ/方針を含むセキュリティプロトコルのための情報。
Crypto Session (CS): uni- or bi-directional data stream(s), protected by a single instance of a security protocol. For example, when SRTP is used, the Crypto Session will often contain two streams, an RTP stream and the corresponding RTCP, which are both protected by a single SRTP Cryptographic Context, i.e., they share key data and the bulk of security parameters in the SRTP Cryptographic Context (default behavior in [SRTP]). In the case of IPsec, a Crypto Session would represent an instantiation of an IPsec SA. A Crypto Session can be viewed as a Data SA (as defined in [GKMARCH]) and could therefore be mapped to other security protocols if necessary.
暗号セッション(Cs): uniか双方向のデータがセキュリティプロトコルのただ一つのインスタンスによって保護された(s)を流します。 SRTPが使用されているとき、例えば、Crypto Sessionはしばしば2つのストリーム、RTPストリーム、および対応するRTCPを含むでしょう、どれが両方であるかが独身のSRTP Cryptographic Contextによって保護されました、すなわち、それらはSRTP Cryptographic Context([SRTP]のデフォルトの振舞い)のセキュリティパラメタの重要なデータと大半を共有します。 IPsecの場合では、Crypto SessionはIPsec SAの具体化を表すでしょう。 Crypto SessionをData SAとして見なすことができて([GKMARCH]で定義されるように)、したがって、必要なら、他のセキュリティプロトコルに写像できました。
Arkko, et al. Standards Track [Page 4] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[4ページ]。
Crypto Session Bundle (CSB): collection of one or more Crypto Sessions, which can have common TGKs (see below) and security parameters.
暗号セッションバンドル(CSB): 1Cryptoのセッションズの収集。(セッションズは、一般的なTGKs(以下を見る)とセキュリティパラメタを持つことができます)。
Crypto Session ID: unique identifier for the CS within a CSB.
暗号セッションID: CSBの中のCSに、ユニークな識別子。
Crypto Session Bundle ID (CSB ID): unique identifier for the CSB.
暗号セッションバンドルID(CSB ID): CSBに、ユニークな識別子。
TEK Generation Key (TGK): a bit-string agreed upon by two or more parties, associated with CSB. From the TGK, Traffic-encrypting Keys can then be generated without needing further communication.
TEK世代キー(TGK): CSBに関連づけられた2回以上のパーティーによって同意されて、少し結びます。 そして、TGKから、さらなるコミュニケーションを必要としないで、Trafficを暗号化しているキーズは生成することができます。
Traffic-Encrypting Key (TEK): the key used by the security protocol to protect the CS (this key may be used directly by the security protocol or may be used to derive further keys depending on the security protocol). The TEKs are derived from the CSB's TGK.
キー(TEK)をトラフィックで暗号化します: セキュリティプロトコルによって使用される、CS(このキーは、直接セキュリティプロトコルによって使用されるか、またはセキュリティプロトコルによる一層のキーを引き出すのに使用されるかもしれない)を保護するキー。 CSBのTGKからTEKsを得ます。
TGK re-keying: the process of re-negotiating/updating the TGK (and consequently future TEK(s)).
TGK再の合わせること: TGKをアップデートしながら/を再交渉するのを処理してください。(そして、その結果未来TEK(s))。
Initiator: the initiator of the key management protocol, not necessarily the initiator of the communication.
創始者: 必ずコミュニケーションの創始者ではなく、かぎ管理プロトコルの創始者。
Responder: the responder in the key management protocol.
応答者: かぎ管理プロトコルの応答者。
Salting key: a random or pseudo-random (see [RAND, HAC]) string used to protect against some off-line pre-computation attacks on the underlying security protocol.
キーに塩味を付けさせます: a無作為である、または、基本的なセキュリティプロトコルに対するいくつかのオフラインプレ計算攻撃から守るのに使用される擬似ランダム([RAND、HAC]を見る)ストリング。
PRF(k,x): a keyed pseudo-random function (see [HAC]).
E(k,m): encryption of m with the key k.
PKx: the public key of x
[] an optional piece of information
{} denotes zero or more occurrences
|| concatenation
| OR (selection operator)
^ exponentiation
XOR exclusive or
PRF(k、x): 合わせられた擬似ランダム機能([HAC]を見ます)。 E(k、m): キーkによるmの暗号化。 PKx: xの公開鍵、[] 任意の情報、ゼロか、より多くの発生を指示します。|| 連結| またはOR(選択オペレータ)^羃法XOR排他的である。
Bit and byte ordering: throughout the document bits and bytes are indexed, as usual, from left to right, with the leftmost bits/bytes being the most significant.
ビットとバイト順: 一番左ビット/バイトが最も重要な状態でドキュメントビットとバイト中で左から右までいつものように索引をつけられます。
Arkko, et al. Standards Track [Page 5] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[5ページ]。
1.4. Abbreviations
1.4. 略語
AES Advanced Encryption Standard CM Counter Mode (as defined in [SRTP]) CS Crypto Session CSB Crypto Session Bundle DH Diffie-Hellman DoS Denial of Service MAC Message Authentication Code MIKEY Multimedia Internet KEYing PK Public-Key PSK Pre-Shared key RTP Real-time Transport Protocol RTSP Real Time Streaming Protocol SDP Session Description Protocol SIP Session Initiation Protocol SRTP Secure RTP TEK Traffic-encrypting key TGK TEK Generation Key
SRTP Secure RTP TEK Trafficを暗号化しているKEYing PK Public主要なPSK Preによって共有された主要なAESエー・イー・エスCM Counter Mode([SRTP]で定義されるように)CS Crypto Session CSB Crypto Session Bundle DHディフィー-ヘルマンDoSサービス妨害MACメッセージ立証コードマイキーMultimediaインターネットのプロトコルSIP Session Initiationプロトコル主要なRTPレアル-時間TransportプロトコルRTSPレアルTime StreamingプロトコルSDP Session記述TGK TEK Generation Key
1.5. Outline
1.5. アウトライン
Section 2 describes the basic scenarios and the design goals for which MIKEY is intended. It also gives a brief overview of the entire solution and its relation to the group key management architecture [GKMARCH].
セクション2はマイキーが意図する基本的なシナリオとデザイン目標について説明します。 また、それは全体のソリューションの簡潔な概要とグループかぎ管理アーキテクチャ[GKMARCH]とのその関係を与えます。
The basic key transport/exchange mechanisms are explained in detail in Section 3. The key derivation, and other general key management procedures are described in Section 4.
基本的な主要な輸送/交換メカニズムはセクション3で詳細に説明されます。 主要な派生、およびもう一方一般的なかぎ管理手順はセクション4で説明されます。
Section 5 describes the expected behavior of the involved parties. This also includes message creation and parsing.
セクション5は関係者の予想された振舞いについて説明します。 また、これはメッセージ作成と構文解析を含んでいます。
All definitions of the payloads in MIKEY are described in Section 6.
ペイロードのすべての定義がセクション6にマイキーに説明されます。
Section 7 deals with transport considerations, while Section 8 focuses on how MIKEY is used in group scenarios.
セクション7は輸送問題に対処しますが、セクション8はマイキーがグループシナリオでどう使用されるかに焦点を合わせます。
The Security Considerations section (Section 9), gives a deeper explanation of important security related topics.
Security Considerationsは(セクション9)を区分して、重要なセキュリティ関連した話題の、より深い説明をします。
Arkko, et al. Standards Track [Page 6] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[6ページ]。
2. Basic Overview
2. 基本的な概要
2.1. Scenarios
2.1. シナリオ
MIKEY is mainly intended to be used for peer-to-peer, simple one-to- many, and small-size (interactive) groups. One of the main multimedia scenarios considered when designing MIKEY has been the conversational multimedia scenario, where users may interact and communicate in real-time. In these scenarios it can be expected that peers set up multimedia sessions between each other, where a multimedia session may consist of one or more secured multimedia streams (e.g., SRTP streams).
マイキーは、ピアツーピアに使用されることを主に意図して、簡単なものから多くて、小さいサイズ(対話的な)のグループです。 主なマルチメディアシナリオのひとりは、いつマイキーを設計するのが、会話のマルチメディアシナリオであるかを考えました。そこでは、ユーザは、リアルタイムでで相互作用して、交信するかもしれません。 これらのシナリオでは、同輩が互い、マルチメディアセッションがどこで1から成るかもしれないか、そして、またはさらに機密保護しているマルチメディアストリーム(例えば、SRTPストリーム)の間のマルチメディアセッションをセットアップすると予想できます。
peer-to-peer/ many-to-many many-to-many
simple one-to-many (distributed) (centralized)
++++ ++++ ++++ ++++ ++++
|. | |A | |B | |A |---- ----|B |
--| ++++ | |----------| | | | \ / | |
++++ / ++|. | ++++ ++++ ++++ (S) ++++
|A |---------| ++++ \ / |
| | \ ++|B | \ / |
++++ \-----| | \ ++++ / ++++
++++ \|C |/ |C |
| | | |
++++ ++++
多くへの多くへの多くへの多くピアツーピア/多くの簡単なもの(分配されます)(集結される)++++++++++++++++++++|. | |A| |B| |A|---- ----|B| --| ++++ | |----------| | | | \ / | | ++++ / ++|. | + + + + + + + + + + + + (S) + + + +|A|---------| ++++ \ / | | | \ ++|B| \ / | ++++ \-----| | \ ++++ / ++++ ++++ \|C|/ |C| | | | | ++++ ++++
Figure 2.1: Examples of the four scenarios: peer-to-peer, simple one-to-many, many-to-many without a centralized server (also denoted as small interactive group), and many-to-many with a centralized server.
図2.1: 4つのシナリオに関する例: ピアツーピア、多く、多くへの多くへの簡単なものはaなしで集中しました。サーバ(また、小さい対話的なグループとして、指示される)、および多くへの集結されたサーバがある多く。
We identify in the following some typical scenarios which involve the multimedia applications we are dealing with (see also Figure 2.1).
私たちは以下で私たちが対処しているマルチメディア応用にかかわるいくつかの典型的なシナリオを特定します(また、図2.1を見てください)。
a) peer-to-peer (unicast), e.g., a SIP-based [SIP] call between two
parties, where it may be desirable that the security is either set
up by mutual agreement or that each party sets up the security for
its own outgoing streams.
a) ピアツーピア(ユニキャスト)、例えば、SIPベースの[SIP]は2回のパーティーの間に呼びます。そこでは、セキュリティが相談ずくにセットアップされるか、または各当事者がそれ自身の外向的なストリームのためにセキュリティをセットアップするのが、望ましいかもしれません。
b) simple one-to-many (multicast), e.g., real-time presentations,
where the sender is in charge of setting up the security.
b) 多くへの簡単なもの(マルチキャスト)、例えば、リアルタイムのプレゼンテーション。(そこでは、送付者がセキュリティをセットアップするのを担当しています)。
c) many-to-many, without a centralized control unit, e.g., for
small-size interactive groups where each party may set up the
security for its own outgoing media. Two basic models may be used
here. In the first model, the Initiator of the group acts as the
多くへのc)多く、集中制御ユニット、例えば、小型のために、インタラクティブは各当事者がそれ自身の出発しているメディアのためにセキュリティをセットアップするかもしれないところで分類されます。 2人の基本型がここで使用されるかもしれません。 第1代モデルでは、グループのInitiatorは行動します。
Arkko, et al. Standards Track [Page 7] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[7ページ]。
group server (and is the only one authorized to include new
members). In the second model, authorization information to
include new members can be delegated to other participants.
サーバを分類してください(唯一無二が新しいメンバーを含んでいるのが認可されます)。 第2代モデルでは、新しいメンバーを含む承認情報を他の関係者へ代表として派遣することができます。
d) many-to-many, with a centralized control unit, e.g., for larger
groups with some kind of Group Controller that sets up the
security.
集中制御ユニット、例えば、セキュリティをセットアップするある種のGroup Controllerがある、より大きいグループのための多くへのd)多く。
The key management solutions may be different in the above scenarios. When designing MIKEY, the main focus has been on case a, b, and c. For scenario c, only the first model is covered by this document.
かぎ管理解決は上のシナリオにおいて異なっているかもしれません。 マイキーを設計するとき、ケースa、b、およびcの上に主な焦点がありました。 シナリオcにおいて、第1代モデルだけがこのドキュメントでカバーされています。
2.2. Design Goals
2.2. デザイン目標
The key management protocol is designed to have the following characteristics:
かぎ管理プロトコルは以下の特性を持つように設計されています:
* End-to-end security. Only the participants involved in the
communication have access to the generated key(s).
* 終わりから終わりへのセキュリティ。 コミュニケーションにかかわる関係者だけが発生しているキーに近づく手段を持っています。
* Simplicity.
* 簡単さ。
* Efficiency. Designed to have:
- low bandwidth consumption,
- low computational workload,
- small code size, and
- minimal number of roundtrips.
* 効率。 以下を持つために、設計されました。 - そして、低い帯域幅消費--低いコンピュータのワークロード--小さいコードサイズ、--最小量の数の往復旅行。
* Tunneling. Possibility to "tunnel"/integrate MIKEY in session
establishment protocols (e.g., SDP and RTSP).
* トンネリング。 セッション設立プロトコル(例えば、SDPとRTSP)にマイキーを「トンネルを堀る」か、または統合する可能性。
* Independence from any specific security functionality of the
underlying transport.
* 基本的な輸送のどんな特定のセキュリティの機能性からの独立。
2.3. System Overview
2.3. システム概要
One objective of MIKEY is to produce a Data SA for the security protocol, including a traffic-encrypting key (TEK), which is derived from a TEK Generation Key (TGK), and used as input for the security protocol.
マイキーの1つの目的はセキュリティプロトコルのためにData SAを生産することです、トラフィックを暗号化するキー(TEK)(セキュリティプロトコルのために入力されるようにTEK Generation Key(TGK)から得られて、使用される)を含んでいて。
MIKEY supports the possibility of establishing keys and parameters for more than one security protocol (or for several instances of the same security protocol) at the same time. The concept of Crypto Session Bundle (CSB) is used to denote a collection of one or more Crypto Sessions that can have common TGK and security parameters, but which obtain distinct TEKs from MIKEY.
マイキーは同時に1つ以上のセキュリティプロトコル(または同じセキュリティプロトコルのいくつかのインスタンスのために)のためのキーとパラメタを確立する可能性をサポートします。 Crypto Session Bundle(CSB)の概念は一般的なTGKとセキュリティパラメタを持つことができる1Cryptoのセッションズの収集を指示するのに使用されて、どれがマイキーから異なったTEKsを入手するかをそうされます。
Arkko, et al. Standards Track [Page 8] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[8ページ]。
The procedure of setting up a CSB and creating a TEK (and Data SA), is done in accordance with Figure 2.2:
設定の手順をCSBとTEKを作成するのを(そして、Data SA)上げて、図2.2によると、します:
1. A set of security parameters and TGK(s) are agreed upon for the
Crypto Session Bundle (this is done by one of the three
alternative key transport/exchange mechanisms, see Section 3).
1. パラメタとTGK(s)がCrypto Session Bundleのために同意される1セットのセキュリティ(3つの代替の主要な輸送/交換メカニズムの1つでこれをします、とセクション3は見ます)。
2. The TGK(s) is used to derive (in a cryptographically secure way) a
TEK for each Crypto Session.
2. TGK(s)は、各Crypto SessionのためにTEKを引き出すこと(aでは、暗号で道を保証する)に使用されます。
3. The TEK, together with the security protocol parameters, represent
the Data SA, which is used as the input to the security protocol.
3. TEKはセキュリティプロトコルパラメタと共にData SAを表します。(Data SAは入力としてセキュリティプロトコルに使用されます)。
+-----------------+
| CSB |
| Key transport | (see Section 3)
| /exchange |
+-----------------+
| :
| TGK :
v :
+----------+ :
CS ID ->| TEK | : Security protocol (see Section 4)
|derivation| : parameters (policies)
+----------+ :
TEK | :
v v
Data SA
|
v
+-------------------+
| Crypto Session |
|(Security Protocol)|
+-------------------+
+-----------------+ | CSB| | 主要な輸送| (セクション3を見ます) | /交換| +-----------------+ | : | TGK: v: +----------+ : Cs ID、->| TEK| : セキュリティプロトコル(セクション4を見ます)|派生| : パラメタ(方針)+----------+ : TEK| : v Data SAに対して| +に対して-------------------+ | 暗号セッション| |(セキュリティプロトコル)| +-------------------+
Figure 2.2: Overview of MIKEY key management procedure.
図2.2: マイキーかぎ管理手順の概要。
The security protocol can then either use the TEK directly, or, if supported, derive further session keys from the TEK (e.g., see SRTP [SRTP]). It is however up to the security protocol to define how the TEK is used.
そして、セキュリティプロトコルが、直接TEKを使用するか、またはサポートされるなら、一層のセッションキーにTEKに由来できます(例えば、SRTP[SRTP]を見てください)。 TEKがどう使用されているかを定義するセキュリティプロトコルにどんなに上がってもそれはそうです。
MIKEY can be used to update TEKs and the Crypto Sessions in a current Crypto Session Bundle (see Section 4.5). This is done by executing the transport/exchange phase once again to obtain a new TGK (and consequently derive new TEKs) or to update some other specific CS parameters.
現在のCrypto Session BundleでTEKsとCryptoセッションズをアップデートするのにマイキーを使用できます(セクション4.5を見てください)。 新しいTGK(その結果、新しいTEKsを引き出す)を入手するか、またはある他の特定のCSパラメタをアップデートするためにもう一度輸送/交換フェーズを実行することによって、これをします。
Arkko, et al. Standards Track [Page 9] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[9ページ]。
2.4. Relation to GKMARCH
2.4. GKMARCHとの関係
The Group key management architecture (GKMARCH) [GKMARCH] describes a general architecture for group key management protocols. MIKEY is a part of this architecture, and can be used as a so-called Registration protocol. The main entities involved in the architecture are the group controller/key server (GCKS), the receiver(s), and the sender(s).
Groupかぎ管理アーキテクチャ(GKMARCH)[GKMARCH]はグループかぎ管理プロトコルのために一般的なアーキテクチャについて説明します。 マイキーは、このアーキテクチャの一部であり、いわゆるRegistrationプロトコルとして使用できます。 アーキテクチャにかかわる主な実体は、グループコントローラ/主要なサーバ(GCKS)と、受信機と、送付者です。
In MIKEY, the sender could act as GCKS and push keys down to the receiver(s).
マイキーでは、GCKSとプッシュキーが受信機にダウンするとき、送付者は行動できました。
Note that, for example, in a SIP-initiated call, the sender may also be a receiver. As MIKEY addresses small interactive groups, a member may dynamically change between being a sender and receiver (or being both simultaneously).
例えばSIPによって開始された呼び出しでは、送付者がそうするかもしれないことに注意してください、そして、また、受信機になってください。マイキーが小さい対話的なグループに演説するとき、メンバーは送付者と受信機であるときにダイナミックに変化してもよいです(同時に両方であり)。
3. Basic Key Transport and Exchange Methods
3. 基本的な主要な輸送と交換メソッド
The following sub-sections define three different methods of transporting/establishing a TGK: with the use of a pre-shared key, public-key encryption, and Diffie-Hellman (DH) key exchange. In the following, we assume unicast communication for simplicity. In addition to the TGK, a random "nonce", denoted RAND, is also transported. In all three cases, the TGK and RAND values are then used to derive TEKs as described in Section 4.1.3. A timestamp is also sent to avoid replay attacks (see Section 5.4).
以下の小区分はTGKを輸送するか、または設立する3つの異なったメソッドを定義します: あらかじめ共有されたキー、公開鍵暗号化、およびディフィー-ヘルマン(DH)の主要な交換の使用で。 以下では、私たちは簡単さのためのユニキャストコミュニケーションを仮定します。 TGKに加えて、無作為の「一回だけ」は、RANDを指示して、また、輸送されます。 そして、全部で、3つのケース、TGK、およびRAND値は、セクション4.1.3で説明されるようにTEKsを引き出すのに使用されます。 また、反射攻撃を避けるためにタイムスタンプを送ります(セクション5.4を見てください)。
The pre-shared key method and the public-key method are both based on key transport mechanisms, where the actual TGK is pushed (securely) to the recipient(s). In the Diffie-Hellman method, the actual TGK is instead derived from the Diffie-Hellman values exchanged between the peers.
あらかじめ共有された主要なメソッドと公開鍵メソッドはともに主要な移送機構に基づいています。そこでは、実際のTGKが(しっかりと)受取人に押されます。 ディフィー-ヘルマンメソッドで、代わりに同輩の間で交換されたディフィー-ヘルマン値から実際のTGKを得ます。
The pre-shared case is, by far, the most efficient way to handle the key transport due to the use of symmetric cryptography only. This approach also has the advantage that only a small amount of data has to be exchanged. Of course, the problematic issue is scalability as it is not always feasible to share individual keys with a large group of peers. Therefore, this case mainly addresses scenarios such as server-to-client and also those cases where the public-key modes have already been used, thus allowing for the "cache" of a symmetric key (see below and Section 3.2).
あらかじめ共有されたケースは断然左右対称の暗号だけの使用による主要な輸送を扱う最も効率的な方法です。 また、このアプローチには、少量のデータだけが交換するために持っている利点があります。 もちろん、同輩の大きいグループと個々のキーを共有するのがいつも可能であるというわけではないときに、問題の多い問題はスケーラビリティです。 したがって、本件は公開鍵モードが既に使用されたサーバからクライアントやそれらのケースについてもシナリオを主に扱います、その結果、対称鍵の「キャッシュ」を考慮します(以下とセクション3.2を見てください)。
Public-key cryptography can be used to create a scalable system. A disadvantage with this approach is that it is more resource consuming than the pre-shared key approach. Another disadvantage is that in most cases, a PKI (Public Key Infrastructure) is needed to handle the
スケーラブルなシステムを作成するのに公開鍵暗号を使用できます。 このアプローチがある不都合はそれがあらかじめ共有された主要近接路より多くのリソース消費であるということです。 別の不都合は多くの場合、a PKI(公開鍵基盤)がハンドルに必要であるということです。
Arkko, et al. Standards Track [Page 10] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[10ページ]。
distribution of public keys. Of course, it is possible to use public keys as pre-shared keys (e.g., by using self-signed certificates). It should also be noted that, as mentioned above, this method may be used to establish a "cached" symmetric key that later can be used to establish subsequent TGKs by using the pre-shared key method (hence, the subsequent request can be executed more efficiently).
公開鍵の分配。 もちろん、あらかじめ共有されたキー(例えば、自己署名入りの証書を使用するのによる)として公開鍵を使用するのは可能です。 また、このメソッドが後であらかじめ共有された主要なメソッドを使用することによってその後のTGKsを証明するのに使用できる「キャッシュされた」対称鍵を証明するのに上に言及されるように使用されるかもしれないことに(したがって、より効率的にその後の要求を実行できます)注意されるべきです。
In general, the Diffie-Hellman (DH) key agreement method has a higher resource consumption (both computationally and in bandwidth) than the previous ones, and needs certificates as in the public-key case. However, it has the advantage of providing perfect forward secrecy (PFS) and flexibility by allowing implementation in several different finite groups.
一般に、ディフィー-ヘルマン(DH)の主要な協定メソッドは、前のものより高いリソース消費(計算上、そして、帯域幅の)を持って、公開鍵ケースのように証明書を必要とします。 しかしながら、それには、いくつかの異なった有限群で実装を許容することによって完全な前進の秘密保持(PFS)と柔軟性を提供する利点があります。
Note that by using the DH method, the two involved parties will generate a unique unpredictable random key. Therefore, it is not possible to use this DH method to establish a group TEK (as the different parties in the group would end up with different TEKs). It is not the intention of the DH method to work in this scenario, but to be a good alternative in the special peer-to-peer case.
DHメソッドを使用することによって、2回の関係者がユニークな予測できないランダムキーを生成することに注意してください。 したがって、グループTEKを確立するこのDHメソッドを使用するのは可能ではありません(グループにおける異なったパーティーが異なったTEKsで終わるだろうというとき)。 それはしかし特別なピアツーピア場合における良い代替手段になるようにこのシナリオで働くDHメソッドの意志ではありません。
The following general notation is used:
以下の一般表記は使用されています:
HDR: The general MIKEY header, which includes MIKEY CSB related data (e.g., CSB ID) and information mapping to the specific security protocol used. See Section 6.1 for payload definition.
HDR: 一般的なマイキーヘッダーであり、どれがMIKEY CSBを含んでいるかが特定のセキュリティプロトコルへのマッピングが使用したデータ(例えば、CSB ID)と情報について話しました。 ペイロード定義に関してセクション6.1を見てください。
T: The timestamp, used mainly to prevent replay attacks. See Section 6.6 for payload definition and also Section 5.4 for other timestamp related information.
T: 主に反射攻撃を防ぐのに使用されるタイムスタンプ。 ペイロード定義のためのセクション6.6と他のタイムスタンプ関連情報のためのセクション5.4も見てください。
IDx: The identity of entity x (IDi=Initiator, IDr=Responder). See Section 6.7 for payload definition.
IDx: 実体x(IDiは創始者と等しく、IDrは応答者と等しいです)のアイデンティティ。 ペイロード定義に関してセクション6.7を見てください。
RAND: Random/pseudo-random byte-string, which is always included in the first message from the Initiator. RAND is used as a freshness value for the key generation. It is not included in update messages of a CSB. See Section 6.11 for payload definition. For randomness recommendations for security, see [RAND].
底ならし革: 無作為の/擬似ランダムバイトストリング。(そのストリングはInitiatorからの最初のメッセージにいつも含まれています)。 RANDはキー生成に新しさ値として使用されます。 それはCSBに関するアップデートメッセージに含まれていません。 ペイロード定義に関してセクション6.11を見てください。 セキュリティのための偶発性推薦に関しては、[RAND]を見てください。
SP: The security policies for the data security protocol. See Section 6.10 for payload definition.
SP: データ機密保護のための安全保障政策は議定書を作ります。 ペイロード定義に関してセクション6.10を見てください。
Arkko, et al. Standards Track [Page 11] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[11ページ]。
3.1. Pre-shared key
3.1. あらかじめ共有されたキー
In this method, the pre-shared secret key, s, is used to derive key material for both the encryption (encr_key) and the integrity protection (auth_key) of the MIKEY messages, as described in Section 4.1.4. The encryption and authentication transforms are described in Section 4.2.
このメソッドで、プレ共有秘密キーキー(s)は暗号化(encr_キー)とマイキーメッセージの保全保護(auth_キー)の両方のための主要な材料を誘導するのに使用されます、セクション4.1.4で説明されるように。 暗号化と認証変換はセクション4.2で説明されます。
Initiator Responder
創始者応答者
I_MESSAGE =
HDR, T, RAND, [IDi],[IDr],
{SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
I_メッセージ=HDR、T、底ならし革、[IDi]、[IDr]、SP、KEMAC--->R_メッセージ=、[<--、]、HDR、T、[IDr]、V
The main objective of the Initiator's message (I_MESSAGE) is to transport one or more TGKs (carried into KEMAC) and a set of security parameters (SPs) to the Responder in a secure manner. As the verification message from the Responder is optional, the Initiator indicates in the HDR whether it requires a verification message or not from the Responder.
Initiatorのメッセージ(I_MESSAGE)の主な目標は安全な方法で1TGKs(KEMACまで運ばれる)とセキュリティパラメタのセット(SPs)をResponderに輸送することです。 Responderからの検証メッセージが任意であるので、Initiatorは、HDRでResponderからそれが検証メッセージを必要とするかどうかを示します。
KEMAC = E(encr_key, {TGK}) || MAC
KEMACはE(encr_キー、TGK)と等しいです。|| Mac
The KEMAC payload contains a set of encrypted sub-payloads and a MAC. Each sub-payload includes a TGK randomly and independently chosen by the Initiator (and other possible related parameters, e.g., the key lifetime). The MAC is a Message Authentication Code covering the entire MIKEY message using the authentication key, auth_key. See Section 6.2 for payload definition and Section 5.2 for an exact definition of the MAC calculation.
KEMACペイロードは1セットの暗号化されたサブペイロードとMACを含んでいます。 それぞれのサブペイロードはInitiator(そして、他の可能な関係パラメータ、例えば、主要な生涯)によって無作為に独自に選ばれたTGKを含んでいます。 MACは主要な認証auth_キーを使用することで全体のマイキーメッセージをカバーするメッセージ立証コードです。 ペイロード定義のためのセクション6.2とMAC計算の正確な定義のためのセクション5.2を見てください。
The main objective of the verification message from the Responder is to obtain mutual authentication. The verification message, V, is a MAC computed over the Responder's entire message, the timestamp (the same as the one that was included in the Initiator's message), and the two parties identities, using the authentication key. See also Section 5.2 for the exact definition of the Verification MAC calculation and Section 6.9 for payload definition.
Responderからの検証メッセージの主な目標は互いの認証を得ることです。 検証メッセージ(V)はResponderの全体のメッセージ、タイムスタンプ(Initiatorのメッセージに含まれていたものと同じ)、および2つのパーティーのアイデンティティに関して計算されたMACです、認証キーを使用して。 また、Verification MAC計算の正確な定義のためのセクション5.2とペイロード定義のためのセクション6.9を見てください。
The ID fields SHOULD be included, but they MAY be left out when it can be expected that the peer already knows the other party's ID (otherwise it cannot look up the pre-shared key). For example, this could be the case if the ID is extracted from SIP.
含まれていて、IDはSHOULDをさばきますが、同輩が既に相手のIDを知る(さもなければ、それはあらかじめ共有されたキーを見上げることができない)と予想できるとき、それらは省かれるかもしれません。 例えば、IDがSIPから抽出されるなら、これはそうであるかもしれません。
It is MANDATORY to implement this method.
それはこのメソッドを実装するMANDATORYです。
Arkko, et al. Standards Track [Page 12] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[12ページ]。
3.2. Public-key encryption
3.2. 公開鍵暗号化
Initiator Responder
創始者応答者
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi], [IDr], {SP},
KEMAC, [CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
I_メッセージ=HDR、T、底ならし革、[IDi| CERTi]、[IDr]、SP、KEMAC、[CHASH]、PKE、SIGNi--->R_メッセージ=、[<--、]、HDR、T、[IDr]、V
As in the previous case, the main objective of the Initiator's message is to transport one or more TGKs and a set of security parameters to the Responder in a secure manner. This is done using an envelope approach where the TGKs are encrypted (and integrity protected) with keys derived from a randomly/pseudo-randomly chosen "envelope key". The envelope key is sent to the Responder encrypted with the public key of the Responder.
先の事件のように、Initiatorのメッセージの主な目標は安全な方法で1TGKsとセキュリティパラメタのセットをResponderに輸送することです。 これがTGKsが暗号化されている(保全は保護されました)ところでaから手当たりしだいに得られたキーで封筒アプローチを使用し終わっている、/、疑似である、無作為である、選ばれた「封筒キー。」 Responderの公開鍵で暗号化されたResponderに封筒キーを送ります。
The PKE contains the encrypted envelope key: PKE = E(PKr, env_key). It is encrypted using the Responder's public key (PKr). If the Responder possesses several public keys, the Initiator can indicate the key used in the CHASH payload (see Section 6.8).
PKEは暗号化された封筒キーを含んでいます: PKEはE(PKr、env_キー)と等しいです。 それは、Responderの公開鍵(PKr)を使用することで暗号化されています。 Responderにいくつかの公開鍵があるなら、InitiatorはCHASHペイロードで使用されるキーを示すことができます(セクション6.8を見てください)。
The KEMAC contains a set of encrypted sub-payloads and a MAC:
KEMACは1セットの暗号化されたサブペイロードとMACを含んでいます:
KEMAC = E(encr_key, IDi || {TGK}) || MAC
KEMACはE(IDi| | encr_キー、TGK)と等しいです。|| Mac
The first payload (IDi) in KEMAC is the identity of the Initiator (not a certificate, but generally the same ID as the one specified in the certificate). Each of the following payloads (TGK) includes a TGK randomly and independently chosen by the Initiator (and possible other related parameters, e.g., the key lifetime). The encrypted part is then followed by a MAC, which is calculated over the KEMAC payload. The encr_key and the auth_key are derived from the envelope key, env_key, as specified in Section 4.1.4. See also Section 6.2 for payload definition.
KEMACにおける最初のペイロード(IDi)はInitiatorのアイデンティティ(証明書ではなく、一般にものと同じIDが証明書で指定した)です。 それぞれの以下のペイロード(TGK)はInitiator(そして、他の可能な関係パラメータ、例えば、主要な生涯)によって無作為に独自に選ばれたTGKを含んでいます。 そして、暗号化された部分はMACによって続かれています。(MACはKEMACペイロードの上計算されます)。 封筒キー、セクション4.1.4における指定されるとして主要なenv_からencr_キーとauth_キーを得ます。 また、ペイロード定義に関してセクション6.2を見てください。
The SIGNi is a signature covering the entire MIKEY message, using the Initiator's signature key (see also Section 5.2 for the exact definition).
SIGNiは全体のマイキーメッセージをカバーする署名です、Initiatorの署名キーを使用して(また、正確な定義に関してセクション5.2を見てください)。
The main objective of the verification message from the Responder is to obtain mutual authentication. As the verification message V from the Responder is optional, the Initiator indicates in the HDR whether it requires a verification message or not from the Responder. V is calculated in the same way as in the pre-shared key mode (see also Section 5.2 for the exact definition). See Section 6.9 for payload definition.
Responderからの検証メッセージの主な目標は互いの認証を得ることです。 Responderからの検証メッセージVが任意であるので、Initiatorは、HDRでResponderからそれが検証メッセージを必要とするかどうかを示します。 同様に、Vはあらかじめ共有された主要なモードのように計算されます(また、正確な定義に関してセクション5.2を見てください)。 ペイロード定義に関してセクション6.9を見てください。
Arkko, et al. Standards Track [Page 13] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[13ページ]。
Note that there will be one encrypted IDi and possibly also one unencrypted IDi. The encrypted one is used together with the MAC as a countermeasure for certain man-in-the-middle attacks, while the unencrypted one is always useful for the Responder to immediately identify the Initiator. The encrypted IDi MUST always be verified to be equal with the expected IDi.
1暗号化されたIDiとことによるとまた、1unencrypted IDiがあることに注意してください。 暗号化されたものはある介入者攻撃にMACと共に対策として使用されます、ResponderがすぐにInitiatorを特定するように、非暗号化されたものがいつも役に立ちますが。 予想されたIDiと対等にあるようにいつも暗号化されたIDiについて確かめなければなりません。
It is possible to cache the envelope key, so that it can be used as a pre-shared key. It is not recommended for this key to be cached indefinitely (however it is up to the local policy to decide this). This function may be very convenient during the lifetime of a CSB, if a new crypto session needs to be added (or an expired one removed). Then, the pre-shared key can be used, instead of the public keys (see also Section 4.5). If the Initiator indicates that the envelope key should be cached, the key is at least to be cached during the lifetime of the entire CSB.
封筒キーをキャッシュするのは、あらかじめ共有されたキーとしてそれを使用できるくらい可能です。 このキーがそれが無期限にキャッシュされることが勧められません(しかしながら、これについて決めるのはローカルの方針まで達しています)。 この機能はCSBの生涯非常に便利であるかもしれません、新しい暗号セッションが、加えられる必要があるなら(満期のものは取り外されました)。 そして、公開鍵の代わりにあらかじめ共有されたキーを使用できます(また、セクション4.5を見てください)。 Initiatorが、封筒キーがキャッシュされるべきであるのを示すなら、キーは全体のCSBの生涯少なくともキャッシュされることになっています。
The cleartext ID fields and certificate SHOULD be included, but they MAY be left out when it can be expected that the peer already knows the other party's ID, or can obtain the certificate in some other manner. For example, this could be the case if the ID is extracted from SIP.
cleartext ID分野と証明書SHOULDは含まれています、同輩が既に相手のIDを知ると予想できるとき、それらだけを省いてもよいということである、またはある他の方法による証明書を入手できます。 例えば、IDがSIPから抽出されるなら、これはそうであるかもしれません。
For certificate handling, authorization, and policies, see Section 4.3.
証明書取り扱い、承認、および方針に関しては、セクション4.3を見てください。
It is MANDATORY to implement this method.
それはこのメソッドを実装するMANDATORYです。
3.3. Diffie-Hellman key exchange
3.3. ディフィー-ヘルマンの主要な交換
For a fixed, agreed upon, cyclic group, (G,*), we let g denote a generator for this group. Choices for the parameters are given in Section 4.2.7. The other transforms below are described in Section 4.2.
循環群に同意されて、固定されたa、(G、*)に関しては、私たちはgにこのグループのためにジェネレータを指示させます。 セクション4.2.7でパラメタのための選択を与えます。 以下での他の変換はセクション4.2で説明されます。
This method creates a DH-key, which is used as the TGK. This method cannot be used to create group keys; it can only be used to create single peer-to-peer keys. It is OPTIONAL to implement this method.
このメソッドはDH-キーを作成します。(それは、TGKとして使用されます)。 グループキーを作成するのにこのメソッドを使用できません。 単一のピアツーピアキーを作成するのにそれを使用できるだけです。 それはこのメソッドを実装するOPTIONALです。
Initiator Responder
創始者応答者
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],[IDr]
{SP}, DHi, SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr], IDi,
DHr, DHi, SIGNr
I_メッセージ=HDR、T、底ならし革、[IDi| CERTi]、[IDr]SP、DHi、SIGNi--->R_メッセージ=<。--- HDR、T、[IDr| CERTr]、IDi、DHr、DHi、SIGNr
Arkko, et al. Standards Track [Page 14] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[14ページ]。
The main objective of the Initiator's message is to, in a secure way, provide the Responder with its DH value (DHi) g^(xi), where xi MUST be randomly/pseudo-randomly and secretly chosen, and a set of security protocol parameters.
Initiatorのメッセージの主な目標が安全な方法で、ξが手当たりしだいにそうであるに違いないDH価値(DHi)のg^(ξ)をResponderに提供することである、/、疑似である、無作為である、そして、セキュリティプロトコルパラメタの秘かに選ばれて、aセット。
The SIGNi is a signature covering the Initiator's MIKEY message, I_MESSAGE, using the Initiator's signature key (see Section 5.2 for the exact definition).
SIGNiはInitiatorのマイキーメッセージをカバーする署名です、I_MESSAGE、Initiatorの署名キーを使用して(正確な定義に関してセクション5.2を見てください)。
The main objective of the Responder's message is to, in a secure way, provide the Initiator with the Responder's value (DHr) g^(xr), where xr MUST be randomly/pseudo-randomly and secretly chosen. The timestamp that is included in the answer is the same as the one included in the Initiator's message.
Responderのメッセージの主な目標が安全な方法で、xrが手当たりしだいにそうであるに違いないResponderの値(DHr)のg^(xr)をInitiatorに提供することである、/、疑似である、無作為である、そして、秘かに選ばれています。 答えに含まれているタイムスタンプはInitiatorのメッセージにものを含んでいるのと同じです。
The SIGNr is a signature covering the Responder's MIKEY message, R_MESSAGE, using the Responder's signature key (see Section 5.2 for the exact definition).
SIGNrはResponderのマイキーメッセージをカバーする署名です、R_MESSAGE、Responderの署名キーを使用して(正確な定義に関してセクション5.2を見てください)。
The DH group parameters (e.g., the group G, the generator g) are chosen by the Initiator and signaled to the Responder. Both parties calculate the TGK, g^(xi*xr) from the exchanged DH-values.
DHグループパラメタ(例えば、グループG、ジェネレータg)は、Initiatorによって選ばれていて、Responderに合図されます。 双方は交換されたDH-値からTGK、g^(ξ*xr)について計算します。
Note that this approach does not require that the Initiator has to possess any of the Responder's certificates before the setup. Instead, it is sufficient that the Responder includes its signing certificate in the response.
このアプローチが、InitiatorにはResponderの証明書のどれかがセットアップの前になければならないのを必要としないことに注意してください。 代わりに、Responderが応答に署名証明書を含んでいるのは、十分です。
The ID fields and certificate SHOULD be included, but they MAY be left out when it can be expected that the peer already knows the other party's ID (or can obtain the certificate in some other manner). For example, this could be the case if the ID is extracted from SIP.
同輩が既に、相手のID(または、ある他の方法による証明書を入手できる)を知ると予想できるとき、ID分野と証明書SHOULDが含まれていて、それらだけを省いてもよいです。 例えば、IDがSIPから抽出されるなら、これはそうであるかもしれません。
For certificate handling, authorization, and policies, see Section 4.3.
証明書取り扱い、承認、および方針に関しては、セクション4.3を見てください。
4. Selected Key Management Functions
4. 選択されたKey Management機能
MIKEY manages symmetric keys in two main ways. First, following key transport or key exchange of TGK(s) (and other parameters) as defined by any of the above three methods, MIKEY maintains a mapping between Data SA identifiers and Data SAs, where the identifiers used depend on the security protocol in question, see Section 4.4. Thus, when the security protocol requests a Data SA, given such a Data SA identifier, an up-to-date Data SA will be obtained. In particular,
マイキーは2つの主な方法で対称鍵を管理します。 まず最初に、上の3つのメソッドのどれかで定義されるようにTGK(s)(そして、他のパラメタ)の主要な輸送か主要な交換に続いて、マイキーはData SA識別子とData SAsの間のマッピングを維持します、とセクション4.4は見ます。そこでは、使用される識別子が問題のセキュリティプロトコルによります。 したがって、そのようなData SA識別子を考えて、セキュリティプロトコルがData SAを要求すると、最新のData SAを入手するでしょう。 特に
Arkko, et al. Standards Track [Page 15] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[15ページ]。
correct keying material, TEK(s), might need to be derived. The derivation of TEK(s) (and other keying material) is done from a TGK and is described in Section 4.1.3.
材料(TEK(s))が引き出されるために必要とするかもしれない合わせることを修正してください。 TEK(s)(そして、他の合わせることの材料)の派生をTGKからして、セクション4.1.3で説明します。
Second, for use within MIKEY itself, two key management procedures are needed:
2番目に、マイキー自身の中の使用において、2つのかぎ管理手順が必要です:
* in the pre-shared case, deriving encryption and authentication key
material from a single pre-shared key, and
* そしてシングルから暗号化と認証の主要な材料を得るとあらかじめ共有された場合では、キーがあらかじめ共有された。
* in the public key case, deriving similar key material from the
transported envelope key.
* 同様の主要な材料に輸送された封筒キーに由来している公開鍵場合で。
These two key derivation methods are specified in section 4.1.4.
これらの2つの主要な誘導法がセクション4.1.4で指定されます。
All the key derivation functionality mentioned above is based on a pseudo-random function, defined next.
前記のようにすべての主要な派生の機能性が次に定義された擬似ランダム機能に基づいています。
4.1. Key Calculation
4.1. 主要な計算
In the following, we define a general method (pseudo-random function) to derive one or more keys from a "master" key. This method is used to derive:
以下では、私たちは「マスター」キーから1個以上のキーを得る一般的なメソッド(擬似ランダム機能)を定義します。 このメソッドは派生するのにおいて使用されています:
* TEKs from a TGK and the RAND value,
* TGKとRAND値からのTEKs
* encryption, authentication, or salting key from a pre-shared/
envelope key and the RAND value.
* あらかじめ共有された/封筒キーとRAND値から主要な暗号化、認証、または塩味を付け。
4.1.1. Assumptions
4.1.1. 仮定
We assume that the following parameters are in place:
私たちは、以下のパラメタが適所にあると思います:
csb_id : Crypto Session Bundle ID (32-bits unsigned integer)
cs_id : the Crypto Session ID (8-bits unsigned integer)
RAND : (at least) 128-bit (pseudo-)random bit-string sent by the
Initiator in the initial exchange.
csb_イド: 暗号Session Bundle ID(32ビットの符号のない整数)Cs_イド: Crypto Session ID(8ビットの符号のない整数)RAND: (少なくとも) 初期の交換でInitiatorによって送られた128ビット(疑似な)の無作為のビット列。
The key derivation method has the following input parameters:
主要な誘導法には、以下の入力パラメタがあります:
inkey : the input key to the derivation function
inkey_len : the length in bits of the input key
label : a specific label, dependent on the type of the key to be
derived, the RAND, and the session IDs
outkey_len: desired length in bits of the output key.
inkey: 派生機能inkey_lenに主要な入力: 入力キーラベルのビットの長さ: 特定のラベル、引き出されるべきキーのタイプの上の扶養家族、RAND、およびセッションID outkey_len: 出力キーのビットの必要な長さ。
Arkko, et al. Standards Track [Page 16] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[16ページ]。
The key derivation method has the following output:
主要な誘導法には、以下の出力があります:
outkey: the output key of desired length.
outkey: 必要な長さの出力キー。
4.1.2. Default PRF Description
4.1.2. デフォルトPRF記述
Let HMAC be the SHA-1 based message authentication function, see [HMAC] [SHA-1]. Similarly to [TLS], we define:
HMACがSHA-1のベースの通報認証機能であることをさせてください、そして、[HMAC][SHA-1]を考えてください。 同様に、[TLS]と私たちは以下を定義します。
P (s, label, m) = HMAC (s, A_1 || label) ||
HMAC (s, A_2 || label) || ...
HMAC (s, A_m || label)
where
P(s、ラベル、m)はHMAC(A_1| | s、ラベル)と等しいです。|| HMAC(A_2| | s、ラベル)|| ... HMAC、(A_m| | s、ラベル)どこ
A_0 = label,
A_i = HMAC (s, A_(i-1))
s is a key (defined below)
m is a positive integer (also defined below).
_0=ラベル、A_i=HMAC(s、A_(i-1))sによる主要な(以下では、定義される)mが正の整数(また、以下では、定義される)であるということです。
Values of label depend on the case in which the PRF is invoked, and values are specified in the following for the default PRF. Thus, note that other PRFs later added to MIKEY MAY specify different input parameters.
ラベルの値をPRFが呼び出される場合に依存します、そして、値はデフォルトPRFのための以下で指定されます。 したがって、後でマイキーに加えられた他のPRFsが異なった入力パラメタを指定するかもしれないことに注意してください。
The following procedure describes a pseudo-random function, denoted PRF(inkey,label), based on the above P-function, applied to compute the output key, outkey:
以下の手順は擬似ランダム機能について説明します、とPRF(inkey、ラベル)は指示しました、出力キーを計算するために適用された上のP-機能に基づいて、outkey:
* let n = inkey_len / 256, rounded up to the nearest integer if not
already an integer
* nを最も近い整数か既に整数まで一周したinkey_len / 256との等しさにしてください。
* split the inkey into n blocks, inkey = s_1 || ... || s_n, where *
all s_i, except possibly s_n, are 256 bits each
* inkeyをnブロックに分割してください、そして、inkeyはs_1と等しいです。|| ... || s。*(そこでは、ことによるとsを除いたすべてのs_iがそれぞれ256ビットです)。
* let m = outkey_len / 160, rounded up to the nearest integer if not
already an integer
* 最も近い整数まで一周したm=outkey_len / 160か既に整数をさせてください。
(The values "256" and "160" equals half the input block-size and full output hash size, respectively, of the SHA-1 hash as part of the P- function.)
(値「256」と「160」はP機能の一部としてそれぞれ入力ブロック・サイズと全出力ハッシュサイズの半分とSHA-1ハッシュと等しいです。)
Then, the output key, outkey, is obtained as the outkey_len most significant bits of
そして、_が最上位ビットをlenするoutkeyとして出力キー(outkey)を入手します。
PRF(inkey, label) = P(s_1, label, m) XOR P(s_2, label, m) XOR ...
XOR P(s_n, label, m).
PRF(inkey、ラベル)はP(s_1、ラベル、m)XOR P(s_2、ラベル、m)XORと等しいです… XOR P(s、ラベル、m)。
Arkko, et al. Standards Track [Page 17] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[17ページ]。
4.1.3. Generating keys from TGK
4.1.3. TGKからキーを生成します。
In the following, we describe how keying material is derived from a TGK, thus assuming that a mapping of the Data SA identifier to the correct TGK has already been done according to Section 4.4.
以下では、私たちはTGKから材料を合わせるのをどう得るかを説明します、その結果、セクション4.4によると、既に正しいTGKへのData SA識別子に関するマッピングをしたと仮定します。
The key derivation method SHALL be executed using the above PRF with the following input parameters:
実行された使用が以下の入力パラメタがある上のPRFであったなら誘導法SHALLを合わせてください:
inkey : TGK inkey_len : bit length of TGK label : constant || cs_id || csb_id || RAND outkey_len : bit length of the output key.
inkey: TGK inkey_len: 噛み付いている長さのTGKラベル: 定数|| Cs_イド|| csb_イド|| RAND outkey_len: 出力キーの長さに噛み付きました。
The constant part of label depends on the type of key that is to be generated. The constant 0x2AD01C64 is used to generate a TEK from TGK. If the security protocol itself does not support key derivation for authentication and encryption from the TEK, separate authentication and encryption keys MAY be created directly for the security protocol by replacing 0x2AD01C64 with 0x1B5C7973 and 0x15798CEF respectively, and outkey_len by the desired key-length(s) in each case.
ラベルの一定の一部が発生させていることになっているキーのタイプに頼っています。 一定の0x2AD01C64は、TGKからTEKを生成するのに使用されます。 セキュリティプロトコル自体がTEKから認証と暗号化のための主要な派生をサポートしないなら、別々の認証と暗号化キーは直接それぞれ0x2AD01C64を0x1B5C7973と0x15798CEFに取り替えるのによるセキュリティプロトコル、および必要なキー長に従ったoutkey_lenのためにその都度作成されるかもしれません。
A salt key can be derived from the TGK as well, by using the constant 0x39A2C14B. Note that the Key data sub-payload (Section 6.13) can carry a salt. The security protocol in need of the salt key SHALL use the salt key carried in the Key data sub-payload (in the pre- shared and public-key case), when present. If that is not sent, then it is possible to derive the salt key via the key derivation function, as described above.
また、TGKから一定の0x39A2C14Bを使用することによって、塩のキーを得ることができます。 Keyデータサブペイロード(セクション6.13)が塩を運ぶことができることに注意してください。 セキュリティは塩のキーSHALL使用を必要としてKeyデータサブペイロード(あらかじめ共有されるのと公開鍵場合における)で運ばれた塩のキーについて議定書の中で述べます、存在しているとき。 それが送られないなら、主要な派生機能を通して主要な塩を誘導するのは可能です、上で説明されるように。
The table below summarizes the constant values, used to generate keys from a TGK.
以下のテーブルはTGKからキーを生成するのに使用される恒常価値をまとめます。
constant | derived key from the TGK -------------------------------------- 0x2AD01C64 | TEK 0x1B5C7973 | authentication key 0x15798CEF | encryption key 0x39A2C14B | salting key
定数| TGKから主要な状態で、引き出されます。-------------------------------------- 0x2AD01C64| TEK 0x1B5C7973| 認証の主要な0x15798CEF| 暗号化の主要な0x39A2C14B| キーに塩味を付けさせます。
Table 4.1.3: Constant values for the derivation of keys from TGK.
テーブル4.1.3: TGKからのキーの派生のための恒常価値。
Note that these 32-bit constant values (listed in the table above) are taken from the decimal digits of e (i.e., 2.7182...), where each constant consists of nine decimal digits (e.g., the first nine decimal digits 718281828 = 0x2AD01C64). The strings of nine
これらの32ビットの定数値(上のテーブルでは、記載されている)が各定数が9つの10進数字(例えば、アウトコース10進数字718281828 = 0x2AD01C64)から成るe(すなわち、2.7182…)の10進数字から取られることに注意してください。 9のストリング
Arkko, et al. Standards Track [Page 18] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[18ページ]。
decimal digits are not chosen at random, but as consecutive "chunks" from the decimal digits of e.
10進数字はeの10進数字からの無作為に選ばれませんでしたが、連続した「塊」です。
4.1.4. Generating keys for MIKEY messages from an envelope/pre-shared
key
4.1.4. あらかじめ封筒/共有されたキーからのマイキーメッセージのためにキーを生成します。
This derivation is to form the symmetric encryption key (and salting key) for the encryption of the TGK in the pre-shared key and public key methods. This is also used to derive the symmetric key used for the message authentication code in these messages, and the corresponding verification messages. Hence, this derivation is needed in order to get different keys for the encryption and the MAC (and in the case of the pre-shared key, it will result in fresh key material for each new CSB). The parameters for the default PRF are here:
この派生は左右対称の暗号化あらかじめ共有されたキーと公開鍵における、TGKの暗号化に、主要な(キーに塩味を付けさせて)メソッドを形成することです。 また、これもこれらのメッセージ、および対応する検証メッセージのメッセージ確認コードに使用される対称鍵を引き出すのにおいて使用されています。 したがって、この派生が、暗号化とMACのために異なったキーを手に入れるのに必要です(あらかじめ共有されたキーの場合では、それは新鮮なそれぞれの新しいCSBに、主要な材料をもたらすでしょう)。 デフォルトPRFのためのパラメタがここにあります:
inkey : the envelope key or the pre-shared key inkey_len : the bit length of inkey label : constant || 0xFF || csb_id || RAND outkey_len : desired bit length of the output key.
inkey: 封筒キーかあらかじめ共有された主要なinkey_len: 噛み付いている長さのinkeyラベル: 定数|| 0xFF|| csb_イド|| RAND outkey_len: 出力キーの必要な噛み付いている長さ。
The constant part of label depends on the type of key that is to be generated from an envelope/pre-shared key, as summarized below.
ラベルの一定の一部をあらかじめ封筒/共有されたキーから生成されることになっているキーのタイプに頼っています、以下へまとめられるように。
constant | derived key -------------------------------------- 0x150533E1 | encryption key 0x2D22AC75 | authentication key 0x29B88916 | salt key
定数| 主要な状態で、引き出されます。-------------------------------------- 0x150533E1| 暗号化の主要な0x2D22AC75| 認証の主要な0x29B88916| 塩のキー
Table 4.1.4: Constant values for the derivation of keys from an envelope/pre-shared key.
テーブル4.1.4: あらかじめ封筒/共有されたキーからのキーの派生のための恒常価値。
4.2. Pre-defined Transforms and Timestamp Formats
4.2. 事前に定義された変換とタイムスタンプ形式
This section identifies default transforms for MIKEY. It is mandatory to implement and support the following transforms in the respective case. New transforms can be added in the future (see Section 4.2.9 for further guidelines).
このセクションはマイキーのためにデフォルト変換を特定します。 それぞれの場合における以下の変換を実装して、サポートするのは義務的です。 将来、新しい変換を加えることができます(さらなるガイドラインに関してセクション4.2.9を見てください)。
4.2.1. Hash functions
4.2.1. ハッシュ関数
In MIKEY, it is MANDATORY to implement SHA-1 as the default hash function.
マイキーでは、それはデフォルトハッシュ関数としてSHA-1を実装するMANDATORYです。
Arkko, et al. Standards Track [Page 19] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[19ページ]。
4.2.2. Pseudo-random number generator and PRF
4.2.2. 疑似乱数生成器とPRF
A cryptographically secure random or pseudo-random number generator MUST be used for the generation of the keying material and nonces, e.g., [BMGL]. However, which one to use is implementation specific (as the choice will not affect the interoperability).
Aは暗号で無作為であるか擬似乱数ジェネレータを固定します。合わせることの材料と一回だけの世代例えば、[BMGL]に使用しなければなりません。 しかしながら、どれを使用したらよいかは実装特有です(選択が相互運用性に影響しないので)。
For the key derivations, it is MANDATORY to implement the PRF specified in Section 4.1. Other PRFs MAY be added by writing standard-track RFCs specifying the PRF constructions and their exact use within MIKEY.
主要な派生のために、PRFを実装するMANDATORYがセクション4.1で指定したということです。 他のPRFsは、マイキーの中にPRF構造と彼らの正確な使用を標準の道のRFCs指定に書くことによって、加えられるかもしれません。
4.2.3. Key data transport encryption
4.2.3. 重要なデータ輸送暗号化
The default and mandatory-to-implement key transport encryption is AES in counter mode, as defined in [SRTP], using a 128-bit key as derived in Section 4.1.4, SRTP_PREFIX_LENGTH set to zero, and using the initialization vector
カウンタモードでデフォルトと実装するために義務的な主要な輸送暗号化はAESです、[SRTP]で定義されるように、セクション4.1.4と、LENGTHがゼロに設定するSRTP_PREFIX_と、初期化ベクトルを使用する際に引き出されるように128ビットのキーを使用して
IV = (S XOR (0x0000 || CSB ID || T)) || 0x0000,
IV=(S XOR(0×0000| | CSB ID| | T))|| 0×0000
where S is a 112-bit salting key, also derived as in Section 4.1.4, and where T is the 64-bit timestamp sent by the Initiator.
Sがまた、セクション4.1.4のように引き出された112ビットの塩味を付けキーであり、TがInitiatorによって送られた64ビットのタイムスタンプであるところで。
Note: this restricts the maximum size that can be encrypted to 2^23 bits, which is still enough for all practical purposes [SRTP].
以下に注意してください。 これは2^に23ビット暗号化できる、まだ実際上は十分な最大サイズ[SRTP]を制限します。
The NULL encryption algorithm (i.e., no encryption) can be used (but implementation is OPTIONAL). Note that this MUST NOT be used unless the underlying protocols can guarantee security. The main reason for including this is for specific SIP scenarios, where SDP is protected end-to-end. For this scenario, MIKEY MAY be used with the pre-shared key method, the NULL encryption, and NULL authentication algorithm (see Section 4.2.4) while relying on the security of SIP. Use this option with caution!
NULL暗号化アルゴリズム(すなわち、暗号化がない)を使用できます(実装はOPTIONALです)。 基本的なプロトコルが安全を保障できないならこれを使用してはいけないことに注意してください。 これを含む主な理由は特定のSIPシナリオのためのものです。そこでは、SDPは保護された終わりから終わりです。 このシナリオのために、あらかじめ共有された主要なメソッド、NULL暗号化、およびNULL認証アルゴリズム(セクション4.2.4を見る)でマイキーはSIPのセキュリティを当てにしている間、使用されるかもしれません。 慎重にこのオプションを使用してください!
The AES key wrap function [AESKW] is included as an OPTIONAL implementation method. If the key wrap function is used in the public key method, the NULL MAC is RECOMMENDED to be used, as the key wrap itself will provide integrity of the encrypted content (note though that the NULL MAC SHOULD NOT be used in the pre-shared key case, as the MAC in that case covers the entire message). The 128- bit key and a 64-bit salt, S, are derived in accordance to Section 4.1.4 and the key wrap IV is then set to S.
AESの主要な包装機能[AESKW]はOPTIONAL実装メソッドとして含まれています。 主要な包装機能が公開鍵メソッドで使用されるなら、NULL MACは使用されるべきRECOMMENDEDです、主要な包装自体が暗号化された内容の保全を提供するとき(もっとも、NULL MAC SHOULD NOTがあらかじめ共有されたキーケースに使用されることに注意してください、MACがその場合全体のメッセージをカバーするとき)。 128の噛み付いているキーと64ビットの塩(S)は一致でセクション4.1.4まで誘導されます、そして、次に、主要な包装IVはSに設定されます。
Arkko, et al. Standards Track [Page 20] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[20ページ]。
4.2.4. MAC and Verification Message function
4.2.4. MACとVerification Messageは機能します。
MIKEY uses a 160-bit authentication tag, generated by HMAC with SHA-1 as the MANDATORY implementation method, see [HMAC]. Authentication keys are derived according to Section 4.1.4. Note that the authentication key size SHOULD be equal to the size of the hash function's output (e.g., for HMAC-SHA-1, a 160-bit authentication key is used) [HMAC].
[HMAC]は、マイキーがSHA-1と共にMANDATORY実装メソッドとしてHMACによって生成された160ビットの認証タグを使用するのを見ます。 セクション4.1.4に従って、認証キーは引き出されます。 認証の主要なサイズSHOULDがハッシュ関数の出力のサイズと等しいことに注意してください(例えば、HMAC-SHA-1に関して、160ビットの認証キーは使用されています)[HMAC]。
The NULL authentication algorithm (i.e., no MAC) can be used together with the NULL encryption algorithm (but implementation is OPTIONAL). Note that this MUST NOT be used unless the underlying protocols can guarantee security. The main reason for including this is for specific SIP scenarios, where SDP is protected end-to-end. For this scenario, MIKEY MAY be used with the pre-shared key method and the NULL encryption and authentication algorithm, while relying on the security of SIP. Use this option with caution!
NULL暗号化アルゴリズムと共にNULL認証アルゴリズム(すなわち、MACがない)を使用できます(実装はOPTIONALです)。 基本的なプロトコルが安全を保障できないならこれを使用してはいけないことに注意してください。 これを含む主な理由は特定のSIPシナリオのためのものです。そこでは、SDPは保護された終わりから終わりです。 このシナリオのために、マイキーはSIPのセキュリティを当てにしている間、あらかじめ共有された主要なメソッド、NULL暗号化、および認証アルゴリズムで使用されるかもしれません。 慎重にこのオプションを使用してください!
4.2.5. Envelope Key encryption
4.2.5. 封筒Key暗号化
The public key encryption algorithm applied is defined by, and dependent on the certificate used. It is MANDATORY to support RSA PKCS#1, v1.5, and it is RECOMMENDED to also support RSA OAEP [PSS].
適用された公開鍵暗号化アルゴリズムは、使用される証明書に、定義されていて依存しています。 それはRSA PKCS#が1、v1.5であるとサポートするMANDATORYです、そして、サポートRSA OAEP[PSS]にもRECOMMENDEDです。
4.2.6. Digital Signatures
4.2.6. デジタル署名
The signature algorithm applied is defined by, and dependent on the certificate used. It is MANDATORY to support RSA PKCS#1, v1.5, and it is RECOMMENDED to also support RSA PSS [PSS].
適用された署名アルゴリズムは、使用される証明書に、定義されていて依存しています。 それはRSA PKCS#が1、v1.5であるとサポートするMANDATORYです、そして、サポートRSA PSS[PSS]にもRECOMMENDEDです。
4.2.7. Diffie-Hellman Groups
4.2.7. ディフィー-ヘルマングループ
The Diffie-Hellman key exchange, when supported, uses OAKLEY 5 [OAKLEY] as a mandatory implementation. Both OAKLEY 1 and OAKLEY 2 MAY be used (but these are OPTIONAL implementations).
サポートされると、ディフィー-ヘルマンの主要な交換は義務的な実装としてオークリー5[オークリー]を使用します。 オークリー1とオークリー2の両方が使用されるかもしれません(これらはOPTIONAL実装です)。
See Section 4.2.9 for the guidelines on specifying a new DH Group to be used within MIKEY.
セクション4.2.9を見て、新しいDH Groupを指定することに関するガイドラインはマイキーの中で使用されてください。
4.2.8. Timestamps
4.2.8. タイムスタンプ
The timestamp is as defined in NTP [NTP], i.e., a 64-bit number in seconds relative to 0h on 1 January 1900. An implementation MUST be aware of (and take into account) the fact that the counter will overflow approximately every 136th year. It is RECOMMENDED that the time always be specified in UTC.
タイムスタンプがNTP[NTP](すなわち、1900年1月1日の0hに比例した秒の64ビットの数)で定義されるようにあります。 実装はカウンタがおよそあらゆる136年目にあふれるという(アカウントを連れていってください)事実を知っているに違いありません。 時間がUTCでいつも指定されるのは、RECOMMENDEDです。
Arkko, et al. Standards Track [Page 21] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[21ページ]。
4.2.9. Adding new parameters to MIKEY
4.2.9. 新しいパラメタをマイキーに加えます。
There are two different parameter sets that can be added to MIKEY. The first is a set of MIKEY transforms (needed for the exchange itself), and the second is the Data SAs.
マイキーに加えることができる2つの異なったパラメタセットがあります。 1番目は1セットのマイキー変換(交換自体に必要である)です、そして、2番目はData SAsです。
New transforms and parameters (including new policies) SHALL be added by registering with IANA (according to [RFC2434], see also Section 10) a new number for the concerned payload, and also if necessary, documenting how the new transform/parameter is used. Sometimes it might be enough to point to an already specified document for the usage, e.g., when adding a new, already standardized, hash function.
新しい変換とパラメタ(新しい政策を含んでいる)SHALLが必要ならも、IANA(また、[RFC2434]に従って、セクション10を見る)に関係があるペイロードの新しい数を示すことによって加えられて、どのようにを記録して、新しい変換/パラメタは使用されています。 例えば、新しくて、既に標準化されたハッシュ関数を加えるとき、時々、用法のための既に指定されたドキュメントを示すのは十分であるかもしれません。
In the case of adding a new DH group, the group MUST be specified in a companion standards-track RFC (it is RECOMMENDED that the specified group use the same format as used in [OAKLEY]). A number can then be assigned by IANA for such a group to be used in MIKEY.
新しいDHグループを加える場合では、仲間標準化過程RFCでグループを指定しなければなりません(指定されたグループが同じ形式を使用するのは、[オークリー]で使用されるようにRECOMMENDEDです)。 そして、IANAは、そのようなグループがマイキーで使用されるために数を割り当てることができます。
When adding support for a new data security protocol, the following MUST be specified:
新しいデータ機密保護プロトコルのサポートを加えるとき、以下を指定しなければなりません:
* A map sub-payload (see Section 6.1). This is used to be able to
map a crypto session to the right instance of the data security
protocol and possibly also to provide individual parameters for
each data security protocol.
* 地図サブペイロード(セクション6.1を見ます)。 これは、データ機密保護プロトコルの正しいインスタンスに暗号セッションを写像して、また、ことによるとそれぞれのデータ機密保護プロトコルのための個々のパラメタを提供できるように使用されます。
* A policy payload, i.e., specification of parameters and supported
values.
* すなわち、方針ペイロード、パラメタとサポートしている値の仕様。
* General guidelines of usage.
* 用法に関する一般的ガイドライン。
4.3. Certificates, Policies and Authorization
4.3. 証明書、方針、および承認
4.3.1. Certificate handling
4.3.1. 証明書取り扱い
Certificate handling may involve a number of additional tasks not shown here, and effect the inclusion of certain parts of the message (c.f. [X.509]). However, the following observations can be made:
証明書取り扱いは、ここに示されなかった多くの追加タスクにかかわって、メッセージのある部分の包含に作用するかもしれません。(c. f。 [X.509]). しかしながら、以下の観測をすることができます:
* The Initiator typically has to find the certificate of the
Responder in order to send the first message. If the Initiator
does not already have the Responder's certificate, this may
involve one or more roundtrips to a central directory agent.
* Initiatorは、最初のメッセージを送るためにResponderの証明書を通常見つけなければなりません。 InitiatorにResponderの証明書が既にないなら、これは主要なディレクトリエージェントに1つ以上の往復旅行にかかわるかもしれません。
* It will be possible for the Initiator to omit its own certificate
and rely on the Responder getting this certificate using other
means. However, we only recommend doing this when it is
reasonable to expect that the Responder has cached the certificate
* Initiatorがそれ自身の証明書を省略して、他の手段を使用することでこの証明書を手に入れるResponderを当てにするのは、可能でしょう。 しかしながら、私たちは、Responderが証明書をキャッシュしたと予想するのが妥当であるときに、これをすることを勧めるだけです。
Arkko, et al. Standards Track [Page 22] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[22ページ]。
from a previous connection. Otherwise accessing the certificate
would mean additional roundtrips for the Responder as well.
前の接続から。 そうでなければ、証明書にアクセスすると、追加往復旅行はまた、Responderのために意味するでしょう。
* Verification of the certificates using Certificate Revocation
Lists (CRLs) [X.509] or protocols such as OCSP [OCSP] may be
necessary. All parties in a MIKEY exchange should have a local
policy which dictates whether such checks are made, how they are
made, and how often they are made. Note that performing the
checks may imply additional messaging.
* OCSP[OCSP]などのCertificate Revocation Lists(CRLs)[X.509]かプロトコルを使用する証明書の検証が必要であるかもしれません。 マイキー交換におけるすべてのパーティーには、そのようなチェックをするかどうかと、どのようにそれらを作るか、そして、どれくらいの頻度でそれらを作るかを決めるローカルの方針があるべきです。 チェックを実行すると追加メッセージングが含意されるかもしれないことに注意してください。
4.3.2. Authorization
4.3.2. 承認
In general, there are two different models for making authorization decisions for both the Initiator and the Responder, in the context of the applications targeted by MIKEY:
一般に、両方のための承認決定をInitiatorとResponderにするための2つの異なったモデルがあります、マイキーによって狙われたアプリケーションの文脈で:
* Specific peer-to-peer configuration. The user has configured the
application to trust a specific peer.
* 特定のピアツーピア構成。 ユーザは、特定の同輩を信じるためにアプリケーションを構成しました。
When pre-shared secrets are used, this is pretty much the only
available scheme. Typically, the configuration/entering of the
pre-shared secret is taken to mean that authorization is implied.
プレ共有秘密キーが使用されているとき、これはほとんど唯一の利用可能な体系です。 通常、承認が含意されることを意味するためにプレ共有秘密キーの構成/入ることを取ります。
In some cases, one could also use this with public keys, e.g., if
two peers exchange keys offline and configure them to be used for
the purpose of running MIKEY.
また、いくつかの場合、1つは公開鍵と共にこれを使用するかもしれません、例えば、2人の同輩がマイキーを車で送る目的に使用されるためにキーをオフラインで交換して、それらを構成するなら。
* Trusted root. The user accepts all peers that prove to have a
certificate issued by a specific CA. The granularity of
authorization decisions is not very precise in this method.
* 根を信じました。 ユーザは特定のカリフォルニアに証明書を発行させると判明するすべての同輩を受け入れます。 承認決定の粒状はこのメソッドでそれほど正確ではありません。
In order to make this method possible, all participants in the
MIKEY protocol need to configure one or more trusted roots. The
participants also need to be capable of performing certificate
chain validation, and possibly transfer more than a single
certificate in the MIKEY messages (see also Section 6.7).
このメソッドを可能にするように、マイキープロトコルのすべての関係者が、1つ以上がルーツを信じたのを構成する必要があります。 関係者は、また、証明書チェーン合法化を実行できるのが必要であり、ことによるとマイキーメッセージのただ一つの証明書より移します(また、セクション6.7を見てください)。
In practice, a combination of both mentioned methods might be advantageous. Also, the possibility for a user to explicitly exclude a specific peer (or sub-tree) in a trust chain might be needed.
実際には、両方の組み合わせは、メソッドが有利であるかもしれないと言及しました。 また、ユーザが信頼チェーンで明らかに、特定の同輩(または、下位木)を除く可能性が必要であるかもしれません。
These authorization policies address the MIKEY scenarios a-c of Section 2.1, where the Initiator acts as the group owner and is also the only one that can invite others. This implies that for each Responder, the distributed keys MUST NOT be re-distributed to other parties.
これらの承認方針は、マイキーシナリオが1cのセクション2.1であると扱います。Initiatorはそこのグループの所有者として務めて、また、他のものを招待できる唯一無二です。 これは、各Responderに関して、分配されたキーを相手に再配付してはいけないのを含意します。
Arkko, et al. Standards Track [Page 23] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[23ページ]。
In a many-to-many situation, where the group control functions are distributed (and/or where it is possible to delegate the group control function to others), a means of distributing authorization information about who may be added to the group MUST exist. However, it is out of scope of this document to specify how this should be done.
多くへの多く状況で、だれがグループに追加されるかもしれないかの承認情報を分配する手段は存在しなければなりません。そこでは、集団経営機能が分散されています(集団経営機能を他のものへ代表として派遣するのが可能であるところ)。 しかしながら、これがどのように完了しているべきであるかを指定するために、このドキュメントの範囲の外にそれはあります。
For any broader communication situation, an external authorization infrastructure may be used (following the assumptions of [GKMARCH]).
どんなより広いコミュニケーション状況のためにも、外部の承認インフラストラクチャは使用されるかもしれません([GKMARCH]の仮定に続いて)。
4.3.3. Data Policies
4.3.3. データ方針
Included in the message exchange, policies (i.e., security parameters) for the Data security protocol are transmitted. The policies are defined in a separate payload and are specific to the security protocol (see also Section 6.10). Together with the keys, the validity period of these can also be specified. For example, this can be done with an SPI (or SRTP MKI) or with an Interval (e.g., a sequence number interval for SRTP), depending on the security protocol.
交換処理に含まれていて、Dataセキュリティプロトコルのための方針(すなわち、セキュリティパラメタ)は伝えられます。 方針は、別々のペイロードで定義されて、セキュリティプロトコルに特定です(また、セクション6.10を見てください)。 また、キーと共に、これらの有効期間を指定できます。 例えば、SPI(または、SRTP MKI)かInterval(例えば、SRTPのための一連番号間隔)と共にこれができます、セキュリティプロトコルによって。
New parameters can be added to a policy by documenting how they should be interpreted by MIKEY and by also registering new values in the appropriate name space in IANA. If a completely new policy is needed, see Section 4.2.9 for guidelines.
それらがマイキーによってどう解釈されるべきであるかを記録して、また、IANAの適切な名前スペースに新しい値を示すことによって、新しいパラメタを方針に追加できます。 完全に新しい方針が必要であるなら、ガイドラインに関してセクション4.2.9を見てください。
4.4. Retrieving the Data SA
4.4. データSAを検索します。
The retrieval of a Data SA will depend on the security protocol, as different security protocols will have different characteristics. When adding support for a security protocol to MIKEY, some interface of how the security protocol retrieves the Data SA from MIKEY MUST be specified (together with policies that can be negotiated).
異なったセキュリティプロトコルに異なった特性があるとき、Data SAの検索はセキュリティプロトコルによるでしょう。 セキュリティプロトコルのサポートをマイキーに加えるとき、セキュリティプロトコルがマイキーからData SAをどう検索するかに関するいくつかのインタフェースを指定しなければなりません(交渉できる方針と共に)。
For SRTP, the SSRC (see [SRTP]) is one of the parameters used to retrieve the Data SA (while the MKI may be used to indicate the TGK/TEK used for the Data SA). However, the SSRC is not sufficient. For the retrieval of the Data SA from MIKEY, it is RECOMMENDED that the MIKEY implementation support a lookup using destination network address and port together with SSRC. Note that MIKEY does not send network addresses or ports. One reason for this is that they may not be known in advance. Also, if a NAT exists in-between, problems may arise. When SIP or RTSP is used, the local view of the destination address and port can be obtained from either SIP or RTSP. MIKEY can then use these addresses as the index for the Data SA lookup.
SRTPに関しては、SSRC([SRTP]を見る)はData SAを検索するのに使用されるパラメタの1つ(MKIはData SAに使用されるTGK/TEKを示すのに使用されるかもしれませんが)です。 しかしながら、SSRCは十分ではありません。 マイキーからのData SAの検索のために、マイキー実装がSSRCと共にルックアップが目的地ネットワーク・アドレスを使用して、ポートであるとサポートするのは、RECOMMENDEDです。 マイキーがネットワーク・アドレスかポートを送らないことに注意してください。 この1つの理由はそれらがあらかじめ知られていないかもしれないということです。 中間者、また、NATが存在しているなら、問題は起こるかもしれません。 SIPかRTSPが使用されているとき、SIPかRTSPのどちらかから送付先アドレスとポートのローカルの意見を得ることができます。 そして、マイキーはData SAルックアップにインデックスとしてこれらのアドレスを使用できます。
Arkko, et al. Standards Track [Page 24] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[24ページ]。
4.5. TGK re-keying and CSB updating
4.5. TGK再の合わせるのとCSBアップデート
MIKEY provides a means of updating the CSB (e.g., transporting a new TGK/TEK or adding a new Crypto Session to the CSB). The updating of the CSB is done by executing MIKEY again, for example, before a TEK expires, or when a new Crypto Session is added to the CSB. Note that MIKEY does not provide re-keying in the GKMARCH sense, only updating of the keys by normal unicast messages.
マイキーはCSB(例えば、新しいTGK/TEKを輸送するか、または新しいCrypto SessionをCSBに加える)をアップデートする手段を提供します。 再び、例えばマイキーを処刑することによって、CSBのアップデートをします、TEKが期限が切れる前か新しいCrypto SessionがCSBに加えられるときに時。 マイキーが正常なユニキャストメッセージでGKMARCH意味における再の合わせるキーのアップデートだけを提供しないことに注意してください。
When MIKEY is executed again to update the CSB, it is not necessary to include certificates and other information that was provided in the first exchange, for example, all payloads that are static or optionally included may be left out (see Figure 4.1).
マイキーがCSBをアップデートするために再び処刑されるとき、第一交換に提供された証明書と他の情報を含むのは必要でない、例えば、すべての静的であるか任意に含まれているペイロードが置かれるかもしれません(図4.1を見てください)。
The new message exchange MUST use the same CSB ID as the initial exchange, but MUST use a new timestamp. A new RAND MUST NOT be included in the message exchange (the RAND will only have effect in the Initial exchange). If desired, new Crypto Sessions are added in the update message. Note that a MIKEY update message does not need to contain new keying material (e.g., new TGK). In this case, the crypto session continues to use the previously established keying material, while updating the new information.
新しい交換処理は、初期の交換と同じCSB IDを使用しなければなりませんが、新しいタイムスタンプを使用しなければなりません。 新しいRAND MUST NOT、交換処理で含められてください(RANDには、Initial交換における効果があるだけでしょう)。 望まれているなら、新しいCryptoセッションズはアップデートメッセージで加えられます。 マイキーアップデートメッセージが新しい合わせることの材料(例えば、新しいTGK)を含む必要はないことに注意してください。 この場合、暗号セッションは、新情報をアップデートする間、以前に確立した合わせることの材料を使用し続けています。
As explained in Section 3.2, the envelope key can be "cached" as a pre-shared key (this is indicated by the Initiator in the first message sent). If so, the update message is a pre-shared key message with the cached envelope key as the pre-shared key; it MUST NOT be a public key message. If the public key message is used, but the envelope key is not cached, the Initiator MUST provide a new encrypted envelope key that can be used in the verification message. However, the Initiator does not need to provide any other keys.
セクション3.2で説明されるように、あらかじめ共有されたキーとして封筒キーを「キャッシュできる」(これは送られた最初のメッセージでInitiatorによって示されます)。 そうだとすれば、アップデートメッセージはあらかじめ共有されたキーとして主要なキャッシュされた封筒があるあらかじめ共有された主要なメッセージです。 それは公開鍵メッセージであるはずがありません。 公開鍵メッセージが使用されていますが、封筒キーがキャッシュされないなら、Initiatorは検証メッセージで使用できる新しい暗号化された封筒キーを提供しなければなりません。 しかしながら、Initiatorはいかなる他のキーも提供する必要はありません。
Figure 4.1 visualizes the update messages that can be sent, including the optional parts. The main difference from the original message is that it is optional to include TGKs (or DH values in the DH method). Also see Section 3 for more details on the specific methods.
図4.1 オプショナル・パーツを含んでいて、送ることができるアップデートメッセージを想像します。 オリジナルのメッセージからの主な違いはTGKs(または、DHメソッドによるDH値)を含んでいるのが任意であるということです。 また、特定のメソッドに関するその他の詳細に関してセクション3を見てください。
By definition, a CSB can contain several CSs. A problem that then might occur is to synchronize the TGK re-keying if an SPI (or similar functionality, e.g., MKI in [SRTP]) is not used. It is therefore RECOMMENDED that an SPI or MKI be used, if more than one CS is present.
定義上、CSBは数個のCSsを含むことができます。 次に起こるかもしれない問題はSPI(または、同様の機能性、例えば、[SRTP]のMKI)が使用されていないならTGK再の合わせることを連動させることです。 したがって、1CSが存在しているなら、SPIかMKIが使用されるのは、RECOMMENDEDです。
Arkko, et al. Standards Track [Page 25] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[25ページ]。
Initiator Responder
創始者応答者
Pre-shared key method:
あらかじめ共有された主要なメソッド:
I_MESSAGE =
HDR, T, [IDi], [IDr], {SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
I_メッセージ=HDR、T、[IDi]、[IDr]、SP、KEMAC--->R_メッセージ=、[<--、]、HDR、T、[IDr]、V
Public key method:
公開鍵メソッド:
I_MESSAGE =
HDR, T, [IDi|CERTi], [IDr], {SP},
[KEMAC], [CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
I_メッセージ=HDR、T、[IDi| CERTi]、[IDr]、SP、[KEMAC]、[CHASH]、PKE、SIGNi--->R_メッセージ=、[<--、]、HDR、T、[IDr]、V
DH method:
DHメソッド:
I_MESSAGE =
HDR, T, [IDi|CERTi], [IDr], {SP},
[DHi], SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr], IDi,
[DHr, DHi], SIGNr
SIGNi、I_は=HDR、T、[IDi| CERTi]、[IDr]、SP[DHi]を通信させます。--->R_メッセージ=<。--- HDR、T、[IDr| CERTr]、IDi[DHr、DHi]、SIGNr
Figure 4.1: Update messages.
図4.1: メッセージをアップデートしてください。
Note that for the DH method, if the Initiator includes the DHi payload, then the Responder MUST include DHr and DHi. If the Initiator does not include DHi, the Responder MUST NOT include DHr or DHi.
InitiatorがDHiペイロードを含んでいるならDHメソッドのために、ResponderがDHrとDHiを含まなければならないことに注意してください。 InitiatorがDHiを含んでいないなら、ResponderはDHrかDHiを含んではいけません。
5. Behavior and message handling
5. 振舞いとメッセージハンドリング
Each message that is sent by the Initiator or the Responder is built by a set of payloads. This section describes how messages are created and also when they can be used.
InitiatorかResponderによって送られる各メッセージは1セットのペイロードによって築き上げられます。 このセクションは、どのようにメッセージを作成するか、そして、また、いつそれらを使用できるかを説明します。
5.1. General
5.1. 一般
5.1.1. Capability Discovery
5.1.1. 能力発見
The Initiator indicates the security policy to be used (i.e., in terms of security protocol algorithms). If the Responder does not support it (for some reason), the Responder can together with an error message (indicating that it does not support the parameters), send back its own capabilities (negotiation) to let the Initiator
Initiatorは、使用される(すなわち、セキュリティプロトコルアルゴリズムで)ために安全保障政策を示します。 Responderがそれ(ある理由で)をサポートしないなら、Responderはエラーメッセージ(パラメタをサポートしないのを示す)と共に戻ることができて、Initiatorをさせるそれ自身の能力(交渉)を返送します。
Arkko, et al. Standards Track [Page 26] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[26ページ]。
choose a common set of parameters. This is done by including one or more security policy payloads in the error message sent in response (see Section 5.1.2.). Multiple attributes can be provided in sequence in the response. This is done to reduce the number of roundtrips as much as possible (i.e., in most cases, where the policy is accepted the first time, one roundtrip is enough). If the Responder does not accept the offer, the Initiator must go out with a new MIKEY message.
一般的なセットのパラメタを選んでください。 応答で送られたエラーメッセージの1個以上の安全保障政策ペイロードを含んでいることによって、これをします(.2にセクション5.1を見てください)。 複数の属性を連続して応答に提供できます。 往復旅行の数をできるだけ減少させるためにこれをします(すなわち、多くの場合、1つの往復旅行が1回目に方針を受け入れるところで十分です)。 Responderが申し出を受け入れないなら、Initiatorは新しいマイキーメッセージと外に出なければなりません。
If the Responder is not willing/capable of providing security or the parties simply cannot agree, it is up to the parties' policies how to behave, for example, accepting or rejecting an insecure communication.
Responderが望まない、セキュリティを提供できませんし、またパーティーが絶対に同意できないなら、それは、どう振る舞うか例えば、受諾をパーティーの方針に上げるか、または不安定なコミュニケーションを拒絶することです。
Note that it is not the intention of this protocol to have a broad variety of options, as it is assumed that a denied offer should rarely occur.
それがこのプロトコルには広いバラエティーのオプションがあるという意志でないことに注意してください、否定された申し出がめったに起こるべきでないと思われるとき。
In the one-to-many and many-to-many scenarios using multicast communication, one issue is of course that there MUST be a common security policy for all the receivers. This limits the possibility of negotiation.
マルチキャストコミュニケーションを使用する多くへの1と多くへの多くシナリオでは、1冊はもちろん、すべての受信機のための共通の安全保障方針があるに違いないということです。 これは交渉の可能性を制限します。
5.1.2. Error Handling
5.1.2. エラー処理
Due to the key management protocol, all errors SHOULD be reported to the peer(s) by an error message. The Initiator SHOULD therefore always be prepared to receive such a message from the Responder.
かぎ管理プロトコル、すべての誤りSHOULDがエラーメッセージによって同輩に報告されますか? Initiator SHOULD、したがって、いつもResponderからそのようなメッセージを受け取るように用意してください。
If the Responder does not support the set of parameters suggested by the Initiator, the error message SHOULD include the supported parameters (see also Section 5.1.1).
ResponderがInitiatorによって勧められたパラメタのセットを支えないなら、エラーメッセージSHOULDはサポートしているパラメタを含んでいます(また、セクション5.1.1を見てください)。
The error message is formed as:
エラーメッセージは以下として形成されます。
HDR, T, {ERR}, {SP}, [V|SIGNr]
SP、HDR(T)は間違えます。[V| SIGNr]
Note that if failure is due to the inability to authenticate the peer, the error message is OPTIONAL, and does not need to be authenticated. It is up to local policy to determine how to treat this kind of message. However, if in response to a failed authentication a signed error message is returned, this can be used for DoS purposes (against the Responder). Similarly, an unauthenticated error message could be sent to the Initiator in order to fool the Initiator into tearing down the CSB. It is highly RECOMMENDED that the local policy take this into consideration. Therefore, in case of authentication failure, one recommendation would be not to authenticate such an error message, and when
失敗が同輩を認証できないことのためであるなら、エラーメッセージがOPTIONALであり、認証される必要はないことに注意してください。 この種類に関するメッセージを扱う方法を決定するのはローカルの方針まで達しています。 しかしながら、失敗した認証に対応して署名しているエラーメッセージを返すなら、DoS目的(Responderに対する)にこれを使用できます。 同様に、InitiatorがCSBを取りこわすようにだますために非認証されたエラーメッセージをInitiatorに送ることができました。 それが非常にそうである、RECOMMENDED、ローカルの方針はこれを考慮に入れます。 したがって、認証失敗の場合に、1つの推薦はそのようなエラーメッセージ、およびいつを認証しないだろうかことです。
Arkko, et al. Standards Track [Page 27] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[27ページ]。
receiving an unauthenticated error message view it only as a recommendation of what may have gone wrong.
非認証されたエラーメッセージを受け取って、何が支障をきたしたかもしれないかに関する推薦であるとそれだけをみなしてください。
5.2. Creating a message
5.2. メッセージを作成します。
To create a MIKEY message, a Common Header payload is first created. This payload is then followed, depending on the message type, by a set of information payloads (e.g., DH-value payload, Signature payload, Security Policy payload). The defined payloads and the exact encoding of each payload are described in Section 6.
マイキーメッセージを作成するために、Common Headerペイロードは最初に、作成されます。 次に、このペイロードは続かれています、メッセージタイプに頼っていて、1セットの情報ペイロード(例えば、DH-値のペイロード、Signatureペイロード、Security Policyペイロード)に従って。 定義されたペイロードとそれぞれのペイロードの正確なコード化はセクション6で説明されます。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! version ! data type ! next payload ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +
~ Common Header... ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload 1 ... !
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload x ... !
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MAC/Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1、+++++++++++++++++++++++++++++++++! バージョン! データ型!次のペイロード!+++++++++++++++++++++++++… + ~一般的なヘッダー… ~ ! ! +++++++++++++++++++++++++++++++++! 次のペイロード!有効搭載量1… ! +-+-+-+-+-+-+-+-+ + ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +++++++++++++++++++++++++++++++++! 次のペイロード!有効搭載量x… ! 署名
Figure 5.1. MIKEY payload message example. Note that the payloads are byte aligned and not 32-bit aligned.
図5.1。 マイキーペイロードメッセージの例。 ペイロードがバイトであるというメモは並びました、そして、32ビットは並びませんでした。
The process of generating a MIKEY message consists of the following steps:
マイキーメッセージを生成するプロセスは以下のステップから成ります:
* Create an initial MIKEY message starting with the Common Header
payload.
* Common Headerペイロードから始まる初期のマイキーメッセージを作成してください。
* Concatenate necessary payloads of the MIKEY message (see the
exchange definitions for payloads that may be included, and the
recommended order).
* マイキーメッセージの必要なペイロードを連結してください(含まれるかもしれないペイロード、およびお勧めの注文のための交換定義を見てください)。
* As a last step (for messages that must be authenticated, this also
includes the verification message), create and concatenate the
MAC/signature payload without the MAC/signature field filled in
* 最後のステップ(また、認証しなければならないメッセージに関して、これは検証メッセージを含んでいる)で、記入されたMAC/署名分野なしでMAC/署名ペイロードを作成して、連結してくださいというとき
Arkko, et al. Standards Track [Page 28] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[28ページ]。
(if a Next payload field is included in this payload, it is set to
Last payload).
(Nextペイロード分野がこのペイロードに含まれているなら、それはLastペイロードに設定されます。)
* Calculate the MAC/signature over the entire MIKEY message, except
the MAC/Signature field, and add the MAC/signature in the field.
In the case of the verification message, the Identity_i ||
Identity_r || Timestamp MUST directly follow the MIKEY message in
the Verification MAC calculation. Note that the added identities
and timestamp are identical to those transported in the ID and T
payloads.
* MAC/署名分野を除いて、全体のマイキーメッセージの上のMAC/署名について計算してください、そして、その分野でMAC/署名を加えてください。 検証メッセージ、Identity_iの場合で|| アイデンティティ_r|| タイムスタンプは直接Verification MAC計算におけるマイキーメッセージに従わなければなりません。 加えられたアイデンティティとタイムスタンプがIDとTペイロードで輸送されたものと同じであることに注意してください。
In the public key case, the Key data transport payload is generated by concatenating the IDi with the TGKs. This is then encrypted and placed in the data field. The MAC is calculated over the entire Key data transport payload except the MAC field. Before calculating the MAC, the Next payload field is set to zero.
公開鍵場合では、Keyデータ伝送ペイロードは、TGKsとIDiを連結することによって、生成されます。 これは、データ・フィールドに次に、暗号化されて、置かれます。 MAC分野を除いて、MACは全体のKeyデータ伝送ペイロードの上計算されます。 MACについて計算する前に、Nextペイロード分野はゼロに設定されます。
Note that all messages from the Initiator MUST use a unique timestamp. The Responder does not create a new timestamp, but uses the timestamp used by the Initiator.
Initiatorからのすべてのメッセージがユニークなタイムスタンプを使用しなければならないことに注意してください。 Responderは新しいタイムスタンプを作成しませんが、Initiatorによって使用されたタイムスタンプを使用します。
5.3. Parsing a message
5.3. メッセージを分析します。
In general, parsing of a MIKEY message is done by extracting payload by payload and checking that no errors occur. The exact procedure is implementation specific; however, for the Responder, it is RECOMMENDED that the following procedure be followed:
一般に、ペイロードに従ってペイロードを抽出して、誤りが全く発生しないのをチェックすることによって、マイキーメッセージの構文解析をします。 正確な手順は実装特有です。 しかしながら、Responderに関して、以下の手順が従われているのは、RECOMMENDEDです:
* Extract the Timestamp and check that it is within the allowable
clock skew (if not, discard the message). Also check the replay
cache (Section 5.4) so that the message is not replayed (see
Section 5.4). If the message is replayed, discard it.
* Timestampを抽出してください、そして、許容できる時計斜行の中にそれがあるのをチェックしてください(メッセージを捨ててください)。 また、メッセージが再演されない(セクション5.4を見る)ように、再生キャッシュ(セクション5.4)をチェックしてください。 メッセージが再演されるなら、それを捨ててください。
* Extract the ID and authentication algorithm (if not included,
assume the default).
* IDと認証アルゴリズムを抜粋してください(含まれていないなら、デフォルトを仮定してください)。
* Verify the MAC/signature.
* MAC/署名について確かめてください。
* If the authentication is not successful, an Auth failure Error
message MAY be sent to the Initiator. The message is then
discarded from further processing. See also Section 5.1.2 for
treatment of errors.
* 認証がうまくいかないなら、Auth失敗ErrorメッセージをInitiatorに送るかもしれません。 そして、メッセージはさらなる処理から捨てられます。 また、誤りの処理に関してセクション5.1.2を見てください。
* If the authentication is successful, the message is processed and
also added to the replay cache; processing is implementation
specific. Note also that only successfully authenticated messages
are stored in the replay cache.
* 認証がうまくいくなら、メッセージは、処理されて、また、再生キャッシュに加えられます。 処理は実装特有です。 また、首尾よく認証されたメッセージだけが再生キャッシュで保存されることに注意してください。
Arkko, et al. Standards Track [Page 29] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[29ページ]。
* If any unsupported parameters or errors occur during the
processing, these MAY be reported to the Initiator by sending an
error message. The processing is then aborted. The error message
can also include payloads to describe the supported parameters.
* 何かサポートされないパラメタや誤りが処理の間、発生するなら、これらは発生します。エラーメッセージを送ることによって、Initiatorに報告されます。 そして、処理は中止されます。 また、エラーメッセージは、サポートしているパラメタについて説明するためにペイロードを含むことができます。
* If the processing was successful and in case the Initiator
requested it, a verification/response message MAY be created and
sent to the Initiator.
* 処理がうまくいって、Initiatorがそれを要求するといけなかったので、検証/応答メッセージをInitiatorに作成して、送るかもしれません。
5.4. Replay handling and timestamp usage
5.4. 再生取り扱いとタイムスタンプ用法
MIKEY does not use a challenge-response mechanism for replay handling; instead, timestamps are used. This requires that the clocks are synchronized. The required synchronization is dependent on the number of messages that can be cached (note though, that the replay cache only contains messages that have been successfully authenticated). If we could assume an unlimited cache, the terminals would not need to be synchronized at all (as the cache could then contain all previous messages). However, if there are restrictions on the size of the replay cache, the clocks will need to be synchronized to some extent. In short, one can in general say that it is a tradeoff between the size of the replay cache and the required synchronization.
マイキーは再生取り扱いにチャレンジレスポンスメカニズムを使用しません。 代わりに、タイムスタンプは使用されています。 これは、時計が連動するのを必要とします。 必要な同期はキャッシュできるメッセージの数に依存しています(もっとも、再生キャッシュがそうしたメッセージを含むだけであるのが、首尾よくそうであることに認証されていた状態で注意してください)。 私たちが無制限なキャッシュを仮定できるなら、端末は全く連動する必要はないでしょうに(次に、キャッシュが前のすべてのメッセージを含むことができたとき)。 しかしながら、制限が再生キャッシュのサイズにあると、時計は、ある程度連動する必要があるでしょう。 要するに、一般に、人は、それが再生キャッシュのサイズと必要な同期の間の見返りであると言うことができます。
Timestamp usage prevents replay attacks under the following assumptions:
タイムスタンプ用法は以下の仮定で反射攻撃を防ぎます:
* Each host has a clock which is at least "loosely synchronized"
with the clocks of the other hosts.
* 各ホストは他のホストの時計に少なくとも「緩く連動する」時計を持っています。
* If the clocks are to be synchronized over the network, a secure
network clock synchronization protocol SHOULD be used, e.g.,
[ISO3].
* 時計がそうなら、ネットワーク、安全なネットワーク時計同期プロトコルSHOULDの上で連動するのに、使用されてください、例えば、[ISO3。]
* Each Responder utilizes a replay cache in order to remember the
successfully authenticated messages presented within an allowable
clock skew (which is set by the local policy).
* 各Responderは、許容できる時計斜行(ローカルの方針で設定される)の中に提示された首尾よく認証されたメッセージを覚えているのに再生キャッシュを利用します。
* Replayed and outdated messages, for example, messages that can be
found in the replay cache or which have an outdated timestamp are
discarded and not processed.
* 再演されて時代遅れのメッセージ、例えば、再生キャッシュで見つけることができるか、または時代遅れのタイムスタンプを持っているメッセージが、捨てられて、処理されません。
* If the host loses track of the incoming requests (e.g., due to
overload), it rejects all incoming requests until the clock skew
interval has passed.
* ホストが入って来る要求(例えば、オーバーロードによる)を見失うなら、時計斜行間隔が過ぎるまで、それはすべての入って来る要求を拒絶します。
Arkko, et al. Standards Track [Page 30] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[30ページ]。
In a client-server scenario, servers may encounter a high workload, especially if a replay cache is necessary. However, servers that assume the role of MIKEY Initiators will not need to manage any significant replay cache as they will refuse all incoming messages that are not a response to a message previously sent by the server.
クライアント/サーバシナリオでは、特に再生キャッシュが必要であるなら、サーバは高いワークロードに遭遇するかもしれません。 しかしながら、彼らが以前にサーバによって送られたメッセージへの応答でないすべての入力メッセージを拒否するとき、マイキーInitiatorsの役割を引き受けるサーバはどんな重要な再生キャッシュも管理する必要はないでしょう。
In general, a client may not expect a very high load of incoming messages and may therefore allow the degree of looseness to be on the order of several minutes to hours. If a (D)DoS attack is launched and the replay cache grows too large, MIKEY MAY dynamically decrease the looseness so that the replay cache becomes manageable. However, note that such (D)DoS attacks can only be performed by peers that can authenticate themselves. Hence, such an attack is very easy to trace and mitigate.
一般に、クライアントは、入力メッセージの非常に高い負荷を期待しないで、したがって、数分から何時間もの注文にはゆるみの度合いがあるのを許すかもしれません。 (D)DoS攻撃が進水して、再生キャッシュが大きくなり過ぎるなら、マイキーがゆるみをダイナミックに静まらせるかもしれないので、再生キャッシュは処理しやすくなります。 しかしながら、自分たちを認証できる同輩がそのような(D)DoS攻撃を実行できるだけであることに注意してください。 したがって、たどりやすくて、そのような攻撃は非常に緩和しやすいです。
The maximum number of messages that a client will need to cache may vary depending on the capacity of the client itself and the network. The number of expected messages should be taken into account.
クライアント自身とネットワークの容量によって、クライアントがキャッシュする必要があるメッセージの最大数は異なるかもしれません。 予想されたメッセージの数は考慮に入れられるべきです。
For example, assume that we can at most spend 6kB on a replay cache. Assume further that we need to store 30 bytes for each incoming authenticated message (the hash of the message is 20 bytes). This implies that it is possible to cache approximately 204 messages. If the expected number of messages per minute can be estimated, the clock skew can easily be calculated. For example, in a SIP scenario where the client is expected, in the most extreme case, to receive 10 calls per minute, the clock skew needed is then approximately 20 minutes. In a not so extreme setting, where one could expect an incoming call every 5th minute, this would result in a clock skew on the order of 16.5 hours (approx 1000 minutes).
例えば、私たちが再生キャッシュに6kBを高々費やすことができると仮定してください。 私たちが、それぞれの入って来る認証されたメッセージあたり30バイトを保存する必要であるとさらに仮定してください(メッセージのハッシュは20バイトです)。 これは、およそ204のメッセージをキャッシュするのが可能であることを含意します。 1分あたりのメッセージの予想された数を見積もることができるなら、容易に時計斜行について計算できます。 例えば、クライアントが最も極端な場合で1分あたり10の呼び出しを受けると予想されるSIPシナリオでは、そして、必要である時計斜行はおよそ20分です。 あまりに極端でない設定で。そこでは、ものが、5番目の分あたり1つのかかってきた電話に、これが16.5時間(約1000分)の注文ときに時計斜行をもたらすと予想できました。
Consider a very extreme case, where the maximum number of incoming messages are assumed to be on the order of 120 messages per minute, and a requirement that the clock skew is on the order of 10 minutes, a 48kB replay cache would be required.
非常に極端なケースを考えてください。そこでは、入力メッセージの最大数が1分あたり120のメッセージの注文、および10分の注文には時計斜行があるという要件にあると思われて、48kB再生キャッシュが必要でしょう。
Hence, one can note that the required clock skew will depend largely on the setting in which MIKEY is used. One recommendation is to fix a size for the replay cache, allowing the clock skew to be large (the initial clock skew can be set depending on the application in which it is used). As the replay cache grows, the clock skew is decreased depending on the percentage of the used replay cache. Note that this is locally handled, which will not require interaction with the peer (even though it may indirectly effect the peer). However, exactly how to implement such functionality is out of the scope of this document and considered implementation specific.
したがって、人は、必要な時計斜行を主にマイキーが使用されている設定に依存することに注意できます。 1つの推薦は再生キャッシュのためのサイズを固定することです、時計斜行が大きいのを許容して(それが使用されているアプリケーションによるように初期の時計斜行を設定できます)。 再生キャッシュが成長するのに従って、中古の再生キャッシュの割合によって、時計斜行は減少します。 これ(同輩との相互作用を必要としない)が局所的に扱われることに注意してください(間接的に同輩に作用するかもしれませんが)。 しかしながら、ちょうどどうそのような機能性を実装するかは、このドキュメントの範囲の外にあって、考えられた実装特有です。
Arkko, et al. Standards Track [Page 31] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[31ページ]。
In case of a DoS attack, the client will most likely be able to handle the replay cache. A more likely (and serious) DoS attack is a CPU DoS attack where the attacker sends messages to the peer, which then needs to expend resources on verifying the MACs/signatures of the incoming messages.
DoS攻撃の場合には、クライアントはたぶん再生キャッシュを扱うことができるでしょう。 より多くのありそうで(重大)のDoS攻撃は攻撃者が同輩(次に、入力メッセージのMACs/署名について確かめながらリソースを使う必要がある)にメッセージを送るところのCPU DoS攻撃です。
6. Payload Encoding
6. 有効搭載量コード化
This section describes, in detail, all the payloads. For all encoding, network byte order is always used. While defining supported types (e.g., which hash functions are supported) the mandatory-to-implement types are indicated (as Mandatory), as well as the default types (note, default also implies mandatory implementation). Support for the other types are implicitly assumed to be optional.
このセクションは詳細にすべてのペイロードについて説明します。 すべてのコード化のために、ネットワークバイトオーダーはいつも使用されます。 定義はタイプをサポートしましたが(例えばハッシュ関数がサポートされる)、実装するために義務的なタイプは示されます(Mandatoryとして)、デフォルトタイプと同様に(注意、また、デフォルトは義務的な実装を含意します)。 もう片方のサポートは、任意であるとそれとなく思われるのをタイプします。
In the following, note that the support for SRTP [SRTP] as a security protocol is defined. This will help us better understand the purpose of the different payloads and fields. Other security protocols MAY be specified for use within MIKEY, see Section 10.
以下では、SRTP[SRTP]のサポートがセキュリティが議定書を作ると定義されることに注意してください。 これは、私たちが異なったペイロードと分野の目的を理解しているほうがよいのを助けるでしょう。 セクション10は、他のセキュリティプロトコルがマイキーの中で使用に指定されるかもしれないのを見ます。
In the following, the sign ~ indicates variable length field.
以下では、サイン~は可変長フィールドを示します。
6.1. Common Header payload (HDR)
6.1. 一般的なHeaderペイロード(HDR)
The Common Header payload MUST always be present as the first payload in each message. The Common Header includes a general description of the exchange message.
Common Headerペイロードは各メッセージにおける最初のペイロードとしていつも存在していなければなりません。 Common Headerは交換メッセージの概説を含んでいます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! version ! data type ! next payload !V! PRF func !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! CSB ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! #CS ! CS ID map type! CS ID map info ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1、+++++++++++++++++++++++++++++++++! バージョン! データ型!次のペイロード!V! 写像..タイプ CS ID地図インフォメーション~+++++++++++++++++++++++++++++++++
* version (8 bits): the version number of MIKEY.
* バージョン(8ビット): マイキーのバージョン番号。
version = 0x01 refers to MIKEY as defined in this document.
バージョン=0×01は本書では定義されるマイキーについて言及します。
* data type (8 bits): describes the type of message (e.g., public-
key transport message, verification message, error message).
* data type (8 bits): describes the type of message (e.g., public- key transport message, verification message, error message).
Arkko, et al. Standards Track [Page 32] RFC 3830 MIKEY August 2004
Arkko, et al. Standards Track [Page 32] RFC 3830 MIKEY August 2004
Data type | Value | Comment
--------------------------------------
Pre-shared | 0 | Initiator's pre-shared key message
PSK ver msg | 1 | Verification message of a Pre-shared
| | key message
Public key | 2 | Initiator's public-key transport message
PK ver msg | 3 | Verification message of a public-key
| | message
D-H init | 4 | Initiator's DH exchange message
D-H resp | 5 | Responder's DH exchange message
Error | 6 | Error message
Data type | Value | Comment -------------------------------------- Pre-shared | 0 | Initiator's pre-shared key message PSK ver msg | 1 | Verification message of a Pre-shared | | key message Public key | 2 | Initiator's public-key transport message PK ver msg | 3 | Verification message of a public-key | | message D-H init | 4 | Initiator's DH exchange message D-H resp | 5 | Responder's DH exchange message Error | 6 | Error message
Table 6.1.a
Table 6.1.a
* next payload (8 bits): identifies the payload that is added after
this payload.
* next payload (8 bits): identifies the payload that is added after this payload.
Next payload | Value | Section
------------------------------
Last payload | 0 | -
KEMAC | 1 | 6.2
PKE | 2 | 6.3
DH | 3 | 6.4
SIGN | 4 | 6.5
T | 5 | 6.6
ID | 6 | 6.7
CERT | 7 | 6.7
CHASH | 8 | 6.8
V | 9 | 6.9
SP | 10 | 6.10
RAND | 11 | 6.11
ERR | 12 | 6.12
Key data | 20 | 6.13
General Ext. | 21 | 6.15
Next payload | Value | Section ------------------------------ Last payload | 0 | - KEMAC | 1 | 6.2 PKE | 2 | 6.3 DH | 3 | 6.4 SIGN | 4 | 6.5 T | 5 | 6.6 ID | 6 | 6.7 CERT | 7 | 6.7 CHASH | 8 | 6.8 V | 9 | 6.9 SP | 10 | 6.10 RAND | 11 | 6.11 ERR | 12 | 6.12 Key data | 20 | 6.13 General Ext. | 21 | 6.15
Table 6.1.b
Table 6.1.b
Note that some of the payloads cannot directly follow the header
(such as "Last payload", "Signature"). However, the Next payload
field is generic for all payloads. Therefore, a value is
allocated for each payload. The Next payload field is set to zero
(Last payload) if the current payload is the last payload.
Note that some of the payloads cannot directly follow the header (such as "Last payload", "Signature"). However, the Next payload field is generic for all payloads. Therefore, a value is allocated for each payload. The Next payload field is set to zero (Last payload) if the current payload is the last payload.
* V (1 bit): flag to indicate whether a verification message is
expected or not (this only has meaning when it is set by the
Initiator). The V flag SHALL be ignored by the receiver in the DH
method (as the response is MANDATORY).
* V (1 bit): flag to indicate whether a verification message is expected or not (this only has meaning when it is set by the Initiator). The V flag SHALL be ignored by the receiver in the DH method (as the response is MANDATORY).
Arkko, et al. Standards Track [Page 33] RFC 3830 MIKEY August 2004
Arkko, et al. Standards Track [Page 33] RFC 3830 MIKEY August 2004
V = 0 ==> no response expected
V = 1 ==> response expected
V = 0 ==> no response expected V = 1 ==> response expected
* PRF func (7 bits): indicates the PRF function that has been/will
be used for key derivation.
* PRF func (7 bits): indicates the PRF function that has been/will be used for key derivation.
PRF func | Value | Comments
--------------------------------------------------------
MIKEY-1 | 0 | Mandatory (see Section 4.1.2)
PRF func | Value | Comments -------------------------------------------------------- MIKEY-1 | 0 | Mandatory (see Section 4.1.2)
Table 6.1.c
Table 6.1.c
* CSB ID (32 bits): identifies the CSB. It is RECOMMENDED that the
CSB ID be chosen at random by the Initiator. This ID MUST be
unique between each Initiator-Responder pair, i.e., not globally
unique. An Initiator MUST check for collisions when choosing the
ID (if the Initiator already has one or more established CSBs with
the Responder). The Responder uses the same CSB ID in the
response.
* CSB ID (32 bits): identifies the CSB. It is RECOMMENDED that the CSB ID be chosen at random by the Initiator. This ID MUST be unique between each Initiator-Responder pair, i.e., not globally unique. An Initiator MUST check for collisions when choosing the ID (if the Initiator already has one or more established CSBs with the Responder). The Responder uses the same CSB ID in the response.
* #CS (8 bits): indicates the number of Crypto Sessions that will be
handled within the CBS. Note that even though it is possible to
use 255 CSs, it is not likely that a CSB will include this many
CSs. The integer 0 is interpreted as no CS included. This may be
the case in an initial setup message.
* #CS (8 bits): indicates the number of Crypto Sessions that will be handled within the CBS. Note that even though it is possible to use 255 CSs, it is not likely that a CSB will include this many CSs. The integer 0 is interpreted as no CS included. This may be the case in an initial setup message.
* CS ID map type (8 bits): specifies the method of uniquely mapping
Crypto Sessions to the security protocol sessions.
* CS ID map type (8 bits): specifies the method of uniquely mapping Crypto Sessions to the security protocol sessions.
CS ID map type | Value
-----------------------
SRTP-ID | 0
CS ID map type | Value ----------------------- SRTP-ID | 0
Table 6.1.d
Table 6.1.d
* CS ID map info (16 bits): identifies the crypto session(s) for
which the SA should be created. The currently defined map type is
the SRTP-ID (defined in Section 6.1.1).
* CS ID map info (16 bits): identifies the crypto session(s) for which the SA should be created. The currently defined map type is the SRTP-ID (defined in Section 6.1.1).
Arkko, et al. Standards Track [Page 34] RFC 3830 MIKEY August 2004
Arkko, et al. Standards Track [Page 34] RFC 3830 MIKEY August 2004
6.1.1. SRTP ID
6.1.1. SRTP ID
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_1 ! SSRC_1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC_1 (cont) ! ROC_1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_1 (cont) ! Policy_no_2 ! SSRC_2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC_2 (cont) ! ROC_2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_2 (cont) ! :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_#CS ! SSRC_#CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!SSRC_#CS (cont)! ROC_#CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_#CS (cont)!
+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Policy_no_1 ! SSRC_1 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SSRC_1 (cont) ! ROC_1 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ROC_1 (cont) ! Policy_no_2 ! SSRC_2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SSRC_2 (cont) ! ROC_2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ROC_2 (cont) ! : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Policy_no_#CS ! SSRC_#CS ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !SSRC_#CS (cont)! ROC_#CS ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ROC_#CS (cont)! +-+-+-+-+-+-+-+-+
* Policy_no_i (8 bits): The security policy applied for the stream
with SSRC_i. The same security policy may apply for all CSs.
* Policy_no_i (8 bits): The security policy applied for the stream with SSRC_i. The same security policy may apply for all CSs.
* SSRC_i (32 bits): specifies the SSRC that MUST be used for the
i-th SRTP stream. Note that it is the sender of the streams that
chooses the SSRC. Therefore, it is possible that the Initiator of
MIKEY cannot fill in all fields. In this case, SSRCs that are not
chosen by the Initiator are set to zero and the Responder fills in
these fields in the response message. Note that SRTP specifies
requirements on the uniqueness of the SSRCs (to avoid two-time pad
problems if the same TEK is used for more than one stream) [SRTP].
* SSRC_i (32 bits): specifies the SSRC that MUST be used for the i-th SRTP stream. Note that it is the sender of the streams that chooses the SSRC. Therefore, it is possible that the Initiator of MIKEY cannot fill in all fields. In this case, SSRCs that are not chosen by the Initiator are set to zero and the Responder fills in these fields in the response message. Note that SRTP specifies requirements on the uniqueness of the SSRCs (to avoid two-time pad problems if the same TEK is used for more than one stream) [SRTP].
* ROC_i (32 bits): Current rollover counter used in SRTP. If the
SRTP session has not started, this field is set to 0. This field
is used to enable a member to join and synchronize with an already
started stream.
* ROC_i (32 bits): Current rollover counter used in SRTP. If the SRTP session has not started, this field is set to 0. This field is used to enable a member to join and synchronize with an already started stream.
NOTE: The stream using SSRC_i will also have Crypto Session ID equal to no i (NOT to the SSRC).
NOTE: The stream using SSRC_i will also have Crypto Session ID equal to no i (NOT to the SSRC).
Arkko, et al. Standards Track [Page 35] RFC 3830 MIKEY August 2004
Arkko, et al. Standards Track [Page 35] RFC 3830 MIKEY August 2004
6.2. Key data transport payload (KEMAC)
6.2. Key data transport payload (KEMAC)
The Key data transport payload contains encrypted Key data sub- payloads (see Section 6.13 for the definition of the Key data sub- payload). It may contain one or more Key data payloads, each including, for example, a TGK. The last Key data payload has its Next payload field set to Last payload. For an update message (see also Section 4.5), it is allowed to skip the Key data sub-payloads (which will result in the Encr data len being equal to 0).
The Key data transport payload contains encrypted Key data sub- payloads (see Section 6.13 for the definition of the Key data sub- payload). It may contain one or more Key data payloads, each including, for example, a TGK. The last Key data payload has its Next payload field set to Last payload. For an update message (see also Section 4.5), it is allowed to skip the Key data sub-payloads (which will result in the Encr data len being equal to 0).
Note that the MAC coverage depends on the method used, i.e., pre- shared vs public key, see below.
Note that the MAC coverage depends on the method used, i.e., pre- shared vs public key, see below.
If the transport method used is the pre-shared key method, this Key data transport payload is the last payload in the message (note that the Next payload field is set to Last payload). The MAC is then calculated over the entire MIKEY message following the directives in Section 5.2.
If the transport method used is the pre-shared key method, this Key data transport payload is the last payload in the message (note that the Next payload field is set to Last payload). The MAC is then calculated over the entire MIKEY message following the directives in Section 5.2.
If the transport method used is the public-key method, the Initiator's identity is added in the encrypted data. This is done by adding the ID payload as the first payload, which is then followed by the Key data sub-payloads. Note that for an update message, the ID is still sent encrypted to the Responder (this is to avoid certain re-direction attacks) even though no Key data sub-payload is added after.
If the transport method used is the public-key method, the Initiator's identity is added in the encrypted data. This is done by adding the ID payload as the first payload, which is then followed by the Key data sub-payloads. Note that for an update message, the ID is still sent encrypted to the Responder (this is to avoid certain re-direction attacks) even though no Key data sub-payload is added after.
In the public-key case, the coverage of the MAC field is over the Key data transport payload only, instead of the complete MIKEY message, as in the pre-shared case. The MAC is therefore calculated over the Key data transport payload, except for the MAC field and where the Next payload field has been set to zero (see also Section 5.2).
In the public-key case, the coverage of the MAC field is over the Key data transport payload only, instead of the complete MIKEY message, as in the pre-shared case. The MAC is therefore calculated over the Key data transport payload, except for the MAC field and where the Next payload field has been set to zero (see also Section 5.2).
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Encr alg ! Encr data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Mac alg ! MAC ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next payload ! Encr alg ! Encr data len ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Encr data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Mac alg ! MAC ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for defined values.
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for defined values.
* Encr alg (8 bits): the encryption algorithm used to encrypt the
Encr data field.
* Encr alg (8 bits): the encryption algorithm used to encrypt the Encr data field.
Arkko, et al. Standards Track [Page 36] RFC 3830 MIKEY August 2004
Arkko, et al. Standards Track [Page 36] RFC 3830 MIKEY August 2004
Encr alg | Value | Comment
-------------------------------------------
NULL | 0 | Very restricted usage, see Section 4.2.3!
AES-CM-128 | 1 | Mandatory; AES-CM using a 128-bit key, see
Section 4.2.3)
AES-KW-128 | 2 | AES Key Wrap using a 128-bit key, see
Section 4.2.3
Encr alg | Value | Comment ------------------------------------------- NULL | 0 | Very restricted usage, see Section 4.2.3! AES-CM-128 | 1 | Mandatory; AES-CM using a 128-bit key, see Section 4.2.3) AES-KW-128 | 2 | AES Key Wrap using a 128-bit key, see Section 4.2.3
Table 6.2.a
Table 6.2.a
* Encr data len (16 bits): length of Encr data (in bytes).
* Encr data len (16 bits): length of Encr data (in bytes).
* Encr data (variable length): the encrypted key sub-payloads (see
Section 6.13).
* Encr data (variable length): the encrypted key sub-payloads (see Section 6.13).
* MAC alg (8 bits): specifies the authentication algorithm used.
* MAC alg (8 bits): specifies the authentication algorithm used.
MAC alg | Value | Comments | Length (bits)
----------------------------------------------------------
NULL | 0 | restricted usage | 0
| | Section 4.2.4 |
HMAC-SHA-1-160 | 1 | Mandatory, | 160
| | Section 4.2.4 |
MAC alg | Value | Comments | Length (bits) ---------------------------------------------------------- NULL | 0 | restricted usage | 0 | | Section 4.2.4 | HMAC-SHA-1-160 | 1 | Mandatory, | 160 | | Section 4.2.4 |
Table 6.2.b
Table 6.2.b
* MAC (variable length): the message authentication code of the
entire message.
* MAC (variable length): the message authentication code of the entire message.
6.3. Envelope data payload (PKE)
6.3. Envelope data payload (PKE)
The Envelope data payload contains the encrypted envelope key that is used in the public-key transport to protect the data in the Key data transport payload. The encryption algorithm used is implicit from the certificate/public key used.
The Envelope data payload contains the encrypted envelope key that is used in the public-key transport to protect the data in the Key data transport payload. The encryption algorithm used is implicit from the certificate/public key used.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! C ! Data len ! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! C ! Data len ! Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* C (2 bits): envelope key cache indicator (Section 3.2).
* C (2 bits): envelope key cache indicator (Section 3.2).
Arkko, et al. Standards Track [Page 37] RFC 3830 MIKEY August 2004
Arkko, et al. Standards Track [Page 37] RFC 3830 MIKEY August 2004
Cache type | Value | Comments
--------------------------------------
No cache | 0 | The envelope key MUST NOT be cached
Cache | 1 | The envelope key MUST be cached
Cache for CSB | 2 | The envelope key MUST be cached, but only
| | to be used for the specific CSB.
Table 6.3
Cache type | Value | Comments -------------------------------------- No cache | 0 | The envelope key MUST NOT be cached Cache | 1 | The envelope key MUST be cached Cache for CSB | 2 | The envelope key MUST be cached, but only | | to be used for the specific CSB. Table 6.3
* Data len (14 bits): the length of the data field (in bytes).
* Data len (14 bits): the length of the data field (in bytes).
* Data (variable length): the encrypted envelope key.
* Data (variable length): the encrypted envelope key.
6.4. DH data payload (DH)
6.4. DH data payload (DH)
The DH data payload carries the DH-value and indicates the DH-group used. Notice that in this sub-section, "MANDATORY" is conditioned upon DH being supported.
The DH data payload carries the DH-value and indicates the DH-group used. Notice that in this sub-section, "MANDATORY" is conditioned upon DH being supported.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! DH-Group ! DH-value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Reserv! KV ! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! DH-Group ! DH-value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Reserv! KV ! KV data (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* DH-Group (8 bits): identifies the DH group used.
* DH-Group (8 bits): identifies the DH group used.
DH-Group | Value | Comment | DH Value length (bits)
--------------------------------------|---------------------
OAKLEY 5 | 0 | Mandatory | 1536
OAKLEY 1 | 1 | | 768
OAKLEY 2 | 2 | | 1024
DH-Group | Value | Comment | DH Value length (bits) --------------------------------------|--------------------- OAKLEY 5 | 0 | Mandatory | 1536 OAKLEY 1 | 1 | | 768 OAKLEY 2 | 2 | | 1024
Table 6.4
Table 6.4
* DH-value (variable length): the public DH-value (the length is
implicit from the group used).
* DH-value (variable length): the public DH-value (the length is implicit from the group used).
* KV (4 bits): indicates the type of key validity period specified.
This may be done by using an SPI (alternatively an MKI in SRTP) or
by providing an interval in which the key is valid (e.g., in the
latter case, for SRTP this will be the index range where the key
is valid). See Section 6.13 for pre-defined values.
* KV (4 bits): indicates the type of key validity period specified. This may be done by using an SPI (alternatively an MKI in SRTP) or by providing an interval in which the key is valid (e.g., in the latter case, for SRTP this will be the index range where the key is valid). See Section 6.13 for pre-defined values.
Arkko, et al. Standards Track [Page 38] RFC 3830 MIKEY August 2004
Arkko, et al. Standards Track [Page 38] RFC 3830 MIKEY August 2004
* KV data (variable length): This includes either the SPI/MKI or an
interval (see Section 6.14). If KV is NULL, this field is not
included.
* KV data (variable length): This includes either the SPI/MKI or an interval (see Section 6.14). If KV is NULL, this field is not included.
6.5. Signature payload (SIGN)
6.5. Signature payload (SIGN)
The Signature payload carries the signature and its related data. The signature payload is always the last payload in the PK transport and DH exchange messages. The signature algorithm used is implicit from the certificate/public key used.
The Signature payload carries the signature and its related data. The signature payload is always the last payload in the PK transport and DH exchange messages. The signature algorithm used is implicit from the certificate/public key used.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! S type| Signature len ! Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! S type| Signature len ! Signature ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* S type (4 bits): indicates the signature algorithm applied by the
signer.
* S type (4 bits): indicates the signature algorithm applied by the signer.
S type | Value | Comments
-------------------------------------
RSA/PKCS#1/1.5| 0 | Mandatory, PKCS #1 version 1.5 signature
[PSS]
RSA/PSS | 1 | RSASSA-PSS signature [PSS]
S type | Value | Comments ------------------------------------- RSA/PKCS#1/1.5| 0 | Mandatory, PKCS #1 version 1.5 signature [PSS] RSA/PSS | 1 | RSASSA-PSS signature [PSS]
Table 6.5
Table 6.5
* Signature len (12 bits): the length of the signature field (in
bytes).
* Signature len (12 bits): the length of the signature field (in bytes).
* Signature (variable length): the signature (its formatting and
padding depend on the type of signature).
* Signature (variable length): the signature (its formatting and padding depend on the type of signature).
6.6. Timestamp payload (T)
6.6. Timestamp payload (T)
The timestamp payload carries the timestamp information.
The timestamp payload carries the timestamp information.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! TS type ! TS value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! TS type ! TS value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* TS type (8 bits): specifies the timestamp type used.
* TS type (8 bits): specifies the timestamp type used.
Arkko, et al. Standards Track [Page 39] RFC 3830 MIKEY August 2004
Arkko, et al. Standards Track [Page 39] RFC 3830 MIKEY August 2004
TS type | Value | Comments | length of TS value
-------------------------------------|-------------------
NTP-UTC | 0 | Mandatory | 64-bits
NTP | 1 | Mandatory | 64-bits
COUNTER | 2 | Optional | 32-bits
TS type | Value | Comments | length of TS value -------------------------------------|------------------- NTP-UTC | 0 | Mandatory | 64-bits NTP | 1 | Mandatory | 64-bits COUNTER | 2 | Optional | 32-bits
Table 6.6
Table 6.6
Note: COUNTER SHALL be padded (with leading zeros) to a 64-bit
value when used as input for the default PRF.
Note: COUNTER SHALL be padded (with leading zeros) to a 64-bit value when used as input for the default PRF.
* TS-value (variable length): The timestamp value of the specified
TS type.
* TS-value (variable length): The timestamp value of the specified TS type.
6.7. ID payload (ID) / Certificate Payload (CERT)
6.7. ID payload (ID) / Certificate Payload (CERT)
Note that the ID payload and the Certificate payload are two completely different payloads (having different payload identifiers). However, as they share the same payload structure, they are described in the same section.
Note that the ID payload and the Certificate payload are two completely different payloads (having different payload identifiers). However, as they share the same payload structure, they are described in the same section.
The ID payload carries a uniquely defined identifier.
The ID payload carries a uniquely defined identifier.
The certificate payload contains an indicator of the certificate provided as well as the certificate data. If a certificate chain is to be provided, each certificate in the chain should be included in a separate CERT payload.
The certificate payload contains an indicator of the certificate provided as well as the certificate data. If a certificate chain is to be provided, each certificate in the chain should be included in a separate CERT payload.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! ID/Cert Type ! ID/Cert len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID/Certificate Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! ID/Cert Type ! ID/Cert len ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID/Certificate Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
If the payload is an ID payload, the following values apply for the ID type field:
If the payload is an ID payload, the following values apply for the ID type field:
* ID Type (8 bits): specifies the identifier type used.
* ID Type (8 bits): specifies the identifier type used.
Arkko, et al. Standards Track [Page 40] RFC 3830 MIKEY August 2004
Arkko, et al. Standards Track [Page 40] RFC 3830 MIKEY August 2004
ID Type | Value | Comments
----------------------------------------------
NAI | 0 | Mandatory (see [NAI])
URI | 1 | Mandatory (see [URI])
ID Type | Value | Comments ---------------------------------------------- NAI | 0 | Mandatory (see [NAI]) URI | 1 | Mandatory (see [URI])
Table 6.7.a
Table 6.7.a
If the payload is a Certificate payload, the following values applies for the Cert type field:
If the payload is a Certificate payload, the following values applies for the Cert type field:
* Cert Type (8 bits): specifies the certificate type used.
* Cert Type (8 bits): specifies the certificate type used.
Cert Type | Value | Comments
----------------------------------------------
X.509v3 | 0 | Mandatory
X.509v3 URL | 1 | plain ASCII URL to the location of the Cert
X.509v3 Sign | 2 | Mandatory (used for signatures only)
X.509v3 Encr | 3 | Mandatory (used for encryption only)
Cert Type | Value | Comments ---------------------------------------------- X.509v3 | 0 | Mandatory X.509v3 URL | 1 | plain ASCII URL to the location of the Cert X.509v3 Sign | 2 | Mandatory (used for signatures only) X.509v3 Encr | 3 | Mandatory (used for encryption only)
Table 6.7.b
Table 6.7.b
* ID/Cert len (16 bits): the length of the ID or Certificate field
(in bytes).
* ID/Cert len (16 bits): the length of the ID or Certificate field (in bytes).
* ID/Certificate (variable length): The ID or Certificate data. The
X.509 [X.509] certificates are included as a bytes string using
DER encoding as specified in X.509.
* ID/Certificate (variable length): The ID or Certificate data. The X.509 [X.509] certificates are included as a bytes string using DER encoding as specified in X.509.
6.8. Cert hash payload (CHASH)
6.8. Cert hash payload (CHASH)
The Cert hash payload contains the hash of the certificate used.
The Cert hash payload contains the hash of the certificate used.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Hash func ! Hash ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! Hash func ! Hash ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* Hash func (8 bits): indicates the hash function that is used (see
also Section 4.2.1).
* Hash func (8 bits): indicates the hash function that is used (see also Section 4.2.1).
Arkko, et al. Standards Track [Page 41] RFC 3830 MIKEY August 2004
Arkko, et al. Standards Track [Page 41] RFC 3830 MIKEY August 2004
Hash func | Value | Comment | hash length (bits)
-------------------------------------------------
SHA-1 | 0 | Mandatory | 160
MD5 | 1 | | 128
Hash func | Value | Comment | hash length (bits) ------------------------------------------------- SHA-1 | 0 | Mandatory | 160 MD5 | 1 | | 128
Table 6.8
Table 6.8
* Hash (variable length): the hash data. The hash length is
implicit from the hash function used.
* Hash (variable length): the hash data. The hash length is implicit from the hash function used.
6.9. Ver msg payload (V)
6.9. Ver msg payload (V)
The Ver msg payload contains the calculated verification message in the pre-shared key and the public-key transport methods. Note that the MAC is calculated over the entire MIKEY message, as well as the IDs and Timestamp (see also Section 5.2).
The Ver msg payload contains the calculated verification message in the pre-shared key and the public-key transport methods. Note that the MAC is calculated over the entire MIKEY message, as well as the IDs and Timestamp (see also Section 5.2).
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Auth alg ! Ver data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! Auth alg ! Ver data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
* Auth alg (8 bits): specifies the MAC algorithm used for the
verification message. See Section 6.2 for defined values.
* Auth alg (8 bits): specifies the MAC algorithm used for the verification message. See Section 6.2 for defined values.
* Ver data (variable length): the verification message data. The
length is implicit from the authentication algorithm used.
* Ver data (variable length): the verification message data. The length is implicit from the authentication algorithm used.
6.10. Security Policy payload (SP)
6.10. Security Policy payload (SP)
The Security Policy payload defines a set of policies that apply to a specific security protocol.
The Security Policy payload defines a set of policies that apply to a specific security protocol.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Policy no ! Prot type ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ length (cont) ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next payload ! Policy no ! Prot type ! Policy param ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ length (cont) ! Policy param ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
* Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
Arkko, et al. Standards Track [Page 42] RFC 3830 MIKEY August 2004
Arkko, et al. Standards Track [Page 42] RFC 3830 MIKEY August 2004
* Policy no (8 bits): each security policy payload must be given a
distinct number for the current MIKEY session by the local peer.
This number is used to map a crypto session to a specific policy
(see also Section 6.1.1).
* Policy no (8 bits): each security policy payload must be given a distinct number for the current MIKEY session by the local peer. This number is used to map a crypto session to a specific policy (see also Section 6.1.1).
* Prot type (8 bits): defines the security protocol.
* Prot type (8 bits): defines the security protocol.
Prot type | Value |
---------------------------
SRTP | 0 |
Prot type | Value | --------------------------- SRTP | 0 |
Table 6.10
Table 6.10
* Policy param length (16 bits): defines the total length of the
policy parameters for the specific security protocol.
* Policy param length (16 bits): defines the total length of the policy parameters for the specific security protocol.
* Policy param (variable length): defines the policy for the
specific security protocol.
* Policy param (variable length): defines the policy for the specific security protocol.
The Policy param part is built up by a set of Type/Length/Value
fields. For each security protocol, a set of possible
types/values that can be negotiated is defined.
The Policy param part is built up by a set of Type/Length/Value fields. For each security protocol, a set of possible types/values that can be negotiated is defined.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Length ! Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type ! Length ! Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Type (8 bits): specifies the type of the parameter.
* Type (8 bits): specifies the type of the parameter.
* Length (8 bits): specifies the length of the Value field (in
bytes).
* Length (8 bits): specifies the length of the Value field (in bytes).
* Value (variable length): specifies the value of the parameter.
* Value (variable length): specifies the value of the parameter.
Arkko, et al. Standards Track [Page 43] RFC 3830 MIKEY August 2004
Arkko, et al. Standards Track [Page 43] RFC 3830 MIKEY August 2004
6.10.1. SRTP policy
6.10.1. SRTP policy
This policy specifies the parameters for SRTP and SRTCP. The types/values that can be negotiated are defined by the following table:
This policy specifies the parameters for SRTP and SRTCP. The types/values that can be negotiated are defined by the following table:
Type | Meaning | Possible values
----------------------------------------------------
0 | Encryption algorithm | see below
1 | Session Encr. key length | depends on cipher used
2 | Authentication algorithm | see below
3 | Session Auth. key length | depends on MAC used
4 | Session Salt key length | see [SRTP] for recommendations
5 | SRTP Pseudo Random Function | see below
6 | Key derivation rate | see [SRTP] for recommendations
7 | SRTP encryption off/on | 0 if off, 1 if on
8 | SRTCP encryption off/on | 0 if off, 1 if on
9 | sender's FEC order | see below
10 | SRTP authentication off/on | 0 if off, 1 if on
11 | Authentication tag length | in bytes
12 | SRTP prefix length | in bytes
Type | Meaning | Possible values ---------------------------------------------------- 0 | Encryption algorithm | see below 1 | Session Encr. key length | depends on cipher used 2 | Authentication algorithm | see below 3 | Session Auth. key length | depends on MAC used 4 | Session Salt key length | see [SRTP] for recommendations 5 | SRTP Pseudo Random Function | see below 6 | Key derivation rate | see [SRTP] for recommendations 7 | SRTP encryption off/on | 0 if off, 1 if on 8 | SRTCP encryption off/on | 0 if off, 1 if on 9 | sender's FEC order | see below 10 | SRTP authentication off/on | 0 if off, 1 if on 11 | Authentication tag length | in bytes 12 | SRTP prefix length | in bytes
Table 6.10.1.a
Table 6.10.1.a
Note that if a Type/Value is not set, the default is used (according to SRTP's own criteria). Note also that, if "Session Encr. key length" is set, this should also be seen as the Master key length (otherwise, the SRTP default Master key length is used).
Note that if a Type/Value is not set, the default is used (according to SRTP's own criteria). Note also that, if "Session Encr. key length" is set, this should also be seen as the Master key length (otherwise, the SRTP default Master key length is used).
For the Encryption algorithm, a one byte length is enough. The currently defined possible Values are:
For the Encryption algorithm, a one byte length is enough. The currently defined possible Values are:
SRTP encr alg | Value
---------------------
NULL | 0
AES-CM | 1
AES-F8 | 2
SRTP encr alg| 値--------------------- ヌル| 0AES-CM| 1 AES-F8| 2
Table 6.10.1.b
テーブル6.10.1.b
where AES-CM is AES in CM, and AES-F8 is AES in f8 mode [SRTP].
AES-CMがCMのAESであり、f8モード[SRTP]でAES-F8がAESであるところ。
Arkko, et al. Standards Track [Page 44] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[44ページ]。
For the Authentication algorithm, a one byte length is enough. The currently defined possible Values are:
Authenticationアルゴリズムにおいて、1バイトの長さは十分です。 現在定義された可能なValuesは以下の通りです。
SRTP auth alg | Value
---------------------
NULL | 0
HMAC-SHA-1 | 1
SRTP auth alg| 値--------------------- ヌル| 0 HMAC-SHA-1| 1
Table 6.10.1.c
テーブル6.10.1.c
For the SRTP pseudo-random function, a one byte length is also enough. The currently defined possible Values are:
また、SRTP擬似ランダム機能において、1バイトの長さも十分です。 現在定義された可能なValuesは以下の通りです。
SRTP PRF | Value
---------------------
AES-CM | 0
SRTP PRF| 値--------------------- AES-CM| 0
Table 6.10.1.d
テーブル6.10.1.d
If FEC is used at the same time SRTP is used, MIKEY can negotiate the order in which these should be applied at the sender side.
FECがSRTPが使用されている同時代に使用されるなら、マイキーはこれらが送付者側で適用されるべきであるオーダーを交渉できます。
FEC order | Value | Comments
--------------------------------
FEC-SRTP | 0 | First FEC, then SRTP
FECオーダー| 値| コメント-------------------------------- FEC-SRTP| 0 | 最初に、FEC、当時のSRTP
Table 6.10.1.e
テーブル6.10.1.e
6.11. RAND payload (RAND)
6.11. RANDペイロード(底ならし革)
The RAND payload consists of a (pseudo-)random bit-string. The RAND MUST be independently generated per CSB (note that if the CSB has several members, the Initiator MUST use the same RAND for all the members). For randomness recommendations for security, see [RAND].
RANDペイロードは(疑似な)無作為のビット列から成ります。 RAND MUSTは独自にそうです。CSB(CSBに数人のメンバーがいるなら、Initiatorがすべてのメンバーに同じRANDを使用しなければならないことに注意する)単位で発生しています。 セキュリティのための偶発性推薦に関しては、[RAND]を見てください。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! RAND len ! RAND ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1、+++++++++++++++++++++++++++++++++! Nextペイロード!RAND len!RAND~+++++++++++++++++++++++++++++++++
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
* 次のペイロード(8ビット): 次々と加えられるこのペイロードを特定します。 値に関してセクション6.1を見てください。
* RAND len (8 bits): length of the RAND (in bytes). It SHOULD be at
least 16.
* RAND len(8ビット): RAND(バイトによる)の長さ。 SHOULDは少なくともそうです。それ、16。
* RAND (variable length): a (pseudo-)randomly chosen bit-string.
* RAND(可変長): 手当たりしだいに選ばれた(疑似な)ビット列。
Arkko, et al. Standards Track [Page 45] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[45ページ]。
6.12. Error payload (ERR)
6.12. 誤りペイロード(間違えます)
The Error payload is used to specify the error(s) that may have occurred.
Errorペイロードは、発生したかもしれない誤りを指定するのに使用されます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Error no ! Reserved !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1、+++++++++++++++++++++++++++++++++! Next有効搭載量!Errorノー!Reserved!+++++++++++++++++++++++++++++++++
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
* 次のペイロード(8ビット): 次々と加えられるこのペイロードを特定します。 値に関してセクション6.1を見てください。
* Error no (8 bits): indicates the type of error that was
encountered.
* 誤りノー(8ビット): 遭遇した誤りのタイプを示します。
Error no | Value | Comment
-------------------------------------------------------
Auth failure | 0 | Authentication failure
Invalid TS | 1 | Invalid timestamp
Invalid PRF | 2 | PRF function not supported
Invalid MAC | 3 | MAC algorithm not supported
Invalid EA | 4 | Encryption algorithm not supported
Invalid HA | 5 | Hash function not supported
Invalid DH | 6 | DH group not supported
Invalid ID | 7 | ID not supported
Invalid Cert | 8 | Certificate not supported
Invalid SP | 9 | SP type not supported
Invalid SPpar | 10 | SP parameters not supported
Invalid DT | 11 | not supported Data type
Unspecified error | 12 | an unspecified error occurred
誤りノー| 値| コメント------------------------------------------------------- Authの故障| 0 | 認証失敗Invalid TS| 1 | 無効のタイムスタンプInvalid PRF| 2 | Invalid MACであることはサポートされなかったPRF機能| 3 | Invalid EAであることはサポートされなかったMACアルゴリズム| 4 | Invalid HAであることはサポートされなかった暗号化アルゴリズム| 5 | Invalid DHであることはサポートされなかったハッシュ関数| 6 | Invalid IDであることはサポートされなかったDHグループ| 7 | Invalid CertであることはサポートされなかったID| 8 | Invalid SPであることは支えられなかった証明書| 9 | Invalid SPparであることはサポートされなかったSPタイプ| 10 | Invalid DTであることはサポートされなかったSPパラメタ| 11 | DataタイプUnspecified誤りであることはサポートされません。| 12 | 不特定の誤りは発生しました。
Table 6.12
テーブル6.12
6.13. Key data sub-payload
6.13. 重要なデータサブペイロード
The Key data payload contains key material, e.g., TGKs. The Key data payloads are never included in clear, but as an encrypted part of the Key data transport payload.
Keyデータペイロードは主要な材料、例えばTGKsを含んでいます。 Keyデータペイロードは中に決してはっきりと含まれていませんが、Keyデータの暗号化された部分として、ペイロードを輸送してください。
Note that a Key data transport payload can contain multiple Key data sub-payloads.
Keyデータ伝送ペイロードが複数のKeyデータサブペイロードを含むことができることに注意してください。
Arkko, et al. Standards Track [Page 46] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[46ページ]。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Type ! KV ! Key data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Salt len (optional) ! Salt data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1、+++++++++++++++++++++++++++++++++! Next有効搭載量!Type!KV!Keyデータlen!+++++++++++++++++++++++++++++++++! Keyデータ~; 任意..データ..任意..データ..任意
* Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
* 次のペイロード(8ビット): 次々と加えられるこのペイロードを特定します。 値に関してセクション6.1を見てください。
* Type (4 bits): indicates the type of key included in the payload.
* タイプしてください(4ビット): ペイロードにキーを含むタイプを示します。
Type | Value
-----------------
TGK | 0
TGK+SALT | 1
TEK | 2
TEK+SALT | 3
タイプ| 値----------------- TGK| 0 TGK+塩| 1 TEK| 2 TEK+塩| 3
Table 6.13.a
テーブル6.13.a
Note that the possibility of including a TEK (instead of using the
TGK) is provided. When sent directly, the TEK can generally not
be shared between more than one Crypto Session (unless the
Security protocol allows for this, e.g., [SRTP]). The recommended
use of sending a TEK, instead of a TGK, is when pre-encrypted
material exists and therefore, the TEK must be known in advance.
TEK(TGKを使用することの代わりに)を含んでいる可能性が提供されることに注意してください。 直接送ると、一般に、1Crypto SessionよりTEKを平等に割り当てることができません(Securityプロトコルがこの、例えば、[SRTP]を考慮しない場合)。 TGKの代わりに、TEKを送ることのお勧めの使用はあらかじめ暗号化された材料が存在する時、そして、したがって、あらかじめ、TEKを知っていなければなりません。
* KV (4 bits): indicates the type of key validity period specified.
This may be done by using an SPI (or MKI in the case of [SRTP]) or
by providing an interval in which the key is valid (e.g., in the
latter case, for SRTP this will be the index range where the key
is valid).
* kV(4ビット): 主要な有効期間のタイプが指定したのを示します。 SPI(または、[SRTP]の場合におけるMKI)を使用するか、またはキーが有効である間隔を提供することによって、これをするかもしれません(例えば、後者の場合では、SRTPに関して、これはインデックス範囲になるでしょうキーが有効である)。
Arkko, et al. Standards Track [Page 47] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[47ページ]。
KV | Value | Comments
-------------------------------------------
Null | 0 | No specific usage rule (e.g., a TEK
| | that has no specific lifetime)
SPI | 1 | The key is associated with the SPI/MKI
Interval | 2 | The key has a start and expiration time
| | (e.g., an SRTP TEK)
kv| 値| コメント------------------------------------------- ヌル| 0 | 特定の用法規則(例えば、TEK| | それには、どんな特定の寿命もない)SPIがありません。| 1 | キーはSPI/MKI Intervalに関連しています。| 2 | キーには、始めと満了時間があります。| | (例えば、SRTP TEK)
Table 6.13.b
テーブル6.13.b
Note that when NULL is specified, any SPI or Interval is valid.
For an Interval, this means that the key is valid from the first
observed sequence number until the key is replaced (or the
security protocol is shutdown).
NULLが指定されるとき、どんなSPIやIntervalも有効であることに注意してください。 Intervalに関しては、これは、キーが最初の観測された一連番号からキーを取り替えるまで(セキュリティプロトコルは閉鎖です)有効であることを意味します。
* Key data len (16 bits): the length of the Key data field (in
bytes). Note that the sum of the overall length of all the Key
data payloads contained in a single Key data transport payload
(KEMAC) MUST be such that the KEMAC payload does not exceed a
length of 2^16 bytes (total length of KEMAC, see Section 6.2).
* 重要なデータlen(16ビット): Keyデータ・フィールド(バイトによる)の長さ。 KEMACペイロードがただ一つのKeyデータ伝送ペイロード(KEMAC)に含まれたすべてのKeyデータペイロードの全長がそのようなものであるに違いないので2^16バイトの長さを超えていないことに注意してください、(全長、KEMACでは、セクション6.2を見てください、)
* Key data (variable length): The TGK or TEK data.
* 重要なデータ(可変長): TGKかTEKデータ。
* Salt len (16 bits): The salt key length in bytes. Note that this
field is only included if the salt is specified in the Type-field.
* len(16ビット)に塩味を付けさせてください: バイトで表現される塩のキー長。 塩がType-分野で指定される場合にだけこの分野が含まれていることに注意してください。
* Salt data (variable length): The salt key data. Note that this
field is only included if the salt is specified in the Type-field.
(For SRTP, this is the so-called master salt.)
* データ(可変長)に塩味を付けさせてください: 塩の重要データ。 塩がType-分野で指定される場合にだけこの分野が含まれていることに注意してください。 (SRTPに関して、これはいわゆるマスター塩です。)
* KV data (variable length): This includes either the SPI or an
interval (see Section 6.14). If KV is NULL, this field is not
included.
* kV、データ(可変長): これはSPIか間隔のどちらかを含んでいます(セクション6.14を見てください)。 KVがNULLであるなら、この分野は含まれていません。
6.14. Key validity data
6.14. 主要な正当性データ
The Key validity data is not a standalone payload, but part of either the Key data payload (see Section 6.13) or the DH payload (see Section 6.4). The Key validity data gives a guideline of when the key should be used. There are two KV types defined (see Section 6.13), SPI/MKI (SPI) or a lifetime range (interval).
Key正当性データはスタンドアロンペイロードではなく、Keyデータペイロード(セクション6.13を見る)かDHペイロードのどちらかの一部(セクション6.4を見る)です。 Key正当性データはキーが使用されるべきである時に関するガイドラインを与えます。 KVタイプが定義した2(セクション6.13を見る)、SPI/MKI(SPI)または生涯範囲(間隔)があります。
Arkko, et al. Standards Track [Page 48] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[48ページ]。
SPI/MKI
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI Length ! SPI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SPI/MKI1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+++++++++++++++++++++++++++++++++! SPI長さ!のSPI~+++++++++++++++++++++++++++++++++
* SPI Length (8 bits): the length of the SPI (or MKI) in bytes.
* SPI Length(8ビット): バイトで表現されるSPI(または、MKI)の長さ。
* SPI (variable length): the SPI (or MKI) value.
* SPI(可変長): SPI(または、MKI)値。
Interval
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VF Length ! Valid From ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VT Length ! Valid To (expires) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
間隔..長さ..有効..バーモント..長さ..有効..吐き出す
* VF Length (8 bits): length of the Valid From field in bytes.
* VF Length(8ビット): バイトで表現されるValid From分野の長さ。
* Valid From (variable length): sequence number, index, timestamp,
or other start value that the security protocol uses to identify
the start position of the key usage.
* 有効なFrom(可変長): 一連番号、インデックス、タイムスタンプ、または他の始めが、セキュリティが主要な用法のスタート位置を特定するために用途について議定書の中で述べるのを評価します。
* VT Length (8 bits): length of the Valid To field in bytes.
* バーモントLength(8ビット): バイトで表現されるValid To分野の長さ。
* Valid To (variable length): sequence number, index, timestamp, or
other expiration value that the security protocol can use to
identify the expiration of the key usage.
* 有効なTo(可変長): 一連番号、インデックス、タイムスタンプ、またはセキュリティプロトコルが主要な用法の満了を特定するのに使用できる他の満了値。
Note that for SRTP usage, the key validity period for a TGK/TEK
should be specified with either an interval, where the VF/VT
Length is equal to 6 bytes (i.e., the size of the index), or with
an MKI. It is RECOMMENDED that if more than one SRTP stream is
sharing the same keys and key update/re-keying is desired, this is
handled using MKI rather than the From-To method.
SRTP用法として、TGK/TEKに、主要な有効期間がVF/バーモントLengthが6バイト(すなわち、インデックスのサイズ)と等しい間隔かMKIと共に指定されるべきであることに注意してください。 それが1つ以上のSRTPストリームが同じキーを共有して、再のアップデート/合わせることであるなら主要な望まれているRECOMMENDEDである、これがむしろMKIを使用することで扱われる、From、-、メソッド
Arkko, et al. Standards Track [Page 49] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[49ページ]。
6.15. General Extension Payload
6.15. 一般拡大有効搭載量
The General extensions payload is included to allow possible extensions to MIKEY without the need for defining a completely new payload each time. This payload can be used in any MIKEY message and is part of the authenticated/signed data part.
一般拡大ペイロードは、その都度完全に新しいペイロードを定義する必要性なしで可能な拡大をマイキーに許すために含まれています。 このペイロードは、どんなマイキーメッセージでも使用できて、認証されたか署名しているデータ部分の一部です。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ペイロード
* Next payload (8 bits): identifies the payload that is added after
this payload.
* 次のペイロード(8ビット): 次々と加えられるこのペイロードを特定します。
* Type (8 bits): identifies the type of general payload.
* タイプしてください(8ビット): 一般的なペイロードのタイプを特定します。
Type | Value | Comments
---------------------------------------
Vendor ID | 0 | Vendor specific byte string
SDP IDs | 1 | List of SDP key mgmt IDs (allocated for use in
[KMASDP])
タイプ| 値| コメント--------------------------------------- ベンダーID| 0 | ベンダーの特定のバイトストリングSDP ID| 1 | SDPの主要な管理IDのリスト([KMASDP]における使用のために、割り当てます)
Table 6.15
テーブル6.15
* Length (16 bits): the length in bytes of the Data field.
* 長さ(16ビット): Data分野のバイトで表現される長さ。
* Data (variable length): the general payload data.
* データ(可変長): 一般的なペイロードデータ。
7. Transport protocols
7. トランスポート・プロトコル
MIKEY MAY be integrated within session establishment protocols. Currently, integration of MIKEY within SIP/SDP and RTSP is defined in [KMASDP]. MIKEY MAY use other transports, in which case how MIKEY is transported over such a transport protocol has to be defined.
マイキーはセッション設立プロトコルの中で統合しているかもしれません。 現在、SIP/SDPとRTSPの中のマイキーの統合は[KMASDP]で定義されます。 マイキーは他の輸送を使用するかもしれません、その場合、マイキーがそのようなトランスポート・プロトコルの上でどう輸送されるかが定義されなければなりません。
8. Groups
8. グループ
What has been discussed up to now is not limited to single peer-to- peer communication (except for the DH method), but can be used to distribute group keys for small-size interactive groups and simple one-to-many scenarios. Section 2.1. describes the scenarios in the focus of MIKEY. This section describes how MIKEY is used in a group scenario (though, see also Section 4.3 for issues related to authorization).
これまで議論したことは、独身の同輩から同輩へのコミュニケーション(DHメソッドを除いた)に制限されませんが、小型の対話的なグループと簡単な多くへの1つのシナリオのためにグループキーを分配するのに使用できます。 セクション2.1はマイキーの焦点でシナリオについて説明します。 このセクションはマイキーがグループシナリオでどう使用されるかを(もっとも、また、承認に関連する問題に関してセクション4.3を見てください)説明します。
Arkko, et al. Standards Track [Page 50] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[50ページ]。
8.1. Simple one-to-many
8.1. 多くへの簡単なもの
++++
|S |
| |
++++
|
--------+-------------- - -
| | |
v v v
++++ ++++ ++++
|A | |B | |C |
| | | | | |
++++ ++++ ++++
++++ |S| | | ++++ | --------+-------------- - - | | | + + + + + + + + + + + v対+に|A| |B| |C| | | | | | | ++++ ++++ ++++
Figure 8.1. Simple one-to-many scenario.
エイト環.1。 簡単な多くへの1つのシナリオ。
In the simple one-to-many scenario, a server is streaming to a small group of clients. RTSP or SIP is used for the registration and the key management set up. The streaming server acts as the Initiator of MIKEY. In this scenario, the pre-shared key or public key transport mechanism will be appropriate in transporting the same TGK to all the clients (which will result in common TEKs for the group).
簡単な多くへの1つのシナリオでは、サーバはクライアントの小さいグループにストリーミングです。 RTSPかSIPが設立された登録とかぎ管理に使用されます。 ストリーミングサーバはマイキーのInitiatorとして機能します。 このシナリオでは、あらかじめ共有されたキーか公開鍵移送機構がすべてのクライアント(グループのための一般的なTEKsをもたらすでしょう)に同じTGKを輸送する際に適切になるでしょう。
Note, if the same TGK/TEK(s) should be used by all the group members, the streaming server MUST specify the same CSB_ID and CS_ID(s) for the session to all the group members.
ストリーミングサーバが同じTGK/TEK(s)がすべてのグループのメンバーによって使用されるならセッションとして同じCSB_IDとCS_IDをすべてのグループのメンバーに指定しなければならないことに注意してください。
As the communication may be performed using multicast, the members need a common security policy if they want to be part of the group. This limits the possibility of negotiation.
コミュニケーションがマルチキャストを使用することで実行されるとき、彼らがグループについて一部になりたがっているなら、メンバーは共通の安全保障方針を必要とします。 これは交渉の可能性を制限します。
Furthermore, the Initiator should carefully consider whether to request the verification message in reply from each receiver, as this may result in a certain load for the Initiator itself as the group size increases.
その上、Initiatorは、各受信機から回答における検証メッセージを要求するかどうか慎重に考えるはずです、グループサイズが増加するのに従ってこれがInitiator自身のためのある負荷をもたらしているかもしれない間。
8.2. Small-size interactive group
8.2. 小型インタラクティブグループ
As described in the overview section, for small-size interactive groups, one may expect that each client will be in charge for setting up the security for its outgoing streams. In these scenarios, the pre-shared key or the public-key transport method is used.
小型インタラクティブグループのために概要部で説明されるように、それぞれのクライアントが外向的なストリームのためにセキュリティをセットアップするのにおいて担当するようになると予想するかもしれません。これらのシナリオでは、あらかじめ共有されたキーか公開鍵輸送メソッドが使用されています。
Arkko, et al. Standards Track [Page 51] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[51ページ]。
++++ ++++
|A | -------> |B |
| | <------- | |
++++ ++++
^ | | ^
| | | |
| | ++++ | |
| --->|C |<--- |
------| |------
++++
++++ ++++ |A| ------->| B| | | <、-、-、-、-、-、--、|、| ++++ ++++ ^ | | ^ | | | | | | ++++ | | | --->|C| <、-、--、| ------| |------ ++++
Figure 8.2. Small-size group without a centralized controller.
エイト環.2。 集結されたコントローラのない小型グループ。
One scenario may then be that the client sets up a three-part call, using SIP. Due to the small size of the group, unicast SRTP is used between the clients. Each client sets up the security for its outgoing stream(s) to the others.
そしてときに1つのシナリオはSIPを使用して、クライアントが3部分の呼び出しをセットアップするということであるかもしれません。 グループの小型のため、ユニキャストSRTPはクライアントの間で使用されます。 各クライアントは外向的なストリームのために他のものにセキュリティをセットアップします。
As for the simple one-to-many case, the streaming client specifies the same CSB_ID and CS_ID(s) for its outgoing sessions if the same TGK/TEK(s) is used for all the group members.
簡単な多くへの1つのケースに関して、同じTGK/TEK(s)がすべてのグループのメンバーに使用されるなら、ストリーミングのクライアントは外向的なセッションとして同じCSB_IDとCS_IDを指定します。
9. Security Considerations
9. セキュリティ問題
9.1. General
9.1. 一般
Key management protocols based on timestamps/counters and one- roundtrip key transport have previously been standardized, for example ISO [ISO1, ISO2]. The general security of these types of protocols can be found in various articles and literature, c.f. [HAC, AKE, LOA].
例えば、タイムスタンプ/カウンタに基づくかぎ管理プロトコルと主要な1つの往復旅行の輸送は以前に、標準化されました。ISO[ISO1、ISO2]。 様々な記事と文学、c.fでこれらのタイプのプロトコルの総合証券を見つけることができます。 [HAC、AKE、LOA。]
No chain is stronger than its weakest link. If a given level of protection is wanted, then the cryptographic functions protecting the keys during transport/exchange MUST offer a security corresponding to at least that level.
どんなチェーンも最も弱いリンクほど強くはありません。 与えられたレベルの保護が欲しいなら、輸送/交換の間にキーを保護する暗号の機能は少なくともそのレベルに対応するセキュリティを提供しなければなりません。
For instance, if a security against attacks with a complexity 2^96 is wanted, then one should choose a secure symmetric cipher supporting at least 96 bit keys (128 bits may be a practical choice) for the actual media protection, and a key transport mechanism that provides equivalent protection, e.g., MIKEY's pre-shared key transport with 128 bit TGK, or RSA with 1024 bit keys (which according to [LV] corresponds to the desired 96 bit level, with some margin).
例えば、マイキーは例えば、複雑さ2^96がある攻撃に対するセキュリティが欲しいなら、実際のメディア保護、および同等な保護を提供する主要な移送機構のために少なくとも96ビットがキー(128ビットは実用的な選択であるかもしれない)であるとサポートする安全な左右対称の暗号を選ぶべきであり、主要な輸送が128ビットのTGKとあらかじめ共有されるか、または1024年のビットのキーでRSAを共有されました([LV]に従って、何らかのマージンで96ビットの必要なレベルに対応します)。
In summary, key size for the key-exchange mechanism MUST be weighed against the size of the exchanged TGK so that it at least offers the required level. For efficiency reasons, one SHOULD also avoid a
概要では、主要な交換メカニズムのための主要なサイズについて交換されたTGKのサイズに比較考量しなければならないので、それは必要なレベルを少なくとも提供します。 効率理由で、また、あるSHOULDがaを避けます。
Arkko, et al. Standards Track [Page 52] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[52ページ]。
security overkill, e.g., by not using a public key transport with public keys giving a security level that is orders of magnitude higher than length of the transported TGK. We refer to [LV] for concrete key size recommendations.
例えば、公開鍵が輸送されたTGKの長さより何桁も高いセキュリティー・レベルを与えている公開鍵輸送を使用しないのによるセキュリティ過剰殺傷。 私たちは具体的な主要なサイズ推薦について[LV]について言及します。
Moreover, if the TGKs are not random (or pseudo-random), a brute force search may be facilitated, again lowering the effective key size. Therefore, care MUST be taken when designing the (pseudo-) random generators for TGK generation, see [FIPS][RAND].
そのうえ、TGKsが無作為でないなら(または、擬似ランダム)、力任せの検索は容易にされるかもしれません、再び有効な主要なサイズを下げて。 [FIPS][RAND]は、したがって、TGK世代のための(疑似な)無作為のジェネレータを設計するとき注意しなければならないのを見ます。
For the selection of the hash function, SHA-1 with 160-bit output is the default one. In general, hash sizes should be twice the "security level", indicating that SHA-1-256, [SHA256], should be used for the default 128-bit level. However, due to the real-time aspects in the scenarios we are treating, hash sizes slightly below 256 are acceptable, as the normal "existential" collision probabilities would be of secondary importance.
ハッシュ関数の選択のために、160ビットの出力があるSHA-1はデフォルト1です。 一般に、ハッシュサイズは「セキュリティー・レベル」の2倍であるべきです、SHA-1-256[SHA256]がデフォルトの128ビットのレベルに使用されるべきであるのを示して。 しかしながら、私たちが扱っているシナリオのリアルタイムの局面のために、256のわずかに下におけるハッシュサイズは許容できます、標準の「実存的な」衝突確率がセカンダリに重要であるだろうというときに。
In a Crypto Session Bundle, the Crypto Sessions can share the same TGK as discussed earlier. From a security point of view, to satisfy the criterion in case the TGK is shared, the encryption of the individual Crypto Sessions are performed "independently". In MIKEY, this is accomplished by having unique Crypto Session identifiers (see also Section 4.1) and a TEK derivation method that provides cryptographically independent TEKs to distinct Crypto Sessions (within the Crypto Session Bundle), regardless of the security protocol used.
Crypto Session Bundleでは、Cryptoセッションズは以前に検討したことであるが同じTGKを共有できます。 セキュリティ観点から、TGKが共有されるといけないので評価基準を満たすために、個々のCryptoセッションズの暗号化は「独自に」実行されます。 マイキーでは、これはユニークなCrypto Session識別子(また、セクション4.1を見る)と暗号で異なったCryptoセッションズに独立しているTEKsを提供するTEK誘導法(Crypto Session Bundleの中の)を持っていることによって、達成されます、使用されるセキュリティプロトコルにかかわらず。
Specifically, the key derivations, as specified in Section 4.1, are implemented by a pseudo-random function. The one used here is a simplified version of that used in TLS [TLS]. Here, only one single hash function is used, whereas TLS uses two different functions. This choice is motivated by the high confidence in the SHA-1 hash function, and by efficiency and simplicity of design (complexity does not imply security). Indeed, as shown in [DBJ], if one of the two hashes is severely broken, the TLS PRF is actually less secure than as if a single hash had been used on the whole key, as is done in MIKEY.
明確に、セクション4.1で指定される主要な派生は擬似ランダム機能によって実装されます。 ここで使用されたのはTLS[TLS]で使用されるその簡易型のバージョンです。 ここで、1つのただ一つのハッシュ関数だけが使用されていますが、TLSは2つの異なった機能を使用します。 この選択はデザインのSHA-1ハッシュ関数における高い信用、効率、および簡単さによって動機づけられています(複雑さはセキュリティを含意しません)。 本当に、[DBJ]に示されるように、2つのハッシュの1つが厳しく壊れているなら、TLS PRFは実際にただ一つのハッシュが全体のキーの上に使用されたされたコネほど安全でないマイキーです。
In the pre-shared key and public-key schemes, the TGK is generated by a single party (Initiator). This makes MIKEY somewhat more sensitive if the Initiator uses a bad random number generator. It should also be noted that neither the pre-shared nor the public-key scheme provides perfect forward secrecy. If mutual contribution or perfect forward secrecy is desired, the Diffie-Hellman method is to be used. Authentication (e.g., signatures) in the Diffie-Hellman method is required to prevent man-in-the-middle attacks.
あらかじめ共有されたキーと公開鍵体系では、TGKは独身のパーティー(創始者)によって生成されます。 これで、Initiatorが悪い乱数発生器を使用するなら、マイキーはいくらか敏感になります。 また、あらかじめ共有にされるのも公開鍵体系も完全な前進の秘密保持を提供しないことに注意されるべきです。 互いの貢献か完全な前進の秘密保持が望まれているなら、ディフィー-ヘルマンメソッドは使用されていることです。 ディフィー-ヘルマンメソッドにおける認証(例えば、署名)が、介入者攻撃を防ぐのに必要です。
Arkko, et al. Standards Track [Page 53] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[53ページ]。
Forward/backward security: if the TGK is exposed, all generated TEKs are compromised. However, under the assumption that the derivation function is a pseudo-random function, disclosure of an individual TEK does not compromise other (previous or later) TEKs derived from the same TGK. The Diffie-Hellman mode can be considered by cautious users, as it is the only one that supports so called perfect forward secrecy (PFS). This is in contrast to a compromise of the pre-shared key (or the secret key of the public key mode), where future sessions and recorded sessions from the past are then also compromised.
前方の、または、後方のセキュリティ: TGKが暴露されるなら、TEKsであると生成されたすべてが感染されます。 しかしながら、派生機能が擬似ランダム機能であるという仮定で、個々のTEKの公開は同じTGKから得られた他の(前であるか後)のTEKsに感染しません。 用心深いユーザはディフィー-ヘルマンモードを考えることができます、それがいわゆる完全な前進の秘密保持(PFS)をサポートする唯一無二であるので。 これはあらかじめ共有されたキー(または、公開鍵モードの秘密鍵)の感染と対照的になっています。次に、また、過去からの今後のセッションと記録されたセッションはそこで感染されます。
The use of random nonces (RANDs) in the key derivation is of utmost importance to counter off-line pre-computation attacks. Note however that update messages re-use the old RAND. This means that the total effective key entropy (relative to pre-computation attacks) for k consecutive key updates, assuming the TGKs and RAND are each n bits long, is about L = n*(k+1)/2 bits, compared to the theoretical maximum of n*k bits. In other words, a 2^L work effort MAY enable an attacker to get all k n-bit keys, which is better than brute force (except when k = 1). While this might seem like a defect, first note that for a proper choice of n, the 2^L complexity of the attack is way out of reach. Moreover, the fact that more than one key can be compromised in a single attack is inherent to the key exchange problem. Consider for instance a user who, using a fixed 1024-bit RSA key, exchanges keys and communicates during a one or two year lifetime of the public key. Breaking this single RSA key will enable access to all exchanged keys and consequently the entire communication of that user over the whole period.
主要な派生における無作為の一回だけ(RANDs)の使用は、オフラインプレ計算攻撃に対抗するためには最重要性のものです。 しかしながら、アップデートメッセージが古いRANDを再使用することに注意してください。 これは、TGKsとRANDが長さビットのそれぞれのnであると仮定するk連続した主要なアップデートのための総有効な主要なエントロピー(プレ計算攻撃に比例した)がn*kビットの理論上の最大と2ビットであって、n*(k+1)/比較されたL=に関するものであることを意味します。 言い換えれば、2^L仕事取り組みは、攻撃者がすべてのk n-ビットキーを手に入れるのを可能にするかもしれません(馬鹿力(k=1であるときに時を除いた)より良いです)。 これは欠陥のように見えるかもしれませんが、最初に、nの適切な選択のために、攻撃の2^Lの複雑さがずっと範囲から脱していることに注意してください。 そのうえ、ただ一つの攻撃で1個以上のキーに感染することができるという事実は主要な交換問題に固有です。 例えば固定1024年のビットのRSAキーを使用して、キーを交換して、公開鍵の1年間か2年間の生涯交信するユーザを考えてください。 この単一のRSAキーを壊すと、そのユーザのすべての交換されたキーとその結果全体のコミュニケーションへのアクセスは全体の期間にわたって可能にされるでしょう。
All the pre-defined transforms in MIKEY use state-of-the-art algorithms that have undergone large amounts of public evaluation. One of the reasons for using the AES-CM from SRTP [SRTP], is to have the possibility of limiting the overall number of different encryption modes and algorithms, while offering a high level of security at the same time.
マイキーでのすべての事前に定義された変換が多量の公共の評価を受けた最先端のアルゴリズムを使用します。 理由の1つ、SRTP[SRTP]からAES-CMを使用して、同時に高いレベルのセキュリティを提供している間、総合的な数の異なった暗号化モードとアルゴリズムを制限する可能性を持つことになっています。
9.2. Key lifetime
9.2. 主要な生涯
Even if the lifetime of a TGK (or TEK) is not specified, it MUST be taken into account that the encryption transform in the underlying security protocol can in some way degenerate after a certain amount of encrypted data. It is not possible to here state universally applicable, general key lifetime bounds; each security protocol should define such maximum amount and trigger a re-keying procedure before the "exhaustion" of the key. For example, according to SRTP [SRTP] the TEK, together with the corresponding TGK, MUST be changed at least every 2^48 SRTP packet.
TGK(または、TEK)の寿命が指定されないでも、基本的なセキュリティプロトコルにおける暗号化変換が、ある量の暗号化されたデータの後に堕落した何らかの方法でそうすることができるのを考慮に入れなければなりません。 ここには、一般に適切な状態、一般が生涯領域を合わせるのが、可能ではありません。 それぞれのセキュリティプロトコルは、キーの「疲労困憊」の前にそのような最大の量を定義して、再の合わせる手順の引き金となるべきです。 例えば、SRTP[SRTP]によると、対応するTGKと共にTEKを変えなければなりません。少なくともあらゆる2^48SRTPパケット。
Arkko, et al. Standards Track [Page 54] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[54ページ]。
Still, the following can be said as a rule of thumb. If the security protocol uses an "ideal" b-bit block cipher (in CBC mode, counter mode, or a feedback mode, e.g., OFB, with full b-bit feedback), degenerate behavior in the crypto stream, possibly useful for an attacker, is (with constant probability) expected to occur after a total of roughly 2^(b/2) encrypted b-bit blocks (using random IVs). For security margin, re-keying MUST be triggered well in advance compared to the above bound. See [BDJR] for more details.
それでも、原則として親指について以下を言うことができます。 セキュリティプロトコルが「理想的な」b-ビットブロック暗号(CBCモード、カウンタモード、またはフィードバックモード、例えば、完全なb-ビットフィードバックがあるOFBの)を使用するなら、合計およそ2^(b/2)がb-ビットブロックを暗号化した(無作為のIVsを使用して)後に暗号ストリームにおける堕落したことによると攻撃者の役に立つ振舞いが起こると予想されます(一定の確率で)。 セキュリティマージンのために、上のバウンドと比べて、あらかじめ、再の合わせることをよく引き起こさなければなりません。 その他の詳細に関して[BDJR]を見てください。
For use of a dedicated stream cipher, we refer to the analysis and documentation of said cipher in each specific case.
ひたむきなストリーム暗号の使用について、私たちはそれぞれの特定の場合における前述の暗号の分析とドキュメンテーションを参照します。
9.3. Timestamps
9.3. タイムスタンプ
The use of timestamps, instead of challenge-responses, requires the systems to have synchronized clocks. Of course, if two clients are not synchronized, they will have difficulties in setting up the security. The current timestamp based solution has been selected to allow a maximum of one roundtrip (i.e., two messages), but still provide a reasonable replay protection. A (secure) challenge- response based version would require at least three messages. For a detailed description of the timestamp and replay handling in MIKEY, see Section 5.4.
チャレンジレスポンスの代わりに、タイムスタンプの使用は、システムが時計を連動させたのを必要とします。 もちろん、2人のクライアントが連動しないと、彼らはセキュリティをセットアップする際に苦労するでしょう。 現在のタイムスタンプに基づいているソリューションが最大1つの往復旅行(すなわち、2つのメッセージ)を許容するのが選択されましたが、それでも、合理的な反復操作による保護を提供してください。 応答が基礎づけた(安全)の挑戦バージョンは少なくとも3つのメッセージを必要とするでしょう。 マイキーのタイムスタンプと再生取り扱いの詳述に関しては、セクション5.4を見てください。
Practical experiences of Kerberos and other timestamp-based systems indicate that it is not always necessary to synchronize the terminals over the network. Manual configuration could be a feasible alternative in many cases (especially in scenarios where the degree of looseness is high). However, the choice must be made carefully with respect to the usage scenario.
ケルベロスと他のタイムスタンプベースのシステムの実用的な経験は、ネットワークの上で端末を連動させるのがいつも必要であるというわけではないことを示します。 多くの場合(特にゆるみの度合いが高であるシナリオで)、手動の構成は可能な代替手段であるかもしれません。 しかしながら、用法シナリオに関して慎重に選択をしなければなりません。
9.4. Identity Protection
9.4. アイデンティティ保護
User privacy is a complex matter that to some extent can be enforced by cryptographic mechanisms, but also requires policy enforcement and various other functionalities. One particular facet of privacy is user identity protection. However, identity protection was not a main design goal for MIKEY. Such a feature will add more complexity to the protocol and was therefore not chosen to be included. As MIKEY is anyway proposed to be transported over, e.g., SIP, the identity may be exposed by this. However, if the transporting protocol is secured and also provides identity protection, MIKEY might inherit the same feature. How this should be done is for future study.
ユーザプライバシーは暗号のメカニズムである程度実施できますが、方針実施と他の様々な機能性をまた必要とする複雑な問題です。 プライバシーの1つの特定の一面はユーザアイデンティティ保護です。 しかしながら、アイデンティティ保護はマイキーの主なデザイン目標ではありませんでした。 そのような特徴は、より多くの複雑さをプロトコルに追加して、したがって、含まれるように選ばれませんでした。 例えば、SIP、マイキーがそうように、輸送されるためにとにかく提案されていて、アイデンティティはこれによって暴露されるかもしれません。 しかしながら、輸送プロトコルが保証されて、また、アイデンティティ保護を提供するなら、マイキーは同じ特徴を引き継ぐかもしれません。 今後の研究にはこれがどう完了しているべきであるかがあります。
Arkko, et al. Standards Track [Page 55] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[55ページ]。
9.5. Denial of Service
9.5. サービス妨害
This protocol is resistant to Denial of Service attacks in the sense that a Responder does not construct any state (at the key management protocol level) before it has authenticated the Initiator. However, this protocol, like many others, is open to attacks that use spoofed IP addresses to create a large number of fake requests. This may for example, be solved by letting the protocol transporting MIKEY do an IP address validity test. The SIP protocol can provide this using the anonymous authentication challenge mechanism (specified in Section 22.1 of [SIP]).
このプロトコルはInitiatorを認証する前にResponderが少しの状態(かぎ管理プロトコルレベルにおける)も構成しないという意味におけるサービス妨害攻撃に抵抗力があります。 しかしながら、多くの他のもののように、このプロトコルは多くのにせの要求を作成するのに偽造されたIPアドレスを使用する攻撃に開かれています。 これは解決するかもしれません。例えば、マイキーを輸送するとIPアドレス妥当性テストがするプロトコルをさせることによって、解決されてください。 SIPプロトコルは、匿名の認証挑戦メカニズム([SIP]のセクション22.1では、指定される)を使用することでこれを提供できます。
It is highly RECOMMENDED to include IDr in the Initiator's message. If not included, its absence can be used for DoS purposes (the largest DoS-impact being on the public key and DH methods), where a message intended for other entities is sent to the target. In fact, the target may verify the signature correctly due to the fact that the Initiator's ID is correct and the message is actually signed by the claimed Initiator (e.g., by re-directing traffic from another session).
非常に、RECOMMENDEDがInitiatorのところのインクルードIDrへ通信するということです。 含まれていないなら、DoS目的(公開鍵とDHメソッドにある最も大きいDoS-影響)に不在を使用できます。そこでは、他の実体のために意図するメッセージが目標に送られます。 事実上、目標はInitiatorのIDが正しく、メッセージが実際に要求されたInitiator(例えば、別のセッションからトラフィックを向け直すのによる)によって署名されるという事実のため正しく署名について確かめるかもしれません。
However, in the public key method, the envelop key and the MAC will ensure that the message is not accepted (still, compared to a normal faked message, where the signature verification would detect the problem, one extra public key decryption is needed to detect the problem in this case).
しかしながら、公開鍵メソッドで確実にする、キーをおおってください。そうすれば、MACは、メッセージが受け入れられないのを確実にするでしょう(それでも、正常な見せかけられたメッセージと比べて、1つの付加的な公開鍵復号化がこの場合問題を検出するのに必要です)。そこでは、署名照合が問題を検出するでしょう。
In the DH method, a message would be accepted (without detecting the error) and a response (and state) would be created for the malicious request.
DHメソッドで、メッセージを受け入れるでしょう、そして、(誤りを検出しないで)悪意がある要求のために、応答(そして、状態)を作成するでしょう。
As also discussed in Section 5.4, the tradeoff between time synchronization and the size of the replay cache may be affected in case of for example, a flooding DoS attack. However, if the recommendations of using a dynamic size of the replay cache are followed, it is believed that the client will in most cases be able to handle the replay cache. Of course, as the replay cache decreases in size, the required time synchronization is more restricted. However, a bigger problem during such an attack would probably be to process the messages (e.g., verify signatures/MACs) due to the computational workload this implies.
また、セクション5.4で議論するように、再生キャッシュの時間同期化とサイズの間の見返りは例えば、氾濫DoS攻撃の場合に影響を受けるかもしれません。 しかしながら、再生キャッシュのダイナミックなサイズを使用する推薦が続かれているなら、多くの場合、クライアントが再生キャッシュを扱うことができると信じられています。 もちろん、再生キャッシュがサイズに縮小するのに従って、必要な時間同期化はさらに制限されます。 しかしながら、そのような攻撃の間の、より大きい問題はこれが含意するコンピュータのワークロードのため、たぶん、メッセージ(例えば、署名/MACsについて確かめる)を処理するだろうことです。
9.6. Session Establishment
9.6. セッション設立
It should be noted that if the session establishment protocol is insecure, there may be attacks on this that will have indirect security implications on the secured media streams. This however only applies to groups (and is not specific to MIKEY). The threat is
セッション設立プロトコルが不安定であるなら、機密保護しているメディアストリームに間接的なセキュリティ意味を持っているこれに対する攻撃があるかもしれないことに注意されるべきです。しかしながら、これはグループ(そして、マイキーにとって、特定でない)に申し込まれるだけです。 脅威はそうです。
Arkko, et al. Standards Track [Page 56] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[56ページ]。
that one group member may re-direct a stream from one group member to another. This will have the same implication as when a member tries to impersonate another member, e.g., by changing its IP address. If this is seen as a problem, it is RECOMMENDED that a Data Origin Authentication (DOA) scheme (e.g., digital signatures) be applied to the security protocol.
その1人のグループのメンバーが1人のグループのメンバーから別のメンバーまでストリームを向け直すかもしれません。 これには、メンバーが別のメンバーをまねようとする時と同じ意味があるでしょう、例えば、IPアドレスを変えることによって。 これが問題と考えられるなら、Data Origin Authentication(DOA)体系(例えば、デジタル署名)がセキュリティプロトコルに適用されるのは、RECOMMENDEDです。
Re-direction of streams can of course be done even if it is not a group. However, the effect will not be the same as compared to a group where impersonation can be done if DOA is not used. Instead, re-direction will only deny the receiver the possibility of receiving (or just delay) the data.
それがグループでなくてももちろんストリームのリダイレクションができます。 しかしながら、効果はDOAが使用されていないならものまねをできるグループと比べるのと同じにならないでしょう。 代わりに、リダイレクションはデータを受け取る(または、まさしく遅れ)可能性を受信機に対して否定するだけでしょう。
10. IANA Considerations
10. IANA問題
This document defines several new name spaces associated with the MIKEY payloads. This section summarizes the name spaces for which IANA is requested to manage the allocation of values. IANA is requested to record the pre-defined values defined in the given sections for each name space. IANA is also requested to manage the definition of additional values in the future. Unless explicitly stated otherwise, values in the range 0-240 for each name space SHOULD be approved by the process of IETF consensus and values in the range 241-255 are reserved for Private Use, according to [RFC2434].
このドキュメントはマイキーペイロードに関連しているいくつかの新しい名前空間を定義します。 このセクションはIANAが値の配分を管理するよう要求されている名前空間をまとめます。 IANAが与えられたセクションでそれぞれの名前スペースと定義された事前に定義された値を記録するよう要求されています。 また、IANAが将来加算値の定義を管理するよう要求されています。 別の方法で明らかに述べられない場合、承認されていて、それぞれのための範囲0-240の値はIETFコンセンサスのプロセスでスペースをSHOULDと命名します、そして、範囲241-255の値は兵士のUseのために予約されます、[RFC2434]に従って。
The name spaces for the following fields in the Common header payload (from Section 6.1) are requested to be managed by IANA (in bracket is the reference to the table with the initially registered values):
Commonヘッダーペイロード(セクション6.1からの)の以下の分野への名前空間はIANAによって管理されるよう要求されています(ブラケットでは、初めは登録された値があるテーブルの参照があります):
* version
* バージョン
* data type (Table 6.1.a)
* データ型(6.1.a)をテーブルの上に置いてください。
* Next payload (Table 6.1.b)
* 次のペイロード(テーブル6.1.b)
* PRF func (Table 6.1.c). This name space is between 0-127, where
values between 0-111 should be approved by the process of IETF
consensus and values between 112-127 are reserved for Private Use.
* PRF func(テーブル6.1.c)。 スペースが0-127にあるこの名前、0-111の間の値がどこでIETFコンセンサスのプロセスによって承認されるべきであるか、そして、112-127の間の値は兵士のUseのために予約されます。
* CS ID map type (Table 6.1.d)
* CS ID地図タイプ(テーブル6.1.d)
The name spaces for the following fields in the Key data transport payload (from Section 6.2) are requested to be managed by IANA:
Keyデータ伝送ペイロード(セクション6.2からの)の以下の分野への名前空間はIANAによって管理されるよう要求されています:
* Encr alg (Table 6.2.a)
* Encr alg(6.2.a)をテーブルの上に置いてください。
* MAC alg (Table 6.2.b)
* MAC alg(テーブル6.2.b)
Arkko, et al. Standards Track [Page 57] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[57ページ]。
The name spaces for the following fields in the Envelope data payload (from Section 6.3) are requested to be managed by IANA:
Envelopeデータペイロード(セクション6.3からの)の以下の分野への名前空間はIANAによって管理されるよう要求されています:
* C (Table 6.3)
* C(テーブル6.3)
The name spaces for the following fields in the DH data payload (from Section 6.4) are requested to be managed by IANA:
DHデータペイロード(セクション6.4からの)の以下の分野への名前空間はIANAによって管理されるよう要求されています:
* DH-Group (Table 6.4)
* DH-グループ(テーブル6.4)
The name spaces for the following fields in the Signature payload (from Section 6.5) are requested to be managed by IANA:
Signatureペイロード(セクション6.5からの)の以下の分野への名前空間はIANAによって管理されるよう要求されています:
* S type (Table 6.5)
* Sタイプ(テーブル6.5)
The name spaces for the following fields in the Timestamp payload (from Section 6.6) are requested to be managed by IANA:
Timestampペイロード(セクション6.6からの)の以下の分野への名前空間はIANAによって管理されるよう要求されています:
* TS type (Table 6.6)
* TSはタイプします。(テーブル6.6)
The name spaces for the following fields in the ID payload and the Certificate payload (from Section 6.7) are requested to be managed by IANA:
IDペイロードとCertificateペイロード(セクション6.7からの)の以下の分野への名前空間はIANAによって管理されるよう要求されています:
* ID type (Table 6.7.a)
* IDタイプ(6.7.a)をテーブルの上に置いてください。
* Cert type (Table 6.7.b)
* 本命タイプ(テーブル6.7.b)
The name spaces for the following fields in the Cert hash payload (from Section 6.8) are requested to be managed by IANA:
Certハッシュペイロード(セクション6.8からの)の以下の分野への名前空間はIANAによって管理されるよう要求されています:
* Hash func (Table 6.8)
* ハッシュfunc(テーブル6.8)
The name spaces for the following fields in the Security policy payload (from Section 6.10) are requested to be managed by IANA:
Security方針ペイロード(セクション6.10からの)の以下の分野への名前空間はIANAによって管理されるよう要求されています:
* Prot type (Table 6.10)
* Protはタイプします。(テーブル6.10)
For each security protocol that uses MIKEY, a set of unique parameters MAY be registered.
マイキーを使用するそれぞれのセキュリティプロトコルにおいて、1セットのユニークなパラメタは示されるかもしれません。
From Section 6.10.1.
セクション6.10.1から。
* SRTP Type (Table 6.10.1.a)
* SRTPはタイプします。(6.10.1.a)をテーブルの上に置いてください。
* SRTP encr alg (Table 6.10.1.b)
* SRTP encr alg(テーブル6.10.1.b)
* SRTP auth alg (Table 6.10.1.c)
* SRTP auth alg(テーブル6.10.1.c)
Arkko, et al. Standards Track [Page 58] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[58ページ]。
* SRTP PRF (Table 6.10.1.d)
* SRTP PRF(テーブル6.10.1.d)
* FEC order (Table 6.10.1.e)
* FECオーダー(テーブル6.10.1.e)
The name spaces for the following fields in the Error payload (from Section 6.12) are requested to be managed by IANA:
Errorペイロード(セクション6.12からの)の以下の分野への名前空間はIANAによって管理されるよう要求されています:
* Error no (Table 6.12)
* 誤りノー(テーブル6.12)
The name spaces for the following fields in the Key data payload (from Section 6.13) are requested to be managed by IANA:
Keyデータペイロード(セクション6.13からの)の以下の分野への名前空間はIANAによって管理されるよう要求されています:
* Type (Table 6.13.a). This name space is between 0-16, which
should be approved by the process of IETF consensus.
* タイプしてください。(テーブル6.13.a)。 スペースが0-16にあるこの名前。(その名前はIETFコンセンサスのプロセスによって承認されるべきです)。
* KV (Table 6.13.b). This name space is between 0-16, which should
be approved by the process of IETF consensus.
* kv(テーブル6.13.b)。 スペースが0-16にあるこの名前。(その名前はIETFコンセンサスのプロセスによって承認されるべきです)。
The name spaces for the following fields in the General Extensions payload (from Section 6.15) are requested to be managed by IANA:
一般Extensionsペイロード(セクション6.15からの)の以下の分野への名前空間はIANAによって管理されるよう要求されています:
* Type (Table 6.15).
* (テーブル6.15)をタイプしてください。
10.1. MIME Registration
10.1. MIME登録
This section gives instructions to IANA to register the application/mikey MIME media type. This registration is as follows:
このセクションは、アプリケーション/mikey MIMEメディアタイプを示すためにIANAに教授します。 この登録は以下の通りです:
MIME media type name : application
MIME subtype name : mikey
Required parameters : none
Optional parameters : version
version: The MIKEY version number of the enclosed message
(e.g., 1). If not present, the version defaults to 1.
Encoding Considerations : binary, base64 encoded
Security Considerations : see section 9 in this memo
Interoperability considerations : none
Published specification : this memo
MIMEメディア型名: アプリケーションMIME「副-タイプ」は以下を命名します。 mikey Requiredパラメタ: なにも、Optionalパラメタ: バージョンバージョン: 同封のメッセージ(例えば、1)のマイキーバージョン番号。 プレゼントでないなら、バージョンは1をデフォルトとします。 問題をコード化します: バイナリー、base64はSecurity Considerationsをコード化しました: このメモInteroperability問題でセクション9を見てください: なにも、Published仕様: このメモ
11. Acknowledgments
11. 承認
The authors would like to thank Mark Baugher, Ran Canetti, Martin Euchner, Steffen Fries, Peter Barany, Russ Housley, Pasi Ahonen (with his group), Rolf Blom, Magnus Westerlund, Johan Bilien, Jon-Olov Vatn, Erik Eliasson, and Gerhard Strangar for their valuable feedback.
作者は彼らの有益なフィードバックについてマークBaugher、Ranカネッティ、マーチンEuchner、ステファン・フリーズ、ピーター・バラニー、ラスHousley、パシ・アホネン(彼のグループがある)、ロルフ・ブロム、マグヌスWesterlund、ジョハンBilien、ジョン-Olov Vatn、エリック・エリアソン、およびゲルハルトStrangarに感謝したがっています。
Arkko, et al. Standards Track [Page 59] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[59ページ]。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[HMAC] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[NAI] AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、1999年1月。
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[オークリー] Orman、H.、「オークリーの主要な決断プロトコル」、RFC2412、1998年11月。
[PSS] PKCS #1 v2.1 - RSA Cryptography Standard, RSA Laboratories,
June 14, 2002, www.rsalabs.com
[PSS]PKCS#1v2.1--RSA Cryptography Standard、RSA研究所、2002年6月14日、www.rsalabs.com
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[SHA-1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
[SHA-1]NIST、FIPSパブ180-1: ハッシュ規格、1995年4月を確保してください。
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real Time Transport Protocol", RFC
3711, March 2004.
[SRTP]BaugherとM.とマグリューとD.とジーターとM.とカラーラ、E.とK.Norrman、「安全なリアルタイムのトランスポート・プロトコル」RFC3711(2004年3月)。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[URI]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[X.509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[X.509] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[AESKW] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002.
[AESKW] SchaadとJ.とR.Housley、「エー・イー・エス(AES)の主要な包装アルゴリズム」、RFC3394、2002年9月。
Arkko, et al. Standards Track [Page 60] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[60ページ]。
12.2. Informative References
12.2. 有益な参照
[AKE] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange
Protocols and their use for Building Secure Channels",
Eurocrypt 2001, LNCS 2054, pp. 453-474, 2001.
[AKE] カネッティとR.とH.Krawczyk、「Key-交換プロトコルと彼らのビルSecure Channelsの使用の分析」、Eurocrypt2001、LNCS2054、ページ 453-474, 2001.
[BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, "A
Concrete Analysis of Symmetric Encryption: Analysis of the
DES Modes of Operation", in Proceedings of the 38th
Symposium on Foundations of Computer Science, IEEE, 1997,
pp. 394-403.
[BDJR] Bellare、M.、デセイ、A.、Jokipii、E.、およびP.Rogaway、「左右対称の暗号化の具体的な分析:」 コンピュータScienceの財団の第38Symposium、IEEE、1997、ページのProceedingsの「OperationのDES Modesの分析」 394-403.
[BMGL] Hastad, J. and M. Naslund: "Practical Construction and
Analysis of Pseduo-randomness Primitives", Proceedings of
Asiacrypt 2001, LNCS. vol 2248, pp. 442-459, 2001.
[BMGL] Hastad、J.、およびM.ジーター: 「Pseduo-偶発性Primitivesの実用的なConstructionとAnalysis」、Asiacrypt2001、LNCS. vol2248、ページのProceedings 442-459, 2001.
[DBJ] Johnson, D.B., "Theoretical Security Concerns with TLS use
of MD5", Contribution to ANSI X9F1 WG, 2001.
[DBJ]ジョンソン、D.B.、「MD5"のTLS使用がある理論上のSecurity Concerns、ANSI X9F1 WG、2001へのContribution。」
[FIPS] "Security Requirements for Cryptographic Modules", Federal
Information Processing Standard Publications (FIPS PUBS)
140-2, December 2002.
[FIPS] 「暗号のモジュールのためのセキュリティ要件」、連邦情報処理基準刊行物(FIPSパブ)140-2、2002年12月。
[GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Group Key Management Architecture", Work in Progress.
[GKMARCH] Baugher、M.、カネッティ、R.、Dondeti、L.、およびF.リンドホルム、「グループKey Managementアーキテクチャ」は進行中で働いています。
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
2003年7月の[GDOI]BaugherとM.とウィスとB.とHardjono、T.とH.ハーニー、「解釈のグループドメイン」RFC3547。
[GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., and R.
Fleischer, "Group Secure Association Key Management
Protocol", Work in Progress.
[GSAKMP]ハーニー、H.、コールグローブ、A.、より一生懸命、E.、メタンフェタミン、U.、およびR.フレイシャー、「グループの安全な協会Key Managementプロトコル」は進行中で働いています。
[HAC] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook
of Applied Cryptography", CRC press, 1996.
[HAC]メネゼスとA.とバンOorschot、P.とS.Vanstone、「適用された暗号のハンドブック」CRCプレス、1996。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[ISO1] ISO/IEC 9798-3: 1997, Information technology - Security
techniques - Entity authentication - Part 3: Mechanisms
using digital signature techniques.
[ISO1]ISO/IEC9798-3: 1997、情報技術--セキュリティのテクニック--実体認証--パート3: デジタル署名のテクニックを使用するメカニズム。
[ISO2] ISO/IEC 11770-3: 1997, Information technology - Security
techniques - Key management - Part 3: Mechanisms using
digital signature techniques.
[ISO2]ISO/IEC11770-3: 1997、情報技術--セキュリティのテクニック--かぎ管理--パート3: デジタル署名のテクニックを使用するメカニズム。
Arkko, et al. Standards Track [Page 61] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[61ページ]。
[ISO3] ISO/IEC 18014 Information technology - Security techniques
- Time-stamping services, Part 1-3.
[ISO3]ISO/IEC18014情報技術--セキュリティのテクニック--タイムスタンピングサービス、Part1-3。
[KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "Key Management Extensions for SDP and RTSP", Work
in Progress.
J.、カラーラ、E.、リンドホルム、F.、ジーター、M.、およびK.Norrman、「SDPとRTSPのためのKey Management拡大」という[KMASDP]Arkkoは進行中で働いています。
[LOA] Burrows, Abadi, and Needham, "A logic of authentication",
ACM Transactions on Computer Systems 8 No.1 (Feb. 1990),
18-36.
[LOA] バロウズ、Abadi、およびニーダム、「認証の論理」、コンピュータシステムズ8No.1(1990年2月)のACM Transactions、18-36。
[LV] Lenstra, A. K. and E. R. Verheul, "Suggesting Key Sizes for
Cryptosystems", http://www.cryptosavvy.com/suggestions.htm
[LV]LenstraとA.K.とE.R.フェルヘール、「暗号系のために主要なサイズを示します」、 http://www.cryptosavvy.com/suggestions.htm
[NTP] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[NTP] 工場、D.、「ネットワーク時間は仕様、実装、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[OCSP] 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.
[OCSP] マイアーズ、M.、Ankney、R.、Malpani、A.、ガリペリン、S.、およびC.アダムス、「X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態は議定書を作ります--OCSP」、RFC2560、1999年6月。
[RAND] Eastlake, 3rd, D., Crocker, S., and J. Schiller,
"Randomness Requirements for Security", RFC 1750, December
1994.
イーストレークと3番目、D.、クロッカー、S.とJ.シラー、「セキュリティのための偶発性要件」RFC1750[ランド]と、1994年12月。
[RTSP] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[RTSP]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[SDP] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512",
http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf
[SHA256]NIST、「SHA-256、SHA-384、およびSHA-512の記述」、 http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf
[SIP] 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.
[一口] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0",
RFC 2246, January 1999.
[TLS] Dierks、T.、およびC.アレン、「TLSは議定書を作ります--バージョン1インチ、RFC2246、1999年1月。」
Arkko, et al. Standards Track [Page 62] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[62ページ]。
Appendix A. MIKEY - SRTP Relation
Appendix A.マイキー--SRTP関係
The terminology in MIKEY differs from the one used in SRTP as MIKEY needs to be more general, nor is tight to SRTP only. Therefore, it might be hard to see the relations between keys and parameters generated in MIKEY and those used by SRTP. This section provides some hints on their relation.
マイキーの用語はマイキーが、より一般的であることが必要であり、きついのでSRTPで使用されるものからSRTPだけまで異なります。 したがって、キーと、マイキーで生成されたパラメタとそれらとの関係がSRTPによって使用されるのを見るのは困難であるかもしれません。 このセクションはいくつかのヒントを彼らの関係に提供します。
MIKEY | SRTP ------------------------------------------------- Crypto Session | SRTP stream (typically with related SRTCP stream) Data SA | input to SRTP's crypto context TEK | SRTP master key
マイキー| SRTP------------------------------------------------- 暗号セッション| SRTPストリーム(通常、関連するSRTCPストリームがある)データSA| SRTPの暗号文脈TEKに入力されます。| SRTPマスターキー
The Data SA is built up by a TEK and the security policy exchanged. SRTP may use an MKI to index the TEK or TGK (the TEK is then derived from the TGK that is associated with the corresponding MKI), see below.
Data SAはTEKと交換された安全保障政策で確立されます。 SRTPはTEKかTGKに索引をつけるのにMKIを使用するかもしれなくて(次に、対応するMKIに関連しているTGKからTEKを得ます)、以下を見てください。
A.1. MIKEY-SRTP Interactions
A.1。 マイキー-SRTP相互作用
In the following, we give a brief outline of the interface between SRTP and MIKEY and the processing that takes place. We describe the SRTP receiver side only, the sender side will require analogous interfacing.
以下では、私たちはSRTPとマイキーとのインタフェースと行われる処理の簡潔なアウトラインをします。 私たちはSRTP受信機側だけについて説明して、送付者側は類似の連結を必要とするでしょう。
1. When an SRTP packet arrives at the receiver and is processed, the
triple <SSRC, destination address, destination port> is extracted
from the packet and used to retrieve the correct SRTP crypto
context, hence the Data SA. (The actual retrieval can, for
example, be done by an explicit request from the SRTP
implementation to MIKEY, or, by the SRTP implementation accessing
a "database", maintained by MIKEY. The application will typically
decide which implementation is preferred.)
1. SRTPパケットが受信機に到着して、処理されるとき、三重の<SSRC、送付先アドレス、パケットから抽出されて、正しいSRTP暗号文脈、したがって、Data SAを検索するのに使用される仕向港>です。 (「データベース」にアクセスするSRTP実装で、例えば、実際の検索を明白なSRTP実装からマイキーまでの要求でするか、またはマイキーは維持できます。 アプリケーションは、どの実装が好まれるかを通常決めるでしょう。)
2. If an MKI is present in the SRTP packet, it is used to point to
the correct key within the SA. Alternatively, if SRTP's <From,
To> feature is used, the ROC||SEQ of the packet is used to
determine the correct key.
2. MKIがSRTPパケットに存在しているなら、それは、SAの中に正しいキーを示すのに使用されます。 あるいはまた、ROC SRTPの<From、To>の特徴が使用されているなら||パケットのSEQは、正しいキーを決定するのに使用されます。
3. Depending on whether the key sent in MIKEY (as obtained in step 2)
was a TEK or a TGK, there are now two cases.
3. キーが、マイキー(ステップ2で得るように)がTEKかTGKであることを送ったかどうかによって、現在、2つのケースがあります。
- If the key obtained in step 2 is the TEK itself, it is used
directly by SRTP as a master key.
- ステップ2で入手されたキーがTEK自身であるなら、それはマスターキーとして直接SRTPによって使用されます。
Arkko, et al. Standards Track [Page 63] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[63ページ]。
- If the key instead is a TGK, the mapping with the CS_ID
(internal to MIKEY, Section 6.1.1) allows MIKEY to compute the
correct TEK from the TGK as described in Section 4.1 before
SRTP uses it.
- キーが代わりにTGKであるなら、CS_ID(マイキー、セクション6.1.1への内部の)があるマッピングで、マイキーはSRTPがそれを使用する前にセクション4.1で説明されるようにTGKから正しいTEKを計算できます。
If multiple TGKs (or TEKs) are sent, it is RECOMMENDED that each TGK (or TEK) be associated with a distinct MKI. It is RECOMMENDED that the use of <From, To> in this scenario be limited to very simple cases, e.g., one stream only.
複数のTGKs(または、TEKs)を送るなら、それぞれのTGK(または、TEK)が異なったMKIに関連しているのは、RECOMMENDEDです。 <From、このシナリオのTo>の使用が非常に簡単なケースに制限されるのは、RECOMMENDEDです、例えば、1つのストリーム専用。
Besides the actual master key, other information in the Data SA (e.g., transform identifiers) will of course also be communicated from MIKEY to SRTP.
また、実際のマスターキー以外に、Data SA(例えば、識別子を変える)の他の情報はもちろんマイキーからSRTPまで伝えられるでしょう。
Arkko, et al. Standards Track [Page 64] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[64ページ]。
Authors' Addresses
作者のアドレス
Jari Arkko Ericsson Research 02420 Jorvas Finland
ヤリArkkoエリクソンResearch02420Jorvasフィンランド
Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com
以下に電話をしてください。 +358 40 5079256はメールされます: jari.arkko@ericsson.com
Elisabetta Carrara Ericsson Research SE-16480 Stockholm Sweden
Elisabettaカラーラエリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 50877040 EMail: elisabetta.carrara@ericsson.com
以下に電話をしてください。 +46 8 50877040 メール: elisabetta.carrara@ericsson.com
Fredrik Lindholm Ericsson Research SE-16480 Stockholm Sweden
フレドリック・リンドホルム・エリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 58531705 EMail: fredrik.lindholm@ericsson.com
以下に電話をしてください。 +46 8 58531705 メール: fredrik.lindholm@ericsson.com
Mats Naslund Ericsson Research SE-16480 Stockholm Sweden
Matsジーター・エリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 58533739 EMail: mats.naslund@ericsson.com
以下に電話をしてください。 +46 8 58533739 メール: mats.naslund@ericsson.com
Karl Norrman Ericsson Research SE-16480 Stockholm Sweden
カール・Norrmanエリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 4044502 EMail: karl.norrman@ericsson.com
以下に電話をしてください。 +46 8 4044502 メール: karl.norrman@ericsson.com
Arkko, et al. Standards Track [Page 65] RFC 3830 MIKEY August 2004
Arkko、他 規格はマイキー2004年8月にRFC3830を追跡します[65ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004). 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.
Copyright(C)インターネット協会(2004)。 このドキュメントは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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Arkko, et al. Standards Track [Page 66]
Arkko、他 標準化過程[66ページ]
一覧
スポンサーリンク
