[要約] RFC 4705は、GigaBeam高速無線リンク暗号化に関する規格であり、高速無線リンクのセキュリティを向上させることを目的としています。
Network Working Group R. Housley
Request for Comments: 4705 Vigil Security
Category: Informational A. Corry
GigaBeam
October 2006
GigaBeam High-Speed Radio Link Encryption
Gigabeam高速無線リンク暗号化
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).
Copyright（c）The Internet Society（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.
このドキュメントでは、GigabeamがWifiber（TM）ファミリーの無線リンク製品の一部として使用する暗号化と主要な管理について説明しています。セキュリティソリューションは、他のワイヤレス製品開発の取り組みに同等の機能が含まれることを期待して文書化されています。
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（TM）製品ファミリは、高速ポイントツーポイントラジオリンクを提供します。データレートは、約1マイルの距離で1ギガビット/秒を超えています。トランスミッションビーム幅は1度未満です。つまり、攻撃者が送信機と受信機の間にいるか、攻撃者がレシーバーのすぐ後ろにいる場合、信号を傍受しようとする試みが最も成功します。傍受が可能なため、一部の顧客は、無線リンク上のデータに対して機密性と整合性保護を必要とします。このドキュメントでは、これらのセキュリティサービスを提供するためにGigabeamによって設計および展開されたセキュリティソリューションについて説明します。
The GigaBeam security solution employs:
Gigabeam Security Solutionが採用しています。
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]を使用して、無線コントロールモジュール間の管理トラフィックの機密性と整合性保護を提供します。
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 AES-CBC [CBC]およびHMAC-SHA-1 [HMAC]はIKEプロトコル[IKE]を使用して、無線制御モジュール間の主要な管理トラフィックの機密性と整合性保護を提供します。と
o OAKLEY key agreement [OAKLEY] and RSA digital signatures [PKCS1] are used with IKE to establish keying material and to provide authentication.
o Oakley Key Agreement [Oakley]およびRSA Digital Signatures [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は、光ファイバーケーブルを介したギガビットイーサネットを使用して通常通信する2つのデバイスの接続を示しています。
+---------+ +----------+ +----------+ +---------+
| | | +----/ | | | |
| Network | | GigaBeam | / | GigaBeam | | Network |
| Device +=====+ Radio | /---- + Radio +=====+ Device |
| | | | | | | |
+---------+ ^ +----------+ ^ +----------+ ^ +---------+
| | |
| | |
Gigabit Ethernet | Gigabit Ethernet
GigaBeam Radio Link
Figure 1. GigaBeam Radio Link Example.
図1. Gigabeam Radio Linkの例。
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 Radio Controlモジュール（RCM）は、このコーディングを削除して、8ビット文字を回復し、文字がコントロールコードであるかどうかを示しています。無線リンクフレームは、224の10ビット入力単語から構成されており、4ウェイインターリーブ（56,50,10）リードソロモンフォワードエラー補正（FEC）ブロックが採用されています。8b/10b形式からのギガビットイーサネットデータの変換は、各フレームに224ビットの追加容量を作成し、64b/65bブロックコードを使用して9ビットデータを再コーディングすることで別の196ビットが獲得されます。この追加の420ビットの容量は、FECおよびリンク制御に必要なフレーミングオーバーヘッドに使用されます。
The GigaBeam radio link frame fields are summarized in Figure 2, which also provides the length of each field in bits.
Gigabeam Radio Link Frameフィールドは図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.
同期同期フィールド、11ビットバーカーコード。常に '101101111000'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キーセレクター - このフレームに適切なキーレジスタを選択します。暗号化キー間のシームレスなロールオーバーを可能にするために、2つの重要なレジスタが維持されます。
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データブロックごとに1つを制御するビットを制御します。ビットが設定されている場合、データフィールドの対応する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.
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.
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.
チェックフォワードエラー修正チェック値-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.
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]は、データ制御チャネル上のすべての非IKトラフィックを保護するために通常の方法で使用されます。IPSEC ESPは、[ESP-CBC]および[ESP-HMAC]で説明されているように、[ESP-CBC]およびHMAC-SHA-1で説明されているように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.
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;
o セクション3.2で説明されているように、フォワードエラー補正（FEC）処理。
o scrambling as described in Section 3.3; and
o セクション3.3で説明されているようにスクランブル。と
o differential encoding as described in Section 3.4.
o セクション3.4で説明されている微分エンコーディング。
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には2つの重要なレジスタが含まれています。単一ビットキーセルフィールドは、フレームに2つのレジスタのどれが使用されたかを示します。
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ビットパケット番号が含まれています。同じキーで暗号化された複数のフレームに同じカウンター値を使用してはなりません。128ビットカウンターブロックは、図3に示すように構築されています。AESカウンターブロックの最初の96ビットは、AES-GCMアルゴリズムの説明のNonCEと呼ばれます。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フィールドは認証されたヘッダーデータとして扱われ、整合性保護されていますが、暗号化されていません。データフィールドは暗号化され、認証されています。タグフィールドには、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ビットシンボル用に設計されたReed-Solomonコード（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.
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）です。同期パターンを除くフレームのすべての単語は、この線形フィードバックシフトレジスタ（LFSR）を使用して伝送前にスクランブルされます。LFSRは、最初の処理ビットの前に、各フレームの開始時にすべてのものに初期化されます。各処理された入力ビットには、x15タップの出力にmodulo 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ビットがエンコードされます。したがって、出力ビットは、以前に送信されたエンコードされたビットを使用して、エンコードされていないビットをXaringした結果です。
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.
レセプションでは、補完的な操作が実行され、デコードされたデータストリームが生成されます。BitStreamは、受信したエンコードされたビットと以前に受信したエンコードビットをXaringすることにより形成されます。
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つのインターネットセキュリティ協会と主要な管理プロトコル（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エクスチェンジはIKEクイックモードであり、完全なフォワード秘密（PFS）がありません。クイックモードとともに交換される情報は、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削除ペイロードを使用して、ピアギガベムデバイスに廃棄されていることを伝えます。
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>
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.
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 Root 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 Proposalの構文は、複数のフェーズ2セキュリティプロトコルスイートの同時交渉を可能にするように特異的に設計されました。解釈のIPSECドメイン（DOI）の識別子は[IPDOI]に与えられます。
The GigaBeam custom security protocol has been assigned the PROTO_GIGABEAM_RADIO protocol identifier, with a value of 5.
Gigabeam Custom Security Protocolには、値が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 Radio Linkフレーム構造の使用を指定します。次の表は、現在定義されているアルゴリズム値を示しています。
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には、20オクテットのキーイング材料が必要です（[ike]でkeymatと呼ばれます）。最初の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 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.
ID_DER_ASN1_DNは、Gigabeamカスタムセキュリティプロトコルで使用するためにセキュリティ協会を交渉するときに使用されます。提供された著名な名前は、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.
Gigabeam Custom Security Protocolでは、セキュリティパラメーターインデックス（SPI）の最も重要なビットが使用されています。2つのGigabeamカスタムセキュリティプロトコルセキュリティアソシエーションが同時にアクティブである場合、同じ方向に通信するために、SPIの最も重要なビットは、Gigabeam Custom Securityのシングルビットによってこれらのアクティブセキュリティアソシエーションが区別できるようにするために異なる必要がありますプロトコル。
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 Radio Link Frame Payloadでサブスクライバーデータを交換する前に、DCCを介したIKE Exchangeを完了する必要があります。各ラジオリンクフレームにはIPデータグラムのごく一部があるため、すべてのゼロビットを運ぶ多くの無線リンクフレームを送信して受信して、IKE Exchangeを完了する必要があります。
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は、ラジオリンクフレームのペイロードでサブスクライバーデータの転送と同時にその後のキーイング材料を確立するために交換します。ラジオリンクフレームのキーセルフィールドは、どのキーイング材料が使用されているかを示すために使用されます。
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.
Radio Linkフレームの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ビットサイズであるため、使用されているモードに関係なく、AES暗号化によって生成される暗号文は、2^64ブロックが単一のキーで暗号化された後、ランダム値と区別できます。Gigabeam Radio Link Frameは、単一のセキュリティアソシエーションで最大2^40の固定長フレームを可能にするため、1つのキーで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.
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.
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 Groupの交渉など、いくつかの有用な機能を提供します。これらの追加機能は、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.
[CBC] Dworkin、M。、「操作のブロックモードの推奨：方法と技術」、Nist Special Publication 800-38A、2001年12月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP] Kent、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] Frankel、S.、Glenn、R。、およびS. Kelly、「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. McGrew、「セキュリティペイロードをカプセル化する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. Glenn、「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] McGrew、D。およびJ. Viega、「Galois/Counter Mode of Operation（GCM）」、NISTへの提出。http://csrc.nist.gov/cryptotoolkit/modes/proposedmodes/ gcm/gcm spec.pdf、2004年1月。[SOON：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.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[Ike] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[IKEv2] Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", RFC 2306, December 2005.
[IKEV2] Kaufman、C。、「The Internet Key Exchange（IKEV2）Protocol」、RFC 2306、2005年12月。
[IPDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[IPDOI] Piper、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. Kojo。「インターネットキーエクスチェンジ（IKE）のモジュール指数（MODP）diffie-hellmanグループ」、RFC 3526、2003年5月。
[OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC 2412, November 1998.
[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.、Polk、W.、Ford、W.、およびD. Solo、「インターネット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.
著者は、Bob SutherlandとDave Marcellasの貢献とレビューに感謝します。
Authors' Addresses
著者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
EMail: housley@vigilsec.com
Alan Corry GigaBeam Corporation 470 Springpark Place, Suite 900 Herndon, VA 20170 USA
Alan Corry Gigabeam Corporation 470 Springpark Place、Suite 900 Herndon、VA 20170 USA
EMail: publications@gigabeam.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。