[要約] RFC 2522は、Photurisセッションキー管理プロトコルに関する仕様です。このRFCの目的は、セキュアなセッションキーの生成と管理を提供することです。
Network Working Group P. Karn
Request for Comments: 2522 Qualcomm
Category: Experimental W. Simpson
DayDreamer
March 1999
Photuris: Session-Key Management Protocol
Photuris：セッションキー管理プロトコル
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
Phyuris [Firefly]は、インターネットを越えてセッションキーを通過することなく、2つのパーティー間で短命のセッションキーを確立します。これらのセッションキーは、セキュリティ目的で歴史的に構成されてきた長寿命のシークレットキー（パスワードやパスフレーズなど）を直接置き換えます。
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.
このドキュメントは、主にPhyurisプロトコルの実装を目的としています。プロトコルメカニズムの適切な実装と操作に必要ないくつかの基本的なポリシー領域に言及していますが、サービスとアプリケーションのインターフェイスの定義を詳しく説明していません。
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].
このドキュメントでは、キーワードは「可能性があります」、「必要はない」、「オプション」、「推奨」、「必要」、「必要はありません」は、[RFC-2119]に記載されているように解釈されるべきではありません。
byte An 8-bit quantity; also known as "octet" in standardese.
バイト8ビット数量。Standardeseの「Octet」としても知られています。
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 Exchangeを指します。
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.
非対称のパブリック/プライベートキーペアの一部である公的に分散できる価値。
secret-key A symmetric key that is not publically distributable. As used in this document, this is distinguished from an asymmetric public/private
Secret-Key公開されていない対称キー。このドキュメントで使用されているように、これは非対称のパブリック/プライベートと区別されます
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つのノード間のセキュリティ関係を説明するパラメーターのコレクション。これらのパラメーターには、パーティーのアイデンティティ、変換（アルゴリズムおよびアルゴリズムモードを含む）、キー（SESSION-KEY、SECRET-KEY、または適切なパブリック/プライベートキーペアなど）、およびその他の情報が含まれます。感度標識など。
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）変換やセッションキーなどのセキュリティ協会の下で使用される特定の一方向属性のセットを示す数字。数値は、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.
セッションキーは、当事者によって共有された秘密から独立して導き出され、1つのトラフィックの方向をキー化するために使用されるキーです。このキーは頻繁に変更されます。
shared-secret As used in this document, the calculated result of the Photuris exchange.
このドキュメントで使用されている共有秘密、Photuris Exchangeの計算結果。
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]はプレーンテキストをCiphertextに変換し、再び戻します。
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
セキュリティ協会（双方向） - セキュリティパラメーターの1つ以上のリスト（統一） - 1つ以上の属性---キーがある場合があります---変換を示す場合があります
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].
実装者は、[Schneier95]の暗号化ハッシュ（MD5など）、暗号化アルゴリズムとモード（DESなど）、デジタル署名（DSSなど）、およびその他のアルゴリズムの詳細を見つけます。
The Photuris protocol consists of several simple phases:
Phyurisプロトコルは、いくつかの単純なフェーズで構成されています。
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. 「Cookie」は、偽のIPソースまたはUDPポートを使用して送信された単純な洪水攻撃に対して守られています。各パーティーは他のパーティーに「クッキー」を渡します。
In return, a list of supported Exchange-Schemes are offered by the Responder for calculating a shared-secret.
その見返りに、共有分泌を計算するために、サポートされている交換スキームのリストがResponderによって提供されます。
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. バリューエクスチェンジは、当事者間で共有分泌を確立します。各当事者は、他方に交換価値を渡します。これらの値は、共有秘密を計算するために使用されます。共有分泌が作成されるまで、レスポンダーはステートレスのままです。
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. 識別交換は、互いに当事者を識別し、フェーズ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つのフェーズ（Cookie、Exchange、およびIdentification）を完全に実行する必要があります。
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
IDENTION_REQUEST-> MAKE SPI PICK SPI属性（s）識別セルフ認証プライバシーキーメイクマスク/暗号化メッセージ<-Identity_response spi pick spi属性を識別セルフ認証プライバシーキー/暗号化メッセージ
[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.
2つのパーティー間の光虫の交換により、SPI値のペア（各方向に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は、IP宛先を管理するエンティティによって割り当てられます：SPI所有者（受信者）。当事者は、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交換を同時に開始したり、1つの当事者が複数のPhoturis Exchangeを開始したりすると、イニシエーターCookie（および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を選択します。
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値を選択することで、予測不可能な値のシーケンスに依存する攻撃を防ぐのに役立ちます。実装者は、SPI値が特定の順序または範囲を持つことを期待してはなりません。
The Photuris exchange results in two kinds of state, each with separate LifeTimes.
Photuris Exchangeは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 Exchange自体に関連する少量の状態の交換寿命。この状態は、インターネットノード間で見られる場合があります。
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の寿命は、交換寿命よりも短くても長い場合があります。これらの寿命は、互いに関連する必要はありません。
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.
Exchange-Valueの有効期限が切れる（または新しい値に置き換えられる）場合、期限切れの導出された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）を持ち、定期的な満了の対象となります。これは、マシンの物理的および物理的なセキュリティに依存し、通常は10分から1日の範囲（デフォルト30分）です。
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
さらに、Photuris Exchangeでは、Exchange Timeout（ETO）が交換が完了するのを待つことを制限します。このタイムアウトには、パケットラウンドトリップと識別交換計算を完了する時間が含まれます。時間は、未知のピアの処理能力に期待される計算遅延の最大量と、最小ユーザーの期待の両方によって区切られています。
results (default 30 seconds).
結果（デフォルト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の2倍未満であってはなりません。
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-Valueを計算するために必要な秒の2倍の範囲内で各交換寿命をランダムに変化させる必要があります。たとえば、レスポンダーが30分のベースELTを使用し、10秒かかる場合、新しいExchange-Valueを計算すると、方程式は（ミリ秒単位）である可能性があります。
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-Scheme、Exchange-Values、および結果として生じる共有秘密は、交換寿命の短期保管でキャッシュされる場合があります。同じ当事者間で繰り返しの光の交換が発生し、交換価値が変更されていないことが発見された場合、以前に計算された共有秘密を使用して、新しいセッションキーを迅速に生成できます。
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の3回以下であってはなりません。
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):
複数の視神経交換間の同期を防ぐために、実装は各SPI寿命をランダムに変化させる必要があります。たとえば、Responderが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
同じ関数についてSPIユーザーが複数の期限切れのSPIを使用できる場合、一般的な実装手法はSPIを選択することです。
with the greatest remaining LifeTime. However, selecting randomly among a large number of SPIs might provide some defense against traffic analysis.
残りの生涯が最も大きい。ただし、多数の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 Exchangeの共有分泌物も有効期限を過ごし、関連状態をパージするまで使用できないようにマークする必要があります。
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:
イニシエーターは、いくつかの状況下で光虫の交換を開始します。
- 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 Exchange状態はありません。このデータグラムは破棄され、代わりに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.
- イニシエーターは、現在のPhoturis交換状態とICMPソースと一致する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]セキュリティ障害を受信しています。
- 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.
- イニシエーターは、現在のPhoturis交換状態とICMPソースと一致する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データグラムと一致する情報が実際に含まれていることに特別な注意が必要です。そうでなければ、これは新しい光虫の交換を刺激することにより、詰まり攻撃の機会を提供する可能性があります。
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.
イニシエーターに返信するとき、レスポンダーは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.
Responder-Cookie 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
0 cookie_request 1 cookie_response 2 value_request 3 value_response 4 idention_request 5 secret_response（optional）6 secret_request（optional）7 Identity_response 8 spi_update 10 bad_cookie 11 resource_limit 12 verifice_failure_failure
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バイト。値フィールドで使用される重要なビットの数。常に最初に最も重要なバイトを常に送信しました。
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).
最も重要なバイトが0〜254（0xfe）の範囲にある場合、フィールドは2バイトです。両方のバイトは、1〜65,279の有意ビット（1〜8,160バイト）の範囲の値フィールドのサイズを示すために使用されます。
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バイトは65,280に追加されて、値フィールドのサイズを示します。これは16,776,959の有意ビットに制限されています（
2,097,120 bytes).
2,097,120バイト）。
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バイトは、値フィールドのサイズを示すために16,776,960に追加されます。
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つの補完的な負の整数であると想定されます。負の整数は、常に最も重要なバイトに少なくとも1つの未使用のリーディングサインビットがあります。
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.
サポートするには、65,279以下の重要なビットが必要です。他の範囲は、これらのUDPメッセージには非常に長すぎますが、完全性のために含まれています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scheme | Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Scheme 2 bytes. A unique value indicating the Exchange-Scheme. See the "Basic Exchange-Schemes" for details.
スキーム2バイト。Exchange-Schemeを示す一意の値。詳細については、「基本的な交換シーム」を参照してください。
Size 2 bytes, ranging from 0 to 65,279. See "Variable Precision Integer".
サイズ2バイト、0〜65,279の範囲。「可変精度整数」を参照してください。
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.
ただし、各スキームとサイズの組み合わせの1つのみがスキームのリストに存在します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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バイト。バイトの値フィールドのサイズ。
When the Length is zero, no Value(s) field is present.
長さがゼロの場合、値フィールドは存在しません。
Value(s) 0 or more bytes. See the "Basic Attributes" for details.
値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」を生成します。イニシエータークッキーは、同じパーティー間の新しいCookie_Requestごとに異なる必要があります。詳細については、「Cookie Generation」を参照してください。
- 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.
たとえば、spi_neededに応じて、以前のイニシエーターからbad_cookieメッセージが受信されました。レスポンダークッキーはイニシエータークッキーに置き換えられ、新しいイニシエータークッキーが生成されます。これにより、bogus 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.
- それ以外の場合、このレスポンダークッキーとカウンターはどちらもゼロに設定されています。
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.
デフォルトでは、イニシエーターは、以前のすべての交換状態が期限切れになったときと同じ方法で動作します。レスポンダーは、独自の交換状態が期限切れになっていない場合に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が再送信されます。イニシエータークッキー値は、同じ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 Exchangeを開始する必要があります。
On receipt of a Cookie_Request, the Responder determines whether there are sufficient resources to begin another Photuris exchange.
Cookie_Requestを受信すると、Responderは、別のPhoturis Exchangeを開始するのに十分なリソースがあるかどうかを決定します。
- 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 Timeoutを超えておらず、Responder-Cookieがこれらの以前の交換のいずれかを指定していない場合、Resource_limitメッセージが送信されます。
Otherwise, the Responder returns a Cookie_Response.
それ以外の場合、レスポンダーはcookie_responseを返します。
Note that the Responder creates no additional state at this time.
現時点では、レスポンダーが追加の状態を作成しないことに注意してください。
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ノード間の以前の交換が有効期限が切れていない場合、応答カウンターは最新のExchangeカウンターと1つに設定されます（Ormer Aut Ormeの再送信を可能にします）。それ以外の場合、応答カウンターはリクエストカウンターと1つに設定されます。
If (through rollover of the Counter) the new Counter value is zero (modulo 256), the value is set to one.
（カウンターのロールオーバーを介して）新しいカウンター値がゼロ（Modulo 256）の場合、値は1に設定されます。
If this new Counter value matches some previous exchange initiated by this particular peer that has not yet exceeded the Exchange TimeOut,
この新しいカウンター値が、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.
Nota Bene：同じ2人のピアの間の254の同時交換がサポートされています。
The Responder generates a unique cookie. The Responder-Cookie value in each successive response SHOULD be different. See "Cookie Generation" for details.
レスポンダーはユニークなクッキーを生成します。各連続した応答のレスポンダークッキー値は異なるはずです。詳細については、「Cookie Generation」を参照してください。
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_responsも静かに破棄されます。
When the message is valid, an Exchange-Scheme is chosen from the list of Offered-Schemes.
メッセージが有効な場合、提供されたスchemesのリストからExchange-Schemeが選択されます。
This Scheme-Choice may affect the next Photuris message sent. By default, the next Photuris message is a Value_Request.
このスキーム選択は、送信された次のPhoturisメッセージに影響を与える可能性があります。デフォルトでは、次のPhyurisメッセージは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.
Exchangeを識別するために、イニシエータークッキーのみが使用されます。カウンターとレスポンダークッキーはどちらも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バイト。交換を識別するランダム化値。値がゼロであることではありません。詳細については、「Cookie Generation」を参照してください。
Responder-Cookie 16 bytes. Identifies a specific previous exchange. Copied from a previous Cookie_Response.
Responder-Cookie 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.
Responder-Cookie 16バイト。交換を識別するランダム化値。値がゼロであることではありません。詳細については、「Cookie Generation」を参照してください。
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つ以上の交換スキームのリストは、最大から最も好ましいものに注文されました。詳細については、「基本的な交換シーム」を参照してください。
Only one Scheme (#2) is required to be supported, and SHOULD be present in every Offered-Schemes list.
サポートする必要があるスキーム（＃2）のみが必要であり、提供されるすべてのスケーメスリストに存在する必要があります。
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パーティーがCookieを生成する正確な手法は、実装に依存しています。選択した方法は、いくつかの基本的な要件を満たす必要があります。
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. Cookieは特定の関係者に依存する必要があります。これにより、攻撃者が実際のIPアドレスとUDPポートを使用してCookieを取得し、ランダムに選択した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を生成することは不可能であってはなりません。これは、発行エンティティがCookieの生成とその後の検証におけるローカルシークレット情報を使用することを意味します。特定のCookieからこの秘密の情報を推測することは不可能であってはなりません。
3. The cookie generation and verification methods MUST be fast to thwart attacks intended to sabotage CPU resources.
3. CPUリソースを妨害することを目的とした攻撃を阻止するために、Cookieの生成方法と検証方法は速くなければなりません。
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.
Cookieに影響を与えるイニシエーターの秘密の値は、新しいPhoturis Exchangeごとに変更され、その後、レスポンダーごとに内部的にキャッシュされます。これにより、リプレイ攻撃に対する同期の改善と保護が提供されます。
An alternative is to cache the cookie instead of the secret value. Incoming cookies can be compared directly without the computational cost of regeneration.
別の方法は、秘密の値の代わりにCookieをキャッシュすることです。着信クッキーは、再生の計算コストなしで直接比較できます。
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.
Cookieは、秘密の値、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).
Cookieに影響を与えるレスポンダーの秘密の値は、多くの異なるイニシエーターで同じままである可能性があります。ただし、この秘密は、Cookieの使用時間を制限するために定期的に変更する必要があります（通常は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.
Responder-Cookieには、イニシエータークッキーを含める必要があります。Responder-Cookieにはカウンターを含める必要があります（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.
Cookieは、秘密の値、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.
Cookieは、最初のCookie交換中に状態を救うことを避けるために、イニシエーターごとにキャッシュされていません。Value_Request（後述）を受信すると、Responderは検証のためにCookieを再生します。
Once the Value_Response is sent (also described later), both Initiator and Responder cookies are cached to identify the exchange.
Value_Responseが送信されると（後述）、イニシエーターとレスポンダーCookieの両方が交換を特定するためにキャッシュされます。
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.
ただし、適切なカウンターを決定するために既存の光虫交換を一致させる場合、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の間の事前に計算されたレスポンダー交換価値の動的な変化を検出するために、いくつかのメカニズムが必要になる場合があります。たとえば、秘密の値を変更してCookieを無効にするか、Photuris Exchange状態を有効期限として明示的にマークします。
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.
イニシエーターは、スキーム選択の適切な交換価値を生成します。この交換価値は事前に計算され、複数のレスポンダーに使用される場合があります。
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 Exchangeを再度開始する必要があります。
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.
- 無効/期限切れのResponder-Cookieが検出されると、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.
- 無効なスキーム選択が検出された場合、または交換値が明らかに欠陥がある場合、または提供される可変長さがUDPの長さと一致しない場合、メッセージは静かに破棄されます。実装では、Occuranceを記録し、必要に応じてオペレーターに通知する必要があります。
When the message is valid, the Responder sets its Exchange timer to the Exchange TimeOut, and returns a Value_Response.
メッセージが有効な場合、ResponderはExchange TimerをExchange Timeoutに設定し、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.
レスポンダーは、着信value_request cookieペアのコピーとその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.
レスポンダーは、スキーム選択の適切な交換価値を生成します。この交換価値は事前に計算され、複数のイニシエーターに使用される場合があります。
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.
この時点で、レスポンダーは共有分泌範囲の計算を開始します。共有分泌の計算は、遅延を最小限に抑えるために並行して実行されます。
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.
イニシエーターは、Cookieのペア、Exchange-Value、および提供されたアトリビュートを検証します。
- When an invalid/expired cookie is detected, the message is silently discarded.
- 無効/有効期限が切れたCookieが検出されると、メッセージは静かに破棄されます。
- 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.
- Exchange-Valueに明らかに欠陥がある場合、または提供される変動長が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が送信されるまで、両方の一致するCookieを持つ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をResponderに送信します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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.
Responder-Cookie 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.
Scheme-Coice 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.
フィールドは、そのサイズフィールドで示されるように、長さのバイト数の任意の積分数である場合があります。特定のアライメントは必要ありません。示されている32ビットアライメントは、イラストの便利さのためです。
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.
このリストの内容と使用法は、「提供された属性リスト」でさらに説明されています。リストの終わりは、UDPの長さで示されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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.
Responder-Cookie 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.
Responder-Exchange-Value変数精度整数。当事者間で共有分泌を計算するためのレスポンダーによって提供されます。値形式は、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.
サイズフィールドで示されるように、長さ。特定のアライメントは必要ありません。示されている32ビットアライメントは、イラストの便利さのためです。
Responder-Offered-Attributes 4 or more bytes. A list of Security Parameter attributes supported by the Responder.
4つ以上のバイトを吸収したreverder-ofttributes。レスポンダーがサポートするセキュリティパラメーター属性のリスト。
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.
このリストの内容と使用法は、「提供された属性リスト」でさらに説明されています。リストの終わりは、UDPの長さで示されています。
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.
リストの最初のセクションには、識別方法が含まれています。このリストからID選択が選択されています。
The second section of the list begins with "AH-Attributes" (#1). It includes methods of authentication, and other operational types.
リストの2番目のセクションは、「ah-aTtributes」（＃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-attributes」（＃2）で始まります。認証、圧縮、暗号化、およびその他の運用タイプの方法が含まれています。カプセル化とアトリビュートが提供されていない場合、「ESP-Attributes」属性自体がリストから省略されます。
Attribute-Choices are selected from the latter two sections of the list.
属性チョイスは、リストの後者の2つのセクションから選択されています。
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-ATTRIBUTES」、「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.
計算の時間は、共有分泌または同一性の検証を生成する際に使用される秘密の値の特定のビットの値に依存する場合があります。計算時間を記録してこれらの秘密ビットの分析を防ぐために、ID_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.
IDの完了前に受信された認証されたユーザーデータグラムおよび/または暗号化されたユーザーデータグラムは、このステップの完了を保留するまでのキューに配置できます。検証が成功した場合、キューは検証の後にデータグラムが到着したかのように処理されます。検証が失敗した場合、キューは破棄されます。
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.
イニシエーターはまた、再送信タイマーを開始します。有効なID_RESPONSEが制限時間内に到着しない場合、その以前のID_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 Exchangeを再度開始する必要があります。
The Responder validates the pair of Cookies, the Padding, the Identification, the Verification, and the Attribute-Choices.
レスポンダーは、クッキーのペア、パディング、識別、検証、および属性チョイスを検証します。
- When an invalid/expired cookie is detected, a Bad_Cookie message is sent.
- 無効/期限切れのCookieが検出されると、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.
- 無効な識別が検出された場合、またはメッセージの確認が失敗すると、検証_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.
メッセージが有効な場合、ResponderはExchange TimerをExchange Lifetimeに設定します（これが以前のExchangeでまだ行われていない場合）。共有分泌の並列計算が完了すると、レスポンダーはID_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.
レスポンダーは、着信ID_REQUEST値のコピーとそのID_RESPONSEを保持します。重複したID_REQUESTが受信された場合、以前のID_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.
Responderは、SPIの属性のセットであるSPIとこぼれた適切な識別、SPIのセットを選択し、検証を計算し、現在のスキーム選択で示されるプライバシーメソッドを使用してメッセージをマスクします。
The Responder calculates the SPI session-keys in both directions.
レスポンダーは、SPIセッションキーを両方向に計算します。
At this time, the Responder begins the authentication and/or encryption of user datagrams.
この時点で、レスポンダーはユーザーデータグラムの認証および/または暗号化を開始します。
The Initiator validates the pair of Cookies, the Padding, the Identification, the Verification, and the Attribute-Choices.
イニシエーターは、Cookieのペア、パディング、識別、検証、および属性チョイスを検証します。
- When an invalid/expired cookie is detected, the message is silently discarded.
- 無効/有効期限が切れた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.
- 無効な識別が検出された場合、またはメッセージの確認が失敗すると、検証_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が送信されるまで、両方の一致するCookieを持つID_RESPONSEも静かに破棄されます。
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タイマーをExchange Lifetimeに設定します（これが以前の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.
Responder-Cookie 16バイト。value_requestからコピー。
Message 4 (Request) or 7 (Response)
メッセージ4（リクエスト）または7（応答）
LifeTime 3 bytes. The number of seconds remaining before the indicated SPI expires.
生涯3バイト。指定されたSPIが失効する前に残っている秒数。
When the SPI is zero, this field MUST be filled with a random non-zero value.
SPIがゼロの場合、このフィールドはランダムな非ゼロ値で満たされる必要があります。
Security-Parameters-Index (SPI) 4 bytes. The SPI to be used for incoming communications.
Security-Parameters-Index（SPI）4バイト。着信通信に使用されるSPI。
When zero, indicates that no SPI is created in this
ゼロの場合、これにSPIが作成されていないことを示します
direction.
方向。
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.
Identity-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.
フィールドは、その長さフィールドで示されるように、長さのバイト数の任意の積分数である場合があります。特定のアライメントは必要ありません。示されている16ビットのアライメントは、イラストの利便性のためです。
Identification Variable Precision Integer, or alternative format indicated by the Identity-Choice. See the "Basic Attributes" for details.
識別変数精度整数、またはID選択によって示される代替形式。詳細については、「基本属性」を参照してください。
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.
フィールドは、長さのバイト数の任意の任意の数である場合があります。特定のアライメントは必要ありません。示されている32ビットアライメントは、イラストの便利さのためです。
Verification Variable Precision Integer, or alternative format indicated by the Identity-Choice. The calculation of the value is described in "Identity Verification".
検証変数精度整数、またはID選択によって示される代替形式。値の計算は、「ID検証」で説明されています。
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.
フィールドは、長さのバイト数の任意の任意の数である場合があります。特定のアライメントは必要ありません。示されている32ビットアライメントは、イラストの便利さのためです。
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.
属性-choices 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).
このリストの内容と使用法は、「属性選択リスト」でさらに説明されています。リストの終わりは、パディングを削除した後のUDPの長さで示されます（UDPの長さ - 最後のパディング値）。
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
さらに、Privacy-Methodが示す場合
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つのセクションで構成されています：Authentication-Attributes、および/またはcapsulation-attributes。
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-attributes」、「deflate」（圧縮）、「xor」（暗号化）、「des-cbc」（暗号化）、 "xor"（encryption）、 "ah-attributes"、 "ah-sequence"、 "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が圧縮とトリプル暗号化（内部）を備えたESPになり、ESPペイロードのシーケンス番号（外側）を使用したAH認証が発生します。
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.
提供されたアトリビュートのリストから選択が行われる場合、セキュリティ協会には、1つの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.
いくつかの種類の属性は、1つの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-Choiceを使用して認証されます。検証値は、マスキング（およびオプションの暗号化）の前に計算され、マスキングを解除した後（およびオプションの復号化）後に検証されます。
The Identity-Choice authentication function is supplied with two input values:
Identity-Choice認証関数には、2つの入力値が付属されています。
- 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:
ID選択データは、次の連結値で構成されています。
+ 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ユーザーID検証（応答のみ）、検証フィールドに続く属性選択、パディング、SPI所有者TBV、SPI所有者Exchange-Value、SPI所有者は、Attributesを提供し、SPIユーザーTBV、SPIユーザーExchange-Value、SPIユーザーが提供するアトリビュート、Responderは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_Requestのカウンターおよびスキーム選択フィールド、または関連するExchange-Valueの直前のValue_Responseからの予約フィールドで構成されています。
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.
Exchange-Valueおよび提供されたアトリビュートフィールドの順序は各方向で異なり、識別とSPIフィールドも各方向で異なる可能性が高いことに注意してください。また、SPIユーザーIDの検証（Identity_Requestから）はID_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.
検証が失敗した場合、ユーザーに通知され、SPIを追加せずに確認_Failureメッセージが送信されます。成功すると、通常の操作は、ユーザーデータグラムの認証および/または暗号化から始まります。
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".
検証計算に含まれる識別と検証キーの正確な詳細は、「基本属性」に記載されているように、ID選択に依存します。
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
各当事者は、The Pretty Good Privacy（PGP）Web of Trustなど、独自の信頼できるデータベースを維持し、そこにあるアイデンティティのみを受け入れたい場合があります。内部データベースまたは外部データベースのいずれかで識別を見つけられなかった結果は、同じです
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.
Exchange-Valueデータには、サイズフィールドと値フィールドの両方が含まれます。提供されたアトリビュートと属性チョイスのデータには、属性、長さ、および値フィールドが含まれます。
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:
スキーム選択指定されたキージェネレーション機能は、各メッセージに特別なプライバシーキーを作成するために使用されます。この関数は、次の連結値で計算されます。
+ 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-Value、SPIユーザーExchange-Value、イニシエーターCookie、Responder Cookie、メッセージ、Lifetime、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.
Exchange-Valueフィールドの順序は各方向で異なり、メッセージ、Lifetime、および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.
パディングの長さ、およびその他の詳細は、プライバシーメソッドに依存します。詳細については、「Basic Privacy-Method」リストを参照してください。
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
Exchange-Valuesを最初の検証後にメモリに保持することを避けるために、それぞれの連結データ値の初期バイトで関数を事前に計算することができることがよくあります
direction, and append the trailing copies of the shared-secret.
方向、および共有秘密の後続のコピーを追加します。
The Exchange-Value data includes both the Size and Value fields.
Exchange-Valueデータには、サイズフィールドと値フィールドの両方が含まれます。
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には1つ以上のセッションキーがあります。これらのキーは、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:
スキーム選択指定されたキージェネレーション機能は、その特定の属性の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 Exchange用に生成されたプライバシーキーとは異なります。異なる初期化データが使用され、反復が個別に維持されます。
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".
セッションキー計算に含まれる検証フィールドと生成キーの正確な詳細は、「基本属性」に記載されているように、ID選択に依存します。
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所有者は、Cookie、パディング、検証、および必要な属性のペアを検証します。
- When an invalid/expired cookie is detected, a Bad_Cookie message is sent.
- 無効/期限切れのCookieが検出されると、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.
- マスキングを解除した後、無効なパディングが検出された場合、必要な変数の長さの属性はUDPの長さと一致しないか、属性が提供されたアトリビュートにありませんでした、メッセージは静かに廃棄されます。
- When the message verification fails, a Verification_Failure message is sent.
- メッセージの確認が失敗すると、確認_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ユーザーまで、1つの方向のみで効果があります。
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ユーザーは、Cookie、パディング、検証、および必要な属性のペアを検証します。
- 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.
- メッセージの確認が失敗すると、確認_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_UPDATEにより、高い遅延環境での高帯域幅アプリケーションの迅速な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）を設定する場合があります。デフォルトでは、生涯の半分の値（Spilled/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.
Responder-Cookie 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.
リザーブリング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.
フィールドは、長さのバイト数の任意の任意の数である場合があります。特定のアライメントは必要ありません。示されている32ビットアライメントは、イラストの便利さのためです。
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).
このリストの内容と使用法は、以前に「属性選択リスト」で説明されているとおりです。リストの終わりは、パディングを削除した後のUDPの長さで示されます（UDPの長さ - 最後のパディング値）。
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.
Responder-Cookie 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.
生涯3バイト。指定されたSPIが失効する前に残っている秒数。値ゼロは、示されたSPIの削除を示します。
Security-Parameters-Index (SPI) 4 bytes. The SPI to be used for incoming communications.
Security-Parameters-Index（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.
これは、新しいSPI値（作成用）、または既存のSPI値（削除用）です。値ゼロは特別な処理を示します。
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.
フィールドは、長さのバイト数の任意の任意の数である場合があります。特定のアライメントは必要ありません。示されている32ビットアライメントは、イラストの便利さのためです。
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.
属性-choices 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).
このリストの内容と使用法は、以前に「属性選択リスト」で説明されているとおりです。リストの終わりは、パディングを削除した後のUDPの長さで示されます（UDPの長さ - 最後のパディング値）。
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.
新しいセッションキーは、ID_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 Exchangeを再び開始します。必要に応じて、この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 Exchange状態を期限切れにマークします。これは、それらを必要とするアプリケーションが終了する場合に特に役立ちます。
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 Exchangeを開始します。
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:
有効性 - メソッド認証関数には、2つの入力値が付属されています。
- 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所有者のID検証、SPIユーザーID検証、検証フィールドに続く属性チョイス、パディング。
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.
ID検証フィールドの順序（ID_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.
検証が失敗した場合、ユーザーに通知され、SPIを追加または削除することなく、確認_Failureメッセージが送信されます。成功すると、通常の操作は、ユーザーデータグラムの認証および/または暗号化から始まります。
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.
ID検証データには、サイズフィールドと値フィールドの両方が含まれます。Attribute-Choicesデータには、属性、長さ、値フィールドが含まれます。
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 Stateの損失またはその他の問題に応じて発行されます。メッセージは1つの方向にのみ効果があります。再送信タイマーは必要ありません。
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.
受信者は、Cookieの有効性をチェックします。エラーメッセージのCookieペアは、実際に現在使用されているペアと一致し、プロトコルは現在、そのようなエラーメッセージが予想される状態にあることに特別な注意を払う必要があります。そうしないと、これらのメッセージは、サービス攻撃の拒否の機会を提供する可能性があります。無効なメッセージは静かに破棄されます。
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.
Responder-Cookie 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が受信されたときに送信され、受信者固有のCookieが無効であるか、関連する交換状態が期限切れになっています。
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交換中、このエラーメッセージが受信されると、プロトコルフェーズの動作に即座に影響しません。その後、再送信が超えられ、このエラーメッセージが受信された場合、イニシエーターは、Responder-Cookieで新しいCookie_Requestを送信し、適切にカウンターを更新することにより、Photuris Exchangeを再度開始する必要があります。
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 Exchangeを開始する必要があります。
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に応じて受信された場合、Exchange状態は期限切れとしてマークされるべきではなく、それ以上のアクションは実行されません。認証されたデータおよび/または暗号化されたデータを送信するために、ピアが必要に応じて新しい交換が開始されます。
Existing SPIs are not deleted. They expire normally, and are purged sometime later.
既存のスピスは削除されていません。それらは正常に期限切れになり、しばらく後にパージされます。
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.
Responder-Cookie 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
Cookie_Requestに特別な処理が適用されます。問題のあるメッセージResponder-CookieとCounterが両方ともゼロであり、既存の交換がまだパージされていない場合、このフィールドは
Responder-Cookie from the existing 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を送信するための再送信タイムアウト（通常どおり）を2倍にする必要があります。それ以外の場合、プロトコルフェーズの動作に即座に影響しません。その後、再送信が超えられ、このエラーメッセージが受信された場合、イニシエーターは、Responder-Cookieで新しいCookie_Requestを送信し、適切にカウンターを更新することにより、Photuris Exchangeを再度開始する必要があります。
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.
Responder-Cookie 16バイト。問題のメッセージからコピーされました。
Message 12
メッセージ12
This error message is sent when an Identity_Message, SPI_Needed or SPI_Update is received, and verification fails.
このエラーメッセージは、ID_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.
Responder-Cookie 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 Key Exchangeに基づいています。民間秘密の値に基づくパブリックD-Hの交換価値の交換は、当事者間で相互に共有された秘密をもたらします。この共有部門は、それ自体で使用すること、または後続のトラフィックの認証と暗号化のために一連のセッションキーを生成するために使用できます。
This document assumes familiarity with the Diffie-Hellman public-key algorithm. A good description can be found in [Schneier95].
このドキュメントは、Diffie-Hellman Public-Keyアルゴリズムに精通しています。[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]は、モジュラー指数を指定しました。パブリック価値は、ジェネレーター（g）を使用して生成され、プライベート秘密の指数（x）、modulo a prime（p）に引き上げられます。
(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.
学習係数を提供する前に、実装は、可能性のある原発性検証の少なくとも1つの反復を実行する必要があります。この方法で、モジュリが渡されると、多くのプロセッサが並行して検証を実行します。
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）の範囲全体に均等に分布するすべての可能なパブリック価値を生成するように、発電機（g）を選択する必要があります。このようなジェネレーターは、「プリミティブルート」と呼ばれます（これは、pが「安全」である場合を見つけるのは些細なことです）。
Only one generator (2) is required to be supported.
サポートする必要があるのは、1つのジェネレーター（2）のみです。
Implementation Notes:
実装メモ：
One useful technique is to select the generator, and then limit the modulus selection sieve to primes with that generator:
有用な手法の1つは、ジェネレーターを選択し、そのジェネレーターを使用してモジュラス選択のふるいをプライムに制限することです。
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 Exchange-Valueが計算されます。
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.
この仕様では、指数の長さは、最も強力な提供されたアトリブによって必要な最長のセッションキーの望ましい暗号化強度の少なくとも2倍になることを推奨しています。
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.
同じ指数と交換の価値は、同じモジュラスと発電機を使用する場合はいつでも、複数のパーティーで使用できますが、指数はランダムな間隔で変更する必要があります。バックグラウンドプロセスは、古い値を定期的に破壊し、新しいランダムな民間秘密の指数を生成し、交換価値を再計算できます。
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
これらの操作にはいくつかの時間のかかるモジュラー指数が含まれるため、それらを「バックグラウンド」に移動すると、Phyurisプロトコルの見かけの実行速度が大幅に向上します。また、CPUの負荷を十分に削減して、単一のパブリック/プライベートキーペアをいくつかの密接な間隔で使用できるようにします
Photuris executions, when creating Security Associations with several different nodes over a short period of time.
短期間にわたっていくつかの異なるノードとセキュリティ関連を作成するとき、Phyurisの実行。
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-Value 1を生成し、Exponent 1はExchange-Value 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であり、それぞれ交換価値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.
実装がランダムな指数を選択すると、結果の交換値が調べられます。Exchange-Valueが弾性率の有意ビットの半分未満で表されている場合、新しいランダム指数を選択する必要があります。
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) 実装が必要です。推奨ジェネレーター（g）が2の推奨ジェネレーター（g）を備えたモジュラス（p）は、交換シームサイズがゼロではない場合、モジュラスは提供されたスキームのリストの交換シーム値フィールドに含まれています。
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) Exchange-Schemes 3〜255は、将来の有名な公開スキームを目的としています。
(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-Schemes 256〜32767は、ベンダー固有の未発表スキームを対象としています。番号を希望する実装者は、著者から番号を要求する必要があります。
(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-Schemes 32768〜65535は、ベンダーの実装に関係なく、個人スキームを示すために協力している当事者が利用できます。これらの数値は予約されておらず、複製の対象となります。Cookie_RequestのIPソースや宛先などのその他の基準は、利用可能な特定のExchange-Schemを区別するために使用されます。
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]は、キーを生成するための擬似ランダム機能として使用されます。キーは、ハッシュの最も重要なビットから始まります。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（キー、キーフィル、データ、データフィル、キー、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.
キーフィルとDataFillは、MD5Fill用に定義された同じ長さの手法を使用しています。このパディングと長さは暗黙的であり、データグラムには表示されません。
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
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属性選択iアイデンティティ選択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〜7の属性0パディングバイトを挿入することで達成されます。
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バイト。IP Next Header（プロトコル）値を使用して、ESP変換データフィールドの内容を示します。IP Next Header（プロトコル）の最新の値は、最新の「割り当てられた数字」[RFC-1700]で指定されています。
For example, when encrypting an entire IP datagram, this field will contain the value 4, indicating IP-in-IP encapsulation.
たとえば、IPデータグラム全体を暗号化する場合、このフィールドには値4が含まれ、IP-in-IPカプセル化を示します。
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.
ID選択として選択されると、直後の識別フィールドには、非構造化変数精度整数が含まれています。有効な識別と対称的なシークレットキーは、当事者によって事前に設定されています。
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（キー、キーフィル、データ、データフィル、キー、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.
キーフィルとDataFillは、MD5Fill用に定義された同じ長さの手法を使用しています。このパディングと長さは暗黙的であり、データグラムには表示されません。
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] et Schequiturに従って、AHまたはESP属性選択として選択できます。選択された交換シェームは、少なくとも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（key、keyfill、datagram、datafill、key、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.
追加のデータフィルは、[PO96]に記載されている（非現実的な）攻撃から保護します。キーフィルとDataFillは、MD5Fill用に定義された同じ長さの手法を使用しています。このパディングと長さは暗黙的であり、データグラムには表示されません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length | OUI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Kind | Value(s) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 255
属性255
Length >= 4
長さ> = 4
When the Length is four, no Value(s) field is present.
長さが4の場合、値フィールドは存在しません。
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.
値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)
RVQ+ = Receive Value_Request (Good)
RVQ- = Receive Value_Request (Bad)
RVR+ = Receive Value_Response (Good)
RVR- = Receive Value_Response (Bad)
RIQ+ = Receive Identity_Request (Good)
RIQ- = Receive Identity_Request (Bad)
RIR+ = Receive Identity_Response (Good)
RIR- = Receive Identity_Response (Bad)
RUN+ = Receive SPI_Needed (Good)
RUN- = Receive SPI_Needed (Bad)
RUM+ = Receive SPI_Update (Good)
RUM- = Receive SPI_Update (Bad)
RBC = Receive Bad Cookie RRL = Receive Resource Limit RVF = Receive Verification Failure RMR = Receive Message Reject
rbc = curece bad cookie rrl = Receien resource lime rvf =受信確認失敗rmr =受信メッセージ拒否
TO+ = Timeout with counter > 0
TO- = Timeout with counter expired UTO = Update TimeOut XTO = Exchange TimeOut
to- =カウンター付きタイムアウト有効期限が切れているuto =更新タイムアウトXTO = Exchange Timeout
Actions
行動
scq = Send Cookie_Request scr = Send Cookie_Response
scq = send cookie_request scr = send cookie_response
svq = Send Value_Request svr = Send Value_Response
svq = send value_request svr = send値_response
siq = Send Identity_Request sir = Send Identity_Response
siq = send Identity_Requestsir = send Identity_response
sum = Send SPI_Update
se* = Send error message (see text) sbc = Send Bad Cookie srl = Send Resource Limit svf = Send Verification Failure
se* =エラーメッセージの送信（テキストを参照）sbc = bad cookie srlを送信=リソース制限を送信svf =検証障害を送信
brto = Backoff Retransmission TimeOut buto = Backoff Update TimeOut rto = Set Retransmission TimeOut uto = Set Update TimeOut xto = Set Exchange TimeOut
brto =バックオフ再送信タイムアウトbuto =バックオフアップデートタイムアウトrto =再送信タイムアウトの設定uto = set update timeout xto = SET Exchange Timeout
log = log operator message
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
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メッセージが受信されたことを示すことです。
The Initial state is fictional, in that there is no state between the parties.
当事者間には状態がないという点で、初期の状態は架空のものです。
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を待っています。再起動と交換タイマーの両方が実行されています。
Note that the Responder has no Cookie state.
レスポンダーにはクッキー状態がないことに注意してください。
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.
値状態では、イニシエーターはその交換価値を送信し、ID_Messageを待っています。再起動と交換タイマーの両方が実行されています。
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.
IDの状態では、イニシエーターがID_REQUESTを送信し、返信でID_RESPONSEを待っています。再起動と交換タイマーの両方が実行されています。
In the Ready state, the Responder has sent its Exchange-Value, and is waiting for an Identity_Message. The Exchange timer is running.
準備が整った状態では、レスポンダーがその交換価値を送信し、ID_Messageを待っています。Exchange Timerが実行されています。
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.
更新状態では、各当事者は光虫の交換を締結しており、交換寿命が切れるまで期限切れのスピスを一方的に更新しています。更新タイマーと交換タイマーの両方が実行されています。
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.
ベースプロトコルの実装には、参加者のアイデンティティと関連する対称シークレットキーのオペレーター構成をサポートする必要があります。
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.
識別フィールドと秘密のフィールドの形式は、読みやすい文字列に制限されていません。より単純な引用文字列構成に加えて、実装は任意のバイトストリームの構成を可能にする必要があります。
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。「Mundane Name」<user@node.site>
There is no requirement that the domain name match any of the particular IP addresses in use by the parties.
ドメイン名が当事者が使用している特定のIPアドレスのいずれかと一致するという要件はありません。
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.
Nota Bene：これらの例で使用されているパスワードは、少なくとも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"
アイデンティティローカル「Tiny VPN 1995 11月 "" Abracadabra "Identity Remote" Tiny VPN 1995 11月 "" Abracadabra "
When the Initiator sends its Identity_Request, the SPI Owner
イニシエーターがIDINTION_REQUESTを送信すると、SPI所有者
Identification field is "Tiny VPN 1995 November" and the SPI Owner secret-key is "abracadabra".
識別フィールドは「Tiny VPN 1995 11月」であり、SPI所有者のSecret-Keyは「Abracadabra」です。
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がID_Responseを送信すると、SPI所有者の識別フィールドは「Tiny VPN 1995 11月」であり、SPI所有者のSecret-Keyは「Abracadabra」です。SPIユーザーの識別は「Tiny VPN 1995 11月」（リクエストから取得）であり、SPIユーザーSecret-Keyは「Abracadabra」です。
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セッションキーの計算に影響します（「セッションキー計算」を参照）。
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.
より堅牢な構成アプローチは、信頼できるグループの参加者に配布される各当事者に別のIDと秘密を使用できます。これは、認証されたファイアウォールトラバーサルに適している場合があります。
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"
ID local "199511@router.site" "faldarah" identity remote "happy_wander@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.0/8トンネル10.0.0.1セキュア10.0.0.1 Authenticateのみのアイデンティティローカル「happy_wanderer@router.site」「「ファルダハハハハハハ」
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_wander@router.site」であり、SPI所有者のSecret-Keyは「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".
ファイアウォールレスポンダーがID_Responseを送信すると、SPI所有者の識別フィールドは「199511@router.site」であり、SPI所有者のSecret-Keyは「Faldarah」です。SPIユーザー識別フィールドは「happy_wander@router.site」（リクエストから取られた）であり、SPIユーザーSecret-Keyは「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」と自分自身を識別するかもしれません。
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:
1つの管理者が設定します。
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"
アイデンティティローカル「Apple」「All for one "ID local" local "apple-baker" "Apple to Baker" "" Baker "Remote" Remote "" Ane for All "Identity Remote" Baker-Apple "" Baker to Apple "
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"
アイデンティティローカル「ベイカー」「すべての」アイデンティティ「ベイカーアプリ」「ベイカー」「ベイカートゥアップル」「アップル」アイデンティティリモート「リモート」「アイデンティティ」リモートリモート「アップルベイカー」「アップルからベイカー」
When the Initiator sends its Identity_Request, the SPI Owner Identification field is "Apple" and the SPI Owner secret-key is "all for one".
イニシエーターがID_REQUESTを送信すると、SPIの所有者識別フィールドは「Apple」であり、SPI所有者のSecret-Keyは「All For One」です。
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
ResponderがID_Responseを送信すると、「Apple」に特別なペアリングが存在することを発見した場合（この例では、3番目のフィールドで示されています）、SPI所有者の識別フィールドは「Baker-Apple」であり、SPI所有者のSecret-Keyは「Bakerです」リンゴに」。SPIユーザーの識別は「Apple」（リクエストから取得）、およびSPIユーザーです
secret-key is "all for one".
Secret-Keyは「All For One」です。
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.
Exchange Timeout（ETO）デフォルト：30秒。最小：再送信 * irto。
Exchange LifeTime (ELT) Default: 30 minutes. Minimum: 2 * ETO.
Exchange Lifetime（ELT）デフォルト：30分。最小：2 * eto。
SPI LifeTime (SPILT) Default: 5 minutes. Minimum: 3 * ETO.
SPI Lifetime（こぼれた）デフォルト：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.
さらに、各当事者は、特定のIDの所有者に付与されるアクセス（ある場合）を決定するローカルポリシーを構成します。たとえば、当事者は匿名の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（1994年12月から1995年3月）と呼ばれるPhyurisの最初の仕様は、設計要件の短いリストとPhil Karnによる簡単な実験コードに基づいています。事前に指定されたグループパラメーターの単一のバイトインデックスを備えた1つのモジュラー指数フォームのみが使用されました。変換属性は、公共価値交換中に選択されました。当事者のプライバシーは、標準の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つのバイト（およびスキームと改名）に拡張され、変数パラメーターを運ぶために再び拡張されました。変換属性は、オプションのパラメーターを付与するために可変長さにされました。他のすべての可能なパラメーターが交渉可能になりました。一部の参加者は、UDPソケットのモードを切り替えて、一部のメッセージのみに標準のESP変換を使用することができず、パーティープライバシーはプロトコルに統合されました。メッセージヘッダーは再編成され、変換属性の選択は識別交換まで遅れました。追加の更新メッセージフェーズが追加されました。
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.
バージョン2（1995年7月から1995年12月）の仕様の安定性は、1995年11月に、ほとんどのパラメーターを後の議論のために個別のドキュメントに移動し、基本仕様にいくつかの必須機能のみを残すことにより達成されました。1か月以内に、複数の相互運用可能な実装が作成されました。
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（1996年4月から1997年6月）は、半ダースのプラットフォームでの長期にわたる仕様の安定性と複数の実装を享受しました。
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
バージョン4（1997年7月以降）これらの他の努力とのインターフェースの互換性の類似性を維持しようとします。わずかな変更があります
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.
変換パディング形式とキー生成で指定されています。スキームごとに複数の値が許可されており、将来の拡張機能の選択肢が大きくなります。この機会は、パーティーのプライバシーを基本ドキュメントに戻し、自動化された更新とエラーの回復に小さなセマンティックな変更を加えることができます。すべての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).
Phil Karnは、主にプロトコルフェーズ、特に「Cookie」防御防御の設計を担当し、最初のテストの実装を開発し、デザインの根拠のテキストの多くを提供しました（現在は別のドキュメントに削除されました）。
William Simpson was responsible for the packet formats and attributes, additional message types, editing and formatting. All such mistakes are his responsibility.
William Simpsonは、パケット形式と属性、追加のメッセージタイプ、編集とフォーマットを担当しました。そのような間違いはすべて彼の責任です。
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.
Angelos 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).
Paul C van Oorschotは、認証のみのアイデンティティ検証を提供するために、公共指数と共有秘密の両方に署名することを提案しました。また、彼はModuli、ジェネレーター、および指数選択に関するテキストを提供しました（現在は別のドキュメントに削除されました）。
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]のBart PreneelとPaul C van Oorschotは、認証のためにハッシュするときにデータとトレーリングキーの間のパディングを推奨しました。
Niels Provos developed another independent implementation (circa May 1997), ported to AIX, Linux, OpenBSD, and Solaris. Also, he made
Niels Provosは、AIX、Linux、OpenBSD、およびSolarisに移植された別の独立した実装（1997年5月頃）を開発しました。また、彼は作った
suggestions regarding automated update, and listing multiple moduli per scheme.
自動更新に関する提案、およびスキームごとの複数のモジュリのリスト。
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).
Bill Sommerfeldは、セッションキー生成に認証対称シークレットキーを含めることを提案し、連続した交換でCookie値を使用して、双方向のユーザー指向のキーイングを提供します（現在は別のドキュメントに削除されています）。
Oliver Spatscheck developed the second independent implementation (circa December 1995) for the Xkernel.
Oliver Spatscheckは、Xkernelの2番目の独立した実装（1995年12月頃）を開発しました。
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.
ランドール・アトキンソン、スティーブン・ベロヴィン、ワタル・ハマダ、ジェームズ・ヒューズ、ブライアン・ラマッチア、シェリル・マドソン、ルイス・マッカーシー、ペリー・メッツガー、ボブ・クイン、ロン・リベスト、リッチ・シュローペル、およびノーマン・シュルマンは、この文書の以前のバージョンの有用な批評を提供しました。
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.
[BGMW93] E. Brickell、D。Gordon、K。McCurley、およびD. Wilson、「事前計算による高速指数（拡張要約）」、暗号化の進歩 - EuroCrypt '92、コンピューターサイエンス658（1993）の講義ノート、Springer-Verlag、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.
また、米国特許＃5,299,262、E.F。ブリッケル、D.M。ゴードン、K.S。McCurley、「暗号化システムにおける指数化の方法」、1994年3月29日。
[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] Diffie、W。、およびHellman、H.E。、「暗号化の新しい方向」、IEEE情報に関するトランザクション、V IT-22 N 6 pp 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] Whitfield Diffie、Paul C Van Oorshot、およびMichael J Wiener、「認証と認証されたキー交換」、デザイン、コード、暗号化、v 2 pp 107-125、Kluwer Academic Publishers、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
[Firefly]「Phyuris」はFireflyのラテン名です。「ホタル」は、STU-III安全な電話の米国国家安全保障局の（分類）主要な交換プロトコルの名前です。情報に基づいた憶測があります
it that Firefly is based on very similar design principles.
Fireflyは非常に類似した設計原則に基づいていることです。
[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] Lim、C.H.、Lee、P.J。、「事前計算によるより柔軟な指数」、暗号学の進歩 - Crypto '94、Computer Science 839（1994）、Springer-Verlag、Pages 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.
[PO96] Bart Preneel、およびPaul C van Oorshot、「2つのMACアルゴリズムのセキュリティについて」、暗号化の進歩 - EuroCrypt '96、コンピューターサイエンス1070（1996年5月）、Springer-Verlag、19-32ページの講義ノート。
[RFC-768] Postel, J., "User Datagram Protocol", STD 6, USC/Information Sciences Institute, August 1980.
[RFC-768] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、USC/Information Sciences Institute、1980年8月。
[RFC-791] Postel, J., "Internet Protocol", STD 5, USC/Information Sciences Institute, September 1981.
[RFC-791] Postel、J。、「インターネットプロトコル」、STD 5、USC/Information Sciences Institute、1981年9月。
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", MIT Laboratory for Computer Science, April 1992.
[RFC-1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、MIT Computer Science for Computer Science、1992年4月。
[RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, USC/Information Sciences Institute, October 1994.
[RFC-1700] Reynolds、J。、およびPostel、J。、「割り当てられた番号」、STD 2、USC/Information Sciences Institute、1994年10月。
[RFC-1812] Baker, F., Editor, "Requirements for IP Version 4 Routers", Cisco Systems, June 1995.
[RFC-1812] Baker、F.、編集者、「IPバージョン4ルーターの要件」、Cisco Systems、1995年6月。
[RFC-1828] Metzger, P., Simpson, W., "IP Authentication using Keyed MD5", July 1995.
[RFC-1828] Metzger、P.、Simpson、W。、「Keyed MD5を使用したIP認証」、1995年7月。
[RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC Transform", July 1995.
[RFC-1829] Karn、P.、Metzger、P.、Simpson、W。、「ESP Des-CBC Transform」、1995年7月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, Harvard University, March 1997.
[RFC-2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、ハーバード大学、1997年3月。
[RFC-2521] Karn, P., and Simpson, W., "ICMP Security Failures Messages", March 1999.
[RFC-2521] Karn、P。、およびSimpson、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
[Rooij94] P. de Rooij、「事前計算とベクター添加チェーンを使用した効率的な指数化」、暗号学の進歩 - EuroCrypt '94、コンピューターの講義ノート
Science, Springer-Verlag, pages 403-415.
Science、Springer-Verlag、403-415ページ。
[Schneier95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7.
[Schneier95] Schneier、B。、「Applied Cryptography Second Edition」、John Wiley＆Sons、New York、NY、1995。ISBN0-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
Phil Karn Qualcomm、Inc。6455 Lusk Blvd.カリフォルニア州サンディエゴ92121-2779
karn@qualcomm.com karn@unix.ka9q.ampr.org (preferred)
karn@qualcomm.com karn@unix.ka9q.ampr.org（優先）
William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071
ウィリアム・アレン・シンプソン・デイドレーマー・コンピューター・システムコンサルティングサービス1384フォンテーヌ・マディソン・ハイツ、ミシガン州48071
wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred)
wsimpson@umich.edu wsimpson@greendragon.com（優先）
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
本書に含まれるこの文書と情報は、「現状のまま」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、本書の情報の使用が保証を含む（ただし、これらに限定されない）すべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害しません。