RFC4705 日本語訳
4705 GigaBeam High-Speed Radio Link Encryption. R. Housley, A. Corry. October 2006. (Format: TXT=30926 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Housley
Request for Comments: 4705 Vigil Security
Category: Informational A. Corry
GigaBeam
October 2006
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4705年の不寝番セキュリティカテゴリ: 情報のA.コリーGigaBeam2006年10月
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)インターネット協会(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によって使用された暗号化とかぎ管理を説明します。 セキュリティソリューションは他のワイヤレス製品開発努力が匹敵する能力を含むという望みに記録されます。
Housley & Corry Informational [Page 1] RFC 4705 GigaBeam Radio Link Encryption October 2006
Housleyとコリーの情報[1ページ]のRFC4705GigaBeamラジオは暗号化2006年10月にリンクされます。
1. Introduction
1. 序論
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セキュリティソリューション雇用:
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 IPsecと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 IKEとAES-CBC[CBC]とHMAC-SHA-1[HMAC]はかぎ管理トラフィックの秘密性と保全保護をラジコンモジュールの間に提供するために[IKE]について議定書の中で述べます。 そして
o OAKLEY key agreement [OAKLEY] and RSA digital signatures
[PKCS1] are used with IKE to establish keying material and to
provide authentication.
o オークリーの主要な協定[オークリー]と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はカスタムセキュリティプロトコルと共に超能力[超能力-GCM]における使用と非常に同様の方法で使用されます。
Housley & Corry Informational [Page 2] RFC 4705 GigaBeam Radio Link Encryption October 2006
Housleyとコリーの情報[2ページ]のRFC4705GigaBeamラジオは暗号化2006年10月にリンクされます。
2. GigaBeam High-Speed Radio Link Overview
2. GigaBeamの高速ラジオリンク概要
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は通常、光ファイバーケーブルの上でGigabitイーサネットを使用することで交信する2台のデバイスの接続を例証します。
+---------+ +----------+ +----------+ +---------+
| | | +----/ | | | |
| Network | | GigaBeam | / | GigaBeam | | Network |
| Device +=====+ Radio | /---- + Radio +=====+ Device |
| | | | | | | |
+---------+ ^ +----------+ ^ +----------+ ^ +---------+
| | |
| | |
Gigabit Ethernet | Gigabit Ethernet
GigaBeam Radio Link
+---------+ +----------+ +----------+ +---------+ | | | +----/ | | | | | ネットワーク| | GigaBeam| / | GigaBeam| | ネットワーク| | デバイス+=====+ ラジオ| /---- + ラジオ+=====+ デバイス| | | | | | | | | +---------+ ^ +----------+ ^ +----------+ ^ +---------+ | | | | | | ギガビットイーサネット| ギガビットイーサネットGigaBeamラジオリンク
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 Radio Control Module(RCM)は、8ビットのキャラクタとキャラクタが制御コードであるかどうかしるしを回復するためにこのコード化を取り除きます。 ラジオリンクフレームは224の10ビットの入力単語から建築されます、そして、はさみ込まれた(56、50、10)リード-ソロモンForward Error Correction(FEC)が妨げる4ウェイは採用しています。 8B/10B形式からのGigabitイーサネットデータの変換は各フレームの追加容量の224ビットを作成します、そして、64B/65Bブロック・コードを使用することで9ビットのデータを再コード化することによって、もう196ビットを獲得します。 容量の追加この420ビットはFECとリンク制御に必要である縁どりオーバーヘッドに使用されます。
Housley & Corry Informational [Page 3] RFC 4705 GigaBeam Radio Link Encryption October 2006
Housleyとコリーの情報[3ページ]のRFC4705GigaBeamラジオは暗号化2006年10月にリンクされます。
2.1. GigaBeam Radio Link Frame Format
2.1. GigaBeamラジオリンクフレーム形式
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
フィールド長記述----- ------ ----------- このフレームPN40AES-GCM Packet Number FLAGSにおいて、それのAESキーが使用されていたSYNC11Frame Synchronization Pattern('10110111000'b)KEYSEL1Indicatesは4の10ビットのシンボル(56、50)のためのCHECK240リード-ソロモンCheck Wordsがコード化する代替のFECアルゴリズムのためにDCC8Data Communications Channel DATA1792Data(28暗号化された64B/65Bコードブロック)TAG96Authentication Tag SPARE24Reservedを28Controlビットと、それぞれの64B/65Bデータあたり1ビット妨げます。
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 Synchronization分野、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 Key Selector--このフレームのための適切な主要なレジスタを選択してください。 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 Packet Number--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.
FLAGS Controlビットであり、それぞれの64B/65Bデータ・ブロック単位の1つはDATA分野で運ばれました。 ビットが設定されるなら、DATA分野での対応する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 Data Communications Channel--各フレームは二地点間データ通信チャンネルの1つの八重奏を2つのラジコンモジュールの間まで運びます。 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がブロックをコード化するので、DATA Subscriberデータは運ばれました。 この分野は暗号化されていました、そして、保全はAES-GCMによって保護されました。
Housley & Corry Informational [Page 4] RFC 4705 GigaBeam Radio Link Encryption October 2006
Housleyとコリーの情報[4ページ]のRFC4705GigaBeamラジオは暗号化2006年10月にリンクされます。
TAG The authentication tag generated by AES-GCM, truncated to
96 bits.
認証タグが96ビットに先端を切られたAES-GCMで生成したTAG。
SPARE 24 bits, set to zero.
SPARE24ビット、ゼロにセットしてください。
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 Forwardエラー修正チェック価値--24 チェックシンボルは4ウェイはさみ込まれたリード-ソロモン(56、50、10)アルゴリズムで生成されます。 FECはいつもアクティブですが、選択的に修正を可能にすることができます。 また、各フレームに関しては、間違い、FEC処理がフレームに失敗したか否かに関係なく、FEC処理は誤り、シンボルの数をビットの数に返します。 この情報はリンクへのビット誤り率に関する見積りを許容します。
2.2. Data Communications Channel
2.2. データ通信チャンネル
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.
Data Communications Channel(DCC)分野は2RCMsの間の専用ポイントツーポイント接続を組み立てることにおける使用のためにそれぞれの2240年のビットのラジオリンクフレームで8ビットを予約します。DCC内容はRCMオペレーティングシステムに目に見える連続の非同期なチャンネルを提供するためにDCCビットストリームを処理するUniversal Asynchronous Receiver/送信機(UART)コントローラに接されます。 Pointからポイントへのプロトコル(PPP)[PPP]は、簡単な2ノードのインターネットプロトコル(IP)ネットワークを創設するのに連続のチャンネルの上に使用されます。 それぞれのIPデータグラムは多くのラジオリンクフレームの上に広げられます。 この2ノードのIPネットワークは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、超能力[超能力]は、データコントロールチャンネルの上のすべての非IKEトラフィックを保護するのに普通のファッションで使用されます。 [超能力-HMAC]で説明されるIPsec超能力雇用の[超能力-CBC]で説明されるAES-CBCとHMAC-SHA-1。
3. Radio Link Processing
3. ラジオリンク処理
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ブロックはDATA分野で運ばれます、そして、制御コードインディケータビットはFLAGS分野で運ばれます。 追加容量は縁どりオーバーヘッドに使用されます。
Housley & Corry Informational [Page 5] RFC 4705 GigaBeam Radio Link Encryption October 2006
Housleyとコリーの情報[5ページ]のRFC4705GigaBeamラジオは暗号化2006年10月にリンクされます。
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で説明される特異なコード化。
3.1. Encryption and Integrity Protection
3.1. 暗号化と保全保護
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つの主要なレジスタを含んでいます。 単一のビットKEYSEL分野は、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と40ビットのパケット番号によってラジオリンクフレームのPN分野から提供された32ビットの塩の値を含んでいます。 同じキーで暗号化された1個以上のフレームに同じ対価を使用してはいけません。 128ビットのカウンタブロックは図3に示されるように構成されます。 AESカウンタブロックの最初の96ビットはAES-GCMアルゴリズム記述でNonceと呼ばれます。 AES-GCMがそれ自身の使用にゼロと1のBLOCK値を使用することに注意してください。 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
フィールド長記述----- ------ ----------- ゼロがPN分野MBZ2で28Theseビット運ばれたPN40AES-GCM Packet Numberであったに違いないならIKE交換MBZ1の間に24Theseビット生成されたSALT32Salt価値はBLOCK4Blockカウンタが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とDATA分野を保護するのに使用されます。 FLAGS分野は認証されたヘッダー・データとして扱われます、そして、保護された保全ですが、それは暗号化されていません。 DATA分野は、暗号化されて、認証されます。 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
レセプション処理は復号化と保全の照合を実行します。 保全チェックがトラフィックの連続したストリームを維持するために失敗するなら、フレームをK30.7制御文字に取り替えます。 これら
Housley & Corry Informational [Page 6] RFC 4705 GigaBeam Radio Link Encryption October 2006
Housleyとコリーの情報[6ページ]のRFC4705GigaBeamラジオは暗号化2006年10月にリンクされます。
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.
通常、制御文字は、データ・ストリームで誤りをマークするのに使用されます。 暗号化と保全の照合がなければ、通常、これらの制御文字は8B/10Bの実行している不一致かコード誤りを示します。
3.2. Forward Error Correction (FEC)
3.2. 前進型誤信号訂正(FEC)
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「副-フレーム」に分類されます。 「副-フレーム」はシンボルインターリービングで形成されます。 リード-ソロモンCodeであり、(56、50)が10ビットのシンボルのために設計したRSは各「副-フレーム」に適用されます。
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.
このリードソロモンCodeは6つの誤りを検出して、各「副-フレーム」の中の3つの誤りを修正します。 FEC機能はいつもアクティブです。 しかしながら、デバッグをサポートするために受信データの修正を無効にするのは可能です。
3.3. Scrambler
3.3. 秘話装置
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)です。 この直線的なフィードバック・シフト・レジスタ(LFSR)を使用することでSYNCパターン以外のフレームのすべての単語がトランスミッションの前にスクランブルをかけられます。 LFSRは最初の処理ビットの前でそれぞれのフレームの始めのすべてのものに初期化されます。 それぞれの処理入力ビットは出力ビットを形成するx15蛇口の出力への加えられた法2です(すなわち、XOR)。
On reception, an identical process is performed after frame synchronization and prior to subsequent processing to recover the original bit pattern.
レセプションに、同じプロセスは、フレーム同期化の後とその後の処理の前にオリジナルのビット・パターンを回復するために実行されます。
3.4. Differential Encoding
3.4. 特異なコード化
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ビットは前の出力ビットからの変化としてコード化されます。 したがって、出力ビットは以前に伝えられたコード化されたビットで噛み付かれた暗号化されていなさXORingの結果です。
Housley & Corry Informational [Page 7] RFC 4705 GigaBeam Radio Link Encryption October 2006
Housleyとコリーの情報[7ページ]のRFC4705GigaBeamラジオは暗号化2006年10月にリンクされます。
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.
レセプションに、補数演算は、解読されたdatastreamを生産するために実行されるでしょう。 bitstreamは受け取られていることの噛み付かれた状態でコード化されたXORingによって形成されます、そして、以前に受け取られているのはビットをコード化しました。
4. Key Management
4. Key Management
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には、二相があります。 Phase1、twoインターネットSecurity AssociationとKey Managementプロトコル(ISAKMP)に、同輩は交信する安全で、認証されたチャンネルを確立します。 これはISAKMP Security Association(SA)と呼ばれます。 GigaBeam環境で、Phase1交換は署名と証明書があるIKE Aggressive Modeです。 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].
それはGigaBeam RCMsの間の管理トラフィックを保護します。フェーズ2が加入者トラフィックとIPsecを保護するGigaBeamのカスタムセキュリティプロトコルのためにSecurity Associationsを交渉する、超能力、GigaBeam環境で、Phase2交換はIKEクィックModeです、完全な前進の秘密保持(PFS)なしで。 クィックModeと共に交換された情報はISAKMP SAによって保護されます。 ISAKMPヘッダー以外のすなわちすべてのペイロードが暗号化されています。 [IKE]のセクション5.5でクィックModeの詳述を見つけることができます。
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.
Security Associationはもう必要でないときに、ISAKMP Delete有効搭載量が、それが捨てられていると同輩GigaBeamデバイスに言うのに使用されます。
4.1. Certificates
4.1. 証明書
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デバイスはそれ自身の公衆/秘密鍵組を生成します。 この世代は工場で実行されます、そして、公開鍵は工場の認証局(カリフォルニア)によって公認されます。 証明書は以下の形式の名前を含んでいます:
C=US O=GigaBeam Corporation OU=GigaBeam WiFiber(tm) SerialNumber=<device-model-identifier>/<device-serial-number>
Cは米国O=GigaBeam社のOU=GigaBeam WiFiber(tm)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 Certificate有効搭載量が運送認可証、および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
GigaBeamデバイスは組でいつもインストールされます。 インストール時に、各々は同輩のデバイスモデル識別子とデバイス通し番号によって構成されます。 また、バックアップデバイスのデバイスモデル識別子とデバイス通し番号を提供できます。 証明書を交換するとき、アクセス制御チェックを実行します。 証明書対象名は構成されたこれらの1つに合わなければなりません。
Housley & Corry Informational [Page 8] RFC 4705 GigaBeam Radio Link Encryption October 2006
Housleyとコリーの情報[8ページ]のRFC4705GigaBeamラジオは暗号化2006年10月にリンクされます。
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 Rootカリフォルニアなどのアンカーを構成された信頼に有効にしなければならなくて、合法化を使用すると[PKIX1]で統治される証明経路。
4.2. Oakley Groups
4.2. オークリーグループ
With IKE, several possible Diffie-Hellman groups are supported. These groups originated with the Oakley protocol and are therefore called "Oakley Groups".
IKEと共に、いくつかの可能なディフィー-ヘルマングループがサポートされます。 これらのグループは、オークリープロトコルを発して、したがって、「オークリーグループ」と呼ばれます。
GigaBeam devices use group 14, which is described in Section 3 of [MODP].
GigaBeamデバイスはグループ14を使用します。(それは、[MODP]のセクション3で説明されます)。
4.3. Security Protocol Identifier
4.3. セキュリティプロトコル識別子
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提案構文は、複数のPhaseの同時の交渉のために2つのセキュリティプロトコル群を許容するように明確に設計されました。 [IPDOI]でInterpretation(DOI)のIPsec Domainのための識別子を与えます。
The GigaBeam custom security protocol has been assigned the PROTO_GIGABEAM_RADIO protocol identifier, with a value of 5.
5の値でプロト_GIGABEAM_RADIOプロトコル識別子をGigaBeamのカスタムセキュリティプロトコルに割り当ててあります。
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.
プロト_GIGABEAM_RADIOはGigaBeamラジオリンク枠組構造の使用を指定します。(枠組構造は秘密性と認証の両方にただ一つのアルゴリズムを使用します)。 以下のテーブルは現在定義されるアルゴリズム値を示します。
Transform ID Value
------------ -----
RESERVED 0
GIGABEAM_AES128_GCM 1
ID値を変えてください。------------ ----- 予約された0_GIGABEAM_AES128GCM1
4.4. Keying Material
4.4. 材料を合わせます。
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はサポートされる唯一の暗号化アルゴリズムです。 将来、他の暗号化アルゴリズムを登録できました。
Housley & Corry Informational [Page 9] RFC 4705 GigaBeam Radio Link Encryption October 2006
Housleyとコリーの情報[9ページ]のRFC4705GigaBeamラジオは暗号化2006年10月にリンクされます。
4.5. Identification Type Values
4.5. 識別タイプ値
The following table lists the assigned values for the Identification Type field found in the ISAKMP Identification Payload.
以下のテーブルはISAKMP Identification有効搭載量で見つけられたIdentification 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
IDタイプ価値------- ----- 予約..ID..ID..ID..ユーザ..ID..サブネット..ID..ID..サブネット..ID..範囲..ID..範囲..ID..ID..ID..キー..ID
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証明書に提供された同輩の対象の名前に合わなければなりません。
4.6. Security Parameter Index
4.6. セキュリティパラメタインデックス
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.
Security Parameter Index(SPI)の最下位ビットはGigaBeamのカスタムセキュリティプロトコルに使用されます。 同じ方向によるコミュニケーションに、2人のGigaBeamの注文品を扱っているセキュリティプロトコルセキュリティ協会が同時に活動的であるときに、SPIの最下位ビットは、GigaBeamのカスタムセキュリティプロトコルの単一のビットでこれらの活動的なセキュリティ協会を区別できるのを保証するために異なっていなければなりません。
4.7. Key Management Latency
4.7. Key Management潜在
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分野は、どの合わせることの材料が使用されているかを示すのに使用されます。
Housley & Corry Informational [Page 10] RFC 4705 GigaBeam Radio Link Encryption October 2006
Housleyとコリーの情報[10ページ]のRFC4705GigaBeamラジオは暗号化2006年10月にリンクされます。
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交換は材料を合わせる交換を確立し始めます。 パケット番号の半分が現在使用されたとき、交換は始まりますが、どんな敷居も使うことができます、パケットカウンタが疲れ果てている前に材料を合わせる交換が利用可能である限り。
5. Security Considerations
5. セキュリティ問題
The security considerations in [IKE], [OAKLEY], [PKCS1], and [ESP] apply to the security system defined in this document.
[イケ]、[オークリー]、[PKCS1]、および[超能力]におけるセキュリティ問題は本書では定義されたセキュリティシステムに適用されます。
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.
交渉されたアルゴリズムの使用で秘密性と保全を提供します。ラジオリンクにおける加入者トラフィックの秘密性と保全保護を提供するのに、GigaBeamのカスタムセキュリティプロトコルと共にAES-GCM[GCM]を使用します。 AES-CBC[CBC]とHMAC-SHA-1[HMAC]はIPsecと共に使用されます。ラジコンモジュールの間で管理トラフィックの保護を秘密性と保全に提供する超能力[超能力]。
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 Counterモードを利用します。 残念ながら、カウンタモードを誤用するのは非常に簡単です。 カウンタブロック値が今までに1個以上のフレームに同じキーで使用されると、同じ主要なストリームは両方のフレームを暗号化するのに使用されるでしょう、そして、秘密性保証は欠如します。 同じキーの下の2つの平文を暗号化するのに同じ対価があるAES Counterモードを使用すると、平文は漏らされます。 ここで説明された自動化されたかぎ管理が、これが起こるのを防ぐことを意図します。
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が妨げる以上が1個のキーで暗号化される可能性が全くありません。
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
ジェネリック前計算攻撃はキーに対して中央で会っている攻撃を許すすべてのブロック暗号モードに反対して公正にいます。 これらの攻撃は知られている平文と知られているキーに関連している暗号文の巨大なテーブルを作成と探すことを必要とします。 メモリとプロセッサ資源がaに利用可能であると仮定します。
Housley & Corry Informational [Page 11] RFC 4705 GigaBeam Radio Link Encryption October 2006
Housleyとコリーの情報[11ページ]のRFC4705GigaBeamラジオは暗号化2006年10月にリンクされます。
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 Counterモード(そして、いかなる他のブロック暗号モードも)の理論上の強さは2^(n/2)ビットに制限されます。そこでは、nがキーのビットの数です。 長いキーの使用は前計算攻撃への最も良い対策です。 カウンタブロックの予測できない一回だけの値は攻撃者がうまくいっている前計算攻撃を仕掛けるために計算しなければならないテーブルのサイズをかなり増強します。
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.
クィックModeと共にRekeyingするのはGigaBeamラジオリンクフレームを保護するために新しいキーに結果として生じます。 しかしながら、これらのキーは同じディフィー-ヘルマン共有秘密キーから生成されます。 このディフィー-ヘルマン共有秘密キーか関連ディフィー-ヘルマン秘密鍵の公開で暴露されるデータ量を制限するために、実装は新しいPhase1交換を使用することで定期的にrekeyされるべきです。
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 Phase1で使用されるディフィー-ヘルマン解説者は使用直後メモリから消されるべきです。 それはもう必要でないときに、同様に、材料を合わせる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の使用はディフィー-ヘルマンのグループ交渉などの役に立ついくつかの能力を提供するでしょう。 これらの追加能力は2ノードのIPネットワークで動く総合的なかぎ管理解決のセキュリティをかなり向上させないでしょう。
6. IANA Considerations
6. IANA問題
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は_プロトGIGABEAM_RADIOのために http://www.iana.org/assignments/isakmp-registry で1IPsec SecurityのプロトコルIdentifierを割り当てました。 値5はそれに割り当てられました。
7. Informative References
7. 有益な参照
[CBC] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Methods and Techniques," NIST Special
Publication 800-38A, December 2001.
[CBC]ドーキン、M.、「ブロックのための推薦は運転モードを解きます」。 「方法とテクニック」、NISTの特別な公表800-38A、12月2001
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[超能力] ケント、S.、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC4303、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.
[超能力-CBC] フランケル、S.、グレン、R.、およびS.ケリー、「AES-CBCはIPsecと共にアルゴリズムとその使用を解きます」、RFC3602、2003年9月。
Housley & Corry Informational [Page 12] RFC 4705 GigaBeam Radio Link Encryption October 2006
Housleyとコリーの情報[12ページ]のRFC4705GigaBeamラジオは暗号化2006年10月にリンクされます。
[ESP-GCM] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
4106, June 2005.
[超能力-GCM] ViegaとJ.とD.マグリュー、「セキュリティ有効搭載量(超能力)を要約するIPsecにおけるガロア/カウンタモード(GCM)の使用」、RFC4106、2005年6月。
[ESP-HMAC] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
そして、[超能力-HMAC] マドソン、C.、およびR.グレン、「超能力の中のHMAC-SHA-1-96の使用、ああ、」、RFC2404、11月1998日
[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] NIST http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ gcm/gcm-spec.pdf、2004年1月までのマグリューとD.とJ.Viega、「ガロア/カウンタ運転モード(GCM)」Submission。 [すぐ:、NIST SP800-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.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[IKEv2] Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol",
RFC 2306, December 2005.
[IKEv2] 2005年12月のコーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」RFC2306。
[IPDOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[IPDOI]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、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)のための、より多くのModular Exponential(MODP)ディフィー-ヘルマングループ」、RFC3526、2003年5月。
[OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC
2412, November 1998.
[オークリー] Orman、H.、「オークリーの主要な決断プロトコル」、RFC2412、1998年11月。
[PKCS1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC
2313, March 1998.
[PKCS1]Kaliski、B.、「PKCS#1:」 1.5インチ(RFC2313)が1998に行進させるRSA暗号化バージョン
[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.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[ppp]シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
8. Acknowledgements
8. 承認
The authors thank Bob Sutherland and Dave Marcellas for their contributions and review.
作者は彼らの貢献とレビューについてボブ・サザーランドとデーヴMarcellasに感謝します。
Housley & Corry Informational [Page 13] RFC 4705 GigaBeam Radio Link Encryption October 2006
Housleyとコリーの情報[13ページ]のRFC4705GigaBeamラジオは暗号化2006年10月にリンクされます。
Authors' Addresses
作者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley不寝番セキュリティ、スプリング小山Driveハーンドン、LLC918ヴァージニア20170米国
EMail: housley@vigilsec.com
メール: housley@vigilsec.com
Alan Corry GigaBeam Corporation 470 Springpark Place, Suite 900 Herndon, VA 20170 USA
アランコリーGigaBeam社470のSpringpark場所、Suite900ハーンドン、ヴァージニア20170米国
EMail: publications@gigabeam.com
メール: publications@gigabeam.com
Housley & Corry Informational [Page 14] RFC 4705 GigaBeam Radio Link Encryption October 2006
Housleyとコリーの情報[14ページ]のRFC4705GigaBeamラジオは暗号化2006年10月にリンクされます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Housley & Corry Informational [Page 15]
Housleyとコリー情報です。[15ページ]
一覧
スポンサーリンク
