Network Working Group P. Karn
Request for Comments: 2522 Qualcomm
Category: Experimental W. Simpson
DayDreamer
March 1999
Photuris: Session-Key Management Protocol
Status of this Memo
このメモの位置付け
This document defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。著作権（C）フィリップ・カーンとウィリアムアレンシンプソン（1994年から1999年）。全著作権所有。
Abstract
抽象
Photuris is a session-key management protocol intended for use with the IP Security Protocols (AH and ESP). This document defines the basic protocol mechanisms.
Photurisは、IPセキュリティプロトコル（AHとESP）での使用を意図セッション鍵管理プロトコルです。このドキュメントでは、基本的なプロトコルメカニズムを定義します。
Table of Contents
目次
1. Introduction .......................................... 1
1.1 Terminology ..................................... 1
1.2 Protocol Overview ............................... 3
1.3 Security Parameters ............................. 5
1.4 LifeTimes ....................................... 6
1.4.1 Exchange LifeTimes .............................. 6
1.4.2 SPI LifeTimes ................................... 7
1.5 Random Number Generation ........................ 8
2. Protocol Details ...................................... 9
2.1 UDP ............................................. 9
2.2 Header Format ................................... 10
2.3 Variable Precision Integers ..................... 11
2.4 Exchange-Schemes ................................ 13
2.5 Attributes ...................................... 13
3. Cookie Exchange ....................................... 14
3.0.1 Send Cookie_Request ............................. 14
3.0.2 Receive Cookie_Request .......................... 15
3.0.3 Send Cookie_Response ............................ 15
3.0.4 Receive Cookie_Response ......................... 16
3.1 Cookie_Request .................................. 17
3.2 Cookie_Response ................................. 18
3.3 Cookie Generation ............................... 19
3.3.1 Initiator Cookie ................................ 19
3.3.2 Responder Cookie ................................ 20
4. Value Exchange ........................................ 21
4.0.1 Send Value_Request .............................. 21
4.0.2 Receive Value_Request ........................... 22
4.0.3 Send Value_Response ............................. 22
4.0.4 Receive Value_Response .......................... 23
4.1 Value_Request ................................... 24
4.2 Value_Response .................................. 25
4.3 Offered Attribute List .......................... 26
5. Identification Exchange ............................... 28
5.0.1 Send Identity_Request ........................... 29
5.0.2 Receive Identity_Request ........................ 29
5.0.3 Send Identity_Response .......................... 30
5.0.4 Receive Identity_Response ....................... 30
5.1 Identity_Messages ............................... 31
5.2 Attribute Choices List .......................... 33
5.3 Shared-Secret ................................... 34
5.4 Identity Verification ........................... 34
5.5 Privacy-Key Computation ......................... 36
5.6 Session-Key Computation ......................... 37
6. SPI Messages .......................................... 38
6.0.1 Send SPI_Needed ................................. 38
6.0.2 Receive SPI_Needed .............................. 39
6.0.3 Send SPI_Update ................................. 39
6.0.4 Receive SPI_Update .............................. 39
6.0.5 Automated SPI_Updates ........................... 40
6.1 SPI_Needed ...................................... 41
6.2 SPI_Update ...................................... 43
6.2.1 Creation ........................................ 44
6.2.2 Deletion ........................................ 45
6.2.3 Modification .................................... 45
6.3 Validity Verification ........................... 45
7. Error Messages ........................................ 46
7.1 Bad_Cookie ...................................... 47
7.2 Resource_Limit .................................. 47
7.3 Verification_Failure ............................ 48
7.4 Message_Reject .................................. 49
8. Public Value Exchanges ................................ 50
8.1 Modular Exponentiation Groups ................... 50
8.2 Moduli Selection ................................ 50
8.2.1 Bootstrap Moduli ................................ 51
8.2.2 Learning Moduli ................................. 51
8.3 Generator Selection ............................. 51
8.4 Exponent Selection .............................. 52
8.5 Defective Exchange Values ....................... 53
9. Basic Exchange-Schemes ................................ 54
10. Basic Key-Generation-Function ......................... 55
10.1 MD5 Hash ........................................ 55
11. Basic Privacy-Method .................................. 55
11.1 Simple Masking .................................. 55
12. Basic Validity-Method ................................. 55
12.1 MD5-IPMAC Check ................................. 55
13. Basic Attributes ...................................... 56
13.1 Padding ......................................... 56
13.2 AH-Attributes ................................... 57
13.3 ESP-Attributes .................................. 57
13.4 MD5-IPMAC ....................................... 58
13.4.1 Symmetric Identification ........................ 58
13.4.2 Authentication .................................. 59
13.5 Organizational .................................. 60
APPENDICES ................................................... 61
A. Automaton ............................................. 61
A.1 State Transition Table .......................... 62
A.2 States .......................................... 65
A.2.1 Initial ......................................... 65
A.2.2 Cookie .......................................... 66
A.2.3 Value ........................................... 66
A.2.4 Identity ........................................ 66
A.2.5 Ready ........................................... 66
A.2.6 Update .......................................... 66
B. Use of Identification and Secrets ..................... 67
B.1 Identification .................................. 67
B.2 Group Identity With Group Secret ................ 67
B.3 Multiple Identities With Group Secrets .......... 68
B.4 Multiple Identities With Multiple Secrets ....... 69
OPERATIONAL CONSIDERATIONS ................................... 70
SECURITY CONSIDERATIONS ...................................... 70
HISTORY ...................................................... 71
ACKNOWLEDGEMENTS ............................................. 72
REFERENCES ................................................... 73
CONTACTS ..................................................... 75
COPYRIGHT .................................................... 76
Photuris [Firefly] establishes short-lived session-keys between two parties, without passing the session-keys across the Internet. These session-keys directly replace the long-lived secret-keys (such as passwords and passphrases) that have been historically configured for security purposes.
Photuris [ホタル]は、インターネット経由でセッション鍵を渡さず、二者間の短命セッション鍵を確立します。これらのセッション・キーは、直接、歴史的なセキュリティ上の目的のために設定されている（例えば、パスワードやパスフレーズなど）長寿命の秘密鍵を交換してください。
The basic Photuris protocol utilizes these existing previously configured secret-keys for identification of the parties. This is intended to speed deployment and reduce administrative configuration changes.
基本的なPhoturisプロトコルは、当事者の識別のために、これらの既存の以前に設定した秘密鍵を利用しています。これは、導入を迅速化し、管理構成の変更を低減することを目的とします。
This document is primarily intended for implementing the Photuris protocol. It does not detail service and application interface definitions, although it does mention some basic policy areas required for the proper implementation and operation of the protocol mechanisms.
この文書は、主にPhoturisプロトコルを実装するためのものです。それはプロトコルメカニズムの適切な実装と運用に必要ないくつかの基本的な政策分野に言及しないが、それは、詳細サービスとアプリケーションインタフェース定義をしません。
Since the basic Photuris protocol is extensible, new data types and protocol behaviour should be expected. The implementor is especially cautioned not to depend on values that appear in examples to be current or complete, since their purpose is primarily pedagogical.
基本的なPhoturisプロトコルは拡張可能なので、新しいデータ型とプロトコルの動作が予想されなければなりません。実装者は、特に彼らの目的は、主に教育的であることから、現在または完全であることを例に表示される値に依存しないように注意を促しています。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC-2119].
この文書では、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" はならない、[RFC-2119]に記載されているように解釈されるべきです。
byte An 8-bit quantity; also known as "octet" in standardese.
8ビット量バイト。またstandardeseで「オクテット」として知られています。
exchange-value The publically distributable value used to calculate a shared-secret. As used in this document, refers to a Diffie-Hellman exchange, not the public part of a public/private key-pair.
交換価値共有秘密を計算するために使用される公に配布値。この文書で使用されるように、のDiffie-Hellman交換ではなく、公開鍵/秘密鍵ペアの公開部分をいいます。
private-key A value that is kept secret, and is part of an asymmetric public/private key-pair.
秘密保持、および非対称の公開鍵/秘密鍵ペアの一部であるプライベート・キーの値。
public-key A publically distributable value that is part of an asymmetric public/private key-pair.
非対称公開鍵/秘密鍵ペアの一部である公開鍵A公に配布値。
secret-key A symmetric key that is not publically distributable. As used in this document, this is distinguished from an asymmetric public/private key-pair. An example is a user password.
公に配布ではない対称鍵秘密鍵。この文書で使用されているように、これは非対称の公開鍵/秘密鍵のペアとは区別されます。例では、ユーザーのパスワードです。
Security Association (SA) A collection of parameters describing the security relationship between two nodes. These parameters include the identities of the parties, the transform (including algorithm and algorithm mode), the key(s) (such as a session-key, secret-key, or appropriate public/private key-pair), and possibly other information such as sensitivity labelling.
セキュリティアソシエーション（SA）2つのノード間の安全保障関係を記述するパラメータの集合。これらのパラメータは、（セッション・キー、秘密キー、または適切な公開鍵/秘密鍵のペアとして）キー（S）、（アルゴリズムとアルゴリズムモードを含む）変換、当事者のアイデンティティを含んで、そしておそらく他の情報感度ラベルなど。
Security Parameters Index (SPI) A number that indicates a particular set of uni-directional attributes used under a Security Association, such as transform(s) and session-key(s). The number is relative to the IP Destination, which is the SPI Owner, and is unique per IP (Next Header) Protocol. That is, the same value MAY be used by multiple protocols to concurrently indicate different Security Association parameters.
セキュリティパラメータインデックス（SPI）など変換（S）とセッション・キー（複数可）などのセキュリティ協会の下で使用さ片方向属性の特定のセットを示す数値。数はSPI所有者であるIP宛先への相対的であり、IP（次ヘッダ）プロトコルごとに一意です。これは、同じ値が同時に異なるセキュリティアソシエーションパラメータを示すために、複数のプロトコルで使用されるかもしれれます。
session-key A key that is independently derived from a shared-secret by the parties, and used for keying one direction of traffic. This key is changed frequently.
セッション・キーは独立当事者間で共有秘密に由来し、かつ、トラフィックの方向をキーイングするために使用されるキー。このキーは頻繁に変更されます。
shared-secret As used in this document, the calculated result of the Photuris exchange.
共有秘密Photuris交換のこの文書で使用され、計算された結果。
SPI Owner The party that corresponds to the IP Destination; the intended recipient of a protected datagram.
SPI所有者IP宛先に対応パーティ。保護されたデータグラムの意図した受信者。
SPI User The party that corresponds to the IP Source; the sender of a protected datagram.
SPIユーザーIPソースに対応するパーティ。保護されたデータグラムの送信者。
transform A cryptographic manipulation of a particular set of data. As used in this document, refers to certain well-specified methods (defined elsewhere). For example, AH-MD5 [RFC-1828] transforms an IP datagram into a cryptographic hash, and ESP-DES-CBC [RFC-1829] transforms plaintext to ciphertext and back again.
データの特定のセットの暗号化操作を変換します。本書で使用されるように、特定のウェルに指定方法（他の場所で定義される）を指します。例えば、AH-MD5 [RFC-1828]暗号ハッシュにIPデータグラムを変換し、ESP-DES-CBC [RFC-1829]は再び暗号文と平文を変換します。
Many of these terms are hierarchically related:
これらの用語の多くは、階層的に関連しています。
Security Association (bi-directional)
- one or more lists of Security Parameters (uni-directional)
-- one or more Attributes
--- may have a key
--- may indicate a transform
Implementors will find details of cryptographic hashing (such as MD5), encryption algorithms and modes (such as DES), digital signatures (such as DSS), and other algorithms in [Schneier95].
実装者は、（例えば、DSSなど）、デジタル署名、および他のアルゴリズム（例えば、DESなど）（例えば、MD5など）の暗号ハッシュの詳細、暗号化アルゴリズムおよびモード[Schneier95]であります。
The Photuris protocol consists of several simple phases:
Photurisプロトコルは、いくつかの簡単なフェーズで構成されます。
1. A "Cookie" Exchange guards against simple flooding attacks sent with bogus IP Sources or UDP Ports. Each party passes a "cookie" to the other.
1. A「クッキー」偽のIPソースまたはUDPポートに送信され、単純なフラッディング攻撃に対して、Exchangeガード。各当事者は、他に「クッキー」を渡します。
In return, a list of supported Exchange-Schemes are offered by the Responder for calculating a shared-secret.
その見返りに、サポートのExchangeスキームのリストは、共有秘密を計算するためレスポンダによって提供されています。
2. A Value Exchange establishes a shared-secret between the parties. Each party passes an Exchange-Value to the other. These values are used to calculate a shared-secret. The Responder remains stateless until a shared-secret has been created.
2. Aバリュー交換は、当事者間の共有秘密を確立します。各当事者は、他に、Exchangeに値を渡します。これらの値は、共有秘密を計算するのに使用されています。共有秘密が作成されるまでResponderはステートレスのまま。
In addition, supported attributes are offered by each party for use in establishing new Security Parameters.
また、サポートされる属性は、新しいセキュリティパラメータを確立するのに使用するため、各当事者によって提供されています。
3. An Identification Exchange identifies the parties to each other, and verifies the integrity of values sent in phases 1 and 2.
3.アン同定Exchangeは互いに相手を識別し、段階1及び2で送信された値の完全性を検証します。
In addition, the shared-secret provides a basis to generate separate session-keys in each direction, which are in turn used for conventional authentication or encryption. Additional security attributes are also exchanged as needed.
また、共有秘密は、次に、従来の認証や暗号化のために使用される各方向に別々のセッション鍵を生成するための基礎を提供します。必要に応じて追加のセキュリティ属性も交換されます。
This exchange is masked for party privacy protection using a message privacy-key based on the shared-secret. This protects the identities of the parties, hides the Security Parameter attribute values, and improves security for the exchange protocol and security transforms.
この交換は、共有秘密に基づいて、メッセージのプライバシー・キーを使用してパーティのプライバシー保護のためにマスクされています。これは、当事者のアイデンティティを保護するセキュリティパラメータの属性値を隠し、および交換プロトコルとセキュリティの変換のためのセキュリティが向上します。
4. Additional messages may be exchanged to periodically change the session-keys, and to establish new or revised Security Parameters.
4.追加のメッセージが定期的にセッション・キーを変更して、新規または改訂されたセキュリティパラメータを確立するために交換することができます。
These exchanges are also masked for party privacy protection in the same fashion as above.
これらの交換も、上記と同じ方法でパーティのプライバシー保護のためにマスクされています。
The sequence of message types and their purposes are summarized in the diagram below. The first three phases (cookie, exchange, and identification) must be carried out in their entirety before any Security Association can be used.
メッセージの種類とその目的のシーケンスは、以下の図にまとめられています。いずれかのセキュリティアソシエーションを使用することができます前に、最初の3つの段階（クッキー、交換、および識別）は、その全体で行われなければなりません。
Initiator Responder
========= =========
Cookie_Request ->
<- Cookie_Response
offer schemes
Value_Request ->
pick scheme
offer value
offer attributes
<- Value_Response
offer value
offer attributes
[generate shared-secret from exchanged values]
【交換値から共有秘密を生成]
Identity_Request -> make SPI pick SPI attribute(s) identify self authenticate make privacy key(s) mask/encrypt message <- Identity_Response make SPI pick SPI attribute(s) identify self authenticate make privacy key(s) mask/encrypt message
Identity_Request - >作るSPIピックSPI属性（s）は、自己認証が作る特定のプライバシーキー（S）マスク/暗号化メッセージ< - Identity_Response SPIピックSPI属性（S）自己認証を行い識別を行い、プライバシーキー（S）マスク/暗号化メッセージ
[make SPI session-keys in each direction]
【各方向のSPIセッション鍵を作ります]
SPI User SPI Owner
======== =========
SPI_Needed ->
list SPI attribute(s)
make validity key
authenticate
make privacy key(s)
mask/encrypt message
<- SPI_Update
make SPI
pick SPI attribute(s)
make SPI session-key(s)
make validity key
authenticate
make privacy key(s)
mask/encrypt message
Either party may initiate an exchange at any time. For example, the Initiator need not be a "caller" in a telephony link.
いずれの当事者は、いつでも交換を開始することができます。例えば、イニシエータは、電話回線の「呼び出し側」である必要はありません。
The Initiator is responsible for recovering from all message losses by retransmission.
イニシエータは、再送信することにより、すべてのメッセージの損失から回復する責任があります。
A Photuris exchange between two parties results in a pair of SPI values (one in each direction). Each SPI is used in creating separate session-key(s) in each direction.
SPI値の対における2つの当事者の結果との間のPhoturis交換（各方向に1つずつ）。各SPIは、各方向に個別のセッション・キーを作成する際に使用されます。
The SPI is assigned by the entity controlling the IP Destination: the SPI Owner (receiver). The parties use the combination of IP Destination, IP (Next Header) Protocol, and SPI to distinguish the correct Security Association.
SPI所有者（受信者）：SPIは、IP宛先を制御するエンティティによって割り当てられます。当事者は、正しいセキュリティアソシエーションを区別するために、IP宛先、IP（次ヘッダ）プロトコル、およびSPIの組み合わせを使用しています。
When both parties initiate Photuris exchanges concurrently, or one party initiates more than one Photuris exchange, the Initiator Cookies (and UDP Ports) keep the exchanges separate. This results in more than one initial SPI for each Destination.
両当事者が同時にPhoturis交換を開始し、または一方の当事者が複数のPhoturis交換を開始すると、イニシエータクッキー（およびUDPポート）は交換が分離しておきます。これは、宛先ごとに複数の初期SPIになります。
To create multiple SPIs with different parameters, the parties may also send SPI_Updates.
異なるパラメータを持つ複数のSPIを作成するには、当事者はまたSPI_Updatesを送信することができます。
There is no requirement that all such outstanding SPIs be used. The SPI User (sender) selects an appropriate SPI for each datagram transmission.
このようなすべての優れたのSPIを使用する必要はありません。 SPIユーザ（送信者）は、各データグラムの送信のために適切なSPIを選択します。
Implementation Notes:
実装上の注意：
The method used for SPI assignment is implementation dependent. The only requirement is that the SPI be unique for the IP Destination and IP (Next Header) Protocol.
SPIの割り当てのために使用される方法は実装依存です。唯一の要件は、SPIがIP宛先とIP（次ヘッダ）のプロトコルに対して一意であることです。
However, selection of a cryptographically random SPI value can help prevent attacks that depend on a predicatable sequence of values. The implementor MUST NOT expect SPI values to have a particular order or range.
しかし、暗号的にランダムなSPI値の選択は、値のpredicatable順序に依存した攻撃を防ぐことができます。実装者は、特定の順序または範囲を持つようにSPI値を予想してはいけません。
The Photuris exchange results in two kinds of state, each with separate LifeTimes.
Photuris交換は状態の2種類の別々の寿命各もたらします。
1) The Exchange LifeTime of the small amount of state associated with the Photuris exchange itself. This state may be viewed as between Internet nodes.
1）Photuris交換自体に関連付けられた状態の少量の交換寿命。この状態は、インターネットノード間と見なすことができます。
2) The SPI LifeTimes of the individual SPIs that are established. This state may be viewed as between users and nodes.
2）確立された個々のSPIのSPI寿命。この状態は、ユーザとノード間と見なすことができます。
The SPI LifeTimes may be shorter or longer than the Exchange LifeTime. These LifeTimes are not required to be related to each other.
SPI寿命は、Exchange寿命より短くても長くてもよいです。これらの寿命が相互に関連させる必要はありません。
When an Exchange-Value expires (or is replaced by a newer value), any unexpired derived SPIs are not affected. This is important to allow traffic to continue without interruption during new Photuris exchanges.
取引値が期限切れになる（またはより新しい値に置き換えられている）場合、任意の期限が切れていない由来のSPIは影響を受けません。これは、トラフィックが新しいPhoturis交換の間、中断することなく継続できるようにすることが重要です。
All retained exchange state of both parties has an associated Exchange LifeTime (ELT), and is subject to periodic expiration. This depends on the physical and logistical security of the machine, and is typically in the range of 10 minutes to one day (default 30 minutes).
双方の全て保持交換状態は、関連する取引寿命（ELT）を有し、周期的呼気を受けます。これは、マシンの物理的および物流セキュリティに依存し、1日（デフォルト30分）への10分の範囲です。
In addition, during a Photuris exchange, an Exchange TimeOut (ETO) limits the wait for the exchange to complete. This timeout includes the packet round trips, and the time for completing the Identification Exchange calculations. The time is bounded by both the maximum amount of calculation delay expected for the processing power of an unknown peer, and the minimum user expectation for results (default 30 seconds).
また、Photuris交換の際には、Exchangeタイムアウト（ETO）は、交換が完了するまで待機を制限します。このタイムアウトは、ラウンドトリップパケット、および同定取引所の計算を完了するための時間が含まれています。時間は、未知のピアの処理能力に期待される演算遅れ、その結果の最小ユーザー期待値（デフォルトは30秒）の最大量の両方によって制限されます。
These Exchange LifeTimes and TimeOuts are implementation dependent and are not disclosed in any Photuris message. The paranoid operator will have a fairly short Exchange LifeTime, but it MUST NOT be less than twice the ETO.
これらの交換寿命およびタイムアウトは、実装依存しており、任意のPhoturisメッセージに開示されていません。偏執的なオペレータは、かなり短い交換寿命を持つことになりますが、それは二回ETO以上でなければなりません。
To prevent synchronization between Photuris exchanges, the implementation SHOULD randomly vary each Exchange LifeTime within twice the range of seconds that are required to calculate a new Exchange-Value. For example, when the Responder uses a base ELT of 30 minutes, and takes 10 seconds to calculate the new Exchange-Value, the equation might be (in milliseconds):
Photuris交換の間の同期を防ぐために、実装はランダムに新しいExchange-値を計算するのに必要とされる秒の倍の範囲内の各Exchange寿命を変えるべきです。 Responderが30分のベースELTを使用して、新しいExchange-値を計算するために10秒かかったときに、例えば、式（ミリ秒単位）のようになります。
1790000 + urandom(20000)
1790000 + urandomの（20000）
The Exchange-Scheme, Exchange-Values, and resulting shared-secret MAY be cached in short-term storage for the Exchange LifeTime. When repetitive Photuris exchanges occur between the same parties, and the Exchange-Values are discovered to be unchanged, the previously calculated shared-secret can be used to rapidly generate new session-keys.
交換・スキームは、Exchange-値、および結果の共有秘密は、Exchange寿命のための短期的なストレージにキャッシュされる場合があります。繰り返しPhoturis交換が同じ当事者間に発生し、Exchange-値は変わらないことが発見された場合、以前に計算された共有秘密は、急速に新しいセッション・キーを生成するために使用することができます。
Each SPI has an associated LifeTime, specified by the SPI owner (receiver). This SPI LifeTime (SPILT) is usually related to the speed of the link (typically 2 to 30 minutes), but it MUST NOT be less than thrice the ETO.
各SPIは、SPI所有者（受信機）によって指定された関連した寿命を有します。このSPI寿命は（こぼれた）通常のリンク（典型的には2〜30分）の速度に関連しているが、それはETO三度未満であってはなりません。
The SPI can also be deleted by the SPI Owner using the SPI_Update. Once the SPI has expired or been deleted, the parties cease using the SPI.
SPIはまたSPI_Updateを使用してSPI所有者によって削除することができます。 SPIの有効期限が切れているか、削除された後は、当事者は、SPIを使用して停止します。
To prevent synchronization between multiple Photuris exchanges, the implementation SHOULD randomly vary each SPI LifeTime. For example, when the Responder uses a base SPILT of 5 minutes, and 30 seconds for the ETO, the equation might be (in milliseconds):
複数Photuris交換の間の同期を防止するために、実装はランダムに各SPI寿命を変化させるべきです。レスポンダは、ETO 5分間、30秒の流出塩基を使用する場合、例えば、式（ミリ秒単位）であるかもしれません。
285000 + urandom(30000)
285000 + urandomの（30000）
There is no requirement that a long LifeTime be accepted by the SPI User. The SPI User might never use an established SPI, or cease using the SPI at any time.
長寿命がSPIユーザーに受け入れられる必要はありません。 SPIユーザーは、確立されたSPIを使用していない、または任意の時点でSPIを使用して停止する決してかもしれません。
When more than one unexpired SPI is available to the SPI User for the same function, a common implementation technique is to select the SPI with the greatest remaining LifeTime. However, selecting randomly among a large number of SPIs might provide some defense against traffic analysis.
複数の期限が切れていないSPIは、同じ機能のSPIユーザに利用可能である場合、一般的な実装技術が最大の残存寿命とSPIを選択することです。しかし、SPIの多数の中からランダムに選択すると、トラフィック分析に対するいくつかの防御を提供するかもしれません。
To prevent resurrection of deleted or expired SPIs, SPI Owners SHOULD remember those SPIs, but mark them as unusable until the Photuris exchange shared-secret used to create them also expires and purges the associated state.
削除または期限切れのSPIの復活を防ぐために、SPI所有者は、これらのSPIを覚えているだけでなく、それらを作成するために使用さPhoturis交換共有秘密の期限が切れると関連する状態をパージするまで、それらを使用不能としてマークすべきです。
When the SPI Owner detects an incoming SPI that has recently expired, but the associated exchange state has not yet been purged, the implementation MAY accept the SPI. The length of time allowed is highly dependent on clock drift and variable packet round trip time, and is therefore implementation dependent.
SPI所有者が最近期限切れになったの着信SPIを検出するが、関連する交換状態がまだパージされていない場合は、実装は、SPIを受け入れることができます。許可された時間の長さは、クロックドリフトおよび可変パケット往復時間に大きく依存し、したがって、実装依存です。
The security of Photuris critically depends on the quality of the secret random numbers generated by each party. A poor random number generator at either party will compromise the shared-secret produced by the algorithm.
Photurisのセキュリティは批判的に各当事者によって生成された秘密乱数の品質に依存します。いずれかの当事者が苦手乱数生成アルゴリズムによって生成共有秘密を侵害します。
Generating cryptographic quality random numbers on a general purpose computer without hardware assistance is a very tricky problem. In general, this requires using a cryptographic hashing function to "distill" the entropy from a large number of semi-random external events, such as the timing of key strokes. An excellent discussion can be found in [RFC-1750].
ハードウェアの支援なし汎用コンピュータ上の暗号の品質乱数を生成することは非常に難しい問題です。一般に、このようなキーストロークのタイミングとしてセミランダム外部イベント、多数のエントロピーを「蒸留」するために暗号ハッシュ関数を使用する必要があります。優れた議論は、[RFC-1750]に見出すことができます。
The Initiator begins a Photuris exchange under several circumstances:
イニシエータは、いくつかの状況下でPhoturis交換を開始します：
- The Initiator has a datagram that it wishes to send with confidentiality, and has no current Photuris exchange state with the IP Destination. This datagram is discarded, and a Cookie_Request is sent instead.
- イニシエータは、それが機密で送信したいデータグラムを持っており、IP送信先とは現在のPhoturis交換状態を持っていません。このデータグラムは破棄され、Cookie_Requestが代わりに送信されます。
- The Initiator has received the ICMP message [RFC-1812] Destination Unreachable: Communication Administratively Prohibited (Type 3, Code 13), and has no current Photuris exchange state with the ICMP Source.
- イニシエータは、ICMPメッセージを受信した[RFC-1812]宛先到達不能：通信管理上禁止（タイプ3、コード13）、およびICMPソースとは、現在のPhoturis交換状態を有していません。
- The Initiator has received the ICMP message [RFC-2521] Security Failures: Bad SPI (Type 40, Code 0), that matches current Photuris exchange state with the ICMP Source.
バートSPI（タイプ40、コード0）、ICMPソースと現在のPhoturis交換状態と一致する： - 開始剤は、ICMPメッセージ[RFC-2521]セキュリティ障害を受けています。
- The Initiator has received the ICMP message [RFC-2521] Security Failures: Need Authentication (Type 40, Code 4), and has no current Photuris exchange state with the ICMP Source.
- イニシエータはICMPメッセージ[RFC-2521]セキュリティ障害受信した：必要性認証（タイプ40、コード4）、およびICMPソースとは、現在のPhoturis交換状態を有していません。
- The Initiator has received the ICMP message [RFC-2521] Security Failures: Need Authorization (Type 40, Code 5), that matches current Photuris exchange state with the ICMP Source.
ICMPソースと現在のPhoturis交換状態に一致する必要性承認（タイプ40、コード5）、 - イニシエータはICMPメッセージ[RFC-2521]セキュリティ障害を受けています。
When the event is an ICMP message, special care MUST be taken that the ICMP message actually includes information that matches a previously sent IP datagram. Otherwise, this could provide an opportunity for a clogging attack, by stimulating a new Photuris Exchange.
イベントは、ICMPメッセージである場合には、特別なケアは、ICMPメッセージは、実際に以前に送信されたIPデータグラムに一致する情報が含まれていることを注意する必要があります。そうでなければ、これは新しいPhoturis交換を刺激することによって、目詰まり攻撃の機会を提供することができます。
All Photuris messages use the User Datagram Protocol header [RFC-768]. The Initiator sends to UDP Destination Port 468.
すべてのPhoturisメッセージは、ユーザーデータグラムプロトコルヘッダ[RFC-768]を使用します。イニシエータは、UDP宛先ポート468に送信します。
When replying to the Initiator, the Responder swaps the IP Source and Destination, and the UDP Source and Destination Ports.
イニシエータに返信するとき、ResponderはIP送信元と送信先、およびUDP送信元ポートと宛先ポートを交換します。
The UDP checksum MUST be correctly calculated when sent. When a message is received with an incorrect UDP checksum, it is silently discarded.
送信されたときにUDPチェックサムが正しく計算されなければなりません。メッセージは間違ったUDPチェックサムを受信した場合、それは黙って破棄されます。
Implementation Notes:
実装上の注意：
It is expected that installation of Photuris will ensure that UDP checksum calculations are enabled for the computer operating system and later disabling by operators is prevented.
PhoturisのインストールはUDPチェックサムの計算はコンピュータのオペレーティングシステムが有効になっていると、後でオペレータによって無効化が防止されていることを確認することが期待されます。
Internet Protocol version 4 [RFC-791] restricts the maximum reassembled datagram to 576 bytes.
インターネットプロトコルバージョン4 [RFC-791]は576バイトに最大再組立データグラムを制限します。
When processing datagrams containing variable size values, the length must be checked against the overall datagram length. An invalid size (too long or short) that causes a poorly coded receiver to abort could be used as a denial of service attack.
可変サイズの値を含むデータグラムを処理する場合、長さは、全体的なデータグラムの長さに対してチェックされなければなりません。中止するの悪いコード化された受信機を引き起こし（あまりにも長いか短い）無効なサイズは、サービス拒否攻撃として使用することができます。
All of the messages have a format similar to the following, as transmitted left to right in network order (most significant to least significant):
（最下位に最も重要な）ネットワーク順に左から右へ送信されるようメッセージのすべては、次のような形式になります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message |
+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes.
イニシエータ・クッキー16バイト。
Responder-Cookie 16 bytes.
レスポンダ・クッキー16バイト。
Message 1 byte. Each message type has a unique value. Initial values are assigned as follows:
メッセージ1バイト。各メッセージタイプは、一意の値を持ちます。次のように初期値が割り当てられています。
0 Cookie_Request
1 Cookie_Response
2 Value_Request
3 Value_Response
4 Identity_Request
5 Secret_Response (optional)
6 Secret_Request (optional)
7 Identity_Response
8 SPI_Needed
9 SPI_Update
10 Bad_Cookie
11 Resource_Limit
12 Verification_Failure
13 Message_Reject
Further details and differences are elaborated in the individual messages.
さらなる詳細および相違点は、個々のメッセージに詳述されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Size 2, 4, or 8 bytes. The number of significant bits used in the Value field. Always transmitted most significant byte first.
サイズ2、4、または8バイト。 Valueフィールドに使用される重要なビットの数。必ず最初に最上位バイトを送信します。
When the Size is zero, no Value field is present;
there are no significant bits. This means "missing"
or "null". It should not be confused with the value
zero, which includes an indication of the number of
significant bits.
When the most significant byte is in the range 0 through 254 (0xfe), the field is 2 bytes. Both bytes are used to indicate the size of the Value field, which ranges from 1 to 65,279 significant bits (in 1 to 8,160 bytes).
最上位バイト（0xFEの）254を介して範囲0である場合、フィールドが2バイトです。両方のバイトは、1から65279の最下位ビット（1 8160バイトで）の範囲にある値フィールドのサイズを示すために使用されます。
When the most significant byte is 255 (0xff), the field is 4 bytes. The remaining 3 bytes are added to 65,280 to indicate the size of the Value field, which is limited to 16,776,959 significant bits (in
最上位バイトが255（0xffの）である場合には、フィールドは4バイトです。残りの3つのバイトは、IN（16776959上位ビットに制限され、値フィールドのサイズを示すために、65,280に加えられます
2,097,120 bytes).
2097120バイト）。
When the most significant 2 bytes are 65,535 (0xffff), the field is 8 bytes. The remaining 6 bytes are added to 16,776,960 to indicate the size of the Value field.
上位2つのバイトは、65,535（0xFFFFの）である場合、フィールドは8バイトです。残りの6つのバイトは、値フィールドのサイズを示すために、16776960に添加されます。
Value 0 or more bytes. Always transmitted most significant byte first.
値が0バイト以上。必ず最初に最上位バイトを送信します。
The bits used are right justified within byte
boundaries; that is, any unused bits are in the most
significant byte. When there are no unused bits, or
unused bits are zero filled, the value is assumed to
be an unsigned positive integer.
When the leading unused bits are ones filled, the number is assumed to be a two's-complement negative integer. A negative integer will always have at least one unused leading sign bit in the most significant byte.
先頭の未使用ビットが埋めものである場合、数は2の補数負の整数であると仮定されます。負の整数は常に最上位バイトに少なくとも一つの未使用の主要な符号ビットを持っています。
Shortened forms SHOULD NOT be used when the Value includes a number of leading zero significant bits. The Size SHOULD indicate the correct number of significant bits.
値がゼロ上位ビットを先頭の数を含む場合短縮形を使用しないでください。サイズは、上位ビットの正確な数を示す必要があります。
Implementation Notes:
実装上の注意：
Negative integers are not required to be supported, but are included for completeness.
負の整数をサポートする必要はありませんが、完全を期すために含まれています。
No more than 65,279 significant bits are required to be supported. Other ranges are vastly too long for these UDP messages, but are included for completeness.
これ以上の65279よりも上位ビットがサポートされる必要があります。他の範囲は大幅にこれらのUDPメッセージのためにあまりにも長いですが、完全性のために含まれています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scheme | Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Scheme 2 bytes. A unique value indicating the Exchange-Scheme. See the "Basic Exchange-Schemes" for details.
スキーム2バイト。交換・スキームを示すユニークな値。詳細については、「基本的な交流・スキーム」を参照してください。
Size 2 bytes, ranging from 0 to 65,279. See "Variable Precision Integer".
0から65279までの範囲のサイズは2バイト、。 「可変精度整数」を参照してください。
Value 0 or more bytes. See "Variable Precision Integer".
値が0バイト以上。 「可変精度整数」を参照してください。
The Size MUST NOT be assumed to be constant for a particular Scheme. Multiple kinds of the same Scheme with varying Sizes MAY be present in any list of schemes.
サイズは、特定のスキームについて一定であると仮定してはなりません。様々なサイズと同じスキームの複数の種類のスキームのいずれかのリストに存在してもよいです。
However, only one of each Scheme and Size combination will be present in any list of schemes.
しかし、それぞれのスキームとサイズの組み合わせの一方のみがスキームの任意のリスト中に存在するであろう。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length | Value(s) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 1 byte. A unique value indicating the kind of attribute. See the "Basic Attributes" for details.
1バイトの属性。属性の種類を示す固有の値。詳細については、「基本属性」を参照してください。
When the value is zero (padding), no Length field is
present (always zero).
Length 1 byte. The size of the Value(s) field in bytes.
長さは1バイト。バイト単位の値（S）フィールドのサイズ。
When the Length is zero, no Value(s) field is
present.
Value(s) 0 or more bytes. See the "Basic Attributes" for details.
値（S）が0バイト以上。詳細については、「基本属性」を参照してください。
The Length MUST NOT be assumed to be constant for a particular
長さは、特定のために一定であると仮定してはなりません
Attribute. Multiple kinds of the same Attribute with varying Lengths MAY be present in any list of attributes.
属性。様々な長さと同じ属性の複数種類の属性のいずれかのリストに存在してもよいです。
Initiator Responder
========= =========
Cookie_Request ->
<- Cookie_Response
offer schemes
The Initiator initializes local state, and generates a unique "cookie". The Initiator-Cookie MUST be different in each new Cookie_Request between the same parties. See "Cookie Generation" for details.
イニシエータは、ローカル状態を初期化し、ユニークな「クッキー」を生成します。イニシエータ・クッキーは、同じ当事者間のそれぞれの新しいCookie_Requestで異なっている必要があります。詳細については、「クッキー世代」を参照してください。
- If any previous exchange between the peer IP nodes has not expired in which this party was the Initiator, this Responder-Cookie is set to the most recent Responder-Cookie, and this Counter is set to the corresponding Counter.
- ピアのIPノード間のいずれかの以前の交換は、このパーティーはイニシエータされた有効期限が切れていない場合は、このレスポンダ・クッキーは、最新のレスポンダ-クッキーに設定されており、このカウンタは、対応するカウンタに設定されています。
For example, a new Virtual Private Network (VPN) tunnel is about to be established to an existing partner. The Counter is the same value received in the prior Cookie_Response, the Responder-Cookie remains the same, and a new Initiator-Cookie is generated.
たとえば、新しい仮想プライベートネットワーク（VPN）トンネルは、既存のパートナーに確立されようとしています。カウンタ前Cookie_Responseで受信した同一の値であり、レスポンダクッキーは同じままであり、新たな開始剤クッキーが生成されます。
- If the new Cookie_Request is in response to a message of a previous exchange in which this party was the Responder, this Responder-Cookie is set to the previous Initiator-Cookie, and this Counter is set to zero.
- 新しいCookie_Requestはこのパーティーはレスポンダされた前回の為替のメッセージに応答している場合は、このレスポンダ・クッキーは、前のイニシエータ-クッキーに設定されており、このカウンタはゼロに設定されています。
For example, a Bad_Cookie message was received from the previous Initiator in response to SPI_Needed. The Responder-Cookie is replaced with the Initiator-Cookie, and a new Initiator-Cookie is generated. This provides bookkeeping to detect bogus Bad_Cookie messages.
例えば、Bad_CookieメッセージはSPI_Neededに応答して、前のイニシエータから受信されました。レスポンダ・クッキーは、イニシエータ・クッキーに置き換えられ、新しいイニシエータ-クッキーが生成されます。これは、偽のBad_Cookieメッセージを検出するために簿記を提供します。
Also, can be used for bi-directional User, Transport, and Process oriented keying. Such mechanisms are outside the scope of this document.
また、双方向のユーザー、トランスポート、およびプロセス指向のキーイングのために使用することができます。そのようなメカニズムは、この文書の範囲外です。
- Otherwise, this Responder-Cookie and Counter are both set to zero.
- それ以外の場合、このレスポンダ-Cookieとカウンターは両方ともゼロに設定されています。
By default, the Initiator operates in the same manner as when all of its previous exchange state has expired. The Responder will send a Resource_Limit when its own exchange state has not expired.
デフォルトでは、イニシエータは、その前の交換状態のすべての有効期限が切れているときと同じように動作します。独自の交換状態が満了していないときResponderはRESOURCE_LIMITを送信します。
The Initiator also starts a retransmission timer. If no valid Cookie_Response arrives within the time limit, the same Cookie_Request is retransmitted for the remaining number of Retransmissions. The Initiator-Cookie value MUST be the same in each such retransmission to the same IP Destination and UDP Port.
イニシエータはまた、再送タイマを開始します。有効なCookie_Responseは、制限時間内に到着しない場合は、同じCookie_Requestは再送の残り回数のために再送信されます。イニシエータ-Cookie値が同じIP送信先およびUDPポートにそれぞれ、このような再送信で同じでなければなりません。
When Retransmissions have been exceeded, if a Resource_Limit message has been received during the exchange, the Initiator SHOULD begin the Photuris exchange again by sending a new Cookie_Request with updated values.
再送を超えた場合はRESOURCE_LIMITメッセージを交換中に受信されている場合、イニシエータは、更新された値を持つ新しいCookie_Requestを送信することによって、再びPhoturis交換を開始する必要があります。
On receipt of a Cookie_Request, the Responder determines whether there are sufficient resources to begin another Photuris exchange.
Cookie_Requestを受信すると、レスポンダは別のPhoturis交換を開始するのに十分なリソースがあるか否かを判断します。
- When too many SPI values are already in use for this particular peer, or too many concurrent exchanges are in progress, or some other resource limit is reached, a Resource_Limit message is sent.
- あまりにも多くのSPI値は、この特定のピアのためにすでに使用されている場合、またはあまりにも多くの同時交換が進行中である、またはいくつかの他のリソース制限に達すると、RESOURCE_LIMITメッセージが送信されます。
- When any previous exchange initiated by this particular peer has not exceeded the Exchange TimeOut, and the Responder-Cookie does not specify one of these previous exchanges, a Resource_Limit message is sent.
- この特定のピアによって開始された以前の交換がExchangeタイムアウトを超えていない、とレスポンダクッキーがこれらの以前の交換のいずれかを指定しない場合、RESOURCE_LIMITメッセージが送信されます。
Otherwise, the Responder returns a Cookie_Response.
それ以外の場合は、ResponderはCookie_Responseを返します。
Note that the Responder creates no additional state at this time.
Responderは、この時点で追加の状態を作成していないことに注意してください。
The IP Source for the Initiator is examined. If any previous exchange between the peer IP nodes has not expired, the response Counter is set to the most recent exchange Counter plus one (allowing for out of order retransmissions). Otherwise, the response Counter is set to the request Counter plus one.
イニシエータのためのIPソースを調べています。ピアIPノード間のいずれかの以前の交換が満了していない場合、応答カウンターは、最新の交換カウンタープラスワン（オーダー再送のうちを可能にする）に設定されています。そうでなければ、応答カウンタは、要求カウンタプラス1に設定されています。
If (through rollover of the Counter) the new Counter value is zero (modulo 256), the value is set to one.
（カウンターのロールオーバーによる）新しいカウンタ値がゼロ（モジュロ256）である場合は、値が1に設定されています。
If this new Counter value matches some previous exchange initiated by this particular peer that has not yet exceeded the Exchange TimeOut, the Counter is incremented again, until a unique Counter value is reached.
この新しいカウンタ値がまだ取引所タイムアウトを超えていないこの特定のピアによって開始され、いくつかの以前の交換が一致した場合のユニークなカウンタ値に到達するまで、カウンタは、再び増加されます。
Nota Bene: No more than 254 concurrent exchanges between the same two peers are supported.
注意ベーネは：同じ2つのピア間ではありません254の以上の同時交換がサポートされています。
The Responder generates a unique cookie. The Responder-Cookie value in each successive response SHOULD be different. See "Cookie Generation" for details.
Responderは独自のクッキーを生成します。各連続反応におけるレスポンダクッキー値が異なるべきです。詳細については、「クッキー世代」を参照してください。
The Exchange-Schemes available between the peers are listed in the Offered-Schemes.
ピア間で利用可能な交換-スキームが提供さ-のスキームに記載されています。
The Initiator validates the Initiator-Cookie, and the Offered-Schemes.
イニシエータは、イニシエータ・クッキー、および提供される-スキームを検証します。
- When an invalid/expired Initiator-Cookie is detected, the message is silently discarded.
- 期限切れ/無効イニシエータクッキーが検出されると、メッセージは静かに破棄されます。
- When the variable length Offered-Schemes do not match the UDP Length, or all Offered-Schemes are obviously defective and/or insufficient for the purposes intended, the message is silently discarded; the implementation SHOULD log the occurance, and notify an operator as appropriate.
- 可変長提供さ-スキームは、UDPの長さと一致しない、またはすべての提供さ-スキームが明らかに意図された目的のために、欠陥及び/又は不十分である場合、メッセージは黙って廃棄されます。実装は、のoccuranceを記録し、必要に応じてオペレータに通知すべきです。
- Once a valid message has been received, later Cookie_Responses with matching Initiator-Cookies are also silently discarded, until a new Cookie_Request is sent.
- 有効なメッセージが受信された後、新たなCookie_Requestが送信されるまで、イニシエータ・クッキーをマッチングして、後でCookie_Responsesも静かに、破棄されます。
When the message is valid, an Exchange-Scheme is chosen from the list of Offered-Schemes.
メッセージが有効である場合は、Exchange-スキームが提供される、スキームのリストから選択されます。
This Scheme-Choice may affect the next Photuris message sent. By default, the next Photuris message is a Value_Request.
このスキームの選択は、送られた次のPhoturisメッセージに影響を与える可能性があります。デフォルトでは、次のPhoturisメッセージがValue_Requestです。
Implementation Notes:
実装上の注意：
Only the Initiator-Cookie is used to identify the exchange. The Counter and Responder-Cookie will both be different from the Cookie_Request.
唯一のイニシエータ・クッキーは、交換を識別するために使用されます。カウンターとレスポンダ・クッキーは、両方のCookie_Request異なります。
Various proposals for extensions utilize the Scheme-Choice to indicate a different message sequence. Such mechanisms are outside the scope of this document.
拡張のための様々な提案が異なるメッセージシーケンスを示すために、スキームの選択を利用します。そのようなメカニズムは、この文書の範囲外です。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. A randomized value that identifies the exchange. The value MUST NOT be zero. See "Cookie Generation" for details.
イニシエータ・クッキー16バイト。交換を識別する無作為値。値がゼロであってはなりません。詳細については、「クッキー世代」を参照してください。
Responder-Cookie 16 bytes. Identifies a specific previous exchange. Copied from a previous Cookie_Response.
レスポンダ・クッキー16バイト。特定の前の交換を識別します。以前Cookie_Responseからコピーされました。
When zero, no previous exchange is specified.
場合はゼロ、以前の交換が指定されていません。
When non-zero, and the Counter is zero, contains the Initiator-Cookie of a previous exchange. The specified party is requested to be the Responder in this exchange, to retain previous party pairings.
非ゼロ、およびカウンタがゼロである場合には、前回の交換のイニシエータクッキーが含まれています。指定された当事者は、この交換でレスポンダする前のパーティのペアを保持することが要求されます。
When non-zero, and the Counter is also non-zero, contains the Responder-Cookie of a previous exchange. The specified party is requested to be the Responder in this exchange, to retain previous party pairings.
非ゼロ、およびカウンタもゼロでない場合は、前回の交流のレスポンダ・クッキーが含まれています。指定された当事者は、この交換でレスポンダする前のパーティのペアを保持することが要求されます。
Message 0
メッセージ0
Counter 1 byte. Indicates the number of previous exchanges.
カウンタ1バイト。前回の交換の数を示します。
When zero, the Responder-Cookie indicates the
Initiator of a previous exchange, or no previous
exchange is specified.
When non-zero, the Responder-Cookie indicates the Responder to a previous exchange. This value is set to the Counter from the corresponding Cookie_Response or from a Resource_Limit.
場合非ゼロ、レスポンダクッキーは以前交換にレスポンダを示しています。この値は、対応するCookie_ResponseまたはRESOURCE_LIMITからカウンターに設定されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Counter | Offered-Schemes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Cookie_Request.
イニシエータ・クッキー16バイト。 Cookie_Requestからコピーされました。
Responder-Cookie 16 bytes. A randomized value that identifies the exchange. The value MUST NOT be zero. See "Cookie Generation" for details.
レスポンダ・クッキー16バイト。交換を識別する無作為値。値がゼロであってはなりません。詳細については、「クッキー世代」を参照してください。
Message 1
メッセージ1
Counter 1 byte. Indicates the number of the current exchange. Must be greater than zero.
カウンタ1バイト。現在の為替の数を示します。ゼロより大きくなければなりません。
Offered-Schemes 4 or more bytes. A list of one or more Exchange-Schemes supported by the Responder, ordered from most to least preferable. See the "Basic Exchange-Schemes" for details.
提供-スキーム4バイト以上。レスポンダでサポートされている1つまたは複数のExchangeスキームのリストは、最もから少なくとも好適に命じました。詳細については、「基本的な交流・スキーム」を参照してください。
Only one Scheme (#2) is required to be supported,
and SHOULD be present in every Offered-Schemes list.
More than one of each kind of Scheme may be offered, but each is distinguished by its Size. The end of the list is indicated by the UDP Length.
スキームの各種類の複数が提供されることがありますが、それぞれがそのサイズによって区別されます。リストの最後は、UDPの長さによって示されます。
The exact technique by which a Photuris party generates a cookie is implementation dependent. The method chosen must satisfy some basic requirements:
Photurisパーティがクッキーを生成することにより、正確な技術が実装依存です。選択した方法は、いくつかの基本的な要件を満たしている必要があります。
1. The cookie MUST depend on the specific parties. This prevents an attacker from obtaining a cookie using a real IP address and UDP port, and then using it to swamp the victim with requests from randomly chosen IP addresses or ports.
1.クッキーは、特定の政党に依存しなければなりません。これは、実際のIPアドレスとUDPポートを使用してクッキーを取得した後、ランダムに選ばれたIPアドレスやポートからのリクエストで被害者を圧倒するためにそれを使用してから、攻撃者を防ぐことができます。
2. It MUST NOT be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. This implies that the issuing entity will use local secret information in the generation and subsequent verification of a cookie. It must not be possible to deduce this secret information from any particular cookie.
発行体以外の者は、そのエンティティによって受け入れられるクッキーを生成するため2.それは可能にすることはできません。これは、発行体がクッキーの生成とその後の検証でローカル秘密情報を使用することを意味します。任意の特定のCookieからこの秘密情報を推定することが可能であってはなりません。
3. The cookie generation and verification methods MUST be fast to thwart attacks intended to sabotage CPU resources.
3.クッキーの生成と検証方法は、CPUリソースを妨害することを意図した攻撃を阻止するために高速でなければなりません。
A recommended technique is to use a cryptographic hashing function (such as MD5).
推奨される技術は、（例えば、MD5など）暗号ハッシュ関数を使用することです。
An incoming cookie can be verified at any time by regenerating it locally from values contained in the incoming datagram and the local secret random value.
入ってくるクッキーは、着信データグラムとローカル秘密のランダムな値に含まれている値からローカルで再生することにより、いつでも確認することができます。
The Initiator secret value that affects its cookie SHOULD change for each new Photuris exchange, and is thereafter internally cached on a per Responder basis. This provides improved synchronization and protection against replay attacks.
そのクッキーに影響イニシエータ秘密の値は、それぞれの新しいPhoturis交換のために変更する必要があり、その後、内部レスポンダごとにキャッシュされます。これは、リプレイ攻撃に対する改良された同期と保護を提供します。
An alternative is to cache the cookie instead of the secret value. Incoming cookies can be compared directly without the computational cost of regeneration.
代替は、秘密の値の代わりにクッキーをキャッシュすることです。着信クッキーは、再生の計算コストなしで直接比較することができます。
It is recommended that the cookie be calculated over the secret value, the IP Source and Destination addresses, and the UDP Source and Destination ports.
クッキーが秘密の値、IP送信元アドレスと宛先アドレス、およびUDP送信元ポートと宛先ポート上で計算することをお勧めします。
Implementation Notes:
実装上の注意：
Although the recommendation includes the UDP Source port, this is very implementation specific. For example, it might not be included when the value is constant.
勧告は、UDPソースポートが含まれていますが、これは非常に実装固有のものです。値が一定である場合例えば、それは含まれていない可能性があります。
However, it is important that the implementation protect mutually suspicious users of the same machine from generating the same cookie.
しかし、実装が同じCookieを生成するから、同じマシンの相互不審なユーザーを保護することが重要です。
The Responder secret value that affects its cookies MAY remain the same for many different Initiators. However, this secret SHOULD be changed periodically to limit the time for use of its cookies (typically each 60 seconds).
そのクッキーに影響レスポンダ秘密の値は、多くの異なるイニシエータのと同じままになることがあります。しかし、この秘密は、そのクッキー（典型的には、各60秒）を使用するための時間を制限するために、定期的に変更する必要があります。
The Responder-Cookie SHOULD include the Initiator-Cookie. The Responder-Cookie MUST include the Counter (that is returned in the Cookie_Response). This provides improved synchronization and protection against replay attacks.
レスポンダ・クッキーは、イニシエータ・クッキーを含むべきです。レスポンダクッキーは、カウンタ（すなわちCookie_Responseに戻される）を含める必要があります。これは、リプレイ攻撃に対する改良された同期と保護を提供します。
It is recommended that the cookie be calculated over the secret value, the IP Source and Destination addresses, its own UDP Destination port, the Counter, the Initiator-Cookie, and the currently Offered-Schemes.
これは、クッキーが秘密の値に対して計算することが推奨され、IP送信元アドレスと宛先アドレス、独自のUDP宛先ポート、カウンター、イニシエータクッキー、および現在提供-スキーム。
The cookie is not cached per Initiator to avoid saving state during the initial Cookie Exchange. On receipt of a Value_Request (described later), the Responder regenerates its cookie for validation.
クッキーは、最初のクッキー交換時の状態を保存避けるために、イニシエータごとにキャッシュされていません。 （後述する）Value_Requestを受信すると、レスポンダは、検証のためにクッキーを再生成します。
Once the Value_Response is sent (also described later), both Initiator and Responder cookies are cached to identify the exchange.
Value_Responseは（また後述）が送信されると、イニシエータとレスポンダの双方クッキーは交換を識別するためにキャッシュされます。
Implementation Notes:
実装上の注意：
Although the recommendation does not include the UDP Source port, this is very implementation specific. It might be successfully included in some variants.
勧告は、UDPソースポートが含まれていませんが、これは非常に実装固有のものです。それは成功し、いくつかの亜種に含まれている場合があります。
However, it is important that the UDP Source port not be included when matching existing Photuris exchanges for determining the appropriate Counter.
しかし、適切なカウンターを決定するために、既存のPhoturis交換を一致させるときUDPソースポートが含まれないことが重要です。
The recommendation includes the Offered-Schemes to detect a dynamic change of scheme value between the Cookie_Response and
推薦はCookie_Response間スキーム値の動的な変化を検出するために提供-スキームを含み、
Value_Response.
Value_Response。
Some mechanism MAY be needed to detect a dynamic change of pre-calculated Responder Exchange-Value between the Value_Response and Identity_Response. For example, change the secret value to render the cookie invalid, or explicitly mark the Photuris exchange state as expired.
いくつかのメカニズムがValue_ResponseとIdentity_Responseの間に事前に計算されたレスポンダ交換価値のダイナミックな変化を検出するために必要とされ得ます。たとえば、クッキーの無効をレンダリングするために秘密の値を変更、または明示的に有効期限が切れてPhoturis交換状態をマーク。
Initiator Responder
========= =========
Value_Request ->
pick scheme
offer value
offer attributes
<- Value_Response
offer value
offer attributes
[generate shared-secret from exchanged values]
【交換値から共有秘密を生成]
The Initiator generates an appropriate Exchange-Value for the Scheme-Choice. This Exchange-Value may be pre-calculated and used for multiple Responders.
イニシエータは、スキームの選択のための適切なExchange-値を生成します。この交換価値は、事前に計算され、複数のレスポンダのために使用することができます。
The IP Destination for the Responder is examined, and the attributes available between the parties are listed in the Offered-Attributes.
レスポンダのためのIP宛先が調べられ、当事者間で利用可能な属性が提供さ-属性に記載されています。
The Initiator also starts a retransmission timer. If no valid Value_Response arrives within the time limit, the same Value_Request is retransmitted for the remaining number of Retransmissions.
イニシエータはまた、再送タイマを開始します。有効なValue_Responseは、制限時間内に到着しない場合は、同じValue_Requestは再送の残り回数のために再送信されます。
When Retransmissions have been exceeded, if a Bad_Cookie or Resource_Limit message has been received during the exchange, the Initiator SHOULD begin the Photuris exchange again by sending a new Cookie_Request.
再送を超えた場合はBad_CookieまたはRESOURCE_LIMITメッセージが交換中に受信されている場合、イニシエータは新しいCookie_Requestを送信することによって、再びPhoturis交換を開始する必要があります。
The Responder validates the Responder-Cookie, the Counter, the Scheme-Choice, the Exchange-Value, and the Offered-Attributes.
レスポンダは、レスポンダ・クッキー、カウンター、スキームの選択、交換価値、および提供される-属性を検証します。
- When an invalid/expired Responder-Cookie is detected, a Bad_Cookie message is sent.
- 期限切れ/無効レスポンダクッキーが検出されると、Bad_Cookieメッセージが送信されます。
- When too many SPI values are already in use for this particular peer, or too many concurrent exchanges are in progress, or some other resource limit is reached, a Resource_Limit message is sent.
- あまりにも多くのSPI値は、この特定のピアのためにすでに使用されている場合、またはあまりにも多くの同時交換が進行中である、またはいくつかの他のリソース制限に達すると、RESOURCE_LIMITメッセージが送信されます。
- When an invalid Scheme-Choice is detected, or the Exchange-Value is obviously defective, or the variable length Offered-Attributes do not match the UDP Length, the message is silently discarded; the implementation SHOULD log the occurance, and notify an operator as appropriate.
- 無効なスキームの選択が検出、またはExchange-Valueは明らかに欠陥がある、または可変長提供さ-属性は、UDPの長さと一致しないと、メッセージは静かに破棄されます。実装は、のoccuranceを記録し、必要に応じてオペレータに通知すべきです。
When the message is valid, the Responder sets its Exchange timer to the Exchange TimeOut, and returns a Value_Response.
メッセージが有効である場合、レスポンダは、Exchangeタイムアウトにその交換タイマーを設定し、Value_Responseを返します。
The Responder keeps a copy of the incoming Value_Request cookie pair, and its Value_Response. If a duplicate Value_Request is received, it merely resends its previous Value_Response, and takes no further action.
Responderは、着信Value_Requestクッキーペアのコピーを保持し、そのValue_Response。重複Value_Requestを受信した場合、それは単にその前のValue_Responseを再送して、以降のアクションを実行しません。
The Responder generates an appropriate Exchange-Value for the Scheme-Choice. This Exchange-Value may be pre-calculated and used for multiple Initiators.
Responderはスキームの選択のための適切なExchange-値を生成します。この交換価値は、事前に計算され、複数のイニシエータのために使用することができます。
The IP Source for the Initiator is examined, and the attributes available between the parties are listed in the Offered-Attributes.
イニシエータのためのIPソースが調べられ、当事者間で利用可能な属性が提供さ-属性に記載されています。
Implementation Notes:
実装上の注意：
At this time, the Responder begins calculation of the shared-secret. Calculation of the shared-secret is executed in parallel to minimize delay.
このとき、Responderは共有秘密の計算を開始します。共有秘密の計算は、遅延を最小化するために並行して実行されます。
This may take a substantial amount of time. The implementor should ensure that retransmission is not blocked by this calculation. This is not usually a problem, as retransmission timeouts typically exceed calculation time.
これはかなりの時間がかかる場合があります。実装者は再送信が、この計算によってブロックされていないことを確認する必要があります。再送タイムアウトは、一般的に計算時間を超えたので、これは、通常は問題ではありません。
The Initiator validates the pair of Cookies, the Exchange-Value, and the Offered-Attributes.
イニシエータは、クッキーのペア、交換価値、および提供される-属性を検証します。
- When an invalid/expired cookie is detected, the message is silently discarded.
- 期限切れの/無効のクッキーが検出されると、メッセージは静かに捨てられます。
- When the Exchange-Value is obviously defective, or the variable length Offered-Attributes do not match the UDP Length, the message is silently discarded; the implementation SHOULD log the occurance, and notify an operator as appropriate.
- 為替価値は明らかに欠陥がある、または可変長提供さ-属性は、UDPの長さと一致しない場合は、メッセージは静かに破棄されます。実装は、のoccuranceを記録し、必要に応じてオペレータに通知すべきです。
- Once a valid message has been received, later Value_Responses with both matching cookies are also silently discarded, until a new Cookie_Request is sent.
- 有効なメッセージが受信された後、新たなCookie_Requestが送信されるまで、両方のマッチングクッキーと後でValue_Responsesも静かに、破棄されます。
When the message is valid, the Initiator begins its parallel computation of the shared-secret.
メッセージが有効である場合には、イニシエータは、共有秘密のその並列計算を開始します。
When the Initiator completes computation, it sends an Identity_Request to the Responder.
イニシエータは、計算を完了すると、レスポンダにIdentity_Requestを送信します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Counter | Scheme-Choice |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Exchange-Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator-Offered-Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Initiator-Cookie 16 bytes. Copied from the Cookie_Response.
イニシエータ・クッキー16バイト。 Cookie_Responseからコピーされました。
Responder-Cookie 16 bytes. Copied from the Cookie_Response.
レスポンダ・クッキー16バイト。 Cookie_Responseからコピーされました。
Message 2
メッセージ2
Counter 1 byte. Copied from the Cookie_Response.
カウンタ1バイト。 Cookie_Responseからコピーされました。
Scheme-Choice 2 bytes. A value selected by the Initiator from the list of Offered-Schemes in the Cookie_Response.
スキーム-Choiceの2バイト。 Cookie_Responseで提供-スキームのリストからイニシエータによって選択された値。
Only the Scheme is specified; the Size will match
the Initiator-Exchange-Value, and the Value(s) are
implicit.
Initiator-Exchange-Value Variable Precision Integer. Provided by the Initiator for calculating a shared-secret between the parties. The Value format is indicated by the Scheme-Choice.
イニシエータ交換価値可変精度整数。当事者間の共有秘密を計算するためイニシエータによって提供されます。値の形式は、スキームの選択によって示されています。
The field may be any integral number of bytes in
length, as indicated by its Size field. It does not
require any particular alignment. The 32-bit
alignment shown is for convenience in the
illustration.
Initiator-Offered-Attributes 4 or more bytes. A list of Security Parameter attributes supported by the Initiator.
4バイト以上をイニシエータ提供さアトリビュート。イニシエータでサポートされているセキュリティパラメータの属性のリスト。
The contents and usage of this list are further
described in "Offered Attributes List". The end of
the list is indicated by the UDP Length.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Exchange-Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder-Offered-Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Initiator-Cookie 16 bytes. Copied from the Value_Request.
イニシエータ・クッキー16バイト。 Value_Requestからコピーされました。
Responder-Cookie 16 bytes. Copied from the Value_Request.
レスポンダ・クッキー16バイト。 Value_Requestからコピーされました。
Message 3
メッセージ3
Reserved 3 bytes. For future use; MUST be set to zero when transmitted, and MUST be ignored when received.
3つのバイトを予約。将来の使用のために。送信、及び受信した場合、無視されなければならない場合、ゼロに設定しなければなりません。
Responder-Exchange-Value Variable Precision Integer. Provided by the Responder for calculating a shared-secret between the parties. The Value format is indicated by the current Scheme-Choice specified in the Value_Request.
レスポンダ交換価値可変精度整数。当事者間の共有秘密を計算するためレスポンダが提供します。値の形式はValue_Requestで指定された現在のスキームの選択によって示されています。
The field may be any integral number of bytes in length, as indicated by its Size field. It does not
require any particular alignment. The 32-bit
alignment shown is for convenience in the
illustration.
Responder-Offered-Attributes 4 or more bytes. A list of Security Parameter attributes supported by the Responder.
4バイト以上をレスポンダ提供さアトリビュート。レスポンダでサポートされているセキュリティパラメータの属性のリスト。
The contents and usage of this list are further
described in "Offered Attributes List". The end of
the list is indicated by the UDP Length.
This list includes those attributes supported by the party that are available to the other party. The attribute formats are specified in the "Basic Attributes".
このリストは、他の当事者に利用可能なパーティでサポートされているそれらの属性を含んでいます。属性の形式は、「基本属性」で指定されています。
The list is composed of two or three sections: Identification-Attributes, Authentication-Attributes, and (optional) Encapsulation-Attributes. Within each section, the attributes are ordered from most to least preferable.
同定-属性、認証、属性、および（オプションの）カプセル化属性：リストは、2つのまたは3つのセクションから構成されています。各セクション内では、属性が最も望ましいが最も注文されています。
The first section of the list includes methods of identification. An Identity-Choice is selected from this list.
リストの最初のセクションは、識別の方法を含みます。アイデンティティの選択は、このリストから選択されます。
The second section of the list begins with "AH-Attributes" (#1). It includes methods of authentication, and other operational types.
リストの第2のセクションは、「AH-属性」（＃1）から始まります。これは、認証の方法、および他の動作タイプが含まれます。
The third section of the list begins with "ESP-Attributes" (#2). It includes methods of authentication, compression, encryption, and other operational types. When no Encapsulation-Attributes are offered, the "ESP-Attributes" attribute itself is omitted from the list.
リストの3番目のセクションは、「ESP-属性」（＃2）から始まります。これは、認証、圧縮、暗号化、およびその他の業務の種類の方法が含まれます。何のカプセル化、属性が提供されていない場合は、「ESP-属性」属性自体がリストから省略されています。
Attribute-Choices are selected from the latter two sections of the list.
属性の選択は、リストの後者の二つの部分から選択されています。
Support is required for the "MD5-IPMAC" (#5) attribute for both "Symmetric Identification" and "Authentication" and they SHOULD be present in every Offered-Attributes list.
サポートは「MD5-IPMAC」（＃5）「対称型識別」の両方の属性および「認証」のために必要であると彼らはすべての提供される、属性リスト内に存在する必要があります。
Implementation Notes:
実装上の注意：
For example,
例えば、
"MD5-IPMAC" (Symmetric Identification), "AH-Attributes", "MD5-IPMAC" (Authentication).
"MD5-IPMAC"（対称識別）、 "AH-属性"、 "MD5-IPMAC"（認証）。
Since the offer is made by the prospective SPI User (sender), order of preference likely reflects the capabilities and engineering tradeoffs of a particular implementation.
オファーは将来のSPIユーザー（送信者）によって作られているので、優先順位は、おそらく、特定の実装の機能とエンジニアリングのトレードオフを反映しています。
However, the critical processing bottlenecks are frequently in the receiver. The SPI Owner (receiver) may express its needs by choosing a less preferable attribute.
しかし、重要な処理のボトルネックは、受信機で頻繁にあります。 SPI所有者（受信機）が少なく好ましい属性を選択することによって、そのニーズを発現し得ます。
The order may also be affected by operational policy and requested services for an application. Such considerations are outside the scope of this document.
順序も運用ポリシーの影響を受けるとアプリケーションのためのサービスを要求することができます。このような考慮事項は、この文書の範囲外です。
The list may be divided into additional sections. These sections will always follow the ESP-Attributes section, and are indistinguishable from unrecognized attributes.
リストには追加のセクションに分割することができます。ここでは、常にESP-属性セクションに従ってください、と認識されていない属性と区別がつかないでしょう。
The authentication, compression, encryption and identification mechanisms chosen, as well as the encapsulation modes (if any), need not be the same in both directions.
選択された認証、圧縮、暗号化および識別メカニズム、ならびにカプセル化モードは、（もしあれば）、両方向で同じである必要はありません。
Initiator Responder
========= =========
Identity_Request ->
make SPI
pick SPI attribute(s)
identify self
authenticate
make privacy key(s)
mask/encrypt message
<- Identity_Response
make SPI
pick SPI attribute(s)
identify self
authenticate
make privacy key(s)
mask/encrypt message
[make SPI session-keys in each direction]
【各方向のSPIセッション鍵を作ります]
The exchange of messages is ordered, although the formats and meanings of the messages are identical in each direction. The messages are easily distinguished by the parties themselves, by examining the Message and Identification fields.
メッセージのフォーマットと意味は各方向で同一であるがメッセージの交換は、順序付けされています。メッセージは簡単にメッセージと識別フィールドを調べることによって、両当事者自身によって区別されます。
Implementation Notes:
実装上の注意：
The amount of time for the calculation may be dependent on the value of particular bits in secret values used in generating the shared-secret or identity verification. To prevent analysis of these secret bits by recording the time for calculation, sending of the Identity_Messages SHOULD be delayed until the time expected for the longest calculation. This will be different for different processor speeds, different algorithms, and different length variables. Therefore, the method for estimating time is implementation dependent.
計算のための時間の量は、共有秘密または本人確認を生成する際に使用される秘密の値の特定のビットの値に依存してもよいです。最長の計算のために期待される時まで遅らせるべきIdentity_Messagesの送信、計算のための時間を記録することによって、これらの秘密のビットの解析を防ぐために。これは、異なるプロセッサ速度、異なるアルゴリズム、そして異なる長さの変数の異なるであろう。したがって、時間を推定する方法は実装依存です。
Any authenticated and/or encrypted user datagrams received before the completion of identity verification can be placed on a queue pending completion of this step. If verification succeeds, the queue is processed as though the datagrams had arrived subsequent to the verification. If verification fails, the queue is discarded.
本人確認が完了する前に受信したすべての認証済みおよび/または暗号化されたユーザデータグラムは、このステップのキュー保留完了に配置することができます。検証が成功した場合、データグラムは、検証の後に到着したかのように、キューが処理されます。検証が失敗した場合、キューが破棄されます。
The Initiator chooses an appropriate Identification, the SPI and SPILT, a set of Attributes for the SPI, calculates the Verification, and masks the message using the Privacy-Method indicated by the current Scheme-Choice.
イニシエータは、適切な識別、SPIを選択し、こぼれ、SPIのための属性のセット、現在のスキームの選択によって示さプライバシ法を使用してメッセージを検証を算出し、マスク。
The Initiator also starts a retransmission timer. If no valid Identity_Response arrives within the time limit, its previous Identity_Request is retransmitted for the remaining number of Retransmissions.
イニシエータはまた、再送タイマを開始します。有効なIdentity_Responseは、制限時間内に到着しない場合には、その前のIdentity_Requestは、再送の残りの数のために再送信されます。
When Retransmissions have been exceeded, if a Bad_Cookie message has been received during the exchange, the Initiator SHOULD begin the Photuris exchange again by sending a new Cookie_Request.
再送を超えている場合にはBad_Cookieメッセージを交換中に受信されている場合、イニシエータは新しいCookie_Requestを送信することによって、再びPhoturis交換を開始する必要があります。
The Responder validates the pair of Cookies, the Padding, the Identification, the Verification, and the Attribute-Choices.
Responderはクッキー、パディング、識別、検証、および属性-選択肢のペアを検証します。
- When an invalid/expired cookie is detected, a Bad_Cookie message is sent.
- 期限切れの/無効のクッキーが検出されると、Bad_Cookieメッセージが送信されます。
- After unmasking, when invalid Padding is detected, the variable length Attribute-Choices do not match the UDP Length, or an attribute was not in the Offered-Attributes, the message is silently discarded.
- 不正なパディングが検出されたときに非マスクした後、可変長属性-選択肢はUDPの長さと一致しない、または属性が提供される-属性に、メッセージは静かに破棄されませんでした。
- When an invalid Identification is detected, or the message verification fails, a Verification_Failure message is sent.
- 無効な識別が検出、またはメッセージの検証が失敗した場合、Verification_Failureメッセージが送信されます。
- Whenever such a problem is detected, the Security Association is not established; the implementation SHOULD log the occurance, and notify an operator as appropriate.
- このような問題が検出されるたびに、セキュリティアソシエーションが確立されていません。実装は、のoccuranceを記録し、必要に応じてオペレータに通知すべきです。
When the message is valid, the Responder sets its Exchange timer to the Exchange LifeTime (if this has not already been done for a previous exchange). When its parallel computation of the shared-secret is complete, the Responder returns an Identity_Response.
メッセージが有効である場合（これはすでに前の交換のために行われていない場合）、レスポンダは、Exchange寿命への交換タイマーを設定します。共有秘密のその並列計算が完了すると、レスポンダはIdentity_Responseを返します。
The Responder keeps a copy of the incoming Identity_Request values, and its Identity_Response. If a duplicate Identity_Request is received, it merely resends its previous Identity_Response, and takes no further action.
Responderは、着信Identity_Request値のコピーを保持し、そのIdentity_Response。重複Identity_Requestを受信した場合、それは単にその前のIdentity_Responseを再送して、以降のアクションを実行しません。
The Responder chooses an appropriate Identification, the SPI and SPILT, a set of Attributes for the SPI, calculates the Verification, and masks the message using the Privacy-Method indicated by the current Scheme-Choice.
レスポンダは、適切な識別、SPIを選択し、こぼれ、SPIのための属性のセット、現在のスキームの選択によって示さプライバシ法を使用してメッセージを検証を算出し、マスク。
The Responder calculates the SPI session-keys in both directions.
Responderは両方向のSPIセッション・キーを計算します。
At this time, the Responder begins the authentication and/or encryption of user datagrams.
このとき、Responderは、ユーザデータグラムの認証および/または暗号化を開始します。
The Initiator validates the pair of Cookies, the Padding, the Identification, the Verification, and the Attribute-Choices.
イニシエータはクッキー、パディング、識別、検証、および属性-選択肢のペアを検証します。
- When an invalid/expired cookie is detected, the message is silently discarded.
- 期限切れの/無効のクッキーが検出されると、メッセージは静かに捨てられます。
- After unmasking, when invalid Padding is detected, the variable length Attribute-Choices do not match the UDP Length, or an attribute was not in the Offered-Attributes, the message is silently discarded.
- 不正なパディングが検出されたときに非マスクした後、可変長属性-選択肢はUDPの長さと一致しない、または属性が提供される-属性に、メッセージは静かに破棄されませんでした。
- When an invalid Identification is detected, or the message verification fails, a Verification_Failure message is sent.
- 無効な識別が検出、またはメッセージの検証が失敗した場合、Verification_Failureメッセージが送信されます。
- Whenever such a problem is detected, the Security Association is not established; the implementation SHOULD log the occurance, and notify an operator as appropriate.
- このような問題が検出されるたびに、セキュリティアソシエーションが確立されていません。実装は、のoccuranceを記録し、必要に応じてオペレータに通知すべきです。
- Once a valid message has been received, later Identity_Responses with both matching cookies are also silently discarded, until a new Cookie_Request is sent.
- 有効なメッセージが受信された後、新たなCookie_Requestが送信されるまで、両方のマッチングクッキーと後でIdentity_Responsesも静かに、破棄されます。
When the message is valid, the Initiator sets its Exchange timer to the Exchange LifeTime (if this has not already been done for a previous exchange).
メッセージが有効である場合（これはすでに前の交換のために行われていない場合）、イニシエータは、Exchange寿命への交換タイマーを設定します。
The Initiator calculates the SPI session-keys in both directions.
イニシエータは、両方向のSPIセッション・キーを計算します。
At this time, the Initiator begins the authentication and/or encryption of user datagrams.
このとき、イニシエータは、ユーザデータグラムの認証および/または暗号化を開始します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | LifeTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security-Parameters-Index |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Identity-Choice | |
+ + + + + + + + + + + + + + + + + +
| |
~ Identification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Verification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Choices ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Value_Request.
イニシエータ・クッキー16バイト。 Value_Requestからコピーされました。
Responder-Cookie 16 bytes. Copied from the Value_Request.
レスポンダ・クッキー16バイト。 Value_Requestからコピーされました。
Message 4 (Request) or 7 (Response)
メッセージ4（要求）または7（応答）
LifeTime 3 bytes. The number of seconds remaining before the indicated SPI expires.
LIFETIME 3バイト。指示SPIの有効期限が切れるまでの残りの秒数。
When the SPI is zero, this field MUST be filled with
a random non-zero value.
Security-Parameters-Index (SPI) 4 bytes. The SPI to be used for incoming communications.
セキュリティ・パラメータ・インデックス（SPI）4バイト。 SPIは、着信通信に使用されます。
When zero, indicates that no SPI is created in this direction.
場合はゼロ、何のSPIはこの方向で作成されていないことを示しています。
Identity-Choice 2 or more bytes. An identity attribute is selected from the list of Offered-Attributes sent by the peer, and is used to calculate the Verification.
アイデンティティ-Choiceの2バイト以上。 ID属性は、ピアによって送信された提供さ-属性のリストから選択され、および検証を計算するために使用されます。
The field may be any integral number of bytes in
length, as indicated by its Length field. It does
not require any particular alignment. The 16-bit
alignment shown is for convenience in the
illustration.
Identification Variable Precision Integer, or alternative format indicated by the Identity-Choice. See the "Basic Attributes" for details.
識別変数精度整数、またはアイデンティティの選択肢で示した別のフォーマット。詳細については、「基本属性」を参照してください。
The field may be any integral number of bytes in
length. It does not require any particular
alignment. The 32-bit alignment shown is for
convenience in the illustration.
Verification Variable Precision Integer, or alternative format indicated by the Identity-Choice. The calculation of the value is described in "Identity Verification".
検証可変精度整数、またはアイデンティティ-選択によって示さ代替形式。値の計算は、「識別情報の検証」に記載されています。
The field may be any integral number of bytes in
length. It does not require any particular
alignment. The 32-bit alignment shown is for
convenience in the illustration.
Attribute-Choices 0 or more bytes. When the SPI is non-zero, a list of attributes selected from the list of Offered-Attributes supported by the peer.
属性選択肢0バイト以上。 SPIは、非ゼロの、ピアによってサポートされて提供される、属性のリストから選択された属性のリストがある場合。
The contents and usage of this list are further
described in "Attribute Choices List". The end of
the list is indicated by the UDP Length after
removing the Padding (UDP Length - last Padding
value).
Padding 8 to 255 bytes. This field is filled up to at least a 128 byte boundary, measured from the beginning of the message. The number of pad bytes are chosen randomly.
8〜255バイトのパディング。このフィールドは、メッセージの先頭から測定し、少なくとも128バイト境界まで充填されます。パッド・バイトの数は、ランダムに選択されます。
In addition, when a Privacy-Method indicated by the current Scheme-Choice requires the plaintext to be a
multiple of some number of bytes (the block size of
a block cipher), this field is adjusted as necessary
to the size required by the algorithm.
Self-Describing-Padding begins with the value 1. Each byte contains the index of that byte. Thus, the final pad byte indicates the number of pad bytes to remove. For example, when the unpadded message length is 120 bytes, the padding values might be 1, 2, 3, 4, 5, 6, 7, and 8.
自己記述-パディングは、各バイトはそのバイトのインデックスが含まれている値が1で始まります。したがって、最終的なパッドバイトは、削除するパッドバイト数を示します。パディングされていないメッセージの長さが120バイトである場合、例えば、パディング値は1、2、3、4、5、6、7、及び8であるかもしれません。
The portion of the message after the SPI field is masked using the Privacy-Method indicated by the current Scheme-Choice.
SPIフィールドの後のメッセージの一部は、現在のスキームの選択によって示さプライバシ法を用いてマスクされます。
The fields following the SPI are opaque. That is, the values are set prior to masking (and optional encryption), and examined only after unmasking (and optional decryption).
SPI次のフィールドは不透明です。すなわち、値が、先行マスキング（およびオプションの暗号化）に設定され、唯一のアンマスキング（及び任意復号）後に検査されます。
This list specifies the attributes of the SPI. The attribute formats are specified in the "Basic Attributes".
このリストは、SPIの属性を指定します。属性の形式は、「基本属性」で指定されています。
The list is composed of one or two sections: Authentication-Attributes, and/or Encapsulation-Attributes.
認証、属性、および/またはカプセル化属性：リストは、1つのまたは2つのセクションで構成されています。
When sending from the SPI User to the SPI Owner, the attributes are processed in the order listed. For example,
SPI所有者へのSPIユーザーから送信する場合は、属性がリストされた順序で処理されています。例えば、
"ESP-Attributes", "Deflate" (Compression), "XOR" (Encryption), "DES-CBC" (Encryption), "XOR" (Encryption), "AH-Attributes", "AH-Sequence", "MD5-IPMAC" (Authentication),
"ESP-属性"、 "デフレート"（圧縮）、 "XOR"（暗号化）、 "DES-CBC"（暗号化）、 "XOR"（暗号化）、 "AH-属性"、 "AH-シーケンス"、「MD5 -IPMAC」（認証）
would result in ESP with compression and triple encryption (inside), and then AH authentication with sequence numbers (outside) of the ESP payload.
ESPペイロードのシーケンス番号（外部）と圧縮と暗号化三重（内側）、次いでAH認証でESPをもたらすであろう。
The SPI Owner will naturally process the datagram in the reverse order.
SPI所有者は当然逆の順序でデータグラムを処理します。
This ordering also affects the order of key generation. Both SPI
この順序はまた、鍵生成の順序に影響を与えます。どちらのSPI
Owner and SPI User generate the keys in the order listed.
所有者およびSPIユーザーがリストされた順にキーを生成します。
Implementation Notes:
実装上の注意：
When choices are made from the list of Offered-Attributes, it is not required that any Security Association include every kind of offered attribute in any single SPI, or that a separate SPI be created for every offered attribute.
選択肢が提供さ-属性のリストから作られている場合は、任意のセキュリティ協会は、任意の単一のSPIで提供される属性のすべての種類が含まれていることを必要とされていない、または別のSPIは、すべて提供された属性を作成すること。
Some kinds of attributes may be included more than once in a single SPI. The set of allowable combinations of attributes are dependent on implementation and operational policy. Such considerations are outside the scope of this document.
属性のいくつかの種類が複数回、単一のSPIよりも含まれていてもよいです。属性の許容組み合わせのセットが実装と運用ポリシーに依存しています。このような考慮事項は、この文書の範囲外です。
The list may be divided into additional sections. This can occur only when both parties recognize the affected attributes.
リストには追加のセクションに分割することができます。これは、両当事者が影響を受けた属性を認識した場合にのみ発生する可能性があります。
The authentication, compression, encryption and identification mechanisms chosen, as well as the encapsulation modes (if any), need not be the same in both directions.
選択された認証、圧縮、暗号化および識別メカニズム、ならびにカプセル化モードは、（もしあれば）、両方向で同じである必要はありません。
A shared-secret is used in a number of calculations. Regardless of the internal representation of the shared-secret, when used in calculations it is in the same form as the Value part of a Variable Precision Integer:
共有秘密は、計算数で使用されています。かかわらず、計算に使用される共有秘密の内部表現のそれは可変精度整数の値部分と同じ形です。
- most significant byte first. - bits used are right justified within byte boundaries. - any unused bits are in the most significant byte. - unused bits are zero filled.
- 最初の最上位バイト。 - 使用されるビットは、右バイト境界内に正当化されています。 - 未使用ビットは、最上位バイトです。 - 未使用のビットはゼロに充填されています。
The shared-secret does not include a Size field.
共有秘密は、サイズのフィールドが含まれていません。
These messages are authenticated using the Identity-Choice. The Verification value is calculated prior to masking (and optional encryption), and verified after unmasking (and optional decryption).
これらのメッセージは、Identity-選択肢を使用して認証されます。検証値は、従来のマスク（及び任意暗号化）を計算し、そしてアンマスキング（及び任意復号）後に確認されます。
The Identity-Choice authentication function is supplied with two input values:
アイデンティティの選択認証機能は、二つの入力値が供給されています。
- the sender (SPI Owner) verification-key, - the data to be verified (as a concatenated sequence of bytes).
- 送信者（SPI所有者）検証鍵、 - データが検証される（バイトの連結配列として）。
The resulting output value is stored in the Verification field.
結果として得られる出力値は、検証フィールドに格納されます。
The Identity-Choice verification data consists of the following concatenated values:
アイデンティティ選択肢検証データは、以下の連結された値で構成されています。
+ the Initiator Cookie, + the Responder Cookie, + the Message, LifeTime and SPI fields, + the Identity-Choice and Identification, + the SPI User Identity Verification (response only), + the Attribute-Choices following the Verification field, + the Padding, + the SPI Owner TBV, + the SPI Owner Exchange-Value, + the SPI Owner Offered-Attributes, + the SPI User TBV, + the SPI User Exchange-Value, + the SPI User Offered-Attributes, + the Responder Offered-Schemes.
+イニシエータクッキー、レスポンダクッキー+、+メッセージ、寿命およびSPIフィールド、+アイデンティティの選択および同定、+ SPIユーザー識別情報の検証（応答のみ）、+属性-選択肢を検証フィールドに続きます、+パディング、+ SPI所有者TBV、+ SPI所有者のExchange値、+ SPI所有者提供さ-属性、+ SPIユーザーTBV、+ SPIユーザーのExchange値、+ SPIユーザー提供さ-属性、+提供されるレスポンダ-Schemes。
The TBV (Three Byte Value) consists of the Counter and Scheme-Choice fields from the Value_Request, or the Reserved field from the Value_Response, immediately preceding the associated Exchange-Value.
TBV（3バイト値）は、すぐに関連する取引価値の前に、Value_ResponseからValue_RequestからのカウンターとScheme-選択フィールド、または予約済みのフィールドで構成されています。
Note that the order of the Exchange-Value and Offered-Attributes fields is different in each direction, and the Identification and SPI fields are also likely to be different in each direction. Note also that the SPI User Identity Verification (from the Identity_Request) is present only in the Identity_Response.
交換価値の順序とフィールドを提供し、属性は各方向で異なり、同定およびSPIフィールドは、各方向に異なる可能性があることに留意されたいです。 SPIユーザー（Identity_Requestから）識別情報の検証のみIdentity_Responseに存在していることにも注意してください。
If the verification fails, the users are notified, and a Verification_Failure message is sent, without adding any SPI. On success, normal operation begins with the authentication and/or encryption of user datagrams.
検証が失敗した場合、ユーザーが通知され、そしてVerification_Failureメッセージは、任意のSPIを追加することなく、送信されます。成功すると、通常の操作では、ユーザデータグラムの認証および/または暗号化することから始まります。
Implementation Notes:
実装上の注意：
This is distinct from any authentication method specified for the SPI.
これはSPIに指定された認証方法とは区別されます。
The exact details of the Identification and verification-key included in the Verification calculation are dependent on the Identity-Choice, as described in the "Basic Attributes".
「基本属性」で説明したように検証計算に含まれる識別と検証キーの正確な詳細は、アイデンティティ・選択に依存しています。
Each party may wish to keep their own trusted databases, such as the Pretty Good Privacy (PGP) web of trust, and accept only those identities found there. Failure to find the Identification in either an internal or external database results in the same
各当事者は、そのような信頼のプリティグッドプライバシー（PGP）ウェブなど、独自の信頼できるデータベースを保持したい、とだけが見られるもののアイデンティティを受け入れることができます。同じで、内部または外部データベースの結果のいずれかで識別を見つけるに失敗
Verification_Failure message as failure of the verification computation.
検証計算の障害などVerification_Failureメッセージ。
The Exchange-Value data includes both the Size and Value fields. The Offered-Attributes and Attribute-Choices data includes the Attribute, Length and Value fields.
交換-値のデータは、サイズと値フィールドの両方を含んでいます。提供さ-属性と属性の選択肢のデータは属性、長さおよび値フィールドが含まれています。
Identification Exchange messages are masked using the Privacy-Method indicated by the current Scheme-Choice. Masking begins with the next field after the SPI, and continues to the end of the data indicated by the UDP Length, including the Padding.
識別交換メッセージは、現在のスキームの選択によって示されたプライバシー・メソッドを使用してマスクされています。マスキングは、SPIの後の次のフィールドで始まり、およびパディングを含むUDPの長さによって示されたデータの最後まで継続します。
The Scheme-Choice specified Key-Generation-Function is used to create a special privacy-key for each message. This function is calculated over the following concatenated values:
スキーム-Choiceの指定された鍵生成・機能は、各メッセージのための特別なプライバシ・キーを作成するために使用されます。この機能は、以下の連結された値の上に計算されます。
+ the SPI Owner Exchange-Value, + the SPI User Exchange-Value, + the Initiator Cookie, + the Responder Cookie, + the Message, LifeTime and SPI (or Reserved) fields, + the computed shared-secret.
+ SPI所有者のExchange値、+ SPIユーザーのExchange値、+イニシエータクッキー、レスポンダクッキー+、+メッセージ、寿命およびSPI（または予約済み）フィールド、+計算された共有秘密。
Since the order of the Exchange-Value fields is different in each direction, and the Message, LifeTime and SPI fields are also different in each direction, the resulting privacy-key will usually be different in each direction.
交換バリューフィールドの順序は、各方向で異なり、メッセージ、寿命およびSPIフィールドは、各方向に異なるため、得られたプライバシーキーは、通常、各方向に異なるであろう。
When a larger number of keying-bits are needed than are available from one iteration of the specified Key-Generation-Function, more keying-bits are generated by duplicating the trailing shared-secret, and recalculating the function. That is, the first iteration will have one trailing copy of the shared-secret, the second iteration will have two trailing copies of the shared-secret, and so forth.
キーイングビットのより大きな数を指定鍵生成ファンクションの1回の繰り返しから入手可能であるよりも、必要とされる場合、より多くのキー・ビットは、後続の共有秘密を複製し、機能を再計算することによって生成されます。それは最初の反復が共有秘密の1つの末尾のコピーを持っているだろう、である、2回目の反復は等々共有秘密の2つの末尾のコピーを持っている、となります。
Implementation Notes:
実装上の注意：
This is distinct from any encryption method specified for the SPI.
これは、SPIに指定された暗号化方式とは区別されます。
The length of the Padding, and other details, are dependent on the Privacy-Method. See the "Basic Privacy-Method" list for details.
パディングの長さ、およびその他の詳細は、プライバシ法に依存しています。詳細については、「基本的なプライバシー・メソッド」リストを参照してください。
To avoid keeping the Exchange-Values in memory after the initial verification, it is often possible to pre-compute the function over the initial bytes of the concatenated data values for each direction, and append the trailing copies of the shared-secret.
最初の検証後にメモリ内のExchange-値を保つ避けるためには、各方向に連結されたデータ値の最初のバイトを超える機能を事前に計算し、共有秘密の末尾にコピーを追加することが可能であることが多いです。
The Exchange-Value data includes both the Size and Value fields.
交換-値のデータは、サイズと値フィールドの両方を含んでいます。
Each SPI has one or more session-keys. These keys are generated based on the attributes of the SPI. See the "Basic Attributes" for details.
各SPIは、一つ以上のセッション・キーがあります。これらのキーは、SPIの属性に基づいて生成されます。詳細については、「基本属性」を参照してください。
The Scheme-Choice specified Key-Generation-Function is used to create the SPI session-key for that particular attribute. This function is calculated over the following concatenated values:
スキーム-Choiceの指定された鍵生成・機能は、その特定の属性のためのSPIセッション・キーを作成するために使用されます。この機能は、以下の連結された値の上に計算されます。
+ the Initiator Cookie, + the Responder Cookie, + the SPI Owner generation-key, + the SPI User generation-key, + the message Verification field, + the computed shared-secret.
+イニシエータクッキー、レスポンダクッキー+、+ SPI所有者世代キー、+ SPIユーザー生成キー、+メッセージの検証フィールド、+計算された共有秘密。
Since the order of the generation-keys is different in each direction, and the Verification field is also likely to be different in each direction, the resulting session-key will usually be different in each direction.
世代キーの順序が各方向で異なり、検証フィールドは、各方向に異なる可能性があるので、得られたセッション鍵は、通常、各方向に異なるであろう。
When a larger number of keying-bits are needed than are available from one iteration of the specified Key-Generation-Function, more keying-bits are generated by duplicating the trailing shared-secret, and recalculating the function. That is, the first iteration will have one trailing copy of the shared-secret, the second iteration will have two trailing copies of the shared-secret, and so forth.
キーイングビットのより大きな数を指定鍵生成ファンクションの1回の繰り返しから入手可能であるよりも、必要とされる場合、より多くのキー・ビットは、後続の共有秘密を複製し、機能を再計算することによって生成されます。それは最初の反復が共有秘密の1つの末尾のコピーを持っているだろう、である、2回目の反復は等々共有秘密の2つの末尾のコピーを持っている、となります。
Implementation Notes:
実装上の注意：
This is distinct from any privacy-key generated for the Photuris exchange. Different initialization data is used, and iterations are maintained separately.
これは、Photuris交換のために生成された任意のプライバシーのキーとは区別されます。別の初期化データが使用され、反復が別々に維持されています。
The exact details of the Verification field and generation-keys that are included in the session-key calculation are dependent on the Identity-Choices, as described in the "Basic Attributes".
「基本属性」に記載されたセッション鍵の計算に含まれている検証分野と世代の鍵の正確な詳細は、アイデンティティ・選択肢に依存しています。
To avoid keeping the generation-keys in memory after the initial verification, it is often possible to pre-compute the function over the initial bytes of the concatenated data values for each direction, and append the trailing copies of the shared-secret.
最初の検証後にメモリ内に生成鍵を維持回避するためには、各方向に連結されたデータ値の最初のバイトを超える関数を事前に計算し、共有秘密の後続コピーを追加することがしばしば可能です。
When both authentication and encryption attributes are used for the same SPI, there may be multiple session-keys associated with the same SPI. These session-keys are generated in the order of the Attribute-Choices list.
両方の認証と暗号化属性が同じSPIのために使用される場合、同じSPIに関連する複数のセッション鍵が存在してもよいです。これらのセッション・キーは、属性、選択肢のリストの順に生成されます。
SPI User SPI Owner
======== =========
SPI_Needed ->
list SPI attribute(s)
make validity key
authenticate
make privacy key(s)
mask/encrypt message
<- SPI_Update
make SPI
pick SPI attribute(s)
make SPI session-key(s)
make validity key
authenticate
make privacy key(s)
mask/encrypt message
The exchange of messages is not related to the Initiator and Responder. Instead, either party may send one of these messages at any time. The messages are easily distinguished by the parties.
メッセージの交換は、イニシエータとレスポンダとは関係ありません。代わりに、いずれかの当事者は、いつでもこれらのメッセージのいずれかを送信することができます。メッセージは簡単に、当事者によって区別されます。
At any time after completion of the Identification Exchange, either party can send SPI_Needed. This message is sent when a prospective SPI User needs particular attributes for a datagram (such as confidentiality), and no current SPI has those attributes.
識別取引終了後の任意の時点で、いずれかの当事者はSPI_Neededを送ることができます。将来のSPIユーザが（例えば、機密性のような）データグラムのための特定の属性を必要としない現在のSPIはこれらの属性を持っていない場合、このメッセージが送信されます。
The prospective SPI User selects from the intersection of attributes that both parties have previously offered, calculates the Verification, and masks the message using the Privacy-Method indicated by the current Scheme-Choice.
将来のSPIユーザーは、現在のスキームの選択によって示されたプライバシー・メソッドを使用してメッセージを、両当事者が以前に提供している属性の交差点から選択検証を計算し、マスク。
The potential SPI Owner validates the pair of Cookies, the Padding, the Verification, and the Attributes-Needed.
潜在的なSPI所有者は、クッキーのペア、パディング、検証、および、必要な属性を検証します。
- When an invalid/expired cookie is detected, a Bad_Cookie message is sent.
- 期限切れの/無効のクッキーが検出されると、Bad_Cookieメッセージが送信されます。
- When too many SPI values are already in use for this particular peer, or some other resource limit is reached, a Resource_Limit message is sent.
- あまりにも多くのSPI値は、この特定のピアのためにすでに使用されている、またはいくつかの他のリソース制限に達すると、RESOURCE_LIMITメッセージが送信されます。
- After unmasking, when invalid Padding is detected, the variable length Attributes-Needed do not match the UDP Length, or an attribute was not in the Offered-Attributes, the message is silently discarded.
- 非マスクした後、無効のPaddingが検出されたときに、変数の長さは、UDPの長さと一致しない属性-必要な、または属性が提供される-属性に、メッセージは静かに破棄されませんでした。
- When the message verification fails, a Verification_Failure message is sent.
- メッセージの検証が失敗した場合、Verification_Failureメッセージが送信されます。
- Whenever such a problem is detected, the SPI is not established; the implementation SHOULD log the occurance, and notify an operator as appropriate.
- このような問題が検出されると、SPIが確立されていません。実装は、のoccuranceを記録し、必要に応じてオペレータに通知すべきです。
When the message is valid, the party SHOULD send SPI_Update with the necessary attributes.
メッセージが有効であるときは、当事者は、必要な属性を持つSPI_Updateを送るべきです。
If an existing SPI has those attributes, that SPI is returned in the SPI_Update with the remaining SPILT.
既存のSPIは、SPIがこぼれ残ってSPI_Updateで返されていること、それらの属性を持っている場合。
At any time after completion of the Identification Exchange, either party can send SPI_Update. This message has effect in only one direction, from the SPI Owner to the SPI User.
識別取引終了後の任意の時点で、いずれかの当事者はSPI_Updateを送ることができます。このメッセージは、SPI所有者からのSPIユーザーに、一方向にのみ効果があります。
The SPI Owner chooses the SPI and SPILT, a set of Attributes for the SPI, calculates the Verification, and masks the message using the Privacy-Method indicated by the current Scheme-Choice.
SPI所有者は、SPIとこぼれ、SPIの属性のセットを選択し、現在のスキームの選択によって示さプライバシ法を使用してメッセージを検証を算出し、マスク。
The prospective SPI User validates the pair of Cookies, the Padding, the Verification, and the Attributes-Needed.
将来のSPIユーザーはクッキー、パディング、検証、および、必要な属性のペアを検証します。
- When an invalid/expired cookie is detected, a Bad_Cookie message
- 期限切れの/無効のクッキーが検出され、Bad_Cookieメッセージ
is sent.
送信されます。
- After unmasking, when invalid Padding is detected, the variable length Attribute-Choices do not match the UDP Length, an attribute was not in the Offered-Attributes, or the message modifies an existing SPI, the message is silently discarded.
- 不正なパディングが検出されたときに、可変長属性-選択肢は、UDPの長さと一致しない、マスク解除した後、属性が提供さ-属性ではありませんでした、またはメッセージが既存のSPIを変更し、メッセージは静かに破棄されます。
- When the message verification fails, a Verification_Failure message is sent.
- メッセージの検証が失敗した場合、Verification_Failureメッセージが送信されます。
- Whenever such a problem is detected, the SPI is not established; the implementation SHOULD log the occurance, and notify an operator as appropriate.
- このような問題が検出されると、SPIが確立されていません。実装は、のoccuranceを記録し、必要に応じてオペレータに通知すべきです。
When the message is valid, further actions are dependent on the value of the LifeTime field, as described later.
メッセージが有効である場合、後述するように、更なるアクションは、ライフタイムフィールドの値に依存しています。
Each SPI requires replacement under several circumstances:
各SPIは、いくつかの状況下での交換が必要です。
- the volume of data processed (inhibiting probability cryptanalysis),
- 処理されたデータの量（阻害確率暗号解読）
- exhaustion of available anti-replay Sequence Numbers,
- 利用できるアンチリプレイシーケンス番号の枯渇、
- and expiration of the LifeTime.
- 生涯の満了。
In general, a determination is made upon receipt of a datagram. If the transform specific processing finds that refreshment is needed, an automated SPI_Update is triggered.
一般に、決意は、データグラムの受信時に行われます。変換具体的な処理は、リフレッシュが必要であることを発見した場合、自動化されたSPI_Updateがトリガされます。
In addition, automated SPI_Updates allow rapid SPI refreshment for high bandwidth applications in a high delay environment. The update messages flow in the opposite direction from the primary traffic, conserving bandwidth and avoiding service interruption.
また、自動化されたSPI_Updatesは、高遅延環境における高帯域幅アプリケーションのための迅速なSPIのリフレッシュを可能にします。更新メッセージは、帯域幅を節約し、サービスの中断を回避、主トラフィックから反対方向に流れます。
When creating each SPI, the implementation MAY optionally set an Update TimeOut (UTO); by default, to half the value of the LifeTime (SPILT/2). This time is highly dynamic, and adjustable to provide an automated SPI_Update long before transform specific processing. If no new Photuris exchange occurs within the time limit, and the current exchange state has not expired, an automated SPI_Update is sent.
各SPIを作成する場合、実装は、必要に応じて更新タイムアウト（UTO）を設定してもよいです。デフォルトでは、寿命（こぼれ/ 2）の半分の値に設定します。この時間は、長い前に、特定の変換処理を自動化SPI_Updateを提供することが非常にダイナミック、かつ調整可能です。新しいPhoturis交換は、制限時間内に発生していない、と現在の為替状態が満了していない場合は、自動化されたSPI_Updateが送信されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Reserved-LT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved-SPI |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
~ Verification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes-Needed ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Value_Request.
イニシエータ・クッキー16バイト。 Value_Requestからコピーされました。
Responder-Cookie 16 bytes. Copied from the Value_Request.
レスポンダ・クッキー16バイト。 Value_Requestからコピーされました。
Message 8
メッセージ8
Reserved-LT 3 bytes. For future use; MUST be filled with a random non-zero value when transmitted, and MUST be ignored when received.
予約-LT 3バイト。将来の使用のために。送信、及び受信した場合、無視されなければならない場合、ランダムな非ゼロ値で埋めなければなりません。
Reserved-SPI 4 bytes. For future use; MUST be set to zero when transmitted, and MUST be ignored when received.
予約-SPI 4バイト。将来の使用のために。送信、及び受信した場合、無視されなければならない場合、ゼロに設定しなければなりません。
Verification Variable Precision Integer, or other format indicated by the current Scheme-Choice. The calculation of the value is described in "Validity Verification".
検証可変精度整数、または現在のスキームの選択によって示された他の形式。値の計算は、「妥当性検証」に記載されています。
The field may be any integral number of bytes in
length. It does not require any particular
alignment. The 32-bit alignment shown is for
convenience in the illustration.
Attributes-Needed 4 or more bytes. A list of two or more attributes, selected from the list of Offered-Attributes supported by the peer.
4バイト以上を-必要な属性。ピアによってサポートされて提供される、属性のリストから選択される2つの以上の属性のリスト。
The contents and usage of this list are as
previously described in "Attribute Choices List".
The end of the list is indicated by the UDP Length
after removing the Padding (UDP Length - last
Padding value).
Padding 8 or more bytes. The message is padded in the same fashion specified for Identification Exchange messages.
8バイト以上をパディング。メッセージは識別為替メッセージに対して指定されたのと同じやり方で水増しされます。
The portion of the message after the SPI field is masked using the Privacy-Method indicated by the current Scheme-Choice.
SPIフィールドの後のメッセージの一部は、現在のスキームの選択によって示さプライバシ法を用いてマスクされます。
The fields following the SPI are opaque. That is, the values are set prior to masking (and optional encryption), and examined only after unmasking (and optional decryption).
SPI次のフィールドは不透明です。すなわち、値が、先行マスキング（およびオプションの暗号化）に設定され、唯一のアンマスキング（及び任意復号）後に検査されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | LifeTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security-Parameters-Index |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
~ Verification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Choices ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Value_Request.
イニシエータ・クッキー16バイト。 Value_Requestからコピーされました。
Responder-Cookie 16 bytes. Copied from the Value_Request.
レスポンダ・クッキー16バイト。 Value_Requestからコピーされました。
Message 9
メッセージ9
LifeTime 3 bytes. The number of seconds remaining before the indicated SPI expires. The value zero indicates deletion of the indicated SPI.
LIFETIME 3バイト。指示SPIの有効期限が切れるまでの残りの秒数。値ゼロは、示さSPIの欠失を示します。
Security-Parameters-Index (SPI) 4 bytes. The SPI to be used for incoming communications.
セキュリティ・パラメータ・インデックス（SPI）4バイト。 SPIは、着信通信に使用されます。
This may be a new SPI value (for creation), or an
existing SPI value (for deletion). The value zero
indicates special processing.
Verification Variable Precision Integer, or other format indicated by the current Scheme-Choice. The calculation of the value is described in "Validity Verification".
検証可変精度整数、または現在のスキームの選択によって示された他の形式。値の計算は、「妥当性検証」に記載されています。
The field may be any integral number of bytes in
length. It does not require any particular
alignment. The 32-bit alignment shown is for
convenience in the illustration.
Attribute-Choices 0 or more bytes. When the SPI and SPILT are non-zero, a list of attributes selected from the list of Offered-Attributes supported by the peer.
属性選択肢0バイト以上。 SPIと流出は、非ゼロ、ピアによってサポートされて提供される、属性のリストから選択された属性のリストである場合。
The contents and usage of this list are as
previously described in "Attribute Choices List".
The end of the list is indicated by the UDP Length
after removing the Padding (UDP Length - last
Padding value).
Padding 8 or more bytes. The message is padded in the same fashion specified for Identification Exchange messages.
8バイト以上をパディング。メッセージは識別為替メッセージに対して指定されたのと同じやり方で水増しされます。
The portion of the message after the SPI field is masked using the Privacy-Method indicated by the current Scheme-Choice.
SPIフィールドの後のメッセージの一部は、現在のスキームの選択によって示さプライバシ法を用いてマスクされます。
The fields following the SPI are opaque. That is, the values are set prior to masking (and optional encryption), and examined only after unmasking (and optional decryption).
SPI次のフィールドは不透明です。すなわち、値が、先行マスキング（およびオプションの暗号化）に設定され、唯一のアンマスキング（及び任意復号）後に検査されます。
When the LifeTime is non-zero, and the SPI is also non-zero, the SPI_Update can be used to create a new SPI. When the SPI is zero, the SPI_Update is silently discarded.
寿命が非ゼロであり、SPIは非ゼロである場合には、SPI_Updateは新しいSPIを作成するために使用することができます。 SPIがゼロの場合は、SPI_Updateは黙って破棄されます。
The new session-keys are calculated in the same fashion as the Identity_Messages. Since the SPI value is always different than any previous SPI during the Exchange LifeTime of the shared-secret, the resulting session-keys will necessarily be different from all others used in the same direction.
新しいセッション・キーがIdentity_Messagesと同じ方法で計算されます。 SPI値が共有秘密の交換寿命の間の任意の以前のSPIよりも常に異なるので、得られたセッション鍵は、必ずしも同じ方向で使用されるすべての他のものと異なるであろう。
No retransmission timer is necessary. Success is indicated by the peer use of the new SPI.
再送タイマーは必要ありません。成功は新しいSPIのピア使用によって示されます。
Should all creation attempts fail, eventually the peer will find that all existing SPIs have expired, and will begin the Photuris exchange again by sending a new Cookie_Request. When appropriate, this Cookie_Request MAY include a Responder-Cookie to retain previous party pairings.
試みが失敗し、すべての創造は、最終的には、ピアは、既存のすべてのSPIの期限が切れていることがわかりますする必要があり、新しいCookie_Requestを送信することによって、再びPhoturis交換を開始します。適切な場合、このCookie_Requestは前回党のペアを保持するレスポンダ-クッキーを含むかもしれません。
When the LifeTime is zero, the SPI_Update can be used to delete a single existing SPI. When the SPI is also zero, the SPI_Update will delete all existing SPIs related to this Security Association, and mark the Photuris exchange state as expired. This is especially useful when the application that needed them terminates.
寿命がゼロである場合、SPI_Updateは、単一の既存のSPIを削除するために使用することができます。 SPIもゼロである場合には、SPI_Updateは、このセキュリティアソシエーションに関連するすべての既存のSPIを削除し、期限切れのPhoturis交換状態をマーク。これは、彼らが必要なアプリケーションが終了するときに特に便利です。
No retransmission timer is necessary. This message is advisory, to reduce the number of ICMP Security Failures messages.
再送タイマーは必要ありません。このメッセージは、ICMPセキュリティ障害メッセージの数を減らすために、顧問です。
Should any deletion attempts fail, the peer will learn that the deleted SPIs are invalid through the normal ICMP Security Failures messages, and will initiate a Photuris exchange by sending a new Cookie_Request.
任意の削除の試みが失敗すると、ピアは、削除のSPIは、通常のICMPセキュリティの失敗メッセージを介して無効であることを学びますし、新しいCookie_Requestを送ることによって、Photuris交換を開始します。
The SPI_Update cannot be used to modify existing SPIs, such as lengthen an existing SPI LifeTime, resurrect an expired SPI, or add/remove an Attribute-Choice.
SPI_Updateは、このような、既存のSPI寿命を長く期限切れのSPIを復活、または追加/属性-選択肢を削除するなど、既存のSPIを、変更するために使用することはできません。
On receipt, such an otherwise valid message is silently discarded.
領収書には、そのようなそうでない場合は、有効なメッセージは静かに捨てられます。
These messages are authenticated using the Validity-Method indicated by the current Scheme-Choice. The Verification value is calculated prior to masking (and optional encryption), and verified after unmasking (and optional decryption).
これらのメッセージは、現在のスキームの選択によって示された有効性・メソッドを使用して認証されます。検証値は、従来のマスク（及び任意暗号化）を計算し、そしてアンマスキング（及び任意復号）後に確認されます。
The Validity-Method authentication function is supplied with two input values:
有効法認証機能は、二つの入力値が供給されます。
- the sender (SPI Owner) verification-key, - the data to be verified (as a concatenated sequence of bytes).
- 送信者（SPI所有者）検証鍵、 - データが検証される（バイトの連結配列として）。
The resulting output value is stored in the Verification field.
結果として得られる出力値は、検証フィールドに格納されます。
The Validity-Method verification data consists of the following concatenated values:
妥当性メソッド検証データは、以下の連結された値で構成されています。
+ the Initiator Cookie, + the Responder Cookie, + the Message, LifeTime and SPI (or Reserved) fields, + the SPI Owner Identity Verification, + the SPI User Identity Verification, + the Attribute-Choices following the Verification field, + the Padding.
+イニシエータクッキー、レスポンダクッキー+、+メッセージ、寿命およびSPI（または予約済み）フィールド、+ SPI所有者識別情報の検証、+ SPIユーザー識別情報の検証、+属性-選択肢を検証フィールドに続く、+パディング。
Note that the order of the Identity Verification fields (from the Identity_Messages) is different in each direction, and the Message, LifeTime and SPI fields are also likely to be different in each direction.
（Identity_Messagesから）識別情報の検証フィールドの順序は、各方向で異なり、メッセージ、寿命及びSPIフィールドは、各方向に異なる可能性があることに留意されたいです。
If the verification fails, the users are notified, and a Verification_Failure message is sent, without adding or deleting any SPIs. On success, normal operation begins with the authentication and/or encryption of user datagrams.
検証が失敗した場合、ユーザーが通知され、そしてVerification_Failureメッセージは、任意のSPIを追加または削除せずに、送信されます。成功すると、通常の操作では、ユーザデータグラムの認証および/または暗号化することから始まります。
Implementation Notes:
実装上の注意：
This is distinct from any authentication method specified for the SPI.
これはSPIに指定された認証方法とは区別されます。
The Identity Verification data includes both the Size and Value fields. The Attribute-Choices data includes the Attribute, Length and Value fields.
識別情報の検証データはサイズと値フィールドの両方を含んでいます。属性-選択肢データは属性、長さおよび値フィールドが含まれています。
These messages are issued in response to Photuris state loss or other problems. A message has effect in only one direction. No retransmission timer is necessary.
これらのメッセージはPhoturis状態の損失やその他の問題に応答して発行されています。メッセージは、一方向のみに効果を有します。再送タイマーは必要ありません。
These messages are not masked.
これらのメッセージは、マスクされていません。
The receiver checks the Cookies for validity. Special care MUST be taken that the Cookie pair in the Error Message actually match a pair currently in use, and that the protocol is currently in a state where such an Error Message might be expected. Otherwise, these messages could provide an opportunity for a denial of service attack. Invalid messages are silently discarded.
受信機は、有効性のためにクッキーをチェックします。特別なケアは、エラーメッセージにクッキーペアが実際に現在使用中のペアに一致するように注意しなければならない、そしてそれは、プロトコルは、このようなエラーメッセージが予想される状態に現在あります。そうでなければ、これらのメッセージは、サービス拒否攻撃の機会を提供することができます。無効なメッセージは静かに破棄されます。
For the format of the 33 byte message, see "Header Format". There are no additional fields.
33バイトのメッセージのフォーマットについては、「ヘッダー形式」を参照してください。追加のフィールドがありません。
Initiator-Cookie 16 bytes. Copied from the offending message.
イニシエータ・クッキー16バイト。問題のあるメッセージからコピーされました。
Responder-Cookie 16 bytes. Copied from the offending message.
レスポンダ・クッキー16バイト。問題のあるメッセージからコピーされました。
Message 10
メッセージ10
This error message is sent when a Value_Request, Identity_Request, SPI_Needed, or SPI_Update is received, and the receiver specific Cookie is invalid or the associated exchange state has expired.
場合Value_Request、Identity_Request、SPI_Neededこのエラーメッセージが送信され、又はSPI_Updateが受信され、そして受信機固有のクッキーが無効であるか、または関連する交換状態の有効期限が切れています。
During the Photuris exchange, when this error message is received, it has no immediate effect on the operation of the protocol phases. Later, when Retransmissions have been exceeded, and this error message has been received, the Initiator SHOULD begin the Photuris exchange again by sending a new Cookie_Request with the Responder-Cookie and Counter updated appropriately.
Photuris交換の間に、このエラーメッセージを受信したとき、それはプロトコルフェーズの動作には即効性がありません。その後、再送を超えていると、このエラーメッセージを受信したとき、イニシエータは適宜更新レスポンダ-Cookieとカウンターで新しいCookie_Requestを送信することによって、再びPhoturis交換を開始する必要があります。
When this error message is received in response to SPI_Needed, the exchange state SHOULD NOT be marked as expired, but the party SHOULD initiate a Photuris exchange by sending a new Cookie_Request.
このエラーメッセージがSPI_Neededに応答して受信された場合、有効期限が切れて交換状態がマークされるべきではなく、当事者が新しいCookie_Requestを送ることによって、Photuris交換を開始すべきです。
When this error message is received in response to SPI_Update, the exchange state SHOULD NOT be marked as expired, and no further action is taken. A new exchange will be initiated later when needed by the peer to send authenticated and/or encrypted data.
このエラーメッセージがSPI_Updateに応答して受信された場合、交換状態が期限切れとしてマークされるべきではない、それ以上のアクションは取られません。認証されたおよび/または暗号化されたデータを送信するために、ピアが必要とするときに、新しい交換は、後に開始されます。
Existing SPIs are not deleted. They expire normally, and are purged sometime later.
既存のSPIは削除されません。彼らは通常、有効期限が切れ、そしていつか後にパージされます。
For the format of the 34 byte message, see "Cookie_Request". There are no additional fields.
34バイトのメッセージのフォーマットについては、「Cookie_Request」を参照してください。追加のフィールドがありません。
Initiator-Cookie 16 bytes. Copied from the offending message.
イニシエータ・クッキー16バイト。問題のあるメッセージからコピーされました。
Responder-Cookie 16 bytes. Copied from the offending message.
レスポンダ・クッキー16バイト。問題のあるメッセージからコピーされました。
Special processing is applied to a Cookie_Request.
When the offending message Responder-Cookie and
Counter were both zero, and an existing exchange has
not yet been purged, this field is replaced with the
Responder-Cookie from the existing exchange.
既存のExchangeからレスポンダ-クッキー。
Message 11
メッセージ11
Counter 1 byte. Copied from the offending message.
カウンタ1バイト。問題のあるメッセージからコピーされました。
When zero, the Responder-Cookie indicates the
Initiator of a previous exchange, or no previous
exchange is specified.
When non-zero, the Responder-Cookie indicates the Responder to a previous exchange. This value is set to the Counter from the corresponding Cookie_Response.
場合非ゼロ、レスポンダクッキーは以前交換にレスポンダを示しています。この値は、対応するCookie_Responseからのカウンターに設定されています。
This error message is sent when a Cookie_Request, Value_Request or SPI_Needed is received, and too many SPI values are already in use for that peer, or some other Photuris resource is unavailable.
Cookie_Request、Value_Request又はSPI_Neededを受信したときにエラーメッセージが送信され、あまりにも多くのSPI値は、そのピアのすでに使用されている、またはいくつかの他のPhoturisリソースが利用できません。
During the Photuris exchange, when this error message is received in response to a Cookie_Request or Value_Request, the implementation SHOULD double the retransmission timeout (as usual) for sending another Cookie_Request or Value_Request. Otherwise, it has no immediate effect on the operation of the protocol phases. Later, when Retransmissions have been exceeded, and this error message has been received, the Initiator SHOULD begin the Photuris exchange again by sending a new Cookie_Request with the Responder-Cookie and Counter updated appropriately.
Photuris交換の間に、このエラーメッセージがCookie_Request又はValue_Requestに応答して受信された場合、実装は、別のCookie_Request又はValue_Requestを送信する（いつものように）再送タイムアウトを倍増すべきです。それ以外の場合は、プロトコルフェーズの動作には直接の影響を与えません。その後、再送を超えていると、このエラーメッセージを受信したとき、イニシエータは適宜更新レスポンダ-Cookieとカウンターで新しいCookie_Requestを送信することによって、再びPhoturis交換を開始する必要があります。
When this error message is received in response to SPI_Needed, the implementation SHOULD NOT send another SPI_Needed until one of the existing SPIs associated with this exchange is deleted or has expired.
このエラーメッセージがSPI_Neededに応答して受信された場合、実装は、この交換が削除されたか、期限が切れているに関連付けられている既存のSPIの1まで、別のSPI_Neededを送るべきではありません。
For the format of the 33 byte message, see "Header Format". There are no additional fields.
33バイトのメッセージのフォーマットについては、「ヘッダー形式」を参照してください。追加のフィールドがありません。
Initiator-Cookie 16 bytes. Copied from the offending message.
イニシエータ・クッキー16バイト。問題のあるメッセージからコピーされました。
Responder-Cookie 16 bytes. Copied from the offending message.
レスポンダ・クッキー16バイト。問題のあるメッセージからコピーされました。
Message 12
メッセージ12
This error message is sent when an Identity_Message, SPI_Needed or SPI_Update is received, and verification fails.
このエラーメッセージはIdentity_Message、SPI_Needed又はSPI_Updateを受信したときに送信され、検証が失敗しています。
When this error message is received, the implementation SHOULD log the occurance, and notify an operator as appropriate. However, receipt has no effect on the operation of the protocol.
このエラーメッセージを受信した場合、実装は、発生を記録し、必要に応じてオペレータに通知すべきです。しかし、領収書は、プロトコルの動作には影響を与えません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Bad-Message | Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the offending message.
イニシエータ・クッキー16バイト。問題のあるメッセージからコピーされました。
Responder-Cookie 16 bytes. Copied from the offending message.
レスポンダ・クッキー16バイト。問題のあるメッセージからコピーされました。
Message 13
メッセージ13
Bad-Message 1 byte. Indicates the Message number of the offending message.
バート・メッセージ1バイト。問題のあるメッセージのメッセージ番号を示します。
Offset 2 bytes. The number of bytes from the beginning of the offending message where the unrecognized field starts. The minimum value is 32.
2つのバイトオフセット。認識できないフィールドが始まり、問題のメッセージの先頭からのバイト数。最小値は32です。
This error message is sent when an optional Message type is received that is not supported, or an optional format of a supported Message is not recognized.
オプションのメッセージタイプを受信した場合、このエラーメッセージはサポートされていない、またはサポートされるメッセージのオプションのフォーマットが認識されない送信されます。
When this error message is received, the implementation SHOULD log the occurance, and notify an operator as appropriate. However, receipt has no effect on the operation of the protocol.
このエラーメッセージを受信した場合、実装は、発生を記録し、必要に応じてオペレータに通知すべきです。しかし、領収書は、プロトコルの動作には影響を与えません。
Photuris is based in principle on public-key cryptography, specifically Diffie-Hellman key exchange. Exchange of public D-H Exchange-Values based on private-secret values results in a mutual shared-secret between the parties. This shared-secret can be used on its own, or to generate a series of session-keys for authentication and encryption of subsequent traffic.
Photurisは、公開鍵暗号、特にのDiffie-Hellman鍵交換に原則的に基づいています。当事者間の相互共有秘密の民間秘密値の結果に基づき、公共D-H交換値の交換。この共有秘密は、独自に使用することができ、または後続のトラフィックの認証と暗号化のためのセッション・キーのシリーズを生成します。
This document assumes familiarity with the Diffie-Hellman public-key algorithm. A good description can be found in [Schneier95].
この文書では、ディフィー-Hellman公開鍵アルゴリズムに精通している前提としています。良好な説明は、[Schneier95]に見出すことができます。
The original Diffie-Hellman technique [DH76] specified modular exponentiation. A public-value is generated using a generator (g), raised to a private-secret exponent (x), modulo a prime (p):
元のDiffie-Hellman技術[DH76]はべき乗剰余を指定しました。公共値は秘密秘密指数（x）は、プライム（p）をモジュロに上げ、発電機（G）を使用して生成されます。
(g**x) mod p.
（G ** X）MOD P。
When these public-values are exchanged between parties, the parties can calculate a shared-secret value between themselves:
これらの公共の値は、当事者間で交換された場合、当事者は自分たちの間で共有秘密値を計算することができます。
(g**xy) mod p.
（G ** XY）MOD P。
The generator (g) and modulus (p) are established by the Scheme-Choice (see the "Basic Exchange-Schemes" for details). They are offered in the Cookie_Response, and one pair is chosen in the Value_Request.
発電機（G）と弾性率（p）はスキームの選択（詳細については、「基本的な交流・スキーム」を参照）によって確立されています。彼らはCookie_Responseで提供されており、1つのペアがValue_Requestに選択されています。
The private exponents (x) and (y) are kept secret by the parties. Only the public-value result of the modular exponentiation with (x) or (y) is sent as the Initiator and Responder Exchange-Value.
プライベート指数（x）と（y）は、当事者が秘密にされています。 （X）または（Y）とのべき乗剰余の唯一の公開値の結果は、イニシエータとレスポンダ交換価値として送信されます。
These public-values are represented in single Variable Precision Integers. The Size of these Exchange-Values will match the Size of the modulus (p).
これらの公共の値は、単一の可変精度整数で表されます。これらの取引値の大きさは、弾性率（P）のサイズと一致します。
Each implementation proposes one or more moduli in its Offered-Schemes. Every implementation MUST support up to 1024-bit moduli.
各実装は、その提供さ-スキーム内の1つまたは複数の弾性係数を提案しています。すべての実装では、最大1024ビットのモジュラスをサポートしなければなりません。
For any particular Photuris node, these moduli need not change for significant periods of time; likely days or weeks. A background process can periodically generate new moduli.
いずれかの特定のPhoturisノードの場合は、これらの弾性率は、時間のかなりの期間に変更する必要はありません。おそらく数日または数週間。バックグラウンド・プロセスは、定期的に新しい弾性係数を生成することができます。
For 512-bit moduli, current estimates would provide 64 (pessimistic) bit-equivalents of cryptographic strength.
512ビットのモジュラスのために、現在の推定値は、暗号の強さの64（悲観的）ビットの等価物を提供します。
For 1024-bit moduli, current estimates would range from 80 (pessimistic) through 98 (optimistic) bit-equivalents of cryptographic strength.
1024ビットモジュラスのために、現在の推定値は80（悲観的）から暗号強度の98（楽観的）ビット当量までの範囲であろう。
These estimates are used when choosing moduli that are appropriate for the desired Security Parameter attributes.
希望のセキュリティパラメータの属性に適した弾性係数を選択するときに、これらの推定値が使用されています。
Each implementation is likely to use a fixed modulus during its bootstrap, until it can generate another modulus in the background. As the bootstrap modulus will be widely distributed, and reused whenever the machine reinitializes, it SHOULD be a "safe" prime (p = 2q+1) to provide the greatest long-term protection.
各実装は、それがバックグラウンドで別の係数を生成することができるまで、そのブートストラップの間に一定の係数を使用する可能性があります。ブートストラップ弾性率が広く分布し、そしていつでも機械の再初期化を再利用されるように、最大の長期的保護を提供するために「安全な」素数（P = 2Q + 1）であるべきです。
Implementors are encouraged to generate their own bootstrap moduli, and to change bootstrap moduli in successive implementation releases.
実装者は、独自のブートストラップ弾性率を生成し、かつ連続した実装のリリースでは、ブートストラップのモジュラスを変更することをお勧めします。
As Photuris exchanges are initiated, new moduli will be learned from the Responder Offered-Schemes. The Initiator MAY cache these moduli for its own use.
Photuris交換が開始されると、新しい弾性係数は、レスポンダ提供さ-スキームから学習されます。イニシエータは、自身の使用のためにこれらの弾性係数をキャッシュすることができます。
Before offering any learned modulus, the implementation MUST perform at least one iteration of probable primality verification. In this fashion, many processors will perform verification in parallel as moduli are passed around.
どんな学んだモジュラスを提供する前に、実装が予想素数検証の少なくとも一回の反復を実行しなければなりません。モジュラスが約渡されるように、この方法で、多くのプロセッサは、並行して検証を実行します。
When primality verification failures are found, the failed moduli SHOULD be retained for some (implementation dependent) period of time, to avoid re-learning and re-testing after subsequent exchanges.
素数検証の失敗が発見された場合は、失敗した弾性係数は、その後の交換後の再学習と再試験を避けるために、時間の一部（実装依存）の期間のために保持する必要があります。
The generator (g) should be chosen such that the private-secret exponents will generate all possible public-values, evenly distributed throughout the range of the modulus (p), without cycling through a smaller subset. Such a generator is called a "primitive root" (which is trivial to find when p is "safe").
発電機（G）は、より小さなサブセットを循環することなく、プライベート秘密指数が均等係数（P）の範囲全体に分散可能なすべての公開値を生成するように選択されるべきです。このような発電機は、（pは「安全」である場合に見つけることが自明である）「原始根」と呼ばれています。
Only one generator (2) is required to be supported.
唯一の発電機（2）をサポートする必要があります。
Implementation Notes:
実装上の注意：
One useful technique is to select the generator, and then limit the modulus selection sieve to primes with that generator:
一つの有用な技術は、発電機を選択し、その発生器をプライミングするモジュラス選択ふるいを制限することです。
2 when p (mod 24) = 11. 3 when p (mod 12) = 5. 5 when p (mod 10) = 3 or 7.
2 P（MOD 24）= 11。3 P（MOD 12）= 5.5場合P（MOD 10）= 3または7。
The required generator (2) improves efficiency in multiplication performance. It is usable even when it is not a primitive root, as it still covers half of the space of possible residues.
必要な発電機（2）が乗算性能の効率を向上させることができます。それはまだ可能性残基のスペースの半分をカバーしていて、それは、原始根でない場合であっても、それは使用可能です。
Each implementation generates a separate random private-secret exponent for each different modulus. Then, a D-H Exchange-Value is calculated for the given modulus, generator, and exponent.
各実装は、それぞれ異なる係数に個別のランダム民間秘密指数を生成します。次いで、D-H交換値は、所与のモジュラス、ジェネレータ、および指数に対して計算されます。
This specification recommends that the exponent length be at least twice the desired cryptographic strength of the longest session-key needed by the strongest offered-attribute.
この仕様は、指数の長さは、少なくとも二回最強の提供属性が必要とする最長のセッションキーの所望の暗号強度にすることをお勧めします。
Based on the estimates in "Moduli Selection" (above):
「モジュライセレクション」（上記）での見積もりに基づいて：
For 512-bit moduli, exponent lengths of 128 bits (or more) are recommended.
512ビットのモジュラスのために、128ビット（以上）の指数長が推奨されます。
For 1024-bit moduli, exponent lengths of 160 to 256 bits (or more) are recommended.
1024ビットモジュラスのために、160〜256ビット（以上）の指数長が推奨されます。
Although the same exponent and Exchange-Value may be used with several parties whenever the same modulus and generator are used, the exponent SHOULD be changed at random intervals. A background process can periodically destroy the old values, generate a new random private-secret exponent, and recalculate the Exchange-Value.
同じ弾性率および発電機が使用されるたびに同じ指数取引値は、いくつかの当事者と一緒に使用することができるが、指数はランダムな間隔で変更する必要があります。バックグラウンド・プロセスは、定期的に、古い値を破棄し、新しいランダムな秘密秘密指数を生成し、Exchange-値を再計算することができます。
Implementation Notes:
実装上の注意：
The size of the exponent is entirely implementation dependent, is unknown to the other party, and can be easily changed.
指数の大きさは、完全実装に依存する他の当事者に知られておらず、容易に変更することができます。
Since these operations involve several time-consuming modular exponentiations, moving them to the "background" substantially improves the apparent execution speed of the Photuris protocol. It also reduces CPU loading sufficiently to allow a single public/private key-pair to be used in several closely spaced
これらの操作は、「背景」に移動する、いくつかの時間のかかるモジュールの累乗を伴うので、実質的にPhoturisプロトコルの見かけ上の実行速度を向上させます。また、単一の公開鍵/秘密鍵のペアは、いくつかの狭い間隔で使用できるように十分にCPUの負荷を軽減します
Photuris executions, when creating Security Associations with several different nodes over a short period of time.
Photurisの実行、時間の短い期間にわたって、いくつかの異なるノードでセキュリティアソシエーションを作成します。
Other pre-computation suggestions are described in [BGMW93, LL94, Rooij94].
他の事前計算の提案は[BGMW93、LL94、Rooij94]に記載されています。
Some exponents do not qualify as secret. The exponent 0 will generate the Exchange-Value 1, and the exponent 1 will generate the Exchange-Value g. Small exponents will be easily visible and SHOULD be avoided where:
いくつかの指数は、秘密としての資格はありません。指数0は、Exchange-値1を生成し、そして指数1は、Exchange-値Gを生成します。小さな指数が簡単に見えるようになり、どこで回避する必要があります。
g**x < p.
G ** X <P。
Depending on the structure of the moduli, certain exponents can be used for sub-group confinement attacks. For "safe" primes (p = 2q+1), these exponents are p-1 and (p-1)/2, which will generate the Exchange-Values 1 and p-1 respectively.
モジュラスの構造に応じて、特定の指数は、サブグループ閉じ込め攻撃のために使用することができます。 "安全な" 素数（P = 2Q + 1）のために、これらの指数は、p-1と（P-1）/ 2、それぞれのExchange値1とp-1が生成されています。
When an implementation chooses a random exponent, the resulting Exchange-Value is examined. If the Exchange-Value is represented in less than half the number of significant bits in the modulus, then a new random exponent MUST be chosen.
実装は、ランダム指数を選択すると、得られた交換価値を調べています。交換価値は、弾性率の有意ビットの半分以下の数で表現される場合、新しいランダムな指数を選択しなければなりません。
For 512-bit moduli, Exchange-Values of 2**256 or greater are required.
512ビットのモジュラスのために、2 ** 256以上の取引-値が必要とされています。
For 1024-bit moduli, Exchange-Values of 2**512 or greater are required.
1024ビットのモジュラスのために、2 ** 512以上の取引-値が必要とされています。
In addition, if the resulting Exchange-Value is p-1, then a new random exponent MUST be chosen.
得られた交流値がP-1である場合に加えて、新しいランダムな指数を選択しなければなりません。
Upon receipt of an Exchange-Value that fails to meet the requirements, the Value Exchange message is silently discarded.
要件を満たすために失敗した取引価値を受信すると、バリュー交換メッセージは静かに捨てられます。
Implementation Notes:
実装上の注意：
Avoidance of small exponents can be assured by setting at least one bit in the most significant half of the exponent.
小さな指数の回避は、指数部の上位半分に少なくとも1つのビットを設定することによって確保することができます。
Initial values are assigned as follows:
次のように初期値が割り当てられています。
(0) Reserved.
（0）予約。
(1) Reserved.
（1）予約。
(2) Implementation Required. Any modulus (p) with a recommended generator (g) of 2. When the Exchange-Scheme Size is non-zero, the modulus is contained in the Exchange-Scheme Value field in the list of Offered-Schemes.
（2）実装に必要です。交換-スキームサイズがゼロでない2の推奨発電機（G）を有する任意の弾性率（P）は、弾性率は、提供・スキームのリストでExchange-スキーム値フィールドに含まれています。
An Exchange-Scheme Size of zero is invalid.
ゼロの交換・スキームサイズが無効です。
Key-Generation-Function "MD5 Hash" Privacy-Method "Simple Masking" Validity-Method "MD5-IPMAC Check"
鍵生成・機能「MD5ハッシュ」プライバシー・メソッド「シンプルマスキング」妥当性-方法「MD5-IPMACチェック」
This combination of features requires a modulus with at least 64-bits of cryptographic strength.
特徴のこの組合せは、暗号強度の少なくとも64ビットの係数を必要とします。
(3) Exchange-Schemes 3 to 255 are intended for future well-known published schemes.
（3）255と交換スキーム3は、将来のよく知られた、公開制度のために意図されています。
(256) Exchange-Schemes 256 to 32767 are intended for vendor-specific unpublished schemes. Implementors wishing a number MUST request the number from the authors.
（256）は、Exchange-スキーム32767から256は、ベンダー固有の未発表の制度のために意図されます。番号を希望する実装者は、著者からの番号を要求しなければなりません。
(32768) Exchange-Schemes 32768 to 65535 are available for cooperating parties to indicate private schemes, regardless of vendor implementation. These numbers are not reserved, and are subject to duplication. Other criteria, such as the IP Source and Destination of the Cookie_Request, are used to differentiate the particular Exchange-Schemes available.
（32768）のExchangeスキーム32768〜65535にかかわらず、ベンダーの実装の、プライベートなスキームを示すために、当事者の協力のために用意されています。これらの数字は予約、および重複の対象とされていません。こうしたIPソースとCookie_Requestの送信先として他の基準は、利用可能な特定のExchangeスキームを区別するために使用されています。
10. Basic Key-Generation-Function 10.1. MD5 Hash
10.基本的な鍵生成・機能10.1。 MD5ハッシュ
MD5 [RFC-1321] is used as a pseudo-random-function for generating the key(s). The key(s) begin with the most significant bits of the hash. MD5 is iterated as needed to generate the requisite length of key material.
MD5 [RFC-1321]キー（S）を生成する擬似ランダム関数として使用されます。キー（複数可）、ハッシュの最上位ビットで始まります。キーマテリアルの必要な長さを生成するために、必要に応じてMD5が繰り返されます。
When an individual key does not use all 128-bits of the last hash, any remaining unused (least significant) bits of the last hash are discarded. When combined with other uses of key generation for the same purpose, the next key will begin with a new hash iteration.
個々のキーが最後のハッシュの全128ビットを使用しない場合、最後のハッシュの任意の残りの未使用の（最下位）ビットが破棄されます。同じ目的のために鍵生成の他の用途と組み合わせると、次のキーは、新しいハッシュの繰り返しで始まります。
11. Basic Privacy-Method 11.1. Simple Masking
11.基本的なプライバシー・メソッド11.1。単純なマスキング
As described in "Privacy-Key Computation", sufficient privacy-key material is generated to match the message length, beginning with the next field after the SPI, and including the Padding. The message is masked by XOR with the privacy-key.
「プライバシーキー計算」で説明したように、十分なプライバシーキー材料はSPIの後に次のフィールドで始まり、およびパディングを含む、メッセージの長さに一致するように生成されます。メッセージはプライバシーキーでXORによってマスクされます。
12. Basic Validity-Method 12.1. MD5-IPMAC Check
12.基本的な妥当性-法12.1。 MD5-IPMACチェック
As described in "Validity Verification", the Verification field value is the MD5 [RFC-1321] hash over the concatenation of
「妥当性検証」に記載されているように、検証フィールドの値は、連結上MD5 [RFC-1321]ハッシュであります
MD5( key, keyfill, data, datafill, key, md5fill )
MD5（キー、keyfill、データ、datafill、キー、md5fill）
where the key is the computed verification-key.
どこキーは、計算された検証鍵です。
The keyfill and datafill use the same pad-with-length technique defined for md5fill. This padding and length is implicit, and does not appear in the datagram.
keyfillとmd5fillに対して定義された同じパッドを有する長技法を使用datafill。このパディングと長さは暗黙的で、かつデータグラムには表示されません。
The resulting Verification field is a 128-bit Variable Precision Integer (18 bytes including Size). When used in calculations, the Verification data includes both the Size and Value fields.
得られた検証フィールド128ビットの可変精度整数型（サイズを含む18バイト）です。計算に使用する場合、検証データはサイズと値フィールドの両方を含んでいます。
Implementors wishing a number MUST request the number from the authors. Initial values are assigned as follows:
番号を希望する実装者は、著者からの番号を要求しなければなりません。次のように初期値が割り当てられています。
Use Type - 0* padding - 1* AH-Attributes - 2+ ESP-Attributes AEI 5* MD5-IPMAC AEIX 255+ Organizational
タイプを使用してください - 0 *のパディング - 1 * AH-属性 - 2+ AEI 5 ESPは、属性* MD5-IPMAC AEIX 255+組織
A AH Attribute-Choice E ESP Attribute-Choice I Identity-Choice X dependent on list location + feature must be recognized even when not supported * feature must be supported (mandatory)
サポートされていないとき、機能がサポートされなければならない* AH属性-選択肢E ESP属性-ChoiceのIアイデンティティ-ChoiceのXリスト場所+機能に依存しても認識されなければならない（必須）
Other attributes are specified in companion documents.
他の属性は、コンパニオンの文書で指定されています。
+-+-+-+-+-+-+-+-+
| Attribute |
+-+-+-+-+-+-+-+-+
Attribute 0
属性0
Each attribute may have value fields that are multiple bytes. To facilitate processing efficiency, these fields are aligned on integral modulo 8 byte (64-bit) boundaries.
各属性には、複数のバイト値フィールドを有することができます。処理効率を促進するために、これらのフィールドは積分モジュロ8バイト（64ビット）境界に整列されます。
Padding is accomplished by insertion of 1 to 7 Attribute 0 padding bytes before the attribute that needs alignment.
パディングは、アライメントを必要と属性前1 0項目7にパディングバイトを挿入することによって達成されます。
No padding is used after the final attribute in a list.
パディングは、リストの最後の属性の後に使用されていません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 1
項目1
Length 0
長さが0
When a list of Attributes is specified, this Attribute begins the section of the list which applies to the Authentication Header (AH).
属性のリストが指定されている場合、この属性は、認証ヘッダー（AH）に適用されるリストのセクションを開始します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length | PayloadType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 2
項目2
Length 1
長さ1
PayloadType 1 byte. Indicates the contents of the ESP Transform Data field, using the IP Next Header (Protocol) value. Up-to-date values of the IP Next Header (Protocol) are specified in the most recent "Assigned Numbers" [RFC-1700].
PayloadType 1バイト。 ESPの内容は、IP次ヘッダ（プロトコル）値を使用して、データフィールドを変換することを示します。 IP次ヘッダ（プロトコル）の最新の値は最新の「Assigned Numbers」[RFC-1700]で指定されています。
For example, when encrypting an entire IP datagram,
this field will contain the value 4, indicating IP-
in-IP encapsulation.
When a list of Attributes is specified, this Attribute begins the section of the list which applies to the Encapsulating Security Payload (ESP).
属性のリストが指定されている場合、この属性は、カプセル化セキュリティペイロード（ESP）に適用されるリストのセクションを開始します。
When listed as an Offered-Attribute, the PayloadType is set to 255.
提供される属性として記載されている場合は、PayloadTypeは255に設定されています。
When selected as an Attribute-Choice, the PayloadType is set to the actual value to be used.
属性の選択肢として選択されたとき、PayloadTypeは、使用される実際の値に設定されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 5
属性5
Length 0
長さが0
When selected as an Identity-Choice, the immediately following Identification field contains an unstructured Variable Precision Integer. Valid Identifications and symmetric secret-keys are preconfigured by the parties.
アイデンティティ選択肢として選択した場合は、すぐに次の識別フィールドは、非構造化可変精度整数が含まれています。有効な識別と対称秘密鍵は、当事者によって事前設定されています。
There is no required format or content for the Identification value. The value may be a number or string of any kind. See "Use of Identification and Secrets" for details.
識別値のための必要な形式や内容はありません。値は、任意の種類の数またはストリングであり得ます。詳細については、「識別と秘密の使用」を参照してください。
The symmetric secret-key (as specified) is selected based on the contents of the Identification field. All implementations MUST support at least 62 bytes. The selected symmetric secret-key SHOULD provide at least 64-bits of cryptographic strength.
対称秘密鍵は、（指定された）識別フィールドの内容に基づいて選択されます。すべての実装は、少なくとも62のバイトをサポートしなければなりません。選択された対称秘密鍵は、暗号強度の少なくとも64ビットを提供すべきです。
As described in "Identity Verification", the Verification field value is the MD5 [RFC-1321] hash over the concatenation of:
「識別情報の検証」に記載されているように、検証フィールドの値は、連結上MD5 [RFC-1321]ハッシュです。
MD5( key, keyfill, data, datafill, key, md5fill )
MD5（キー、keyfill、データ、datafill、キー、md5fill）
where the key is the computed verification-key.
どこキーは、計算された検証鍵です。
The keyfill and datafill use the same pad-with-length technique defined for md5fill. This padding and length is implicit, and does not appear in the datagram.
keyfillとmd5fillに対して定義された同じパッドを有する長技法を使用datafill。このパディングと長さは暗黙的で、かつデータグラムには表示されません。
The resulting Verification field is a 128-bit Variable Precision Integer (18 bytes including Size). When used in calculations, the Verification data includes both the Size and Value fields.
得られた検証フィールド128ビットの可変精度整数型（サイズを含む18バイト）です。計算に使用する場合、検証データはサイズと値フィールドの両方を含んでいます。
For both "Identity Verification" and "Validity Verification", the verification-key is the MD5 [RFC-1321] hash of the following concatenated values:
「アイデンティティ検証」と「妥当性検証」の両方について、検証鍵は、以下の連結された値のMD5 [RFC-1321]ハッシュです。
+ the symmetric secret-key, + the computed shared-secret.
+左右対称秘密鍵、+計算された共有秘密。
For "Session-Key Computation", the symmetric secret-key is used directly as the generation-key.
「セッション・キー計算」について、対称秘密鍵は、世代の鍵として直接使用されます。
Regardless of the internal representation of the symmetric secret-key, when used in calculations it is in the same form as the Value part of a Variable Precision Integer:
計算に使用した場合にかかわらず、対称秘密鍵の内部表現が、可変精度整数の値部分と同じ形です。
- most significant byte first. - bits used are right justified within byte boundaries. - any unused bits are in the most significant byte. - unused bits are zero filled.
- 最初の最上位バイト。 - 使用されるビットは、右バイト境界内に正当化されています。 - 未使用ビットは、最上位バイトです。 - 未使用のビットはゼロに充填されています。
The symmetric secret-key does not include a Size field.
対称秘密鍵は、サイズのフィールドが含まれていません。
May be selected as an AH or ESP Attribute-Choice, pursuant to [RFC-1828] et sequitur. The selected Exchange-Scheme SHOULD provide at least 64-bits of cryptographic strength.
[RFC-1828]に基づき、AHまたはESP項目の選択肢として選択することができるらsequitur。選択されたExchange-スキームは、暗号強度の少なくとも64ビットを提供すべきです。
As described in "Session-Key Computation", the most significant 384- bits (48 bytes) of the Key-Generation-Function iterations are used for the key.
「セッション鍵計算」に記載されているように、鍵生成機能反復の最上位384ビット（48バイト）は、キーに使用されます。
Profile:
プロフィール：
When negotiated with Photuris, the transform differs slightly from [RFC-1828].
Photurisと交渉すると、変換[RFC-1828]とは若干異なります。
The form of the authenticated message is:
認証されたメッセージの形式は次のとおりです。
MD5( key, keyfill, datagram, datafill, key, md5fill )
MD5（キー、keyfill、データグラム、datafill、キー、md5fill）
where the key is the SPI session-key.
どこキーはSPIセッションキーです。
The additional datafill protects against the (impractical) attack described in [PO96]. The keyfill and datafill use the same pad-with-length technique defined for md5fill. This padding and length is implicit, and does not appear in the datagram.
追加datafillは[PO96]に記載の（非現実的）攻撃から保護します。 keyfillとmd5fillに対して定義された同じパッドを有する長技法を使用datafill。このパディングと長さは暗黙的で、かつデータグラムには表示されません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length | OUI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Kind | Value(s) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 255
属性255
Length >= 4
長さ> = 4
When the Length is four, no Value(s) field is
present.
OUI 3 bytes. The vendor's Organizationally Unique Identifier, assigned by IEEE 802 or IANA (see [RFC-1700] for contact details). The bits within the byte are in canonical order, and the most significant byte is transmitted first.
OUI 3バイト。 IEEE 802又はIANAによって割り当てられたベンダーの組織固有識別子（連絡先の詳細については[RFC-1700]を参照）。バイト内のビットは、標準的な順序にあり、最上位バイトが最初に送信されます。
Kind 1 byte. Indicates a sub-type for the OUI. There is no standardization for this field. Each OUI implements its own values.
種類1バイト。 OUIのためのサブタイプを示します。このフィールドには標準化はありません。各OUIは独自の値を実装します。
Value(s) 0 or more bytes. The details are implementation specific.
値（S）が0バイト以上。詳細は、実装固有のものです。
Some implementors might not need nor want to publish their proprietary algorithms and attributes. This OUI mechanism is available to specify these without encumbering the authors with proprietary number requests.
いくつかの実装は必要でも、その独自のアルゴリズムと属性を公開したくない場合があります。このOUIメカニズムは独自の番号要求に著者をに妨げることなく、これらを指定することが可能です。
A. Automaton
A.オートマトン
An example automaton is provided to illustrate the operation of the protocol. It is incomplete and non-deterministic; many of the Good/Bad semantic decisions are policy-based or too difficult to represent in tabular form. Where conflicts appear between this example and the text, the text takes precedence.
例えば、オートマトンは、プロトコルの動作を説明するために提供されます。それは不完全と非決定的です。グッド/バッドセマンティック決定の多くは、ポリシーベースまたは表形式で表現するにはあまりにも難しいです。競合がこの例とテキストの間に表示される場合は、テキストが優先されます。
The finite-state automaton is defined by events, actions and state transitions. Events include reception of external commands such as expiration of a timer, and reception of datagrams from a peer. Actions include the starting of timers and transmission of datagrams to the peer.
有限状態オートマトンは、イベント、アクションと状態遷移によって定義されます。イベントは、ピアからのデータグラムのタイマの満了、及び受信などの外部コマンドの受信を含みます。アクションは、タイマーとピアへのデータグラムの送信の開始を含みます。
Events
イベント
DU13 = Communication Administratively Prohibited SF0 = Bad SPI SF4 = Need Authentication SF5 = Need Authorization WC = Want Confidentiality
DU13 =コミュニケーション管理上禁止SF0 =悪いSPI SF4 =認証SF5 =認可のWCは=機密保持をしたい必要必要
RCQ+ = Receive Cookie_Request (Good) RCQ- = Receive Cookie_Request (Bad) RCR+ = Receive Cookie_Response (Good) RCR- = Receive Cookie_Response (Bad)
RCQ + =受信Cookie_Request（グッド）RCQ- = Cookie_Request（悪い）RCRを受信+ =受信Cookie_Response（グッド）RCR- =受信Cookie_Response（悪いです）
RVQ+ = Receive Value_Request (Good) RVQ- = Receive Value_Request (Bad) RVR+ = Receive Value_Response (Good) RVR- = Receive Value_Response (Bad)
RVQ + =受信Value_Request（グッド）RVQ- =受信Value_Request（悪い）RVR + =受信Value_Response（グッド）RVR- =受信Value_Response（悪いです）
RIQ+ = Receive Identity_Request (Good) RIQ- = Receive Identity_Request (Bad) RIR+ = Receive Identity_Response (Good) RIR- = Receive Identity_Response (Bad)
RIQ + =受信Identity_Request（グッド）RIQ- =受信Identity_Request（悪い）RIR + =受信Identity_Response（グッド）RIR- = Identity_Response（悪い）を受信
RUN+ = Receive SPI_Needed (Good) RUN- = Receive SPI_Needed (Bad) RUM+ = Receive SPI_Update (Good) RUM- = Receive SPI_Update (Bad)
RUN + =受信SPI_Needed（グッド）RUN-=受信SPI_Needed（悪い）RUM + =受信SPI_Update（グッド）RUM- =受信SPI_Update（悪いです）
RBC = Receive Bad Cookie RRL = Receive Resource Limit RVF = Receive Verification Failure RMR = Receive Message Reject
RBCは=悪いクッキーRRLは=拒否検証の失敗RMR =受信メッセージを受信=リソース制限RVFを受信受信します
TO+ = Timeout with counter > 0
TO + =タイムアウトカウンタ> 0で
TO- = Timeout with counter expired UTO = Update TimeOut XTO = Exchange TimeOut
カウンターとTO- =タイムアウトはUTO =アップデートTimeOutのXTO =取引所タイムアウトを有効期限が切れ
Actions
行動
scq = Send Cookie_Request scr = Send Cookie_Response
SCQ = Cookie_Responseを送る= Cookie_Request SCRを送ります
svq = Send Value_Request svr = Send Value_Response
SVQ = Value_RequestのSVRは= Value_Responseを送るSend
siq = Send Identity_Request sir = Send Identity_Response
= Identity_Responseを送る= Identity_Request SIRを送るSIQ
sum = Send SPI_Update
合計= SPI_Updateを送ります
se* = Send error message (see text) sbc = Send Bad Cookie srl = Send Resource Limit svf = Send Verification Failure
SE * =（本文参照）、エラーメッセージを送るSBC =検証失敗情報を送る=リソース制限のSVFを送る=悪いクッキーSRLを送ります
brto = Backoff Retransmission TimeOut buto = Backoff Update TimeOut rto = Set Retransmission TimeOut uto = Set Update TimeOut xto = Set Exchange TimeOut
brto =バックオフ再送信タイムアウト舞踏=バックオフを更新タイムアウトRTO =設定再送信TimeOutの宇土=セットアップデートタイムアウトXTO =セットの交換TimeOutの
log = log operator message
ログイン=オペレーター・メッセージをログに記録
A.1. State Transition Table
A.1。状態遷移表
States are indicated horizontally, and events are read vertically. State transitions and actions are represented in the form action/new-state. Multiple actions are separated by commas, and may continue on succeeding lines as space requires; multiple actions may be implemented in any convenient order. The state may be followed by a letter, which indicates an explanatory footnote. The dash ('-') indicates an illegal transition.
国は水平に示され、イベントは縦に読み込まれます。状態遷移とアクションは、フォームアクション/新状態で表されています。複数のアクションは、カンマで区切られ、そして空間を必要とする後続の行に継続することができます。複数のアクションは、任意の便利な順序で実施することができます。状態は説明脚注を示す文字が続くことができます。ダッシュ（「 - 」）は、不正の遷移を示しています。
Initiator
イニシエータ
| 0 1 2 3 4
| Initial Cookie CookieBad Value ValueBad
------+--------------------------------------------------
DU13 |rto,scq/1 rto,scq/1 rto,scq/1 3 4
SF0 |rto,scq/1 1 2 3 4
SF4 |rto,scq/1 1 2 3 4
SF5 |rto,scq/1 1 2 3 4
WC |rto,scq/1 1 2 3 4
|
RCR+ | - rto,svq/3 rto,svq/3 3 4
RCR- | 0 1 2 3 4
RVR+ | - - - rto,siq/5 rto,siq/5
RVR- | 0 1 2 3 4
RIR+ | - - - - -
RIR- | 0 1 2 3 4
|
RUN+ | - - - - -
RUN- | sbc/0 sbc/1 sbc/2 sbc/3 sbc/4
RUM+ | - - - - -
RUM- | sbc/0 sbc/1 sbc/2 sbc/3 sbc/4
|
RBC | - - - 4 4
RRL | - brto/2 brto/2 brto/4 brto/4
RVF | - - - - -
RMR | - - - - -
|
TO+ | - scq/1 scq/2 svq/3 svq/4
TO- | - 0 scq/1 0 scq/1
UTO | - - - - -
XTO | - 0 0 0 0
Initiator
イニシエータ
| 5 6 8
|Identity IdentityBad Update
------+-----------------------------
DU13 | 5 6 8
SF0 | 5 6 rto,scq/1
SF4 | 5 6 rto,scq/1
SF5 | 5 6 rto,scq/1
WC | 5 6 sun/8
|
RCR+ | 5 6 8
RCR- | 5 6 8
RVR+ | 5 6 8
RVR- | 5 6 8
RIR+ | uto/8 uto/8 8
RIR- | svf/5 svf/6 8
|
RUN+ | - - sum/8
RUN- | sbc/5 sbc/6 se*/8
RUM+ | - - 8
RUM- | sbc/5 sbc/6 se*/8
|
RBC | 6 6 rto,scq/1
RRL | 5 6 buto/8
RVF | log/5 log/6 log/8
RMR | log/5 log/6 log/8
|
TO+ | sim/5 sim/6 -
TO- | 0 scq/1 -
UTO | - - sum/8
XTO | 0 0 0
Responder
答え
| 0 7 8
| Initial Ready Update
------+-----------------------------
WC | - 7 sun/8
|
RCQ+ | scr/0 scr/7 scr/8
RCQ- | srl/0 srl/7 srl/8
RVQ+ |xto,svr/7 svr/7 svr/8
RVQ- | sbc/0 sbc/7 sbc/8
RIQ+ | - uto,sir/8 sir/8
RIQ- | sbc/0 se*/7 se*/8
|
RUN+ | - - sum/8
RUN- | sbc/0 sbc/7 se*/8
RUM+ | - - 8
RUM- | sbc/0 sbc/7 se*/8
|
RBC | - 7 rto,scq/1
RRL | - - buto/8
RVF | - - log/8
RMR | - - log/8
|
UTO | - - sum/8
XTO | - 0 0
A.2. States
A.2。アメリカ
Following is a more detailed description of each automaton state.
以下は、各オートマトンの状態の詳細な説明です。
The "Bad" version of a state is to indicate that the Bad_Cookie or Resource_Limit message has been received.
状態の「悪い」バージョンがBad_CookieまたはRESOURCE_LIMITメッセージが受信されたことを示すためです。
A.2.1. Initial
A.2.1。初期
The Initial state is fictional, in that there is no state between the parties.
関係者の間には状態が存在しないという点で、初期状態では、架空のものです。
A.2.2. Cookie
A.2.2。クッキー
In the Cookie state, the Initiator has sent a Cookie_Request, and is waiting for a Cookie_Response. Both the Restart and Exchange timers are running.
Cookieの状態では、イニシエータはCookie_Request送信した、とCookie_Responseを待っています。どちらも再起動し、Exchangeタイマーが実行されています。
Note that the Responder has no Cookie state.
Responderがクッキーの状態を持っていないことに注意してください。
A.2.3. Value
A.2.3。値
In the Value state, the Initiator has sent its Exchange-Value, and is waiting for an Identity_Message. Both the Restart and Exchange timers are running.
値の状態では、イニシエータは、その交換価値を送った、とIdentity_Messageを待っています。どちらも再起動し、Exchangeタイマーが実行されています。
A.2.4. Identity
A.2.4。身元
In the Identity state, the Initiator has sent an Identity_Request, and is waiting for an Identity_Response in reply. Both the Restart and Exchange timers are running.
アイデンティティの状態では、イニシエータはIdentity_Requestを送信した、との回答でIdentity_Responseを待っています。どちらも再起動し、Exchangeタイマーが実行されています。
A.2.5. Ready
A.2.5。レディ
In the Ready state, the Responder has sent its Exchange-Value, and is waiting for an Identity_Message. The Exchange timer is running.
レディ状態では、Responderはその交換価値を送った、とIdentity_Messageを待っています。為替タイマーが実行されています。
A.2.6. Update
A.2.6。更新
In the Update state, each party has concluded the Photuris exchange, and is unilaterally updating expiring SPIs until the Exchange LifeTime expires. Both the Update and Exchange timers are running.
更新状態では、各当事者は、Photuris交換を締結しており、およびExchange寿命が切れるまで一方的に期限切れSPIを更新しています。更新とExchangeタイマーの両方が実行されています。
B. Use of Identification and Secrets
同定と秘密のB.使用
Implementation of the base protocol requires support for operator configuration of participant identities and associated symmetric secret-keys.
基本プロトコルの実装は、参加者のIDと関連付けられている対称秘密鍵のオペレータ設定のためのサポートが必要です。
The form of the Identification and Secret fields is not constrained to be a readable string. In addition to a simpler quoted string configuration, an implementation MUST allow configuration of an arbitrary stream of bytes.
同定と秘密のフィールドの形式は読みやすい文字列に制限されていません。単純な引用符で囲まれた文字列の構成に加えて、実装は、任意のバイトストリームの構成を可能にしなければなりません。
B.1. Identification
B.1。識別
Typically, the Identification is a user name, a site name, a Fully Qualified Domain Name, or an email address which contains a user name and a domain name. Examples include:
一般的に、識別は、ユーザー名、サイト名、完全修飾ドメイン名、またはユーザー名とドメイン名が含まれている電子メールアドレスです。例としては、
user node.site. user@node.site. rcmd@node.site. "Mundane Name" <user@node.site>
ユーザーnode.site。 user@node.site。 rcmd@node.site。 "世俗的な名前" <user@node.site>
There is no requirement that the domain name match any of the particular IP addresses in use by the parties.
ドメイン名は、当事者が使用して特定のIPアドレスのいずれかに一致する必要はありません。
B.2. Group Identity With Group Secret
B.2。グループの秘密を持つグループのアイデンティティ
A simple configuration approach could use a single Identity and Secret, distributed to all the participants in the trusted group. This might be appropriate between routers under a single administration comprising a Virtual Private Network over the Internet.
シンプルな構成のアプローチは、信頼グループ内のすべての参加者に配布単一のアイデンティティと秘密を、使用することができます。これは、インターネット上の仮想プライベートネットワークを含む単一の管理下にルータ間で適切な場合があります。
Nota Bene: The passwords used in these examples do not meet the "MD5-IPMAC Symmetric Identification" recommendation for at least 64-bits of cryptographic strength.
注意ベーネ：これらの例で使用されるパスワードは、暗号強度の少なくとも64ビットのための「MD5-IPMAC対称識別」勧告を満たしていません。
The administrator configures each router with the same username and password:
管理者は、同じユーザー名とパスワードを使用して各ルータを設定します。
identity local "Tiny VPN 1995 November" "abracadabra" identity remote "Tiny VPN 1995 November" "abracadabra"
ローカルアイデンティティ「タイニーVPN 1995 11月」「アブラカダブラ」アイデンティティリモート「タイニーVPN 1995 11月」「アブラカダブラ」
When the Initiator sends its Identity_Request, the SPI Owner
イニシエータは、そのIdentity_Request、SPI所有者を送信するとき
Identification field is "Tiny VPN 1995 November" and the SPI Owner secret-key is "abracadabra".
識別フィールドは、「タイニーVPN 1995 11月」であるとSPI所有者の秘密鍵は、「アブラカダブラ」です。
When the Responder sends its Identity_Response, the SPI Owner Identification field is "Tiny VPN 1995 November" and the SPI Owner secret-key is "abracadabra". The SPI User Identification is "Tiny VPN 1995 November" (taken from the request), and the SPI User secret-key is "abracadabra".
ResponderはそのIdentity_Responseを送信すると、SPI所有者識別フィールドは、「タイニーVPN 1995 11月」であるとSPI所有者の秘密鍵は、「アブラカダブラ」です。 SPIのユーザ識別は、（リクエストから取られた）「タイニーVPN 1995 11月」であり、SPIユーザ秘密鍵は「アブラカダブラ」です。
Note that even in the face of implementations with very poor random number generation yielding the same random numbers for both parties at every step, and with this completely identical configuration, the addition of the SPI User Verification field in the response calculation is highly likely to produce a different Verification value (see "Identity Verification"). In turn, the different Verification values affect the calculation of SPI session-keys that are highly likely to be different in each direction (see "Session-Key Computation").
なおも非常に悪い乱数発生は、すべてのステップにおいて、両当事者のために同一の乱数を得て、この全く同じ構成で、応答計算におけるSPIユーザ認証フィールドの添加が生じる可能性が高いとの実装の面で異なる検証値（「識別情報の検証」を参照）。ターンでは、異なる検証値は、それぞれの方向に異なる可能性が高いですSPIセッション・キー（「セッション・キーの計算」を参照）の計算に影響を与えます。
B.3. Multiple Identities With Group Secrets
B.3。グループの秘密で複数のID
A more robust configuration approach could use a separate Identity and Secret for each party, distributed to the participants in the trusted group. This might be appropriate for authenticated firewall traversal.
より堅牢なコンフィギュレーション・アプローチは、信頼できるグループの参加者に配布し、各当事者に別々のアイデンティティと秘密を、使用することができます。これは、認証されたファイアウォール越えのための適切な場合があります。
An administrator has one or more networks, and a number of mobile users. It is desirable to restrict access to authorized external users. The example boundary router is 10.0.0.1.
管理者は、1つまたは複数のネットワークを持っており、モバイルユーザーの数。許可された外部ユーザーへのアクセスを制限することが望ましいです。例えば、境界ルータは10.0.0.1です。
The administrator gives each user a different username and password, together with a group username and password for the router.
管理者は、一緒にルータのグループのユーザ名とパスワードを使用して、ユーザーごとに異なるユーザー名とパスワードを提供します。
The administrator configures (in part):
管理者は、（一部で）設定します。
identity local "199511@router.site" "FalDaRah" identity remote "Happy_Wanderer@router.site" "FalDaRee"
アイデンティティ地元の「199511@router.site」「FalDaRah」アイデンティティリモート「Happy_Wanderer@router.site」「FalDaRee」
Each mobile user adds commands to tunnel and authenticate.
各モバイルユーザーは、トンネルおよび認証するためのコマンドを追加します。
route addprivate 10.0.0.0/8 tunnel 10.0.0.1 secure 10.0.0.1 authenticate-only identity local "Happy_Wanderer@router.site" "FalDaRee" identity remote "199511@router.site" "FalDaRah" identity remote "199512@router.site" "FalDaHaHaHaHaHaHa"
ルートaddprivate 10.0.0.1セキュアな10.0.0.1認証のみのアイデンティティローカル「Happy_Wanderer@router.site」「FalDaRee」アイデンティティリモート「199511@router.site」リモート「FalDaRah」アイデンティティ「199512@router.site 10.0.0.0/8トンネル「 "FalDaHaHaHaHaHaHa"
When the mobile Initiator sends its Identity_Request, the SPI Owner
モバイルイニシエータは、そのIdentity_Request、SPI所有者を送信するとき
Identification field is "Happy_Wanderer@router.site" and the SPI Owner secret-key is "FalDaRee".
識別フィールドは、「Happy_Wanderer@router.site」であるとSPI所有者の秘密鍵は、「FalDaRee」です。
When the firewall Responder sends its Identity_Response, the SPI Owner Identification field is "199511@router.site" and the SPI Owner secret-key is "FalDaRah". The SPI User Identification field is "Happy_Wanderer@router.site" (taken from the request), and the SPI User secret-key is "FalDaRee".
ファイアウォールResponderはそのIdentity_Responseを送信すると、SPI所有者識別フィールドは、「199511@router.site」であるとSPI所有者の秘密鍵は、「FalDaRah」です。 SPIユーザ識別フィールドは、（リクエストから取られた）「Happy_Wanderer@router.site」であり、SPIユーザ秘密鍵は「FalDaRee」です。
In this example, the mobile user is already prepared for a monthly password changeover, where the router might identify itself as "199512@router.site".
この例では、モバイルユーザーがすでにルータが「199512@router.site」として自身を識別可能性がある毎月のパスワード切り替え、ために準備されます。
B.4. Multiple Identities With Multiple Secrets
B.4。複数の秘密で複数のID
Greater security might be achieved through configuration of a pair of secrets between each party. As before, one secret is used for initial contact to any member of the group, but another secret is used between specific parties. Compromise of one secret or pair of secrets does not affect any other member of the group. This might be appropriate between the routers forming a boundary between cooperating Virtual Private Networks that establish local policy for each VPN member access.
グレーターセキュリティは、各当事者間で秘密のペアの構成によって達成される可能性があります。前と同じように、1つの秘密は、グループのメンバーへの最初の接触のために使用されますが、別の秘密は、特定の当事者間で使用されています。秘密のシークレット1種またはペアの妥協は、グループの他のメンバーには影響を与えません。これは、各VPNのメンバーにアクセスするためのローカルポリシーを確立する仮想プライベートネットワークを連携するとの間の境界を形成するルータ間で適切な場合があります。
One administrator configures:
一つの管理者が設定します。
identity local "Apple" "all for one" identity local "Apple-Baker" "Apple to Baker" "Baker" identity remote "Baker" "one for all" identity remote "Baker-Apple" "Baker to Apple"
アイデンティティローカル「アップル」「オールインワン」ローカルアイデンティティ「アップル・ベイカー」「アップルベーカーへ」「ベーカー」アイデンティティリモート「ベーカー」アイデンティティ「すべてに対して1つの」リモート「ベイカー・アップル」「アップルへベイカー」のために
Another configures:
もう一つ設定しています。
identity local "Baker" "one for all" identity local "Baker-Apple" "Baker to Apple" "Apple" identity remote "Apple" "all for one" identity remote "Apple-Baker" "Apple to Baker"
アイデンティティ地元の「ベイカー」「「アップル」アイデンティティリモート「アップル」ベイカーの「オールインワンのための」アイデンティティリモート「アップル・ベイカー」「アップル」「アップルへベイカー」すべての」アイデンティティローカル「ベイカー・アップル」のための1
When the Initiator sends its Identity_Request, the SPI Owner Identification field is "Apple" and the SPI Owner secret-key is "all for one".
イニシエータは、そのIdentity_Requestを送信すると、SPI所有者識別フィールドには、「アップル」であるとSPI所有者の秘密鍵は、「いずれかのすべて」です。
When the Responder sends its Identity_Response, finding that the special pairing exists for "Apple" (in this example, indicated by a third field), the SPI Owner Identification field is "Baker-Apple" and the SPI Owner secret-key is "Baker to Apple". The SPI User Identification is "Apple" (taken from the request), and the SPI User secret-key is "all for one".
Responderが特別なペアリングが（3番目のフィールドで示され、この例では、）「アップル」のために存在することを発見、そのIdentity_Responseを送信すると、SPI所有者識別フィールドは「ベイカー・アップル」であるとSPI所有者の秘密鍵は「ベイカーです「アップルへ。 SPIのユーザ識別は、「アップル」（リクエストから取られた）で、SPIユーザ秘密鍵は、「すべての1のために」です。
Operational Considerations
運用の考慮事項
The specification provides only a few configurable parameters, with defaults that should satisfy most situations.
仕様では、ほとんどの状況に満足しなければならないデフォルト値を使用して、わずか数設定可能なパラメータを提供します。
Retransmissions Default: 3.
再送デフォルト：3。
Initial Retransmission TimeOut (IRTO) Default: 5 seconds.
初期再送タイムアウト（IRTO）デフォルト：5秒。
Exchange TimeOut (ETO) Default: 30 seconds. Minimum: Retransmissions * IRTO.
取引タイムアウト（ETO）デフォルト：30秒。最小：再送* IRTO。
Exchange LifeTime (ELT) Default: 30 minutes. Minimum: 2 * ETO.
交換寿命（ELT）デフォルト：30分。最小：2 * ETO。
SPI LifeTime (SPILT) Default: 5 minutes. Minimum: 3 * ETO.
SPI寿命（こぼれ）デフォルト：5分。最小：3 * ETO。
Each party configures a list of known identities and symmetric secret-keys.
各当事者は、既知のアイデンティティと対称秘密キーのリストを設定します。
In addition, each party configures local policy that determines what access (if any) is granted to the holder of a particular identity. For example, the party might allow anonymous FTP, but prohibit Telnet. Such considerations are outside the scope of this document.
また、各当事者は、特定のアイデンティティの保持者に付与されるものアクセス（もしあれば）を決定するローカルポリシーを設定します。例えば、当事者は匿名FTPを許可しますが、Telnetを禁止するかもしれません。このような考慮事項は、この文書の範囲外です。
Security Considerations
セキュリティの考慮事項
Photuris was based on currently available tools, by experienced network protocol designers with an interest in cryptography, rather than by cryptographers with an interest in network protocols. This specification is intended to be readily implementable without requiring an extensive background in cryptology.
Photurisは、現在利用可能なツールに、暗号技術に興味を持つ経験豊富なネットワークプロトコル設計者によってではなく、ネットワークプロトコルに関心のある暗号技術によって基づいていました。この仕様は、暗号学で広範な背景を必要とすることなく、容易に実現可能であることが意図されています。
Therefore, only minimal background cryptologic discussion and rationale is included in this document. Although some review has been provided by the general cryptologic community, it is anticipated that design decisions and tradeoffs will be thoroughly analysed in subsequent dissertations and debated for many years to come.
そのため、最小限の背景暗号議論と論拠は、本文書に含まれています。いくつかのレビューは、一般的な暗号コミュニティによって提供されているが、設計上の決定とトレードオフは徹底的に、その後の論文で分析して来て、長年にわたって議論されることが予想されます。
Cryptologic details are reserved for separate documents that may be more readily and timely updated with new analysis.
暗号の詳細は、より容易にかつタイムリーに新たな分析を用いて更新することができる別のドキュメント用に予約されています。
History
歴史
The initial specification of Photuris, now called version 1 (December 1994 to March 1995), was based on a short list of design requirements, and simple experimental code by Phil Karn. Only one modular exponentiation form was used, with a single byte index of pre-specified group parameters. The transform attributes were selected during the public value exchange. Party privacy was protected in the identification signature exchange with standard ESP transforms.
今バージョン1（1995年3月から1994年12月）と呼ばれるPhoturisの初期仕様は、設計要件の短いリストに基づいて、そしてフィル・カーンによって、簡単な実験的なコードされました。唯一のべき乗剰余形態は、予め指定されたグループのパラメータの単一バイトインデックスと、を用いました。変換属性は、公共の価値交換時に選択しました。党のプライバシーは、標準的なESPトランスフォームと識別署名交換で保護されていました。
Upon submission for review by the IP Security Working Group, a large number of features were demanded. A mere 254 future group choices were not deemed enough; it was expanded to two bytes (and renamed schemes), and was expanded again to carry variable parameters. The transform attributes were made variable length to accomodate optional parameters. Every other possible parameter was made negotiable. Some participants were unable to switch modes on the UDP sockets to use standard ESP transforms for only some messages, and party privacy was integrated into the protocol. The message headers were reorganized, and selection of transform attributes was delayed until the identification exchange. An additional update message phase was added.
IPセキュリティワーキンググループによる検討のため提出されると、機能の大規模な数が求められました。単なる254の今後のグループの選択肢は十分でないと考えました。それは2バイト（および改名方式）に拡大し、そして可変パラメータを運ぶために再び拡大しました。変換属性は、オプションのパラメータを収容するために可変長を作りました。他のすべての可能なパラメータは交渉を行いました。一部の参加者は、標準ESPのみ、一部のメッセージに変換し、党のプライバシーをプロトコルに統合された使用するUDPソケットでモードを切り替えることができませんでした。メッセージヘッダは再編成し、変換属性の選択は、識別交換まで遅延しました。追加の更新メッセージ相を添加しました。
Version 2 (July 1995 to December 1995) specification stability was achieved in November 1995 by moving most parameters into separate documents for later discussion, and leaving only a few mandatory features in the base specification. Within a month, multiple interoperable implementations were produced.
（1995年12月から1995年7月）バージョン2仕様の安定性は、後の議論のための別のドキュメントにほとんどのパラメータを動かすことにより、1995年11月に達成し、基本仕様にわずか数の必須機能を残していました。月以内に、複数の相互運用可能な実装を作製しました。
Unfortunately, in a fit of demagoguery, the IP Security Working Group decided in a straw poll to remove party privacy protection, and the Working Group chair terminated the meeting without allowing further discussion. Because the identification exchange messages required privacy to function correctly, the messages were reorganized again. Party privacy and other optional schemes were split into a separate document.
残念ながら、demagogueryのフィット感で、IPセキュリティワーキンググループは、パーティのプライバシー保護を削除するためにわらの世論調査で決定し、作業部会の議長は、さらなる議論を許可せずに会議を終了しました。プライバシーを必要と識別交換メッセージが正しく機能しているため、メッセージが再び再編成されました。パーティーのプライバシー及び他の任意のスキームは、別の文書に分けました。
The implementors established a separate discussion group. Version 3 (April 1996 to June 1997) enjoyed a long period of specification stability and multiple implementations on half a dozen platforms.
実装者は、別のディスカッション・グループを設立しました。バージョン3（1997年6月から1996年4月）は、半ダースのプラットフォーム上の仕様の安定性と複数の実装の長い期間を楽しみました。
Meanwhile, the IP Security Working Group has developed a competing specification with large numbers of negotiable parameters. Also, the PPP Extensions Working Group has deployed link security transforms.
一方、IPセキュリティワーキンググループは交渉パラメータの数が多い競合する仕様を開発しました。また、PPP拡張ワーキンググループは、リンクのセキュリティ変換を展開しています。
Version 4 (July 1997 onward) attempts to maintain a semblance of interface compatibility with these other efforts. Minor changes are specified in transform padding format and key generation. More than one value is permitted per scheme, giving greater latitude in choice for future extensions. The opportunity is taken to return party privacy to the base document, and make small semantic changes in automated updates and error recovery. All ESP transform attributes are moved to separate documents, to (hopefully) avoid future incompatible changes to the base document.
バージョン4（1997年7月以降）は、これらの他の努力とのインターフェース互換性の姿を維持しようとします。マイナーな変更は、パディングフォーマットや鍵の生成を変換中に指定されています。複数の値は、将来の拡張のために選択の自由度を与えて、スキームごとに許可されます。機会が基本文書の当事者のプライバシーを返し、自動更新とエラー回復の小さな意味的な変更を行うことが取られています。すべてのESP変換の属性は（たぶん）、ベース・ドキュメントの将来の互換性のない変更を避けるために、別のドキュメントに移動されます。
Acknowledgements
謝辞
Thou shalt make no law restricting the size of integers that may
be multiplied together, nor the number of times that an integer
may be multiplied by itself, nor the modulus by which an integer
may be reduced. [Prime Commandment]
Phil Karn was principally responsible for the design of the protocol phases, particularly the "cookie" anti-clogging defense, developed the initial testing implementation, and provided much of the design rationale text (now removed to a separate document).
フィル・カーンは、特に「クッキー」目詰まり防止防衛、プロトコルフェーズの設計のために主に担当した最初のテストの実装を開発し、（今別のドキュメントに削除）、設計根拠のテキストの多くを提供します。
William Simpson was responsible for the packet formats and attributes, additional message types, editing and formatting. All such mistakes are his responsibility.
ウィリアム・シンプソンは、パケットフォーマットと属性、追加のメッセージタイプ、編集および書式設定を担当していました。そのようなすべての過ちは自分の責任です。
This protocol was later discovered to have many elements in common with the Station-To-Station authentication protocol [DOW92].
このプロトコルは、後で[DOW92]ステーション間の認証プロトコルと共通する多くの要素を持つことが発見されました。
Angelos Keromytis developed the first completely independent implementation (circa October 1995). Also, he suggested the cookie exchange rate limitation counter.
アンゲロスKeromytisは（1995年10月頃）最初の完全に独立した実装を開発しました。また、彼はクッキーの為替レートの制限カウンタを示唆しました。
Paul C van Oorschot suggested signing both the public exponents and the shared-secret, to provide an authentication-only version of identity verification. Also, he provided text regarding moduli, generator, and exponent selection (now removed to a separate document).
ポールCバンOorschotは、本人確認の認証のみのバージョンを提供するために、公共指数と共有秘密の両方に署名を提案しました。また、彼は（今別のドキュメントに削除）弾性係数、発電機、および指数選択に関するテキストを提供しました。
Hilarie Orman suggested adding secret "nonces" to session-key generation for asymmetric public/private-key identity methods (now removed to a separate document), and provided extensive review of the protocol details.
ヒラリーオーマンは（今別のドキュメントに削除）非対称公開/秘密鍵の識別方法のためのセッション鍵の生成に秘密の「ナンス」を追加提案し、プロトコルの詳細の大規模な見直しを提供します。
Bart Preneel and Paul C van Oorschot in [PO96] recommended padding between the data and trailing key when hashing for authentication.
認証のためのハッシュ場合バート・プレニール及び[PO96]ポール・C・ヴァン・Oorschotデータと末尾のキーの間にパディングを推奨しました。
Niels Provos developed another independent implementation (circa May 1997), ported to AIX, Linux, OpenBSD, and Solaris. Also, he made suggestions regarding automated update, and listing multiple moduli per scheme.
ニールス・プロボスはAIX、Linuxでは、OpenBSDの、およびSolarisに移植され、（年頃1997年5月）、別の独立した実装を開発しました。また、彼は、自動更新に関する提案を行い、制度ごとに複数の弾性係数をリストアップ。
Bill Sommerfeld suggested including the authentication symmetric secret-keys in the session-key generation, and using the Cookie values on successive exchanges to provide bi-directional user-oriented keying (now removed to a separate document).
ビル・ゾンマーフェルトは、セッション鍵生成における認証対称秘密鍵を含む、双方向ユーザ指向のキーを提供するために、連続した取引所にクッキー値を使用して（現在は別の文書に除去）を示唆しました。
Oliver Spatscheck developed the second independent implementation (circa December 1995) for the Xkernel.
オリバーSpatscheckはXkernelのために（1995年12月頃）は、第2の独立した実装を開発しました。
International interoperability testing between early implementors provided the impetus for many of the implementation notes herein, and numerous refinements in the semantics of the protocol messages.
初期の実装者間の国際相互運用性テストは、プロトコルメッセージの意味で本明細書の実施ノートの多くの、そして数多くの改良のための原動力を提供します。
Randall Atkinson, Steven Bellovin, Wataru Hamada, James Hughes, Brian LaMacchia, Cheryl Madson, Lewis McCarthy, Perry Metzger, Bob Quinn, Ron Rivest, Rich Schroeppel, and Norman Shulman provided useful critiques of earlier versions of this document.
ランドール・アトキンソン、スティーブンBellovin氏、渉浜田、ジェームズ・ヒューズ、ブライアン・ラマキア、シェリルMadson、ルイス・マッカーシー、ペリーメッツガー、ボブ・クイン、ロナルド・リベスト、リッチSchroeppel、とノーマンシュルマンは、このドキュメントの以前のバージョンの有益な批評を提供します。
Special thanks to the Center for Information Technology Integration (CITI) for providing computing resources.
コンピューティングリソースを提供するための情報基盤の統合のためのセンター（CITI）に感謝します。
References
リファレンス
[BGMW93] E. Brickell, D. Gordon, K. McCurley, and D. Wilson, "Fast Exponentiation with Precomputation (Extended Abstract)", Advances in Cryptology -- Eurocrypt '92, Lecture Notes in Computer Science 658 (1993), Springer-Verlag, 200-207.
、（1993）、EUROCRYPT '92コンピュータサイエンス658における講義ノート - [BGMW93] E.ブリッケル、D.ゴードン、K. McCurley、及びD.ウィルソン、 "プリコンピュテーション（拡張アブストラクト）による高速累乗" は、暗号理論の進歩しますシュプリンガー・フェアラーク、200〜207。
Also U.S. Patent #5,299,262, E.F. Brickell, D.M. Gordon,
K.S. McCurley, "Method for exponentiating in
cryptographic systems", 29 Mar 1994.
[DH76] Diffie, W., and Hellman, H.E., "New Directions in Cryptography", IEEE Transactions on Information Theory, v IT-22 n 6 pp 644-654, November 1976.
[DH76]ディフィー、W.、およびヘルマン、H.E.、 "暗号に関する新"、情報理論に関するIEEEトランザクション、V IT-22 N 6頁644から654まで、1976年11月。
[DOW92] Whitfield Diffie, Paul C van Oorshot, and Michael J Wiener, "Authentication and Authenticated Key Exchanges", Designs, Codes and Cryptography, v 2 pp 107-125, Kluwer Academic Publishers, 1992.
[DOW92]ホイットフィールドディフィー、ポールCバンOorshot、そしてマイケル・Jウィーン、「認証および認証鍵交換」、デザイン、コード、および暗号化、V 2頁107から125、Kluwerの学術出版社、1992。
[Firefly] "Photuris" is the latin name for the firefly. "Firefly" is in turn the name for the USA National Security Administration's (classified) key exchange protocol for the STU-III secure telephone. Informed speculation has it that Firefly is based on very similar design principles.
[ホタル]「Photurisは」ホタルのためのラテン語の名前です。 「ホタルは」今度はSTU-III安全な電話のための米国国家安全保障管理者（分類）鍵交換プロトコルの名前です。インフォ憶測はホタルが非常によく似た設計原理に基づいていること、それを持っています。
[LL94] Lim, C.H., Lee, P.J., "More flexible exponentiation with precomputation", Advances in Cryptology -- Crypto '94, Lecture Notes in Computer Science 839 (1994), Springer-Verlag, pages 95-107.
[LL94]リム、C.H.、リー、P.J.、 "事前計算とより柔軟累乗" は、暗号学の進歩 - 暗号'94、コンピュータサイエンス839（1994）での講義ノート、シュプリンガー・フェアラーク、ページ95-107。
[Prime Commandment] A derivation of an apocryphal quote from the usenet list sci.crypt.
[プライム戒] Usenetのリストsci.cryptから作り話の引用の導出。
[PO96] Bart Preneel, and Paul C van Oorshot, "On the security of two MAC algorithms", Advances in Cryptology -- Eurocrypt '96, Lecture Notes in Computer Science 1070 (May 1996), Springer-Verlag, pages 19-32.
「2つのMACアルゴリズムのセキュリティについて」[PO96]バート・プレニール、およびポールCバンOorshotは、暗号学における進歩 - コンピュータサイエンス1070（1996年5月）、シュプリンガー・フェアラーク、ページ19-32でEUROCRYPT '96、講義ノートを。
[RFC-768] Postel, J., "User Datagram Protocol", STD 6, USC/Information Sciences Institute, August 1980.
[RFC-768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、USC /情報科学研究所、1980年8月。
[RFC-791] Postel, J., "Internet Protocol", STD 5, USC/Information Sciences Institute, September 1981.
[RFC-791]ポステル、J.、 "インターネットプロトコル"、STD 5、USC /情報科学研究所、1981年9月。
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", MIT Laboratory for Computer Science, April 1992.
[RFC-1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、コンピュータサイエンスのためのMIT研究所、1992年4月。
[RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, USC/Information Sciences Institute, October 1994.
[RFC-1700]レイノルズ、J.、およびポステル、J.、 "割り当て番号"、STD 2、USC /情報科学研究所、1994年10月。
[RFC-1812] Baker, F., Editor, "Requirements for IP Version 4 Routers", Cisco Systems, June 1995.
[RFC-1812]ベイカー、F.、エディタ、 "IPバージョン4つのルータのための要件"、シスコシステムズ、1995年6月。
[RFC-1828] Metzger, P., Simpson, W., "IP Authentication using Keyed MD5", July 1995.
[RFC-1828]メッツガー、P.、シンプソン、W.、 "キー付きMD5を使用してIP認証"、1995年7月。
[RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC Transform", July 1995.
[RFC-1829]カーン、P.、メッツガー、P.、シンプソン、W.は、 "ESP DES-CBC変換を"、1995年7月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, Harvard University, March 1997.
[RFC-2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、ハーバード大学、1997年3月。
[RFC-2521] Karn, P., and Simpson, W., "ICMP Security Failures Messages", March 1999.
[RFC-2521]カーン、P.、およびシンプソン、W.、 "ICMPセキュリティの失敗メッセージ"、1999年3月。
[Rooij94] P. de Rooij, "Efficient exponentiation using precomputation and vector addition chains", Advances in Cryptology -- Eurocrypt '94, Lecture Notes in Computer
コンピュータにEUROCRYPT '94、講義ノート - [Rooij94] P.デRooij、「事前計算とベクトル加算チェーンを用いた効率的な累乗」には、暗号学の進歩します
Science, Springer-Verlag, pages 403-415.
科学、シュプリンガー・フェアラーク、ページ403から415。
[Schneier95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7.
[Schneier95]シュナイアー、B.、 "応用暗号第二版"、John Wiley＆Sons、ニューヨーク、NY、1995 ISBN 0-471-12845-7。
Contacts
コンタクト
Comments about this document should be discussed on the photuris@adk.gr mailing list.
この文書についてのコメントはphoturis@adk.grメーリングリストで議論されるべきです。
Questions about this document can also be directed to:
このドキュメントに関する質問も対象とすることができます。
Phil Karn Qualcomm, Inc. 6455 Lusk Blvd. San Diego, California 92121-2779
フィル・カーンクアルコム社6455ラスクブルバードサンディエゴ、カリフォルニア92121-2779
karn@qualcomm.com
karn@unix.ka9q.ampr.org (preferred)
William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071
ウィリアムアレンシンプソン空想家コンピュータシステムズコンサルティングサービス1384フォンテーヌマディソンハイツ、ミシガン州48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。著作権（C）フィリップ・カーンとウィリアムアレンシンプソン（1994年から1999年）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards (in which case the procedures for copyrights defined in the Internet Standards process must be followed), or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手続きが規定されている場合には（インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化過程で）続く、またはとしては、英語以外の言語に翻訳するために必要とされなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and 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.
基礎とインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または黙示、（に限らず）を含めた情報の使用は、本明細書に一切の保証「そのまま」本明細書中に含まれるこの文書や情報を上に設けられています特定の目的に対する権利または商品性または適合性の黙示の保証を侵害することはありません。