Network Working Group R. Housley
Request for Comments: 4705 Vigil Security
Category: Informational A. Corry
GigaBeam
October 2006
GigaBeam High-Speed Radio Link Encryption
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio link products. The security solution is documented in the hope that other wireless product development efforts will include comparable capabilities.
この文書では、無線リンクの製品のWiFiber（TM）ファミリの一部としてGigaBeamで使用される暗号化と鍵管理について説明します。セキュリティソリューションは、他のワイヤレス製品開発の努力が同等の機能が含まれますことを期待して文書化されています。
The GigaBeam WiFiber(tm) product family provides a high-speed point-to-point radio link. Data rates exceed 1 gigabit/second at a distance of about a mile. The transmission beam width is less than one degree, which means that attempts to intercept the signal are most successful when the attacker is either between the transmitter and receiver or the attacker is directly behind the receiver. Since interception is possible, some customers require confidentiality and integrity protection for the data on the radio link. This document describes the security solution designed and deployed by GigaBeam to provide these security services.
GigaBeam WiFiber（商標）製品ファミリーは、高速ポイント・ツー・ポイント無線リンクを提供します。データレートは約1マイルの距離で1ギガビット/秒を超えます。送信ビーム幅は、攻撃者がいずれかであり、送信機と受信機または攻撃の間に受信機の真後ろにある場合に信号を傍受しようとする試みは、ほとんど成功していることを意味し、1度未満です。傍受が可能ですので、一部の顧客は、無線リンク上のデータの機密性と完全性保護を必要としています。この文書では、これらのセキュリティサービスを提供するために、GigaBeamによって設計され、展開されたセキュリティソリューションについて説明します。
The GigaBeam security solution employs:
GigaBeamセキュリティソリューションを採用しています。
o AES-GCM [GCM] with a custom security protocol specified in this document to provide confidentiality and integrity protection of subscriber traffic on the radio link;
O AES-GCM [GCM]無線リンク上の加入者トラフィックの機密性と完全性保護を提供するために、この文書で指定されたカスタムセキュリティプロトコルを持ちます。
o AES-CBC [CBC] and HMAC-SHA-1 [HMAC] with IPsec ESP [ESP] to provide confidentiality and integrity protection of management traffic between the radio control modules;
O AES-CBC [CBC]およびHMAC-SHA-1は、[HMAC]とのIPsec ESPは、[ESP]無線制御モジュールとの間の管理トラフィックの機密性と完全性保護を提供します。
o AES-CBC [CBC] and HMAC-SHA-1 [HMAC] with the IKE protocol [IKE] to provide confidentiality and integrity protection of key management traffic between the radio control modules; and
O IKEプロトコル[IKE]とAES-CBC [CBC]およびHMAC-SHA-1 [HMAC]は、無線制御モジュールとの間の鍵管理トラフィックの機密性と完全性保護を提供します。そして
o OAKLEY key agreement [OAKLEY] and RSA digital signatures [PKCS1] are used with IKE to establish keying material and to provide authentication.
O OAKLEYキー合意[OAKLEY]とRSAデジタル署名[PKCS1]は、キーイング材料を確立するために、認証を提供するために、IKEで使用されています。
AES-GCM is used with the custom security protocol in a manner that is very similar to its use in ESP [ESP-GCM].
AES-GCMはESP [ESP-GCM]での使用に非常によく似ている方法で、カスタムセキュリティプロトコルで使用されています。
The GigaBeam high-speed radio link appears to be a fiber interface between two network devices. Figure 1 illustrates the connection of two devices that normally communicate using Gigabit Ethernet over a fiber optic cable.
GigaBeam高速無線リンクは、2つのネットワークデバイス間のファイバインターフェイスであるように見えます。図1は、通常、光ファイバ・ケーブルを介してギガビット・イーサネットを使用して通信する二つのデバイスの接続を示す図です。
+---------+ +----------+ +----------+ +---------+
| | | +----/ | | | |
| Network | | GigaBeam | / | GigaBeam | | Network |
| Device +=====+ Radio | /---- + Radio +=====+ Device |
| | | | | | | |
+---------+ ^ +----------+ ^ +----------+ ^ +---------+
| | |
| | |
Gigabit Ethernet | Gigabit Ethernet
GigaBeam Radio Link
Figure 1. GigaBeam Radio Link Example.
1. GigaBeam無線リンクの例を図。
Gigabit Ethernet traffic is encoded in 8B/10B format. The GigaBeam Radio Control Module (RCM) removes this coding to recover the 8-bit characters plus an indication of whether the character is a control code. The radio link frame is constructed from 224 10-bit input words, and a 4-way interleaved (56,50,10) Reed-Solomon Forward Error Correction (FEC) block is employed. Conversion of the Gigabit Ethernet data from 8B/10B format creates 224 bits of additional capacity in each frame, and another 196 bits is gained by recoding the 9-bit data using 64B/65B block codes. This additional 420 bits of capacity is used for the framing overhead required for FEC and link control.
ギガビットイーサネットトラフィックは、8B / 10B形式でエンコードされます。 GigaBeamラジオコントロールモジュール（RCM）は、8ビット文字を加えた文字が制御コードであるかどうかの指標を回復するために、このコードを除去します。無線リンクフレームは、224の10ビット入力ワードから構成され、4ウェイインターリーブ（56,50,10）リードソロモン前方誤り訂正（FEC）ブロックが使用されます。 8B / 10B形式からギガビット・イーサネット・データの変換は、各フレームに追加容量の224ビットを作成し、別の196ビットは、64B / 65Bブロック符号を使用して9ビットデータを再符号化することによって得られます。容量のこの追加の420ビットは、FECとリンク制御のために必要なフレーミングオーバーヘッドのために使用されます。
The GigaBeam radio link frame fields are summarized in Figure 2, which also provides the length of each field in bits.
GigaBeam無線リンクフレームのフィールドもビット内の各フィールドの長さを提供する。図2に要約されています。
Field Length Description
----- ------ -----------
SYNC 11 Frame Synchronization Pattern ('10110111000'b)
KEYSEL 1 Indicates which AES key was used for this frame
PN 40 AES-GCM Packet Number
FLAGS 28 Control bits, one bit for each 64B/65B data block
DCC 8 Data Communications Channel
DATA 1792 Data (28 encrypted 64B/65B code blocks)
TAG 96 Authentication Tag
SPARE 24 Reserved for alternative FEC algorithms
CHECK 240 Reed-Solomon Check Words for 4 10-bit
symbol (56,50) code
Figure 2. GigaBeam Radio Link Frame Structure.
2. GigaBeam無線リンクのフレーム構造を図。
Each of the fields in the GigaBeam 2240-bit radio link frame is described below.
GigaBeam 2240ビット無線リンクフレームの各フィールドについて説明します。
SYNC Synchronization field, an 11-bit Barker code. Always set to '10110111000'b.
SYNC同期フィールド、11ビットのバーカーコード。常に10110111000'b」に設定。
KEYSEL Key Selector -- select the appropriate key register for this frame. Two key registers are maintained to allow seamless rollover between encryption keys.
KEYSELキーセレクタ - このフレームのための適切なキーレジスタを選択します。二つのキーレジスタは、暗号化キーの間のシームレスなロールオーバーを許可するように維持されています。
PN Packet Number -- needed by AES-GCM; it carries the unique counter value for this frame. The value is incremented for each frame.
PNパケット番号 - AES-GCMで必要とされます。それは、このフレームのユニークなカウンタ値を運びます。値がフレーム毎に増分されます。
FLAGS Control bits, one for each 64B/65B data block carried in the DATA field. If the bit is set, then the corresponding 64B/65B block in the DATA field contains a control code. This field is integrity protected by AES-GCM.
フラグはビットデータフィールド内で運ば各64B / 65Bデータブロックのいずれかを制御します。ビットが設定されている場合、データフィールドに対応する64B / 65Bブロックは、制御コードを含んでいます。このフィールドには、AES-GCMにより保護整合性です。
DCC Data Communications Channel -- each frame carries one octet of the point-to-point data communications channel between the two radio control modules. See Section 2.2 for more information on the DCC.
DCCデータ通信チャネル - 各フレームは、二つの無線制御モジュール間のポイントツーポイントデータ通信チャネルの1つのオクテットを搬送します。 DCCの詳細については、セクション2.2を参照してください。
DATA Subscriber data carried as 28 64B/65B code blocks. This field is encrypted and integrity protected by AES-GCM.
28 64B / 65Bコード・ブロックとして搬送されるデータ加入者データ。このフィールドは、暗号化と整合性は、AES-GCMにより保護されています。
TAG The authentication tag generated by AES-GCM, truncated to 96 bits.
96ビットに切り捨てAES-GCMによって生成された認証タグをタグ。
SPARE 24 bits, set to zero.
スペアの24ビットは、ゼロに設定しました。
CHECK Forward error correction check value -- 24 check symbols are generated by a 4-way interleaved Reed-Solomon (56,50,10) algorithm. FEC is always active, but correction can be selectively enabled. For each frame, FEC processing also returns the number of bit errors, the number of symbols in error, and whether the FEC processing failed for the frame. This information allows an estimation of the bit error rate for the link.
CHECK前方誤り訂正チェック値 - 24個のチェックシンボルは4ウェイインターリーブリードソロモン（56,50,10）アルゴリズムによって生成されます。 FECは常にアクティブですが、補正が選択的に有効にすることができます。フレーム毎に、FEC処理はまた、ビットエラー数、エラーのあるシンボルの数を返し、FEC処理はフレームについて失敗したかどうか。この情報は、リンクのビット誤り率の推定を可能にします。
The Data Communications Channel (DCC) field reserves eight bits in each 2240-bit radio link frame for use in constructing a dedicated point-to-point link between the two RCMs. The DCC content is connected to a Universal Asynchronous Receiver/Transmitter (UART) controller that processes the DCC bit stream to provide an asynchronous serial channel that is visible to the RCM operating system. The Point-to-Point Protocol (PPP) [PPP] is used on the serial channel to create a simple two-node Internet Protocol (IP) network. Each IP datagram is spread over a large number of radio link frames. This two-node IP network carries management protocols between the GigaBeam RCMs.
データ通信チャネル（DCC）フィールド埋蔵2つのRCMの間の専用のポイントツーポイントリンクを構築に使用するための各2240ビットの無線リンクフレームの8ビット。 DCCコンテンツはRCMオペレーティングシステムに表示されている非同期シリアルチャンネルを提供するためにDCCビットストリームを処理するユニバーサル非同期レシーバ/トランスミッタ（UART）コントローラに接続されています。ポイントツーポイントプロトコル（PPP）[PPP]は、単純な2ノードのインターネットプロトコル（IP）ネットワークを作成するために、シリアルチャネル上で使用されます。各IPデータグラムは、無線リンクの多数のフレームに広がっています。この2つのノードのIPネットワークがGigaBeamのRCMの間の管理プロトコルを運びます。
IKE [IKE] runs on this two-node IP network to manage all cryptographic keying material. IPsec ESP [ESP] is used in the usual fashion to protect all non-IKE traffic on the data control channel. IPsec ESP employs AES-CBC as described in [ESP-CBC] and HMAC-SHA-1 as described in [ESP-HMAC].
IKE [IKE]は、すべての暗号化キーイングマテリアルを管理するには、この2ノードのIPネットワーク上で実行されます。 IPsecのESPは、[ESP]データ制御チャネル上のすべての非IKEトラフィックを保護するために通常の方法で使用されています。 [ESP-CBC]およびHMAC-SHA-1 [ESP-HMAC]に記載されているように記載されるようにIPsec ESPは、AES-CBCを使用します。
The fiber interface constantly provides a stream of data encoded in 8B/10B format. A radio link frame is constructed from 224 10-bit input words. Conversion of the data from 8B/10B format creates 224 bits of additional capacity in each frame, and then recoding using 64B/65B block codes creates another 196 bits of additional capacity. After encryption, the 64B/65B blocks are carried in the DATA field, and the control code indicator bits are carried in the FLAGS field. The additional capacity is used for the framing overhead.
ファイバインターフェイスは、常に8B / 10B形式で符号化されたデータのストリームを提供します。無線リンクフレームは、224の10ビット入力ワードから構成されています。 8B / 10B形式からのデータの変換は、各フレームに追加容量の224ビットを作成し、64B / 65Bブロック符号を使用して再符号化することは、追加の容量の別の196ビットを生成します。暗号化後、64B / 65Bブロックは、データフィールドに運ばれ、そして制御コードインジケータビットはフラグフィールドで運ばれます。追加容量は、フレーミングオーバーヘッドのために使用されています。
Processing proceeds as follows:
次のように進みます。
o encryption and integrity protection as described in Section 3.1;
Oの暗号化と整合性の保護3.1節で説明したように、
o forward error correction (FEC) processing as described in Section 3.2;
セクション3.2で説明したように、O前方誤り訂正（FEC）処理。
o scrambling as described in Section 3.3; and
O 3.3節で説明したようにスクランブル。そして
o differential encoding as described in Section 3.4.
セクション3.4で説明したように、O差分符号化。
The GigaBeam RCM contains two key registers. The single-bit KEYSEL field indicates which of the two registers was used for the frame.
GigaBeam RCMは、二つの重要なレジスタが含まれています。単一ビットKEYSELフィールドは、フレームのために使用された二つのレジスタのかを示します。
AES-GCM [GCM] employs counter mode for encryption. Therefore, a unique value for each frame is needed to construct the counter. The counter includes a 32-bit salt value provided by IKE and a 40-bit packet number from the PN field in the radio link frame. The same counter value must not be used for more than one frame encrypted with the same key. The 128-bit counter block is constructed as shown in Figure 3. The first 96 bits of the AES counter block are called the Nonce in the AES-GCM algorithm description. Note that AES-GCM uses BLOCK values of zero and one for its own use. The values beginning with two are used for encrypting the radio link frame payload.
AES-GCM [GCM]は、暗号化のためのカウンタモードを採用しています。したがって、フレームごとに一意の値がカウンタを構築するために必要とされます。カウンタは、IKEによって提供される32ビットのソルト値と無線リンクフレームにおけるPNフィールドから40ビットのパケット番号を含みます。同じカウンタ値が同じキーで暗号化された複数のフレームのために使用することはできません。 AESカウンタブロックの最初の96ビットは、AES-GCMアルゴリズム記述のノンスと呼ばれ、図3に示すように、128ビット・カウンタ・ブロックが構成されています。 AES-GCMがゼロとそれ自身の使用のための1つのブロック値を使用することに注意してください。 2で始まる値は、無線リンクフレームのペイロードを暗号化するために使用されています。
Field Length Description
----- ------ -----------
SALT 32 Salt value generated during the IKE exchange
MBZ1 24 These bits must be zero
PN 40 AES-GCM Packet Number carried in PN field
MBZ2 28 These bits must be zero
BLOCK 4 Block counter used in AES-GCM
Figure 3. AES Counter Block Construction.
図3. AESカウンタブロック建造。
AES-GCM is used to protect the FLAGS and DATA fields. The FLAGS field is treated as authenticated header data, and it is integrity protected, but it is not encrypted. The DATA field is encrypted and authenticated. The TAG field contains the authentication tag generated by AES-GCM, truncated to 96 bits.
AES-GCMは、FLAGSとデータフィールドを保護するために使用されます。フラグフィールドは認証ヘッダデータとして扱われ、それが完全性保護され、それは暗号化されていないれます。データフィールドは、暗号化と認証されます。 TAGフィールドは96ビットに切り捨てAES-GCMによって生成された認証タグを含んでいます。
Reception processing performs decryption and integrity checking. If the integrity checks fail, to maintain a continuous stream of traffic, the frame is replaced with K30.7 control characters. These control characters are normally used to mark errors in the data stream. Without encryption and integrity checking, these control characters usually indicate 8B/10B running disparity or code errors.
受信処理は、復号化と整合性チェックを実行します。整合性チェックが失敗した場合、トラフィックの連続ストリームを維持するために、フレームは、K30.7制御文字に置き換えられます。これらの制御文字は、通常、データストリーム中のエラーをマークするために使用されています。暗号化と整合性をチェックすることなく、これらの制御文字は通常、8B / 10Bランニングディスパリティまたはコードのエラーを示しています。
The 224 10-bit data symbols that make up each radio link frame are grouped into 4 subframes each consisting of 56 symbols. The subframes are formed by symbol interleaving. A Reed-Solomon Code, RS(56,50), designed for 10-bit symbols is applied to each subframe.
各無線リンクフレームを構成する224の10ビット・データ・シンボルは、それぞれ56個のシンボルからなる4個のサブフレームにグループ化されます。サブフレームは、シンボルインターリービングにより形成されています。 10ビット・シンボルのために設計されたリードソロモン符号、RS（56,50）は、各サブフレームに適用されます。
This Reed Solomon Code detects 6 errors and corrects 3 errors within each subframe. The FEC function is always active; however, it is possible to disable correction of the received data to support debugging.
このリードソロモンコードは6つのエラーを検出し、各サブフレーム内3つのエラーを修正します。 FEC機能は常にアクティブです。しかし、デバッグをサポートするために、受信したデータの補正を無効にすることが可能です。
The scrambler ensures that long series of one bits and long series of zero bits do not occur. When encryption is enabled, long series of common bit values is very unlikely; however, during the initial IKE exchange, the radio link frame payload is all zero bits.
スクランブラは、1つのビットの長い一連のゼロのビットの長いシリーズが発生しないことを保証します。暗号化が有効になっている場合、一般的なビット値の長いシリーズは非常に低いです。しかし、初期のIKE交換の間、無線リンクフレームのペイロードは、すべてゼロのビットです。
The scrambling polynomial is (1 + x^14 + x^15). All words of a frame except the SYNC pattern are scrambled prior to transmission using this linear feedback shift register (LFSR). The LFSR is initialized to all ones at the start of each frame, prior to the first processed bit. Each processed input bit is added modulo 2 (i.e., an XOR) to the output of the x15 tap to form the output bit.
スクランブル多項式は（1 + X ^ 14 + X ^ 15）です。 SYNCパターン以外のフレームの全ての言葉は、この線形フィードバックシフトレジスタ（LFSR）を用いて、送信前にスクランブルされます。 LFSRは、前処理された第一のビットに、各フレームの開始時にすべて1に初期化されます。各処理された入力ビットの出力ビットを形成するために、X15のタップの出力にモジュロ2（すなわち、XOR）を添加します。
On reception, an identical process is performed after frame synchronization and prior to subsequent processing to recover the original bit pattern.
受信時に、同じプロセスは、フレーム同期の後に行われ、その後の処理の前には、元のビットパターンを回復します。
The data stream is differentially encoded to avoid symbol ambiguity at the receiver. Since the demodulator could produce true or inverted data depending on the details of the radio frequency (RF) and intermediate frequency (IF) processing chains, differential encoding is used to ensure proper reception of the intended bit value. A zero bit is encoded as no change from the previous output bit, and a one bit is encoded as a change from the previous output bit. Thus, an output bit is the result of XORing the unencoded bit with the previously transmitted encoded bit.
データストリームは、示差受信機においてシンボルのあいまいさを回避するために符号化されます。復調器は、無線周波数（RF）および中間周波数（IF）処理チェーンの細部に応じて真または反転データを生成することができるので、差動符号化が意図ビット値の適切な受信を保証するために使用されます。ゼロビットは、前回の出力ビットから変化なしとして符号化され、1ビットは、前の出力ビットからの変化として符号化されます。従って、出力ビットは、以前に送信された符号化ビットを用いてエンコードされていないビットをXOR演算した結果です。
On reception, a complementary operation will be performed to produce the decoded datastream. The bitstream is formed by XORing the received encoded bit and the previously received encoded bit.
受信時に、相補的な動作は、デコードされたデータストリームを生成するために実行されます。ビットストリームは、受信された符号化ビットと以前に受信した符号化ビットのXORをとることによって形成されます。
The Internet Key Exchange (IKE) is used for key management [IKE]. IKE has two phases. In Phase 1, two Internet Security Association and Key Management Protocol (ISAKMP) peers establish a secure, authenticated channel with which to communicate. This is called the ISAKMP Security Association (SA). In the GigaBeam environment, the Phase 1 exchange is IKE Aggressive Mode with signatures and certificates. The RSA signature algorithm is used.
インターネット鍵交換（IKE）は、鍵管理[IKE]に使用されます。 IKEは2つの段階があります。フェーズ1では、2インターネットSecurity AssociationとKey Managementプロトコル（ISAKMP）ピアが通信するためにどのとの安全な、認証されたチャネルを確立します。これは、ISAKMPセキュリティアソシエーション（SA）と呼ばれています。 GigaBeam環境では、フェーズ1交換は署名と証明書とIKEアグレッシブモードです。 RSA署名アルゴリズムが使用されます。
Phase 2 negotiates the Security Associations for the GigaBeam custom security protocol that protects subscriber traffic and IPsec ESP that protects management traffic between the GigaBeam RCMs. In the GigaBeam environment, the Phase 2 exchange is IKE Quick Mode, without perfect forward secrecy (PFS). The information exchanged along with Quick Mode is protected by the ISAKMP SA. That is, all payloads except the ISAKMP header are encrypted. A detailed description of Quick Mode can be found in Section 5.5 of [IKE].
フェーズ2はGigaBeamのRCMの間で管理トラフィックを保護加入者トラフィックおよびIPsec ESPを保護GigaBeamカスタムセキュリティプロトコルのためのセキュリティアソシエーションをネゴシエートします。 GigaBeam環境では、フェーズ2交換は完全転送秘密（PFS）せずに、IKEクイックモードです。クイックモードと一緒に交換された情報は、ISAKMP SAで保護されています。つまり、ISAKMPヘッダを除くすべてのペイロードは暗号化されます。クイックモードの詳細な説明は、[IKE]のセクション5.5に見出すことができます。
When the Security Association is no longer needed, the ISAKMP Delete Payload is used to tell the peer GigaBeam device that it is being discarded.
セキュリティアソシエーションが不要になった場合、ISAKMP削除ペイロードは、それが破棄されているピアGigaBeamデバイスを伝えるために使用されていません。
Each GigaBeam device generates its own public/private key pair. This generation is performed at the factory, and the public key is certified by a Certification Authority (CA) in the factory. The certificate includes a name of the following format:
各GigaBeamデバイスは、自身の公開鍵/秘密鍵のペアを生成します。この世代は工場で行われ、公開鍵は、工場での認証局（CA）によって認定されています。証明書は、次の形式の名前が含まれています。
C=US O=GigaBeam Corporation OU=GigaBeam WiFiber(tm) SerialNumber=<device-model-identifier>/<device-serial-number>
C = US O = GigaBeam株式会社OU = GigaBeam WiFiber（登録商標）のSerialNumber = <デバイスモデル識別子> / <デバイスのシリアル番号>
The ISAKMP Certificate Payload is used to transport certificates, and in the GigaBeam environment, the "X.509 Certificate - Signature" certificate encoding type (indicated by a value of 4) is always used.
ISAKMP証明書ペイロードは、証明書を輸送するために使用され、そしてGigaBeam環境では、「X.509証明書 - 署名」（4の値によって示される）証明書の符号化タイプが常に使用されます。
GigaBeam devices are always installed in pairs. At installation time, each one is configured with the device model identifier and device serial number of its peer. The device model identifier and device serial number of a backup device can also be provided. An access control check is performed when certificates are exchanged. The certificate subject name must match one of these configured values, and the certification path must validate to a configured trust anchor, such as the GigaBeam Root CA, using the validation rules in [PKIX1].
GigaBeamデバイスは常にペアでインストールされています。インストール時に、それぞれがそのピアのデバイスモデル識別子、デバイスのシリアル番号で構成されています。バックアップデバイスのデバイスモデル識別子、デバイスのシリアル番号を設けることもできます。証明書が交換されたときに、アクセス制御チェックが行われます。証明書のサブジェクト名は、これらの構成のいずれかの値と一致する必要があり、及び認証パスは、[PKIX1]で検証ルールを使用して、そのようなGigaBeamルートCAとして構成されたトラストアンカーに検証しなければなりません。
With IKE, several possible Diffie-Hellman groups are supported. These groups originated with the Oakley protocol and are therefore called "Oakley Groups".
IKEでは、いくつかの可能性のDiffie-Hellmanのグループがサポートされています。これらのグループは、オークリーのプロトコルで発信され、したがって「オークリーグループ」と呼ばれています。
GigaBeam devices use group 14, which is described in Section 3 of [MODP].
GigaBeamデバイスは[MODP]のセクション3に記載されているグループ14を使用します。
The ISAKMP proposal syntax was specifically designed to allow for the simultaneous negotiation of multiple Phase 2 security protocol suites. The identifiers for the IPsec Domain of Interpretation (DOI) are given in [IPDOI].
ISAKMP提案の構文は、具体的には、複数のフェーズ2のセキュリティプロトコルスイートの同時交渉を可能にするように設計されました。解釈（DOI）のIPsecのドメインのための識別子は、[IPDOI]に記載されています。
The GigaBeam custom security protocol has been assigned the PROTO_GIGABEAM_RADIO protocol identifier, with a value of 5.
GigaBeamカスタムセキュリティプロトコルは、5の値で、PROTO_GIGABEAM_RADIOプロトコル識別子が割り当てられています。
The PROTO_GIGABEAM_RADIO specifies the use of the GigaBeam radio link frame structure, which uses a single algorithm for both confidentiality and authentication. The following table indicates the algorithm values that are currently defined.
PROTO_GIGABEAM_RADIOは、機密性と認証の両方のために単一のアルゴリズムを使用GigaBeam無線リンクフレーム構造の使用を指定します。以下の表は、現在定義されているアルゴリズム値を示しています。
Transform ID Value
------------ -----
RESERVED 0
GIGABEAM_AES128_GCM 1
GIGABEAM_AES128_GCM requires 20 octets of keying material (called KEYMAT in [IKE]). The first 16 octets are the 128-bit AES key, and the remaining four octets are used as the salt value in the AES counter block.
GIGABEAM_AES128_GCMは（[IKE]でKEYMAT呼ばれる）鍵材料の20個のオクテットを必要とします。第16オクテットは、128ビットのAES鍵であり、残りの4つのオクテットはAESカウンタブロック中の塩の値として使用されます。
Presently, AES with a 128-bit key is the only encryption algorithm that is supported. Other encryption algorithms could be registered in the future.
現在、128ビットの鍵とAESがサポートされている唯一の暗号化アルゴリズムです。他の暗号化アルゴリズムは、将来的に登録することができます。
The following table lists the assigned values for the Identification Type field found in the ISAKMP Identification Payload.
次の表は、ISAKMP IDペイロードで見つかった識別Typeフィールドに割り当てられた値を示します。
ID Type Value
------- -----
RESERVED 0
ID_IPV4_ADDR 1
ID_FQDN 2
ID_USER_FQDN 3
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
ID_DER_ASN1_DN 9
ID_DER_ASN1_GN 10
ID_KEY_ID 11
The ID_DER_ASN1_DN will be used when negotiating security associations for use with the GigaBeam custom security protocol. The provided distinguished name must match the peer's subject name provided in the X.509 certificate.
GigaBeamカスタムセキュリティプロトコルで使用するためのセキュリティアソシエーションをネゴシエートするときID_DER_ASN1_DNが使用されます。提供識別名は、X.509証明書で提供ピアのサブジェクト名と一致する必要があります。
The least significant bit of the Security Parameter Index (SPI) is used in the GigaBeam custom security protocol. When two GigaBeam custom security protocol security associations are active at the same time for communications in the same direction, the least significant bit of the SPI must be different to ensure that these active security associations can be distinguished by the single bit in the GigaBeam custom security protocol.
セキュリティパラメータインデックス（SPI）の最下位ビットはGigaBeamカスタムセキュリティプロトコルで使用されています。 2つのGigaBeamカスタムセキュリティプロトコルセキュリティアソシエーションは同じ方向に通信のために同時にアクティブであるときに、SPIの最下位ビットは、これらのアクティブなセキュリティアソシエーションがGigaBeamカスタムセキュリティに単一のビットによって区別することができることを確実にするために異なっていなければなりませんプロトコル。
The IKE exchange over the DCC must complete before subscriber data can be exchanged in the GigaBeam radio link frame payload. Since each radio link frame carries a small portion of an IP datagram, many radio link frames carrying all zero bits must be sent and received to complete the IKE exchange.
加入者データがGigaBeam無線リンクフレームのペイロードに交換することができます前に、DCCを超えるIKE交換が完了する必要があります。各無線リンクフレームをIPデータグラムの小さな部分を運ぶので、全てゼロのビットを搬送する多くの無線リンクフレームが送信され、IKE交換を完了するために受信されなければなりません。
Once the initial keying material is in place, the IKE exchanges to establish subsequent keying material can be performed concurrent with the transfer of subscriber data in the radio link frame payload. The KEYSEL field in the radio link frame is used to indicate which keying material is being used.
初期鍵材料が配置されると、その後の鍵材料を確立するためにIKE交換は無線リンクフレームのペイロード内の加入者データの転送と同時に行うことができます。無線リンクフレームにおけるKEYSELフィールドは、鍵材料が使用されているかを示すために使用されます。
The PN field in radio link frame provides a continuous indication of the number of frames that have been encrypted with a particular key. Once a threshold is exceeded, the IKE exchanges begin to establish the replacement keying material. Currently, the exchanges begin when half of the packet numbers have been used, but any threshold can be employed, as long as the replacement keying material is available before the packet counters are exhausted.
無線リンクフレームにおけるPNフィールドは、特定のキーで暗号化されたフレームの数の連続的な表示を提供します。しきい値を超えると、IKE交換は、交換鍵材料を確立することを始めます。現在、取引所は、パケット数の半分が使用されてきたが、いずれかのしきい値は限りパケットカウンタが排出される前に、材料をキーイング交換が利用可能になると、使用することができたときに始まります。
The security considerations in [IKE], [OAKLEY], [PKCS1], and [ESP] apply to the security system defined in this document.
セキュリティの考慮事項は、[IKE]は、[OAKLEY]は、[PKCS1]、および[ESP]この文書で定義されたセキュリティシステムに適用されます。
Confidentiality and integrity are provided by the use of negotiated algorithms. AES-GCM [GCM] is used with the GigaBeam custom security protocol to provide confidentiality and integrity protection of subscriber traffic on the radio link. AES-CBC [CBC] and HMAC-SHA-1 [HMAC] are used with IPsec ESP [ESP] to provide confidentiality and integrity protection of management traffic between the radio control modules.
機密性と完全性を交渉したアルゴリズムを使用することによって提供されています。 AES-GCM [GCM]無線リンク上の加入者トラフィックの機密性と完全性保護を提供するGigaBeamカスタムセキュリティプロトコルで使用されています。 AES-CBC [CBC]およびHMAC-SHA-1 [HMAC]で使用されたIPsec ESP [ESP]無線制御モジュールとの間の管理トラフィックの機密性と完全性保護を提供します。
AES-GCM makes use of AES Counter mode to provide confidentiality. Unfortunately, it is very easy to misuse counter mode. If counter block values are ever used for more than one frame with the same key, then the same key stream will be used to encrypt both frames, and the confidentiality guarantees are voided. Using AES Counter mode with the same counter values to encrypt two plaintexts under the same key leaks the plaintext. The automated key management described here is intended to prevent this from ever happening.
AES-GCMは、機密性を提供するために、AESカウンタモードを使用しています。残念ながら、カウンタモードを誤用するのは非常に簡単です。カウンタブロック値は、これまでと同じキーを持つ複数のフレームに使用されている場合は、同じキーストリームは、両方のフレームを暗号化するために使用され、機密性の保証が無効とされています。同じカウンタ値でAESカウンタモードを使用すると、同じキー漏洩の下に2つの平文平文を暗号化します。ここで説明する自動化された鍵管理は、これまで起きてからこれを防止するためです。
Since AES has a 128-bit block size, regardless of the mode employed, the ciphertext generated by AES encryption becomes distinguishable from random values after 2^64 blocks are encrypted with a single key. Since the GigaBeam radio link frame allows for up to 2^40 fixed-length frames in a single security association, there is no possibility for more than 2^64 blocks to be encrypted with one key.
AESは、128ビットのブロックサイズを有するので、2 ^ 64ブロックは、単一の鍵で暗号化された後に関わらず、使用モードの、AES暗号化によって生成された暗号文は、ランダムな値から識別可能となります。 GigaBeam無線リンクフレームは、単一のセキュリティアソシエーションに最大2 ^ 40固定長フレームを可能にするため、一つのキーで暗号化される以上2 ^ 64ブロックのための可能性はありません。
The lifetime of a particular AES key can be shorter than 2^40 frames. A smaller threshold can be used as a trigger to transition to the next key. This capability allows straightforward implementation of policies that require the key to be changed after a particular volume of traffic or a particular amount of time.
特定のAESキーの有効期間は2 ^ 40フレームよりも短くすることができます。小さな閾値は、次のキーへの移行をトリガーとして使用することができます。この機能は、キーを必要とするポリシーの簡単な実装は、トラフィックの特定のボリュームまたは特定の時間後に変更することができます。
There are fairly generic precomputation attacks against all block cipher modes that allow a meet-in-the-middle attack against the key. These attacks require the creation and searching of huge tables of ciphertext associated with known plaintext and known keys. Assuming that the memory and processor resources are available for a precomputation attack, then the theoretical strength of AES Counter mode (and any other block cipher mode) is limited to 2^(n/2) bits, where n is the number of bits in the key. The use of long keys is the best countermeasure to precomputation attacks. The unpredictable nonce value in the counter block significantly increases the size of the table that the attacker must compute to mount a successful precomputation attack.
キーに対する中間一致攻撃を許可するすべてのブロック暗号モードに対してかなり一般的な事前計算攻撃があります。これらの攻撃は、既知の平文と知られたキーに関連付けられた暗号文の巨大なテーブルの作成と検索を必要としています。メモリとプロセッサリソースが事前計算攻撃に利用可能であると仮定すると、AESカウンタモード（および他の任意のブロック暗号モード）の理論強度は、nはビット数である2 ^（N / 2）ビットに制限されていますキー。長いキーを使用すると、攻撃を事前計算するための最良の対策です。カウンタブロックにおける予測不可能なノンス値が大きく攻撃が成功した事前計算攻撃を仕掛けるために計算しなければならないテーブルのサイズを増大させます。
Rekeying with Quick Mode results in new keys to protect GigaBeam radio link frames; however, these keys are generated from the same Diffie-Hellman shared secret. In order to limit the amount of data that would be exposed by the disclosure of this Diffie-Hellman shared secret or the associated Diffie-Hellman private key, implementations should periodically rekey using a new Phase 1 exchange.
GigaBeam無線リンクフレームを保護するために、新しいキーでクイックモードの結果と再入力。しかし、これらのキーは、同じディフィー・ヘルマン共有シークレットから生成されています。このディフィー・ヘルマンの開示によって露出されるデータの量を制限するために、共有秘密または関連のDiffie-Hellmanの秘密鍵は、実装は、定期的に新しいフェーズ1交換を使用リキーべきです。
Diffie-Hellman exponents used in IKE Phase 1 should be erased from memory immediately after use. Likewise, AES and HMAC-SHA-1 keying material should be erased from memory when it is no longer needed.
IKEフェーズ1で使用されるのDiffie-Hellman指数は、使用後直ちにメモリから消去されなければなりません。それが不要になったとき同様に、AESとHMAC-SHA-1の鍵材料は、メモリから消去されるべきではありません。
This security solution makes use of IKEv1 [IKE]. IKEv1 was selected over IKEv2 [IKEv2] primarily due to the availability of an implementation for the processing environment. The use of IKEv2 would provide some useful capabilities, such as Diffie-Hellman group negotiation. These additional capabilities would not significantly improve the security of the overall key management solution that runs on the two-node IP network.
このセキュリティソリューションは、IKEv1の[IKE]を使用しています。 IKEv1のは、主として処理環境の実装の利用可能性のIKEv2 [IKEv2の】上に選択しました。 IKEv2の使用は、このようなのDiffie-Hellmanグループの交渉など、いくつかの便利な機能を、提供します。これらの追加機能は大幅に2ノードのIPネットワーク上で動作し、全体的な鍵管理ソリューションのセキュリティを改善しないでしょう。
IANA has assigned one IPsec Security Protocol Identifier in http://www.iana.org/assignments/isakmp-registry for PROTO_GIGABEAM_RADIO. It was assigned the value 5.
IANAはPROTO_GIGABEAM_RADIOためhttp://www.iana.org/assignments/isakmp-registryに1のIPsecセキュリティプロトコル識別子が割り当てられています。これは、値5を割り当てられました。
[CBC] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques," NIST Special Publication 800-38A, December 2001.
NIST Special Publication 800-38A、2001年12月：[CBC] Dworkin、M.、 "方法と技術、オペレーションのブロック暗号モードのための勧告"。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[ESP-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[ESP-CBC]フランケル、S.、グレン、R.、およびS.ケリー、 "AES-CBC暗号アルゴリズムおよびIPSecでの使用"、RFC 3602、2003年9月。
[ESP-GCM] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[ESP-GCM] Viega、J.とD.マグリュー、 "IPsecのカプセル化セキュリティペイロード（ESP）におけるガロア/カウンタモード（GCM）の使用"、RFC 4106、2005年6月。
[ESP-HMAC] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[ESP-HMAC] Madson、C.およびR.グレン、 "ESPおよびAH内HMAC-SHA-1-96の使用"、RFC 2404、1998年11月。
[GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of Operation (GCM)", Submission to NIST. http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ gcm/gcm-spec.pdf, January 2004. [Soon: NIST SP 800-38D.]
[GCM]マグリュー、D.およびJ. Viega、 "操作のガロア/カウンタ・モード（GCM）"、NISTに提出。 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ GCM / GCM-spec.pdf、2004年1月[すぐ：NIST SP 800-38D。]
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[IKEv2] Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", RFC 2306, December 2005.
[IKEv2の]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 2306、2005年12月。
[IPDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[IPDOI]パイパー、D.、 "ISAKMPのための解釈のインターネットIPセキュリティー領域"、RFC 2407、1998年11月。
[MODP] Kivinen, T. and M. Kojo. "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[MODP] Kivinen、T.及びM.古城。 、RFC 3526、2003年5月 "インターネット鍵交換（IKE）のためのより多くのモジュラー指数（MODP）のDiffie-Hellmanグループ"。
[OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC 2412, November 1998.
[OAKLEY]オーマン、H.、 "オークリーキー決意プロトコル"、RFC 2412、1998年11月。
[PKCS1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998.
[PKCS1] Kaliski、B.、 "PKCS＃1：RSA暗号化バージョン1.5"、RFC 2313、1998年3月。
[PKIX1] 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.
[PKIX1] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[PPP]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
The authors thank Bob Sutherland and Dave Marcellas for their contributions and review.
作者は彼らの貢献とレビューのためにボブ・サザーランドとDave Marcellasに感謝します。
Authors' Addresses
著者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley氏ビジルセキュリティ、LLC 918春小山Driveハーンドン、VA 20170 USA
EMail: housley@vigilsec.com
メールアドレス：housley@vigilsec.com
Alan Corry GigaBeam Corporation 470 Springpark Place, Suite 900 Herndon, VA 20170 USA
アラン・コリーGigaBeam株式会社470 Springparkプレイス、スイート900ハーンドン、VA 20170 USA
EMail: publications@gigabeam.com
メールアドレス：publications@gigabeam.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。