Network Working Group P. Karn
Request for Comments: 2522 Qualcomm
Category: Experimental W. Simpson
DayDreamer
March 1999
Network Working Group P. Karn
Request for Comments: 2522 Qualcomm
Category: Experimental W. Simpson
DayDreamer
March 1999
Photuris: Session-Key Management Protocol
会话密钥管理协议
Status of this Memo
本备忘录的状况
This document defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
本文档为互联网社区定义了一个实验协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有（C）Philip Karn和William Allen Simpson（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
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
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
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
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. 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
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
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
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
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
9. Basic Exchange-Schemes ................................ 54
10. Basic Key-Generation-Function ......................... 55
10.1 MD5 Hash ........................................ 55
10. Basic Key-Generation-Function ......................... 55
10.1 MD5 Hash ........................................ 55
11. Basic Privacy-Method .................................. 55
11.1 Simple Masking .................................. 55
11. Basic Privacy-Method .................................. 55
11.1 Simple Masking .................................. 55
12. Basic Validity-Method ................................. 55
12.1 MD5-IPMAC Check ................................. 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. 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
13.4.2 Authentication .................................. 59
13.5 Organizational .................................. 60
APPENDICES ................................................... 61
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
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
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
OPERATIONAL CONSIDERATIONS ................................... 70
SECURITY CONSIDERATIONS ...................................... 70
SECURITY CONSIDERATIONS ...................................... 70
HISTORY ...................................................... 71
HISTORY ...................................................... 71
ACKNOWLEDGEMENTS ............................................. 72
ACKNOWLEDGEMENTS ............................................. 72
REFERENCES ................................................... 73
REFERENCES ................................................... 73
CONTACTS ..................................................... 75
CONTACTS ..................................................... 75
COPYRIGHT .................................................... 76
COPYRIGHT .................................................... 76
Photuris [Firefly] establishes short-lived session-keys between two parties, without passing the session-keys across the Internet. These session-keys directly replace the long-lived secret-keys (such as passwords and passphrases) that have been historically configured for security purposes.
Photuris[Firefly]在双方之间建立短期会话密钥，而不通过Internet传递会话密钥。这些会话密钥直接替换长期使用的密钥（如密码和密码短语），这些密钥在历史上是出于安全目的配置的。
The basic Photuris protocol utilizes these existing previously configured secret-keys for identification of the parties. This is intended to speed deployment and reduce administrative configuration changes.
基本Photuris协议利用这些现有的先前配置的密钥来识别各方。这旨在加快部署并减少管理配置更改。
This document is primarily intended for implementing the Photuris protocol. It does not detail service and application interface definitions, although it does mention some basic policy areas required for the proper implementation and operation of the protocol mechanisms.
本文件主要用于实施Photuris协议。它没有详细说明服务和应用程序接口定义，尽管它提到了正确实现和操作协议机制所需的一些基本策略领域。
Since the basic Photuris protocol is extensible, new data types and protocol behaviour should be expected. The implementor is especially cautioned not to depend on values that appear in examples to be current or complete, since their purpose is primarily pedagogical.
由于基本的Photuris协议是可扩展的，因此应预期新的数据类型和协议行为。特别提醒实施者不要依赖示例中出现的当前或完整的值，因为它们的目的主要是教学。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC-2119].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”应按照[RFC-2119]中所述进行解释。
byte An 8-bit quantity; also known as "octet" in standardese.
字节是8位的数量；在标准语中也称为“八位组”。
exchange-value The publically distributable value used to calculate a shared-secret. As used in this document, refers to a Diffie-Hellman exchange, not the public part of a public/private key-pair.
交换值用于计算共享机密的可公开分发的值。本文档中使用的是Diffie-Hellman交换，而不是公钥/私钥对的公共部分。
private-key A value that is kept secret, and is part of an asymmetric public/private key-pair.
私钥是保密的值，是非对称公钥/私钥对的一部分。
public-key A publically distributable value that is part of an asymmetric public/private key-pair.
公钥作为非对称公钥/私钥对的一部分的可公开分发的值。
secret-key A symmetric key that is not publically distributable. As used in this document, this is distinguished from an asymmetric public/private
秘密密钥不可公开分发的对称密钥。正如在本文件中所使用的，这与不对称的公共/私有模式不同
key-pair. An example is a user password.
钥匙对。例如，用户密码。
Security Association (SA) A collection of parameters describing the security relationship between two nodes. These parameters include the identities of the parties, the transform (including algorithm and algorithm mode), the key(s) (such as a session-key, secret-key, or appropriate public/private key-pair), and possibly other information such as sensitivity labelling.
安全关联（SA）描述两个节点之间安全关系的参数集合。这些参数包括各方的身份、转换（包括算法和算法模式）、密钥（例如会话密钥、秘密密钥或适当的公钥/私钥对），以及可能的其他信息，例如敏感度标签。
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）表示在安全关联下使用的一组特定单向属性的数字，如转换和会话密钥。该数字相对于IP目的地，即SPI所有者，并且每个IP（下一个标头）协议都是唯一的。也就是说，多个协议可以使用相同的值来同时指示不同的安全关联参数。
session-key A key that is independently derived from a shared-secret by the parties, and used for keying one direction of traffic. This key is changed frequently.
会话密钥一种密钥，由各方独立地从共享密钥中派生，用于为一个方向的通信量设置密钥。这把钥匙经常更换。
shared-secret As used in this document, the calculated result of the Photuris exchange.
本文件中使用的共享机密，即Photuris交换的计算结果。
SPI Owner The party that corresponds to the IP Destination; the intended recipient of a protected datagram.
SPI所有者对应于IP目的地的一方；受保护数据报的预期接收者。
SPI User The party that corresponds to the IP Source; the sender of a protected datagram.
SPI用户与IP源相对应的一方；受保护数据报的发送方。
transform A cryptographic manipulation of a particular set of data. As used in this document, refers to certain well-specified methods (defined elsewhere). For example, AH-MD5 [RFC-1828] transforms an IP datagram into a cryptographic hash, and ESP-DES-CBC [RFC-1829] transforms plaintext to ciphertext and back again.
转换对特定数据集的加密操作。如本文件所用，指某些明确规定的方法（在别处定义）。例如，AH-MD5[RFC-1828]将IP数据报转换为加密散列，ESP-DES-CBC[RFC-1829]将明文转换为密文，然后再转换回来。
Many of these terms are hierarchically related:
这些术语中有许多是层次相关的：
Security Association (bi-directional)
- one or more lists of Security Parameters (uni-directional)
-- one or more Attributes
--- may have a key
--- may indicate a transform
Security Association (bi-directional)
- one or more lists of Security Parameters (uni-directional)
-- one or more Attributes
--- may have a key
--- may indicate a transform
Implementors will find details of cryptographic hashing (such as MD5), encryption algorithms and modes (such as DES), digital signatures (such as DSS), and other algorithms in [Schneier95].
实现者将在[Schneier95]中找到加密哈希（如MD5）、加密算法和模式（如DES）、数字签名（如DSS）和其他算法的详细信息。
The Photuris protocol consists of several simple phases:
Photuris协议由几个简单阶段组成：
1. A "Cookie" Exchange guards against simple flooding attacks sent with bogus IP Sources or UDP Ports. Each party passes a "cookie" to the other.
1. “Cookie”交换可以防止使用伪造的IP源或UDP端口发送的简单洪泛攻击。每一方都将一块“饼干”传递给另一方。
In return, a list of supported Exchange-Schemes are offered by the Responder for calculating a shared-secret.
作为回报，响应者将提供一个支持的交换方案列表，用于计算共享密钥。
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.
使用基于共享秘密的消息隐私密钥屏蔽此交换，以保护参与方隐私。这将保护各方的身份，隐藏安全参数属性值，并提高exchange协议和安全转换的安全性。
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.
下图总结了消息类型的顺序及其用途。在使用任何安全关联之前，必须完整执行前三个阶段（cookie、交换和标识）。
Initiator Responder
========= =========
Cookie_Request ->
<- Cookie_Response
offer schemes
Value_Request ->
pick scheme
offer value
offer attributes
<- Value_Response
offer value
offer attributes
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
标识请求->使SPI选择SPI属性标识自我验证使隐私密钥屏蔽/加密消息<-标识响应使SPI选择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
SPI User SPI Owner
======== =========
SPI_Needed ->
list SPI attribute(s)
make validity key
authenticate
make privacy key(s)
mask/encrypt message
<- SPI_Update
make SPI
pick SPI attribute(s)
make SPI session-key(s)
make validity key
authenticate
make privacy key(s)
mask/encrypt message
Either party may initiate an exchange at any time. For example, the Initiator need not be a "caller" in a telephony link.
任何一方均可在任何时候发起交易。例如，发起方不必是电话链路中的“呼叫方”。
The Initiator is responsible for recovering from all message losses by retransmission.
发起方负责通过重新传输从所有消息丢失中恢复。
A Photuris exchange between two parties results in a pair of SPI values (one in each direction). Each SPI is used in creating separate session-key(s) in each direction.
双方之间的光交换产生一对SPI值（每个方向一个）。每个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交换，或一方发起多个Photuris交换时，发起方Cookie（和UDP端口）会将交换分开。这会导致每个目的地有多个初始SPI。
To create multiple SPIs with different parameters, the parties may also send SPI_Updates.
要创建具有不同参数的多个SPI，各方还可以发送SPI_更新。
There is no requirement that all such outstanding SPIs be used. The SPI User (sender) selects an appropriate SPI for each datagram transmission.
不要求使用所有此类优秀的SPI。SPI用户（发送方）为每个数据报传输选择适当的SPI。
Implementation Notes:
实施说明：
The method used for SPI assignment is implementation dependent. The only requirement is that the SPI be unique for the IP Destination and IP (Next Header) Protocol.
用于SPI分配的方法取决于实现。唯一的要求是SPI对于IP目的地和IP（下一个报头）协议是唯一的。
However, selection of a cryptographically random SPI value can help prevent attacks that depend on a predicatable sequence of values. The implementor MUST NOT expect SPI values to have a particular order or range.
但是，选择加密随机SPI值有助于防止依赖于可预测值序列的攻击。实现者不能期望SPI值具有特定的顺序或范围。
The Photuris exchange results in two kinds of state, each with separate LifeTimes.
光交换产生两种状态，每种状态都有各自的寿命。
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交换本身关联的少量状态的交换生存期。可以将此状态视为Internet节点之间的状态。
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.
当交换值过期（或被较新的值替换）时，任何未过期的派生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分钟到一天（默认为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交换期间，交换超时（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的两倍。
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交换之间的同步，实现应该在计算新交换值所需的两倍秒范围内随机改变每个交换生存期。例如，当响应者使用30分钟的基本ELT，并用10秒计算新的交换值时，方程式可能是（以毫秒为单位）：
1790000 + urandom(20000)
1790000+铀（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.
交换方案、交换值和由此产生的共享秘密可以在交换生存期内缓存在短期存储器中。当同一方之间发生重复的Photuris交换，并且发现交换值没有变化时，可以使用先前计算的共享密钥快速生成新的会话密钥。
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寿命（SPILT）通常与链路速度有关（通常为2到30分钟），但不得小于ETO的三倍。
The SPI can also be deleted by the SPI Owner using the SPI_Update. Once the SPI has expired or been deleted, the parties cease using the SPI.
SPI所有者也可以使用SPI_更新删除SPI。一旦SPI过期或被删除，双方将停止使用SPI。
To prevent synchronization between multiple Photuris exchanges, the implementation SHOULD randomly vary each SPI LifeTime. For example, when the Responder uses a base SPILT of 5 minutes, and 30 seconds for the ETO, the equation might be (in milliseconds):
为了防止多个Photuris交换之间的同步，实现应该随机改变每个SPI生存期。例如，当响应者使用5分钟的基数溢出，ETO使用30秒时，等式可能是（以毫秒为单位）：
285000 + urandom(30000)
285000+铀（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，但关联的exchange状态尚未清除时，实现可能会接受该SPI。允许的时间长度高度依赖于时钟漂移和可变数据包往返时间，因此依赖于实现。
The security of Photuris critically depends on the quality of the secret random numbers generated by each party. A poor random number generator at either party will compromise the shared-secret produced by the algorithm.
Photuris的安全性关键取决于各方生成的秘密随机数的质量。任何一方的不良随机数生成器都会破坏算法产生的共享秘密。
Generating cryptographic quality random numbers on a general purpose computer without hardware assistance is a very tricky problem. In general, this requires using a cryptographic hashing function to "distill" the entropy from a large number of semi-random external events, such as the timing of key strokes. An excellent discussion can be found in [RFC-1750].
在没有硬件帮助的情况下，在通用计算机上生成加密质量的随机数是一个非常棘手的问题。一般来说，这需要使用加密散列函数从大量半随机外部事件（如按键时间）中“提取”熵。在[RFC-1750]中可以找到一个很好的讨论。
The Initiator begins a Photuris exchange under several circumstances:
启动器在以下几种情况下开始Photuris交换：
- The Initiator has a datagram that it wishes to send with confidentiality, and has no current Photuris exchange state with the IP Destination. This datagram is discarded, and a Cookie_Request is sent instead.
- 发起者有一个数据报，它希望以保密的方式发送，并且与IP目标没有当前的Photuris交换状态。该数据报将被丢弃，并发送Cookie_请求。
- 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.
- 启动器已收到ICMP消息[RFC-2521]安全故障：错误SPI（类型40，代码0），该消息与ICMP源的当前Photuris exchange状态相匹配。
- The Initiator has received the ICMP message [RFC-2521] Security Failures: Need Authentication (Type 40, Code 4), and has no current Photuris exchange state with the ICMP Source.
- 启动器已收到ICMP消息[RFC-2521]安全故障：需要身份验证（类型40，代码4），并且与ICMP源没有当前的Photuris交换状态。
- The Initiator has received the ICMP message [RFC-2521] Security Failures: Need Authorization (Type 40, Code 5), that matches current Photuris exchange state with the ICMP Source.
- 发起方已收到ICMP消息[RFC-2521]安全故障：需要授权（类型40，代码5），该消息将当前Photuris exchange状态与ICMP源匹配。
When the event is an ICMP message, special care MUST be taken that the ICMP message actually includes information that matches a previously sent IP datagram. Otherwise, this could provide an opportunity for a clogging attack, by stimulating a new Photuris Exchange.
当事件是ICMP消息时，必须特别注意ICMP消息实际包含与先前发送的IP数据报匹配的信息。否则，通过刺激新的Photuris交换，这可能为阻塞攻击提供机会。
All Photuris messages use the User Datagram Protocol header [RFC-768]. The Initiator sends to UDP Destination Port 468.
所有Photuris消息都使用用户数据报协议头[RFC-768]。启动器发送到UDP目标端口468。
When replying to the Initiator, the Responder swaps the IP Source and Destination, and the UDP Source and Destination Ports.
当响应发起方时，响应方交换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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message |
+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes.
启动器Cookie 16个字节。
Responder-Cookie 16 bytes.
响应器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\u请求1 Cookie\u响应2值\u请求3值\u响应4身份\u请求5机密\u响应（可选）6机密\u请求（可选）7身份\u响应8 SPI\u需要9 SPI\u更新10坏的\u Cookie 11资源限制12验证\u失败13消息\u拒绝
Further details and differences are elaborated in the individual messages.
进一步的细节和差异将在单独的消息中详细说明。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
当大小为零时，不存在值字段；没有有效位。这意味着“缺失”或“空”。不应将其与值0混淆，后者包括有效位数量的指示。
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到65279个有效位（1到8160字节）。
When the most significant byte is 255 (0xff), the field is 4 bytes. The remaining 3 bytes are added to 65,280 to indicate the size of the Value field, which is limited to 16,776,959 significant bits (in
当最高有效字节为255（0xff）时，字段为4个字节。剩余的3个字节添加到65280以指示值字段的大小，该字段限制为16776959个有效位（在
2,097,120 bytes).
2097120字节）。
When the most significant 2 bytes are 65,535 (0xffff), the field is 8 bytes. The remaining 6 bytes are added to 16,776,960 to indicate the size of the Value field.
当最高有效2字节为65535（0xffff）时，字段为8字节。剩余的6个字节添加到16776960以指示值字段的大小。
Value 0 or more bytes. Always transmitted most significant byte first.
值0或更多字节。始终先传输最高有效字节。
The bits used are right justified within byte boundaries; that is, any unused bits are in the most significant byte. When there are no unused bits, or unused bits are zero filled, the value is assumed to be an unsigned positive integer.
使用的位在字节边界内右对齐；也就是说，任何未使用的位都位于最高有效字节中。如果没有未使用的位，或者未使用的位为零填充，则假定该值为无符号正整数。
When the leading unused bits are ones filled, the number is assumed to be a two's-complement negative integer. A negative integer will always have at least one unused leading sign bit in the most significant byte.
当前导未使用的位是已填充的位时，该数字被假定为一个二补负整数。负整数的最高有效字节中始终至少有一个未使用的前导符号位。
Shortened forms SHOULD NOT be used when the Value includes a number of leading zero significant bits. The Size SHOULD indicate the correct number of significant bits.
当值包含多个前导零有效位时，不应使用缩写形式。大小应指示有效位的正确数量。
Implementation Notes:
实施说明：
Negative integers are not required to be supported, but are included for completeness.
不需要支持负整数，但为了完整性，需要包含负整数。
No more than 65,279 significant bits are required to be supported. Other ranges are vastly too long for these UDP messages, but are included for completeness.
需要支持的有效位不超过65279位。其他范围对于这些UDP消息来说太长了，但为了完整性而包括在内。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scheme | Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scheme | Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Scheme 2 bytes. A unique value indicating the Exchange-Scheme. See the "Basic Exchange-Schemes" for details.
方案2字节。指示交换方案的唯一值。详见“基本兑换方案”。
Size 2 bytes, ranging from 0 to 65,279. See "Variable Precision Integer".
大小为2字节，范围从0到65279。请参阅“可变精度整数”。
Value 0 or more bytes. See "Variable Precision Integer".
值0或更多字节。请参阅“可变精度整数”。
The Size MUST NOT be assumed to be constant for a particular Scheme. Multiple kinds of the same Scheme with varying Sizes MAY be present in any list of schemes.
对于特定方案，不得假定大小为常数。任何方案列表中都可能存在多种不同大小的相同方案。
However, only one of each Scheme and Size combination will be present in any list of schemes.
但是，在任何方案列表中，每个方案和尺寸组合中只有一个。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length | Value(s) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | 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
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在同一方之间的每个新Cookie\u请求中必须不同。有关详细信息，请参阅“Cookie生成”。
- 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节点之间的任何先前交换（该方是发起方）尚未过期，则此响应程序Cookie将设置为最新的响应程序Cookie，并且此计数器将设置为相应的计数器。
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_响应中接收到的值相同，响应器Cookie保持不变，并生成新的启动器Cookie。
- 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_请求是对该方是响应方的先前交换的消息的响应，则此响应方Cookie将设置为先前发起方Cookie，并且此计数器将设置为零。
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，从前一个启动器接收到一条错误的Cookie消息。响应程序Cookie将替换为启动器Cookie，并生成新的启动器Cookie。这提供了簿记来检测虚假的坏消息。
Also, can be used for bi-directional User, Transport, and Process oriented keying. Such mechanisms are outside the scope of this document.
此外，还可以用于双向用户、传输和面向进程的键控。这些机制不在本文件的范围之内。
- Otherwise, this Responder-Cookie and Counter are both set to zero.
- 否则，此响应器Cookie和计数器都设置为零。
By default, the Initiator operates in the same manner as when all of its previous exchange state has expired. The Responder will send a Resource_Limit when its own exchange state has not expired.
默认情况下，启动器的操作方式与它以前的所有exchange状态都已过期时相同。当响应程序自己的exchange状态尚未过期时，它将发送一个资源\u限制。
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_响应到达，则针对剩余的重新传输次数重新传输相同的Cookie_请求。启动器Cookie值在每次此类重新传输到同一IP目标和UDP端口时必须相同。
When Retransmissions have been exceeded, if a Resource_Limit message has been received during the exchange, the Initiator SHOULD begin the Photuris exchange again by sending a new Cookie_Request with updated values.
当超过重新传输时，如果在交换期间收到资源限制消息，则发起方应通过发送具有更新值的新Cookie_请求再次开始Photuris交换。
On receipt of a Cookie_Request, the Responder determines whether there are sufficient resources to begin another Photuris exchange.
收到Cookie_请求后，响应者确定是否有足够的资源开始另一次Photuris交换。
- When too many SPI values are already in use for this particular peer, or too many concurrent exchanges are in progress, or some other resource limit is reached, a Resource_Limit message is sent.
- 当太多SPI值已用于此特定对等方，或有太多并发交换正在进行，或达到某些其他资源限制时，将发送资源限制消息。
- 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.
- 当此特定对等方发起的任何以前的交换未超过交换超时，并且响应程序Cookie未指定这些以前的交换之一时，将发送一条资源限制消息。
Otherwise, the Responder returns a Cookie_Response.
否则，响应程序将返回Cookie\u响应。
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节点之间以前的任何交换尚未过期，则响应计数器将设置为最近的交换计数器加上一个（允许无序重新传输）。否则，响应计数器设置为请求计数器加一。
If (through rollover of the Counter) the new Counter value is zero (modulo 256), the value is set to one.
如果（通过计数器的滚动）新计数器值为零（模256），则该值设置为一。
If this new Counter value matches some previous exchange initiated by this particular peer that has not yet exceeded the Exchange TimeOut,
如果此新计数器值与此特定对等方之前发起的尚未超过交换超时的某个交换相匹配，
the Counter is incremented again, until a unique Counter value is reached.
计数器再次递增，直到达到唯一的计数器值。
Nota Bene: No more than 254 concurrent exchanges between the same two peers are supported.
注：同两个对等点之间支持的并发交换不超过254次。
The Responder generates a unique cookie. The Responder-Cookie value in each successive response SHOULD be different. See "Cookie Generation" for details.
响应程序生成一个唯一的cookie。每个后续响应中的响应器Cookie值应该不同。有关详细信息，请参阅“Cookie生成”。
The Exchange-Schemes available between the peers are listed in the Offered-Schemes.
提供的方案中列出了对等方之间可用的交换方案。
The Initiator validates the Initiator-Cookie, and the Offered-Schemes.
启动器验证启动器Cookie和提供的方案。
- When an invalid/expired Initiator-Cookie is detected, the message is silently discarded.
- 当检测到无效/过期的启动器Cookie时，该消息将被自动丢弃。
- 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长度不匹配，或者所有提供的方案明显有缺陷和/或不足以达到预期目的时，消息将被悄悄地丢弃；实施应记录发生的情况，并酌情通知操作员。
- 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的Cookie\u响应也会被静默丢弃，直到发送新的Cookie\u请求。
When the message is valid, an Exchange-Scheme is chosen from the list of Offered-Schemes.
当消息有效时，将从提供的方案列表中选择一个交换方案。
This Scheme-Choice may affect the next Photuris message sent. By default, the next Photuris message is a Value_Request.
此方案选择可能会影响发送的下一条Photuris消息。默认情况下，下一条Photuris消息是一个Value\u请求。
Implementation Notes:
实施说明：
Only the Initiator-Cookie is used to identify the exchange. The Counter and Responder-Cookie will both be different from the Cookie_Request.
只有启动器Cookie用于标识交换。计数器和响应器Cookie都将与Cookie\u请求不同。
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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.
启动器Cookie 16个字节。标识交换的随机值。该值不能为零。有关详细信息，请参阅“Cookie生成”。
Responder-Cookie 16 bytes. Identifies a specific previous exchange. Copied from a previous Cookie_Response.
响应器Cookie 16字节。标识以前的特定交换。从以前的Cookie\u响应复制。
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.
如果非零且计数器为零，则包含上一次交换的启动器Cookie。指定方被请求作为此交换中的响应方，以保留以前的方配对。
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.
当非零且计数器也非零时，包含上一次交换的响应者Cookie。指定方被请求作为此交换中的响应方，以保留以前的方配对。
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.
当为零时，响应器Cookie表示先前交换的发起方，或者未指定先前交换。
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指示前一次交换的响应者。此值设置为相应Cookie_响应或资源限制中的计数器。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Counter | Offered-Schemes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Counter | Offered-Schemes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Cookie_Request.
启动器Cookie 16个字节。从Cookie_请求复制。
Responder-Cookie 16 bytes. A randomized value that identifies the exchange. The value MUST NOT be zero. See "Cookie Generation" for details.
响应器Cookie 16字节。标识交换的随机值。该值不能为零。有关详细信息，请参阅“Cookie生成”。
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个或更多字节的方案。由响应程序支持的一个或多个交换方案的列表，按从高到低的顺序排列。详见“基本兑换方案”。
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. cookie生成和验证方法必须快速，以阻止旨在破坏CPU资源的攻击。
A recommended technique is to use a cryptographic hashing function (such as MD5).
推荐的技术是使用加密哈希函数（如MD5）。
An incoming cookie can be verified at any time by regenerating it locally from values contained in the incoming datagram and the local secret random value.
通过从传入数据报中包含的值和本地机密随机值本地重新生成传入cookie，可以随时对传入cookie进行验证。
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交换进行更改，并在此后按每个响应者进行内部缓存。这提供了改进的同步和防止重播攻击的保护。
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而不是secret值。传入的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.
建议通过机密值、IP源和目标地址以及UDP源和目标端口计算cookie。
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.
响应者Cookie应包括启动器Cookie。响应器Cookie必须包含计数器（在Cookie\u响应中返回）。这提供了改进的同步和防止重播攻击的保护。
It is recommended that the cookie be calculated over the secret value, the IP Source and Destination addresses, its own UDP Destination port, the Counter, the Initiator-Cookie, and the currently Offered-Schemes.
建议根据机密值、IP源和目标地址、其自己的UDP目标端口、计数器、启动器cookie和当前提供的方案计算cookie。
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_请求（稍后描述）时，响应者重新生成其cookie以进行验证。
Once the Value_Response is sent (also described later), both Initiator and Responder cookies are cached to identify the exchange.
发送值_响应后（稍后也将描述），启动器和响应程序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.
但是，在匹配现有Photuris交换机以确定适当的计数器时，不包括UDP源端口是很重要的。
The recommendation includes the Offered-Schemes to detect a dynamic change of scheme value between the Cookie_Response and
该建议包括所提供的方案，用于检测Cookie_响应和响应之间的方案值的动态变化
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.
可能需要一些机制来检测预先计算的响应者交换值在值\响应和标识\响应之间的动态变化。例如，更改secret值以使cookie无效，或者显式地将Photuris交换状态标记为过期。
Initiator Responder
========= =========
Value_Request ->
pick scheme
offer value
offer attributes
<- Value_Response
offer value
offer attributes
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_响应到达，则针对剩余的重新传输次数重新传输相同的Value_请求。
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.
当超过重新传输时，如果在交换过程中收到错误的Cookie或资源限制消息，则发起方应通过发送新的Cookie请求再次开始Photuris交换。
The Responder validates the Responder-Cookie, the Counter, the Scheme-Choice, the Exchange-Value, and the Offered-Attributes.
响应程序验证响应程序Cookie、计数器、方案选择、交换值和提供的属性。
- When an invalid/expired Responder-Cookie is detected, a Bad_Cookie message is sent.
- 当检测到无效/过期的响应程序Cookie时，将发送一条错误的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值已用于此特定对等方，或有太多并发交换正在进行，或达到某些其他资源限制时，将发送资源限制消息。
- 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长度不匹配时，消息将被自动丢弃；实施应记录发生的情况，并酌情通知操作员。
When the message is valid, the Responder sets its Exchange timer to the Exchange TimeOut, and returns a Value_Response.
当消息有效时，响应程序将其交换计时器设置为交换超时，并返回值\u 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.
响应程序保留传入值\u请求cookie对及其值\u响应的副本。如果收到重复的Value_请求，它只会重新发送其先前的Value_响应，而不采取进一步的操作。
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对、交换值和提供的属性。
- 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.
- 当交换值明显有缺陷，或者提供的可变长度属性与UDP长度不匹配时，消息将被静默丢弃；实施应记录发生的情况，并酌情通知操作员。
- 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的Value\u响应也会被静默丢弃，直到发送新的Cookie\u请求。
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_请求。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Counter | Scheme-Choice |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Exchange-Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator-Offered-Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Counter | Scheme-Choice |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Exchange-Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator-Offered-Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Initiator-Cookie 16 bytes. Copied from the Cookie_Response.
启动器Cookie 16个字节。从Cookie\u响应中复制。
Responder-Cookie 16 bytes. Copied from the Cookie_Response.
响应器Cookie 16字节。从Cookie\u响应中复制。
Message 2
信息2
Counter 1 byte. Copied from the Cookie_Response.
计数器1字节。从Cookie\u响应中复制。
Scheme-Choice 2 bytes. A value selected by the Initiator from the list of Offered-Schemes in the Cookie_Response.
方案选择2字节。启动器从Cookie_响应中提供的方案列表中选择的值。
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Exchange-Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder-Offered-Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Initiator-Cookie 16 bytes. Copied from the Value_Request.
启动器Cookie 16个字节。从值_请求复制。
Responder-Cookie 16 bytes. Copied from the Value_Request.
响应器Cookie 16字节。从值_请求复制。
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.
响应程序交换值变量精度整数。由响应者提供，用于计算双方之间的共享秘密。值格式由值请求中指定的当前方案选择指示。
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个或更多字节的属性。响应程序支持的安全参数属性列表。
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.
该列表由两个或三个部分组成：标识属性、身份验证属性和（可选）封装属性。在每个部分中，属性从最优先到最不优先排序。
The first section of the list includes methods of identification. An Identity-Choice is selected from this list.
清单的第一部分包括识别方法。将从此列表中选择一个标识选项。
The second section of the list begins with "AH-Attributes" (#1). It includes methods of authentication, and other operational types.
列表的第二部分以“AH属性”（#1）开头。它包括身份验证方法和其他操作类型。
The third section of the list begins with "ESP-Attributes" (#2). It includes methods of authentication, compression, encryption, and other operational types. When no Encapsulation-Attributes are offered, the "ESP-Attributes" attribute itself is omitted from the list.
列表的第三部分以“ESP属性”（2）开头。它包括身份验证、压缩、加密和其他操作类型的方法。当没有提供封装属性时，“ESP属性”属性本身将从列表中忽略。
Attribute-Choices are selected from the latter two sections of the list.
属性选项从列表的后两部分中选择。
Support is required for the "MD5-IPMAC" (#5) attribute for both "Symmetric Identification" and "Authentication" and they SHOULD be present in every Offered-Attributes list.
“对称标识”和“身份验证”都需要“MD5-IPMAC”（#5）属性的支持，并且它们应该出现在每个提供的属性列表中。
Implementation Notes:
实施说明：
For example,
例如
"MD5-IPMAC" (Symmetric Identification), "AH-Attributes", "MD5-IPMAC" (Authentication).
“MD5-IPMAC”（对称标识）、“AH属性”、“MD5-IPMAC”（身份验证）。
Since the offer is made by the prospective SPI User (sender), order of preference likely reflects the capabilities and engineering tradeoffs of a particular implementation.
由于报价是由潜在的SPI用户（发送方）提出的，所以偏好顺序可能反映了特定实现的功能和工程权衡。
However, the critical processing bottlenecks are frequently in the receiver. The SPI Owner (receiver) may express its needs by choosing a less preferable attribute.
然而，关键的处理瓶颈经常出现在接收器中。SPI所有者（接收者）可以通过选择不太可取的属性来表达其需求。
The order may also be affected by operational policy and requested services for an application. Such considerations are outside the scope of this document.
订单还可能受操作策略和应用程序请求的服务的影响。此类考虑不在本文件的范围内。
The list may be divided into additional sections. These sections will always follow the ESP-Attributes section, and are indistinguishable from unrecognized attributes.
该清单可分为其他部分。这些部分将始终遵循ESP属性部分，并且与未识别的属性无法区分。
The authentication, compression, encryption and identification mechanisms chosen, as well as the encapsulation modes (if any), need not be the same in both directions.
选择的身份验证、压缩、加密和标识机制以及封装模式（如果有）在两个方向上不必相同。
Initiator Responder
========= =========
Identity_Request ->
make SPI
pick SPI attribute(s)
identify self
authenticate
make privacy key(s)
mask/encrypt message
<- Identity_Response
make SPI
pick SPI attribute(s)
identify self
authenticate
make privacy key(s)
mask/encrypt message
Initiator Responder
========= =========
Identity_Request ->
make SPI
pick SPI attribute(s)
identify self
authenticate
make privacy key(s)
mask/encrypt message
<- Identity_Response
make SPI
pick SPI attribute(s)
identify self
authenticate
make privacy key(s)
mask/encrypt message
[make SPI session-keys in each direction]
[在每个方向制作SPI会话密钥]
The exchange of messages is ordered, although the formats and meanings of the messages are identical in each direction. The messages are easily distinguished by the parties themselves, by examining the Message and Identification fields.
消息交换是有序的，尽管消息的格式和含义在每个方向上都是相同的。通过检查消息和标识字段，各方可以轻松区分消息。
Implementation Notes:
实施说明：
The amount of time for the calculation may be dependent on the value of particular bits in secret values used in generating the shared-secret or identity verification. To prevent analysis of these secret bits by recording the time for calculation, sending of the Identity_Messages SHOULD be delayed until the time expected for the longest calculation. This will be different for different processor speeds, different algorithms, and different length variables. Therefore, the method for estimating time is implementation dependent.
计算的时间量可能取决于在生成共享秘密或身份验证时使用的秘密值中的特定比特的值。为了通过记录计算时间来防止对这些秘密位进行分析，应将Identity_消息的发送延迟到最长计算的预期时间。对于不同的处理器速度、不同的算法和不同的长度变量，这将是不同的。因此，估计时间的方法取决于实现。
Any authenticated and/or encrypted user datagrams received before the completion of identity verification can be placed on a queue pending completion of this step. If verification succeeds, the queue is processed as though the datagrams had arrived subsequent to the verification. If verification fails, the queue is discarded.
在完成身份验证之前收到的任何经过身份验证和/或加密的用户数据报都可以放置在队列中，等待完成此步骤。如果验证成功，队列将被处理，就像数据报在验证之后到达一样。如果验证失败，则丢弃队列。
The Initiator chooses an appropriate Identification, the SPI and SPILT, a set of Attributes for the SPI, calculates the Verification, and masks the message using the Privacy-Method indicated by the current Scheme-Choice.
发起者选择适当的标识，即SPI和SPILT，SPI的一组属性，计算验证，并使用当前方案选择指示的隐私方法屏蔽消息。
The Initiator also starts a retransmission timer. If no valid Identity_Response arrives within the time limit, its previous Identity_Request is retransmitted for the remaining number of Retransmissions.
发起方还启动重传计时器。如果在时间限制内没有有效的Identity_响应到达，则其先前的Identity_请求将在剩余的重新传输次数内重新传输。
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.
超过重新传输时，如果在交换过程中收到坏的Cookie消息，则发起方应通过发送新的Cookie请求再次开始Photuris交换。
The Responder validates the pair of Cookies, the Padding, the Identification, the Verification, and the Attribute-Choices.
响应者验证cookie对、填充、标识、验证和属性选择。
- When an invalid/expired cookie is detected, a Bad_Cookie message is sent.
- 当检测到无效/过期的cookie时，将发送一条坏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.
- 当检测到无效标识或消息验证失败时，将发送验证失败消息。
- Whenever such a problem is detected, the Security Association is not established; the implementation SHOULD log the occurance, and notify an operator as appropriate.
- 无论何时检测到此类问题，都不会建立安全关联；实施应记录发生的情况，并酌情通知操作员。
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.
当消息有效时，响应程序将其交换计时器设置为交换生存期（如果之前的交换尚未执行此操作）。当共享秘密的并行计算完成时，响应者返回一个Identity\u响应。
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.
响应程序保留传入标识请求值及其标识响应的副本。如果收到重复的Identity_请求，它只会重新发送其先前的Identity_响应，而不采取进一步的操作。
The Responder chooses an appropriate Identification, the SPI and SPILT, a set of Attributes for the SPI, calculates the Verification, and masks the message using the Privacy-Method indicated by the current Scheme-Choice.
响应者选择适当的标识，即SPI和SPILT，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.
- 当检测到无效标识或消息验证失败时，将发送验证失败消息。
- Whenever such a problem is detected, the Security Association is not established; the implementation SHOULD log the occurance, and notify an operator as appropriate.
- 无论何时检测到此类问题，都不会建立安全关联；实施应记录发生的情况，并酌情通知操作员。
- 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的Identity_响应也会被静默丢弃，直到发送新的Cookie_请求。
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生存期（如果之前的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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | LifeTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security-Parameters-Index |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Identity-Choice | |
+ + + + + + + + + + + + + + + + + +
| |
~ Identification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Verification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Choices ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Value_Request.
启动器Cookie 16个字节。从值_请求复制。
Responder-Cookie 16 bytes. Copied from the Value_Request.
响应器Cookie 16字节。从值_请求复制。
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.
安全参数索引（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.
标识选择2个或更多字节。从对等方发送的提供属性列表中选择标识属性，并用于计算验证。
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.
标识变量精度整数，或标识选项指示的替代格式。有关详细信息，请参见“基本属性”。
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".
验证变量精度整数，或标识选项指示的替代格式。“身份验证”中描述了该值的计算。
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.
属性选择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字节的边界，从消息开始测量。pad字节数是随机选择的。
In addition, when a Privacy-Method indicated by the
此外，当
current Scheme-Choice requires the plaintext to be a multiple of some number of bytes (the block size of a block cipher), this field is adjusted as necessary to the size required by the algorithm.
当前方案选择要求明文是某个字节数（分组密码的块大小）的倍数，此字段根据算法要求的大小进行调整。
Self-Describing-Padding begins with the value 1. Each byte contains the index of that byte. Thus, the final pad byte indicates the number of pad bytes to remove. For example, when the unpadded message length is 120 bytes, the padding values might be 1, 2, 3, 4, 5, 6, 7, and 8.
自描述填充以值1开始。每个字节都包含该字节的索引。因此，最后一个pad字节指示要删除的pad字节数。例如，当未添加的消息长度为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.
该列表由一个或两个部分组成：身份验证属性和/或封装属性。
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属性”、“Deflate”（压缩）、“XOR”（加密）、“DES-CBC”（加密）、“XOR”（加密）、“AH属性”、“AH序列”、“MD5-IPMAC”（身份验证），
would result in ESP with compression and triple encryption (inside), and then AH authentication with sequence numbers (outside) of the ESP payload.
将导致ESP使用压缩和三重加密（内部），然后使用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.
当从提供的属性列表中进行选择时，不要求任何安全关联在任何单个SPI中包含每种提供的属性，也不要求为每个提供的属性创建单独的SPI。
Some kinds of attributes may be included more than once in a single SPI. The set of allowable combinations of attributes are dependent on implementation and operational policy. Such considerations are outside the scope of this document.
某些类型的属性可能在单个SPI中包含多次。允许的属性组合集取决于实施和操作策略。此类考虑不在本文件的范围内。
The list may be divided into additional sections. This can occur only when both parties recognize the affected attributes.
该清单可分为其他部分。只有当双方都认识到受影响的属性时，才会发生这种情况。
The authentication, compression, encryption and identification mechanisms chosen, as well as the encapsulation modes (if any), need not be the same in both directions.
选择的身份验证、压缩、加密和标识机制以及封装模式（如果有）在两个方向上不必相同。
A shared-secret is used in a number of calculations. Regardless of the internal representation of the shared-secret, when used in calculations it is in the same form as the Value part of a Variable Precision Integer:
在许多计算中使用共享秘密。无论共享机密的内部表示形式如何，在计算中使用时，它与可变精度整数的值部分的形式相同：
- most significant byte first. - bits used are right justified within byte boundaries. - any unused bits are in the most significant byte. - unused bits are zero filled.
- 最高有效字节在前。-使用的位在字节边界内右对齐。-任何未使用的位都在最高有效字节中。-未使用的位是零填充的。
The shared-secret does not include a Size field.
共享机密不包括大小字段。
These messages are authenticated using the Identity-Choice. The Verification value is calculated prior to masking (and optional encryption), and verified after unmasking (and optional decryption).
使用标识选项对这些消息进行身份验证。验证值在屏蔽（和可选加密）之前计算，在取消屏蔽（和可选解密）之后验证。
The Identity-Choice authentication function is supplied with two input values:
Identity Choice身份验证功能提供了两个输入值：
- the sender (SPI Owner) verification-key, - the data to be verified (as a concatenated sequence of bytes).
- 发送方（SPI所有者）验证密钥，-要验证的数据（作为串联的字节序列）。
The resulting output value is stored in the Verification field.
结果输出值存储在验证字段中。
The Identity-Choice verification data consists of the following concatenated values:
标识选择验证数据由以下串联值组成：
+ the Initiator Cookie, + the Responder Cookie, + the Message, LifeTime and SPI fields, + the Identity-Choice and Identification, + the SPI User Identity Verification (response only), + the Attribute-Choices following the Verification field, + the Padding, + the SPI Owner TBV, + the SPI Owner Exchange-Value, + the SPI Owner Offered-Attributes, + the SPI User TBV, + the SPI User Exchange-Value, + the SPI User Offered-Attributes, + the Responder Offered-Schemes.
+ 发起方Cookie、+响应方Cookie、+消息、生存期和SPI字段、+身份选择和标识、+SPI用户身份验证（仅响应）、+验证字段后面的属性选择、+填充、+SPI所有者TBV、+SPI所有者交换值、+SPI所有者提供的属性，+SPI用户TBV、+SPI用户交换值、+SPI用户提供的属性、+响应者提供的方案。
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（三字节值）由Value_请求中的计数器和方案选择字段或Value_响应中的保留字段组成，紧跟在相关交换值之前。
Note that the order of the Exchange-Value and Offered-Attributes fields is different in each direction, and the Identification and SPI fields are also likely to be different in each direction. Note also that the SPI User Identity Verification (from the Identity_Request) is present only in the Identity_Response.
请注意，交换值和提供的属性字段在每个方向上的顺序不同，标识字段和SPI字段在每个方向上也可能不同。还要注意，SPI用户身份验证（来自Identity_请求）仅存在于Identity_响应中。
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。成功后，正常操作从用户数据报的身份验证和/或加密开始。
Implementation Notes:
实施说明：
This is distinct from any authentication method specified for the SPI.
这不同于为SPI指定的任何身份验证方法。
The exact details of the Identification and verification-key included in the Verification calculation are dependent on the Identity-Choice, as described in the "Basic Attributes".
验证计算中包含的标识和验证密钥的确切细节取决于“基本属性”中描述的身份选择。
Each party may wish to keep their own trusted databases, such as the Pretty Good Privacy (PGP) web of trust, and accept only those identities found there. Failure to find the Identification in either an internal or external database results in the same
各方可能希望保留自己的受信任数据库，例如相当好的隐私（PGP）信任网，并且只接受在那里找到的身份。在内部或外部数据库中找不到标识会导致相同的结果
Verification_Failure message as failure of the verification computation.
验证\验证计算失败的失败消息。
The Exchange-Value data includes both the Size and Value fields. The Offered-Attributes and Attribute-Choices data includes the Attribute, Length and Value fields.
交换值数据包括大小和值字段。提供的属性和属性选择数据包括属性、长度和值字段。
Identification Exchange messages are masked using the Privacy-Method indicated by the current Scheme-Choice. Masking begins with the next field after the SPI, and continues to the end of the data indicated by the UDP Length, including the Padding.
使用当前方案选择指示的隐私方法屏蔽身份交换消息。屏蔽从SPI之后的下一个字段开始，并继续到UDP长度所指示的数据的末尾，包括填充。
The Scheme-Choice specified Key-Generation-Function is used to create a special privacy-key for each message. This function is calculated over the following concatenated values:
Scheme Choice指定的密钥生成函数用于为每条消息创建特殊的隐私密钥。此函数通过以下串联值进行计算：
+ the SPI Owner Exchange-Value, + the SPI User Exchange-Value, + the Initiator Cookie, + the Responder Cookie, + the Message, LifeTime and SPI (or Reserved) fields, + the computed shared-secret.
+ SPI所有者交换值、+SPI用户交换值、+Initiator Cookie、+Responder Cookie、+Message、LifeTime和SPI（或Reserved）字段、+computed shared secret。
Since the order of the Exchange-Value fields is different in each direction, and the Message, LifeTime and SPI fields are also different in each direction, the resulting privacy-key will usually be different in each direction.
由于交换值字段在每个方向上的顺序不同，消息、生存期和SPI字段在每个方向上也不同，因此生成的隐私密钥通常在每个方向上都不同。
When a larger number of keying-bits are needed than are available from one iteration of the specified Key-Generation-Function, more keying-bits are generated by duplicating the trailing shared-secret, and recalculating the function. That is, the first iteration will have one trailing copy of the shared-secret, the second iteration will have two trailing copies of the shared-secret, and so forth.
当需要的键控比特数大于指定密钥生成函数的一次迭代中可用的数目时，通过复制尾部共享密钥并重新计算该函数将生成更多的键控比特。也就是说，第一次迭代将有一个共享秘密的后续副本，第二次迭代将有两个共享秘密的后续副本，依此类推。
Implementation Notes:
实施说明：
This is distinct from any encryption method specified for the SPI.
这不同于为SPI指定的任何加密方法。
The length of the Padding, and other details, are dependent on the Privacy-Method. See the "Basic Privacy-Method" list for details.
填充的长度和其他细节取决于隐私方法。有关详细信息，请参见“基本隐私方法”列表。
To avoid keeping the Exchange-Values in memory after the initial verification, it is often possible to pre-compute the function over the initial bytes of the concatenated data values for each
为了避免在初始验证后将交换值保留在内存中，通常可以在每个值的串联数据值的初始字节上预计算函数
direction, and append the trailing copies of the shared-secret.
方向，并附加共享机密的后续副本。
The Exchange-Value data includes both the Size and Value fields.
交换值数据包括大小和值字段。
Each SPI has one or more session-keys. These keys are generated based on the attributes of the SPI. See the "Basic Attributes" for details.
每个SPI都有一个或多个会话密钥。这些键是基于SPI的属性生成的。有关详细信息，请参见“基本属性”。
The Scheme-Choice specified Key-Generation-Function is used to create the SPI session-key for that particular attribute. This function is calculated over the following concatenated values:
Scheme Choice指定的密钥生成函数用于为该特定属性创建SPI会话密钥。此函数通过以下串联值进行计算：
+ the Initiator Cookie, + the Responder Cookie, + the SPI Owner generation-key, + the SPI User generation-key, + the message Verification field, + the computed shared-secret.
+ 发起方Cookie、+响应方Cookie、+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.
当需要的键控比特数大于指定密钥生成函数的一次迭代中可用的数目时，通过复制尾部共享密钥并重新计算该函数将生成更多的键控比特。也就是说，第一次迭代将有一个共享秘密的后续副本，第二次迭代将有两个共享秘密的后续副本，依此类推。
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".
会话密钥计算中包含的验证字段和生成密钥的确切细节取决于标识选择，如“基本属性”中所述。
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
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_。当潜在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时，将发送一条坏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值已用于此特定对等方，或达到某些其他资源限制时，将发送资源限制消息。
- 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.
- 当消息验证失败时，将发送验证失败消息。
- Whenever such a problem is detected, the SPI is not established; the implementation SHOULD log the occurance, and notify an operator as appropriate.
- 每当检测到此类问题时，不建立SPI；实施应记录发生的情况，并酌情通知操作员。
When the message is valid, the party SHOULD send SPI_Update with the necessary attributes.
当消息有效时，参与方应发送带有必要属性的SPI_更新。
If an existing SPI has those attributes, that SPI is returned in the SPI_Update with the remaining SPILT.
如果现有SPI具有这些属性，则该SPI将在SPI_更新中与剩余的SPI一起返回。
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_更新。此消息仅在一个方向上有效，即从SPI所有者到SPI用户。
The SPI Owner chooses the SPI and SPILT, a set of Attributes for the SPI, calculates the Verification, and masks the message using the Privacy-Method indicated by the current Scheme-Choice.
SPI所有者选择SPI和SPILT（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
- 当检测到无效/过期的cookie时，将显示一条坏的\u 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.
- 当消息验证失败时，将发送验证失败消息。
- Whenever such a problem is detected, the SPI is not established; the implementation SHOULD log the occurance, and notify an operator as appropriate.
- 每当检测到此类问题时，不建立SPI；实施应记录发生的情况，并酌情通知操作员。
When the message is valid, further actions are dependent on the value of the LifeTime field, as described later.
当消息有效时，进一步的操作取决于LifeTime字段的值，如下所述。
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_更新。
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_更新允许在高延迟环境中对高带宽应用程序进行快速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）；默认情况下，设置为生存期值的一半（SPILT/2）。这段时间是高度动态的，并且可以调整，以在转换特定处理之前很久提供自动SPI_更新。如果在时间限制内未发生新的Photuris交换，且当前交换状态尚未过期，则会发送自动SPI_更新。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Reserved-LT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved-SPI |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
~ Verification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes-Needed ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Reserved-LT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved-SPI |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
~ Verification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes-Needed ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Value_Request.
启动器Cookie 16个字节。从值_请求复制。
Responder-Cookie 16 bytes. Copied from the Value_Request.
响应器Cookie 16字节。从值_请求复制。
Message 8
信息8
Reserved-LT 3 bytes. For future use; MUST be filled with a random non-zero value when transmitted, and MUST be ignored when received.
保留LT 3字节。供日后使用；传输时必须用随机非零值填充，接收时必须忽略。
Reserved-SPI 4 bytes. For future use; MUST be set to zero when transmitted, and MUST be ignored when received.
保留SPI 4字节。供日后使用；传输时必须设置为零，接收时必须忽略。
Verification Variable Precision Integer, or other format indicated by the current Scheme-Choice. The calculation of the value is described in "Validity Verification".
验证变量精度整数，或当前方案选择指示的其他格式。“有效性验证”中描述了该值的计算。
The field may be any integral number of bytes in length. It does not require any particular alignment. The 32-bit alignment shown is for convenience in the illustration.
该字段的长度可以是任意整数个字节。它不需要任何特定的对齐。图中所示的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个或更多字节。从对等方支持的提供属性列表中选择的两个或多个属性的列表。
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | LifeTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security-Parameters-Index |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
~ Verification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Choices ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Value_Request.
启动器Cookie 16个字节。从值_请求复制。
Responder-Cookie 16 bytes. Copied from the Value_Request.
响应器Cookie 16字节。从值_请求复制。
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过期前剩余的秒数。值0表示删除了指定的SPI。
Security-Parameters-Index (SPI) 4 bytes. The SPI to be used for incoming communications.
安全参数索引（SPI）4字节。用于传入通信的SPI。
This may be a new SPI value (for creation), or an existing SPI value (for deletion). The value zero indicates special processing.
这可能是新的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.
属性选择0个或更多字节。当SPI和SPILT为非零时，从对等方支持的提供属性列表中选择的属性列表。
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_更新来创建新的SPI。当SPI为零时，SPI_更新会自动丢弃。
The new session-keys are calculated in the same fashion as the Identity_Messages. Since the SPI value is always different than any previous SPI during the Exchange LifeTime of the shared-secret, the resulting session-keys will necessarily be different from all others used in the same direction.
新会话密钥的计算方式与Identity_消息相同。由于在共享密钥的交换生存期内，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_请求再次开始Photuris交换。适当时，此Cookie_请求可能包括一个响应者Cookie，以保留以前的参与方配对。
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_更新可用于删除单个现有SPI。当SPI也为零时，SPI_更新将删除与此安全关联相关的所有现有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.
如果任何删除尝试失败，对等方将通过正常的ICMP安全故障消息得知已删除的SPI无效，并通过发送新的Cookie_请求启动Photuris交换。
The SPI_Update cannot be used to modify existing SPIs, such as lengthen an existing SPI LifeTime, resurrect an expired SPI, or add/remove an Attribute-Choice.
SPI_更新不能用于修改现有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:
Validity Method authentication函数提供了两个输入值：
- 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.
+ 发起方Cookie、+响应方Cookie、+消息、生存期和SPI（或保留）字段、+SPI所有者身份验证、+SPI用户身份验证、+验证字段后面的属性选择、+填充。
Note that the order of the Identity Verification fields (from the Identity_Messages) is different in each direction, and the Message, LifeTime and SPI fields are also likely to be different in each direction.
请注意，身份验证字段（来自Identity_消息）的顺序在每个方向上都不同，消息、生存期和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。成功后，正常操作从用户数据报的身份验证和/或加密开始。
Implementation Notes:
实施说明：
This is distinct from any authentication method specified for the SPI.
这不同于为SPI指定的任何身份验证方法。
The Identity Verification data includes both the Size and Value fields. The Attribute-Choices data includes the Attribute, Length and Value fields.
身份验证数据包括大小和值字段。属性选择数据包括属性、长度和值字段。
These messages are issued in response to Photuris state loss or other problems. A message has effect in only one direction. No retransmission timer is necessary.
这些消息是针对Photuris状态丢失或其他问题发出的。消息仅在一个方向上有效。无需重新传输计时器。
These messages are not masked.
这些消息没有被屏蔽。
The receiver checks the Cookies for validity. Special care MUST be taken that the Cookie pair in the Error Message actually match a pair currently in use, and that the protocol is currently in a state where such an Error Message might be expected. Otherwise, these messages could provide an opportunity for a denial of service attack. Invalid messages are silently discarded.
接收者检查Cookies的有效性。必须特别注意，错误消息中的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.
启动器Cookie 16个字节。从有问题的消息中复制。
Responder-Cookie 16 bytes. Copied from the offending message.
响应器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.
当收到值请求、标识请求、需要SPI\u或SPI\u更新，并且特定于接收器的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交换期间，当收到此错误消息时，它不会立即影响协议阶段的操作。稍后，当超过重新传输时，并且已收到此错误消息，发起方应通过发送带有响应方Cookie的新Cookie_请求并适当更新计数器，再次开始Photuris交换。
When this error message is received in response to SPI_Needed, the exchange state SHOULD NOT be marked as expired, but the party SHOULD initiate a Photuris exchange by sending a new Cookie_Request.
当收到此错误消息以响应所需的SPI_时，交换状态不应标记为已过期，但该方应通过发送新的Cookie_请求来启动Photuris交换。
When this error message is received in response to SPI_Update, the exchange state SHOULD NOT be marked as expired, and no further action is taken. A new exchange will be initiated later when needed by the peer to send authenticated and/or encrypted data.
当收到此错误消息以响应SPI_更新时，不应将exchange状态标记为已过期，并且不会采取进一步的操作。稍后，当对等方需要发送经过验证和/或加密的数据时，将启动新的交换。
Existing SPIs are not deleted. They expire normally, and are purged sometime later.
现有SPI不会被删除。它们通常会过期，稍后会被清除。
For the format of the 34 byte message, see "Cookie_Request". There are no additional fields.
有关34字节消息的格式，请参阅“Cookie_请求”。没有其他字段。
Initiator-Cookie 16 bytes. Copied from the offending message.
启动器Cookie 16个字节。从有问题的消息中复制。
Responder-Cookie 16 bytes. Copied from the offending message.
响应器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\u请求应用特殊处理。当有问题的消息响应程序Cookie和计数器均为零，并且现有的exchange尚未清除时，此字段将替换为
Responder-Cookie from the existing exchange.
来自现有exchange的响应程序Cookie。
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.
当为零时，响应器Cookie表示先前交换的发起方，或者未指定先前交换。
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指示前一次交换的响应者。此值设置为相应Cookie_响应中的计数器。
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\u请求、Value\u请求或所需SPI\u，并且该对等方已经使用了太多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_请求或Value_请求的此错误消息时，实现应将发送另一个Cookie_请求或Value_请求的重传超时（通常）增加一倍。否则，它不会立即影响协议阶段的操作。稍后，当超过重新传输时，并且已收到此错误消息，发起方应通过发送带有响应方Cookie的新Cookie_请求并适当更新计数器，再次开始Photuris交换。
When this error message is received in response to SPI_Needed, the implementation SHOULD NOT send another SPI_Needed until one of the existing SPIs associated with this exchange is deleted or has expired.
当收到此错误消息以响应需要的SPI_时，在与此交换关联的现有SPI之一被删除或过期之前，实现不应发送另一个需要的SPI_。
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.
启动器Cookie 16个字节。从有问题的消息中复制。
Responder-Cookie 16 bytes. Copied from the offending message.
响应器Cookie 16字节。从有问题的消息中复制。
Message 12
信息12
This error message is sent when an Identity_Message, SPI_Needed or SPI_Update is received, and verification fails.
当收到标识信息、需要SPI信息或SPI更新信息且验证失败时，将发送此错误信息。
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | Bad-Message | Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the offending message.
启动器Cookie 16个字节。从有问题的消息中复制。
Responder-Cookie 16 bytes. Copied from the offending message.
响应器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密钥交换。基于私有秘密值的公共D-H交换值的交换导致双方之间共享秘密。这个共享秘密可以单独使用，也可以生成一系列会话密钥，用于后续通信的身份验证和加密。
This document assumes familiarity with the Diffie-Hellman public-key algorithm. A good description can be found in [Schneier95].
本文档假设您熟悉Diffie-Hellman公钥算法。在[Schneier95]中可以找到一个很好的描述。
The original Diffie-Hellman technique [DH76] specified modular exponentiation. A public-value is generated using a generator (g), raised to a private-secret exponent (x), modulo a prime (p):
最初的Diffie-Hellman技术[DH76]规定了模幂运算。使用生成器（g）生成公共值，将其提升为私有秘密指数（x），模素数（p）：
(g**x) mod p.
（g**x）模块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）模块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\u响应中提供，在Value\u请求中选择一对。
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.
每个实现在其提供的方案中提出一个或多个模块。每个实现必须支持高达1024位的模。
For any particular Photuris node, these moduli need not change for significant periods of time; likely days or weeks. A background process can periodically generate new moduli.
对于任何特定的Photuris节点，这些模量在相当长的时间内不需要改变；可能是几天或几周。后台进程可以周期性地生成新的模块。
For 512-bit moduli, current estimates would provide 64 (pessimistic) bit-equivalents of cryptographic strength.
对于512位模，当前估计值将提供64位（悲观）等效加密强度。
For 1024-bit moduli, current estimates would range from 80 (pessimistic) through 98 (optimistic) bit-equivalents of cryptographic strength.
对于1024位模，当前估计值的范围为80位（悲观）到98位（乐观）等效密码强度。
These estimates are used when choosing moduli that are appropriate for the desired Security Parameter attributes.
当选择适合所需安全参数属性的模时，使用这些估计值。
Each implementation is likely to use a fixed modulus during its bootstrap, until it can generate another modulus in the background. As the bootstrap modulus will be widely distributed, and reused whenever the machine reinitializes, it SHOULD be a "safe" prime (p = 2q+1) to provide the greatest long-term protection.
每个实现都可能在其引导过程中使用固定的模，直到它可以在后台生成另一个模。由于自举模量将广泛分布，并在机器重新初始化时重复使用，因此它应为“安全”素数（p=2q+1），以提供最大的长期保护。
Implementors are encouraged to generate their own bootstrap moduli, and to change bootstrap moduli in successive implementation releases.
鼓励实现者生成自己的引导模块，并在后续的实现版本中更改引导模块。
As Photuris exchanges are initiated, new moduli will be learned from the Responder Offered-Schemes. The Initiator MAY cache these moduli for its own use.
当Photuris交换开始时，将从响应者提供的方案中学习新的模块。发起者可以缓存这些模块以供自己使用。
Before offering any learned modulus, the implementation MUST perform at least one iteration of probable primality verification. In this fashion, many processors will perform verification in parallel as moduli are passed around.
在提供任何学习的模之前，实现必须执行至少一次可能素性验证迭代。在这种方式下，当模传递时，许多处理器将并行执行验证。
When primality verification failures are found, the failed moduli SHOULD be retained for some (implementation dependent) period of time, to avoid re-learning and re-testing after subsequent exchanges.
当发现素性验证失败时，失败的模块应保留一段时间（取决于实现），以避免在后续交换后重新学习和重新测试。
The generator (g) should be chosen such that the private-secret exponents will generate all possible public-values, evenly distributed throughout the range of the modulus (p), without cycling through a smaller subset. Such a generator is called a "primitive root" (which is trivial to find when p is "safe").
生成器（g）的选择应确保私密指数将生成所有可能的公共值，均匀分布在模数（p）的整个范围内，而不会循环通过较小的子集。这样的生成器称为“原始根”（当p是“安全的”时，很难找到它）。
Only one generator (2) is required to be supported.
只需支撑一台发电机（2）。
Implementation Notes:
实施说明：
One useful technique is to select the generator, and then limit the modulus selection sieve to primes with that generator:
一种有用的技术是选择生成器，然后将模量选择筛限制为使用该生成器的素数：
2 when p (mod 24) = 11. 3 when p (mod 12) = 5. 5 when p (mod 10) = 3 or 7.
当p（mod 24）=11时为2。当p（mod 12）=5时为3。当p（mod 10）=3或7时为5。
The required generator (2) improves efficiency in multiplication performance. It is usable even when it is not a primitive root, as it still covers half of the space of possible residues.
所需的生成器（2）提高了乘法性能的效率。即使它不是原始根，也可以使用，因为它仍然覆盖了可能的残基的一半空间。
Each implementation generates a separate random private-secret exponent for each different modulus. Then, a D-H Exchange-Value is calculated for the given modulus, generator, and exponent.
每个实现为每个不同的模生成单独的随机私有秘密指数。然后，计算给定模数、生成器和指数的D-H交换值。
This specification recommends that the exponent length be at least twice the desired cryptographic strength of the longest session-key needed by the strongest offered-attribute.
此规范建议指数长度至少为所提供的最强属性所需的最长会话密钥的所需加密强度的两倍。
Based on the estimates in "Moduli Selection" (above):
根据“模量选择”（上文）中的估计：
For 512-bit moduli, exponent lengths of 128 bits (or more) are recommended.
对于512位模，建议指数长度为128位（或更多）。
For 1024-bit moduli, exponent lengths of 160 to 256 bits (or more) are recommended.
对于1024位模，建议指数长度为160到256位（或更多）。
Although the same exponent and Exchange-Value may be used with several parties whenever the same modulus and generator are used, the exponent SHOULD be changed at random intervals. A background process can periodically destroy the old values, generate a new random private-secret exponent, and recalculate the Exchange-Value.
尽管当使用相同的模数和生成器时，多方可使用相同的指数和交换值，但指数应以随机间隔进行更改。后台进程可以定期销毁旧值，生成新的随机私密指数，并重新计算交换值。
Implementation Notes:
实施说明：
The size of the exponent is entirely implementation dependent, is unknown to the other party, and can be easily changed.
指数的大小完全依赖于实现，另一方不知道，并且很容易更改。
Since these operations involve several time-consuming modular exponentiations, moving them to the "background" substantially improves the apparent execution speed of the Photuris protocol. It also reduces CPU loading sufficiently to allow a single public/private key-pair to be used in several closely spaced
由于这些操作涉及多个耗时的模幂运算，因此将它们移动到“后台”可显著提高Photuris协议的表观执行速度。它还可以充分减少CPU负载，以允许在多个紧密间隔中使用单个公钥/私钥对
Photuris executions, when creating Security Associations with several different nodes over a short period of time.
Photuris执行，在短时间内创建与多个不同节点的安全关联。
Other pre-computation suggestions are described in [BGMW93, LL94, Rooij94].
其他预计算建议如[BGMW93、LL94、Rooij94]所述。
Some exponents do not qualify as secret. The exponent 0 will generate the Exchange-Value 1, and the exponent 1 will generate the Exchange-Value g. Small exponents will be easily visible and SHOULD be avoided where:
有些人不具备保密的资格。指数0将生成交换值1，指数1将生成交换值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.
当一个实现选择一个随机指数时，将检查得到的交换值。如果交换值表示为模中有效位数的一半以下，则必须选择新的随机指数。
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.
通过在指数的最高有效一半设置至少一位，可以确保避免小指数。
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) 需要执行。任何模数（p），推荐的发电机（g）为2。当交换方案大小为非零时，模数包含在所提供方案列表中的交换方案值字段中。
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方案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方案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）交换方案32768至65535可供合作方用于指示私有方案，而不考虑供应商的实施。这些号码没有保留，可能会重复。其他标准（如Cookie_请求的IP源和目标）用于区分可用的特定交换方案。
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( 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.
keyfill和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
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 |
+-+-+-+-+-+-+-+-+
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 | 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 | 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下一个标头（协议）值指示ESP转换数据字段的内容。IP下一个报头（协议）的最新值在最近的“分配编号”[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封装中的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作为属性选项时，PayloadType将设置为要使用的实际值。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 5
属性5
Length 0
长度0
When selected as an Identity-Choice, the immediately following Identification field contains an unstructured Variable Precision Integer. Valid Identifications and symmetric secret-keys are preconfigured by the parties.
选择作为标识选项时，紧跟其后的标识字段包含一个非结构化变量精度整数。有效标识和对称密钥由双方预先配置。
There is no required format or content for the Identification value. The value may be a number or string of any kind. See "Use of Identification and Secrets" for details.
标识值没有必需的格式或内容。该值可以是任何类型的数字或字符串。有关详细信息，请参阅“标识和机密的使用”。
The symmetric secret-key (as specified) is selected based on the contents of the Identification field. All implementations MUST support at least 62 bytes. The selected symmetric secret-key SHOULD provide at least 64-bits of cryptographic strength.
根据标识字段的内容选择对称密钥（如指定）。所有实现必须至少支持62个字节。所选对称密钥应提供至少64位的加密强度。
As described in "Identity Verification", the Verification field value is the MD5 [RFC-1321] hash over the concatenation of:
如“身份验证”中所述，验证字段值是以下各项串联的MD5[RFC-1321]散列：
MD5( key, keyfill, data, datafill, key, md5fill )
MD5（键，键填充，数据，数据填充，键，md5fill）
where the key is the computed verification-key.
其中，密钥是计算的验证密钥。
The keyfill and datafill use the same pad-with-length technique defined for md5fill. This padding and length is implicit, and does not appear in the datagram.
keyfill和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]等选择作为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（键，键填充，数据报，数据填充，键，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]中所述的（不切实际的）攻击。keyfill和datafill使用相同的键盘，长度技术为md5fill定义。此填充和长度是隐式的，不会出现在数据报中。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length | OUI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Kind | Value(s) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
是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)
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)
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)
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)
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=接收坏Cookie RRL=接收资源限制RVF=接收验证失败RMR=接收消息拒绝
TO+ = Timeout with counter > 0
TO+ = Timeout with counter > 0
TO- = Timeout with counter expired UTO = Update TimeOut XTO = Exchange TimeOut
TO-=计数器过期超时UTO=更新超时XTO=交换超时
Actions
行动
scq = Send Cookie_Request scr = Send Cookie_Response
scq=发送Cookie\u请求scr=发送Cookie\u响应
svq = Send Value_Request svr = Send Value_Response
svq=发送值\请求svr=发送值\响应
siq = Send Identity_Request sir = Send Identity_Response
siq=发送标识\请求sir=发送标识\响应
sum = Send SPI_Update
sum = Send SPI_Update
se* = Send error message (see text) sbc = Send Bad Cookie srl = Send Resource Limit svf = Send Verification Failure
se*=发送错误消息（见正文）sbc=发送坏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=设置更新超时xto=设置交换超时
log = log operator message
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
| 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
| 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
| 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.
状态的“坏”版本表示已收到坏的\u Cookie或资源\u限制消息。
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\u请求，并正在等待Cookie\u响应。重新启动计时器和Exchange计时器都在运行。
Note that the Responder has no Cookie state.
请注意，响应程序没有Cookie状态。
In the Value state, the Initiator has sent its Exchange-Value, and is waiting for an Identity_Message. Both the Restart and Exchange timers are running.
在值状态下，启动器已发送其交换值，并正在等待Identity_消息。重新启动计时器和Exchange计时器都在运行。
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.
在标识状态下，发起方已发送标识请求，并正在等待标识响应。重新启动计时器和Exchange计时器都在运行。
In the Ready state, the Responder has sent its Exchange-Value, and is waiting for an Identity_Message. The Exchange timer is running.
在就绪状态下，响应程序已发送其交换值，并正在等待Identity_消息。交换计时器正在运行。
In the Update state, each party has concluded the Photuris exchange, and is unilaterally updating expiring SPIs until the Exchange LifeTime expires. Both the Update and Exchange timers are running.
在更新状态下，各方已完成Photuris交换，并单方面更新到期的SPI，直到交换生存期到期。更新和交换计时器都在运行。
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>
用户节点.site。user@node.site. rcmd@node.site. “平凡的名字”<user@node.site>
There is no requirement that the domain name match any of the particular IP addresses in use by the parties.
不要求域名与双方使用的任何特定IP地址匹配。
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.
一种简单的配置方法可以使用单个标识和密码，分发给受信任组中的所有参与者。这可能适用于由Internet上的虚拟专用网络组成的单一管理下的路由器之间。
Nota Bene: The passwords used in these examples do not meet the "MD5-IPMAC Symmetric Identification" recommendation for at least 64-bits of cryptographic strength.
注：这些示例中使用的密码不符合至少64位密码强度的“MD5-IPMAC对称标识”建议。
The administrator configures each router with the same username and password:
管理员使用相同的用户名和密码配置每个路由器：
identity local "Tiny VPN 1995 November" "abracadabra" identity remote "Tiny VPN 1995 November" "abracadabra"
标识本地“Tiny VPN 1995 11月”“abracadabra”标识远程“Tiny VPN 1995 11月”“abracadabra”
When the Initiator sends its Identity_Request, the SPI Owner
当启动器发送其标识请求时，SPI所有者
Identification field is "Tiny VPN 1995 November" and the SPI Owner secret-key is "abracadabra".
标识字段为“Tiny VPN 1995 11月”，SPI所有者密钥为“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".
当响应者发送其Identity_响应时，SPI所有者标识字段为“Tiny VPN 1995 11月”，SPI所有者密钥为“abracadabra”。SPI用户标识为“Tiny VPN 1995-11”（取自请求），SPI用户密钥为“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.
更健壮的配置方法可以为每一方使用单独的身份和秘密，并分发给受信任组中的参与者。这可能适用于经过身份验证的防火墙遍历。
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.
管理员拥有一个或多个网络和多个移动用户。希望限制授权外部用户的访问。示例边界路由器是10.0.0.1。
The administrator gives each user a different username and password, together with a group username and password for the router.
管理员为每个用户提供不同的用户名和密码，以及路由器的组用户名和密码。
The administrator configures (in part):
管理员配置（部分）：
identity local "199511@router.site" "FalDaRah" identity remote "Happy_Wanderer@router.site" "FalDaRee"
“本地身份”199511@router.site“法尔达拉”身份遥控“快乐”_Wanderer@router.site“法尔达里”
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"
route addprivate 10.0.0.0/8 tunnel 10.0.0.1安全10.0.0.1仅验证身份本地“快乐”_Wanderer@router.site“FalDaRee”身份遥控器199511@router.site“FalDaRah”身份遥控器199512@router.site“法尔达哈哈”
When the mobile Initiator sends its Identity_Request, the SPI Owner
当移动启动器发送其标识请求时，SPI所有者
Identification field is "Happy_Wanderer@router.site" and the SPI Owner secret-key is "FalDaRee".
识别字段是“快乐的”_Wanderer@router.siteSPI所有者的秘密密钥是“Faldarie”。
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".
当防火墙响应程序发送其标识\u响应时，SPI所有者标识字段为“199511@router.siteSPI所有者的秘密密钥是“FalDaRah”。SPI用户标识字段为“高兴”_Wanderer@router.site“（取自请求），SPI用户密钥为“Faldarie”。
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.
通过在各方之间配置一对秘密，可以实现更高的安全性。和以前一样，一个秘密用于与组中任何成员的初始接触，但另一个秘密用于特定各方之间。泄露一个或两个秘密不会影响组中的任何其他成员。这可能适用于形成协作虚拟专用网络之间边界的路由器之间，协作虚拟专用网络为每个VPN成员访问建立本地策略。
One administrator configures:
一名管理员配置：
identity local "Apple" "all for one" identity local "Apple-Baker" "Apple to Baker" "Baker" identity remote "Baker" "one for all" identity remote "Baker-Apple" "Baker to Apple"
标识本地“苹果”标识本地“苹果面包师”苹果对面包师“面包师”标识远程“面包师”标识远程“面包师”标识远程“面包师苹果”面包师对苹果
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".
当启动器发送其标识请求时，SPI所有者标识字段为“Apple”，SPI所有者密钥为“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
当响应者发送其Identity_响应时，发现“Apple”存在特殊配对（在本例中，由第三个字段指示），SPI所有者标识字段为“Baker Apple”，SPI所有者密钥为“Baker to Apple”。SPI用户标识为“Apple”（取自请求），SPI用户
secret-key is "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.
交换超时（ETO）默认值：30秒。最小值：重传*IRTO。
Exchange LifeTime (ELT) Default: 30 minutes. Minimum: 2 * ETO.
Exchange生存期（ELT）默认值：30分钟。最低：2*ETO。
SPI LifeTime (SPILT) Default: 5 minutes. Minimum: 3 * ETO.
SPI生存期（SPILT）默认值：5分钟。最低：3*ETO。
Each party configures a list of known identities and symmetric secret-keys.
各方配置已知身份和对称密钥的列表。
In addition, each party configures local policy that determines what access (if any) is granted to the holder of a particular identity. For example, the party might allow anonymous FTP, but prohibit Telnet. Such considerations are outside the scope of this document.
此外，各方配置本地策略，以确定授予特定身份持有者的访问权限（如果有）。例如，该方可能允许匿名FTP，但禁止Telnet。此类考虑不在本文件的范围内。
Security Considerations
安全考虑
Photuris was based on currently available tools, by experienced network protocol designers with an interest in cryptography, rather than by cryptographers with an interest in network protocols. This specification is intended to be readily implementable without requiring an extensive background in cryptology.
Photuris基于当前可用的工具，由对密码学感兴趣的经验丰富的网络协议设计师，而不是对网络协议感兴趣的密码学家设计。本规范旨在易于实现，无需广泛的密码学背景。
Therefore, only minimal background cryptologic discussion and rationale is included in this document. Although some review has been provided by the general cryptologic community, it is anticipated that design decisions and tradeoffs will be thoroughly analysed in subsequent dissertations and debated for many years to come.
因此，本文件仅包含最低限度的密码学背景讨论和基本原理。虽然一般密码学界已经提供了一些评论，但预计设计决策和权衡将在随后的论文中进行彻底分析，并在未来的许多年中进行辩论。
Cryptologic details are reserved for separate documents that may be more readily and timely updated with new analysis.
密码学详细信息保留给单独的文档，这些文档可能更容易通过新的分析及时更新。
History
历史
The initial specification of Photuris, now called version 1 (December 1994 to March 1995), was based on a short list of design requirements, and simple experimental code by Phil Karn. Only one modular exponentiation form was used, with a single byte index of pre-specified group parameters. The transform attributes were selected during the public value exchange. Party privacy was protected in the identification signature exchange with standard ESP transforms.
Photuris的初始规范，现在称为版本1（1994年12月至1995年3月），基于Phil Karn的设计要求短列表和简单的实验代码。只使用了一种模幂形式，带有预先指定的组参数的单字节索引。转换属性是在公共值交换期间选择的。通过标准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个未来的群体选择被认为是不够的；它被扩展到两个字节（并重命名为schemes），然后再次扩展以携带可变参数。变换属性的长度可变，以容纳可选参数。所有其他可能的参数都可以协商。一些参与者无法在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月通过将大多数参数移动到单独的文件中以供以后讨论而实现，并且在基本规范中只留下一些强制性特征。在一个月内，产生了多个可互操作的实现。
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.
不幸的是，在一阵煽动中，知识产权安全工作组在一次草率投票中决定取消当事人隐私保护，工作组主席在不允许进一步讨论的情况下终止了会议。由于身份交换消息需要隐私才能正常工作，因此再次对消息进行了重新组织。当事人隐私和其他可选方案被拆分为单独的文件。
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 transform属性都被移动到单独的文档中，以（希望）避免将来对基础文档进行不兼容的更改。
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月）。此外，他还建议使用cookie汇率限制计数器。
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建议同时签署公开声明和共享秘密，以提供身份验证的仅认证版本。此外，他还提供了有关模数、生成器和指数选择的文本（现在已删除到单独的文档中）。
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.
Hilarie Orman建议为非对称公钥/私钥标识方法的会话密钥生成添加秘密“nonce”（现已删除到单独的文档中），并对协议细节进行了广泛的审查。
Bart Preneel and Paul C van Oorschot in [PO96] recommended padding between the data and trailing key when hashing for authentication.
Bart Preneel和Paul C van Oorschot在[PO96]中建议在对身份验证进行散列时，在数据和尾随密钥之间进行填充。
Niels Provos developed another independent implementation (circa May 1997), ported to AIX, Linux, OpenBSD, and Solaris. Also, he made
Niels Provos开发了另一个独立的实现（大约1997年5月），移植到AIX、Linux、OpenBSD和Solaris。他还做了
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开发了第二个独立实现（大约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.
Randall Atkinson、Steven Bellovin、Wataru Hamada、James Hughes、Brian LaMacchia、Cheryl Madson、Lewis McCarthy、Perry Metzger、Bob Quinn、Ron Rivest、Rich Schroeppel和Norman Shulman对本文件的早期版本提出了有益的评论。
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.
美国专利#5299262，E.F.Brickell，D.M.Gordon，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第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学术出版社，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
[萤火虫]“Photuris”是萤火虫的拉丁名称。“Firefly”是美国国家安全局（National Security Administration）针对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.，“具有预计算的更灵活的幂运算”，密码学进展——加密'94，计算机科学讲稿839（1994），Springer Verlag，第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，“关于两种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/信息科学研究所，1980年8月。
[RFC-791] Postel, J., "Internet Protocol", STD 5, USC/Information Sciences Institute, September 1981.
[RFC-791]Postel，J.，“互联网协议”，STD 5，南加州大学/信息科学研究所，1981年9月。
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", MIT Laboratory for Computer Science, April 1992.
[RFC-1321]Rivest，R.，“MD5消息摘要算法”，麻省理工学院计算机科学实验室，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/信息科学研究所，1994年10月。
[RFC-1812] Baker, F., Editor, "Requirements for IP Version 4 Routers", Cisco Systems, June 1995.
[RFC-1812]Baker，F.，编辑，“IP版本4路由器的要求”，思科系统，1995年6月。
[RFC-1828] Metzger, P., Simpson, W., "IP Authentication using Keyed MD5", July 1995.
[RFC-1828]梅茨格，P.，辛普森，W.，“使用密钥MD5的IP认证”，1995年7月。
[RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC Transform", July 1995.
[RFC-1829]卡恩，P.，梅茨格，P.，辛普森，W.，“ESP DES-CBC转换”，1995年7月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, Harvard University, March 1997.
[RFC-2119]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.
《科学》，斯普林格·维拉格，第403-415页。
[Schneier95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7.
[Schneier95]Schneier，B.，“应用密码学第二版”，John Wiley&Sons，纽约，1995年。ISBN 0-471-12845-7。
Contacts
联络
Comments about this document should be discussed on the photuris@adk.gr mailing list.
关于本文件的评论应在photuris@adk.gr邮件列表。
Questions about this document can also be directed to:
有关本文件的问题，请联系：
Phil Karn Qualcomm, Inc. 6455 Lusk Blvd. San Diego, California 92121-2779
菲尔·卡恩高通公司，地址：卢斯克大道6455号。加利福尼亚州圣地亚哥92121-2779
karn@qualcomm.com karn@unix.ka9q.ampr.org (preferred)
karn@qualcomm.com karn@unix.ka9q.ampr.org（首选）
William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071
William Allen Simpson DayDreamer计算机系统咨询服务1384 Fontaine Madison Heights，Michigan 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.
版权所有（C）互联网协会（1999年）。版权所有（C）Philip Karn和William Allen Simpson（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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括（但不限于）保证使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。