Network Working Group S. Sakane
Request for Comments: 4430 K. Kamada
Category: Standards Track Yokogawa Electric Corp.
M. Thomas
J. Vilhuber
Cisco Systems
March 2006
Network Working Group S. Sakane
Request for Comments: 4430 K. Kamada
Category: Standards Track Yokogawa Electric Corp.
M. Thomas
J. Vilhuber
Cisco Systems
March 2006
Kerberized Internet Negotiation of Keys (KINK)
密钥的Kerberized Internet协商（扭结）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes the Kerberized Internet Negotiation of Keys (KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations.
本文档描述了Kerberized Internet密钥协商（KINK）协议。KINK定义了一个低延迟、计算成本低、易于管理、加密可靠的协议，用于使用Kerberos身份验证系统建立和维护安全关联。KINK重用Internet密钥交换（IKE）的快速模式有效负载，这将导致大量重用现有IKE实现。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Protocol Overview ...............................................4
3. Message Flows ...................................................4
3.1. GETTGT Message Flow ........................................5
3.2. CREATE Message Flow ........................................6
3.2.1. CREATE Key Derivation Considerations ................7
3.3. DELETE Message Flow ........................................8
3.4. STATUS Message Flow ........................................9
3.5. Reporting Errors ...........................................9
3.6. Rekeying Security Associations ............................10
3.7. Dead Peer Detection .......................................10
3.7.1. Coping with Dead User-to-User Peers ................12
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Protocol Overview ...............................................4
3. Message Flows ...................................................4
3.1. GETTGT Message Flow ........................................5
3.2. CREATE Message Flow ........................................6
3.2.1. CREATE Key Derivation Considerations ................7
3.3. DELETE Message Flow ........................................8
3.4. STATUS Message Flow ........................................9
3.5. Reporting Errors ...........................................9
3.6. Rekeying Security Associations ............................10
3.7. Dead Peer Detection .......................................10
3.7.1. Coping with Dead User-to-User Peers ................12
4. KINK Message Format ............................................13
4.1. KINK Alignment Rules ......................................15
4.2. KINK Payloads .............................................16
4.2.1. KINK_AP_REQ Payload ................................17
4.2.2. KINK_AP_REP Payload ................................18
4.2.3. KINK_KRB_ERROR Payload .............................19
4.2.4. KINK_TGT_REQ Payload ...............................20
4.2.5. KINK_TGT_REP Payload ...............................21
4.2.6. KINK_ISAKMP Payload ................................21
4.2.7. KINK_ENCRYPT Payload ...............................22
4.2.8. KINK_ERROR Payload .................................23
5. Differences from IKE Quick Mode ................................25
5.1. Security Association Payloads .............................26
5.2. Proposal and Transform Payloads ...........................26
5.3. Identification Payloads ...................................26
5.4. Nonce Payloads ............................................26
5.5. Notify Payloads ...........................................27
5.6. Delete Payloads ...........................................28
5.7. KE Payloads ...............................................28
6. Message Construction and Constraints for IPsec DOI .............28
6.1. REPLY Message .............................................28
6.2. ACK Message ...............................................28
6.3. CREATE Message ............................................29
6.4. DELETE Message ............................................30
6.5. STATUS Message ............................................31
6.6. GETTGT Message ............................................32
7. ISAKMP Key Derivation ..........................................32
8. Key Usage Numbers for Kerberos Key Derivation ..................33
9. Transport Considerations .......................................33
10. Security Considerations .......................................34
11. IANA Considerations ...........................................35
12. Forward Compatibility Considerations ..........................35
12.1. New Versions of Quick Mode ...............................36
12.2. New DOI ..................................................36
13. Related Work ..................................................36
14. Acknowledgements ..............................................37
15. References ....................................................37
15.1. Normative References .....................................37
15.2. Informative References ...................................38
4. KINK Message Format ............................................13
4.1. KINK Alignment Rules ......................................15
4.2. KINK Payloads .............................................16
4.2.1. KINK_AP_REQ Payload ................................17
4.2.2. KINK_AP_REP Payload ................................18
4.2.3. KINK_KRB_ERROR Payload .............................19
4.2.4. KINK_TGT_REQ Payload ...............................20
4.2.5. KINK_TGT_REP Payload ...............................21
4.2.6. KINK_ISAKMP Payload ................................21
4.2.7. KINK_ENCRYPT Payload ...............................22
4.2.8. KINK_ERROR Payload .................................23
5. Differences from IKE Quick Mode ................................25
5.1. Security Association Payloads .............................26
5.2. Proposal and Transform Payloads ...........................26
5.3. Identification Payloads ...................................26
5.4. Nonce Payloads ............................................26
5.5. Notify Payloads ...........................................27
5.6. Delete Payloads ...........................................28
5.7. KE Payloads ...............................................28
6. Message Construction and Constraints for IPsec DOI .............28
6.1. REPLY Message .............................................28
6.2. ACK Message ...............................................28
6.3. CREATE Message ............................................29
6.4. DELETE Message ............................................30
6.5. STATUS Message ............................................31
6.6. GETTGT Message ............................................32
7. ISAKMP Key Derivation ..........................................32
8. Key Usage Numbers for Kerberos Key Derivation ..................33
9. Transport Considerations .......................................33
10. Security Considerations .......................................34
11. IANA Considerations ...........................................35
12. Forward Compatibility Considerations ..........................35
12.1. New Versions of Quick Mode ...............................36
12.2. New DOI ..................................................36
13. Related Work ..................................................36
14. Acknowledgements ..............................................37
15. References ....................................................37
15.1. Normative References .....................................37
15.2. Informative References ...................................38
KINK is designed to provide a secure, scalable mechanism for establishing keys between communicating entities within a centrally managed environment in which it is important to maintain consistent security policy. The security goals of KINK are to provide privacy, authentication, and replay protection of key management messages and to avoid denial of service vulnerabilities whenever possible. The performance goals of the protocol are to have a low computational cost, low latency, and a small footprint. It is also to avoid or minimize the use of public key operations. In particular, the protocol provides the capability to establish IPsec security associations (SAs) in two messages with minimal computational effort. These requirements are described in RFC 3129 [REQ4KINK].
KINK旨在提供一种安全、可扩展的机制，用于在集中管理的环境中建立通信实体之间的密钥，在这种环境中，维护一致的安全策略非常重要。KINK的安全目标是提供密钥管理消息的隐私、身份验证和重播保护，并尽可能避免拒绝服务漏洞。该协议的性能目标是具有低计算成本、低延迟和小占地面积。它还可以避免或尽量减少使用公钥操作。特别是，该协议能够以最小的计算工作量在两条消息中建立IPsec安全关联（SA）。RFC 3129[REQ4KINK]中描述了这些要求。
Kerberos [KERBEROS] provides an efficient authentication mechanism for clients and servers using a trusted third-party model. Kerberos also provides a mechanism for cross-realm authentication natively. A client obtains a ticket from an online authentication server, the Key Distribution Center (KDC). The ticket is then used to construct a credential for authenticating the client to the server. As a result of this authentication operation, the server will also share a secret key with the client. KINK uses this property as the basis of distributing keys for IPsec.
Kerberos[Kerberos]使用可信的第三方模型为客户端和服务器提供了一种高效的身份验证机制。Kerberos还提供了一种本机跨域身份验证机制。客户端从在线身份验证服务器密钥分发中心（KDC）获取票据。然后，该票证用于构造用于向服务器验证客户端的凭据。作为此身份验证操作的结果，服务器还将与客户端共享一个密钥。KINK将此属性用作分发IPsec密钥的基础。
The central key management provided by Kerberos is efficient because it limits computational cost and limits complexity versus IKE's necessity of using public key cryptography [IKE]. Initial authentication to the KDC may be performed using either symmetric keys, or asymmetric keys using the Public Key Cryptography for Initial Authentication in Kerberos [PKINIT]; however, subsequent requests for tickets as well as authenticated exchanges between the client and servers always utilize symmetric cryptography. Therefore, public key operations (if any) are limited and are amortized over the lifetime of the credentials acquired in the initial authentication operation to the KDC. For example, a client may use a single public key exchange with the KDC to efficiently establish multiple SAs with many other servers in the realm of the KDC. Kerberos also scales better than direct peer-to-peer keying when symmetric keys are used. The reason is that since the keys are stored in the KDC, the number of principal keys is O(n+m) rather than O(n*m), where "n" is the number of clients and "m" is the number of servers.
Kerberos提供的中央密钥管理是有效的，因为它限制了计算成本并限制了复杂性，而IKE需要使用公钥加密[IKE]。对KDC的初始认证可以使用对称密钥执行，或者使用公钥加密在Kerberos[PKINIT]中进行初始认证的非对称密钥执行；但是，随后的票据请求以及客户端和服务器之间经过身份验证的交换始终使用对称加密。因此，公钥操作（如果有的话）是有限的，并且在对KDC的初始身份验证操作中获取的凭据的生命周期内分期偿还。例如，客户机可以使用与KDC的单个公钥交换来有效地与KDC领域中的许多其他服务器建立多个sa。当使用对称密钥时，Kerberos的可扩展性也优于直接的对等密钥。原因是，由于密钥存储在KDC中，主密钥的数量是O（n+m）而不是O（n*m），其中“n”是客户端的数量，“m”是服务器的数量。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
It is assumed that the readers are familiar with the terms and concepts described in Kerberos Version 5 [KERBEROS], IPsec [IPSEC], and IKE [IKE].
假设读者熟悉Kerberos版本5[Kerberos]、IPsec[IPsec]和IKE[IKE]中描述的术语和概念。
KINK is a command/response protocol that can create, delete, and maintain IPsec SAs. Each command or response contains a common header along with a set of type-length-value payloads. The type of a command or a response constrains the payloads sent in the messages of the exchange. KINK itself is a stateless protocol in that each command or response does not require storage of hard state for KINK. This is in contrast to IKE, which uses Main Mode to first establish an Internet Security Association and Key Management Protocol (ISAKMP) SA followed by subsequent Quick Mode exchanges.
KINK是一种命令/响应协议，可以创建、删除和维护IPsec SAs。每个命令或响应都包含一个公共头以及一组类型长度值有效载荷。命令或响应的类型限制在exchange消息中发送的有效负载。扭结本身是一个无状态协议，因为每个命令或响应都不需要为扭结存储硬状态。这与IKE不同，IKE使用主模式首先建立Internet安全关联和密钥管理协议（ISAKMP）SA，然后进行后续快速模式交换。
KINK uses Kerberos mechanisms to provide mutual authentication and replay protection. For establishing SAs, KINK provides confidentiality for the payloads that follow the Kerberos AP-REQ payload. The design of KINK mitigates denial of service attacks by requiring authenticated exchanges before the use of any public key operations and the installation of any state. KINK also provides a means of using Kerberos User-to-User mechanisms when there is not a key shared between the server and the KDC. This is typically, but not limited to, the case with IPsec peers using PKINIT for initial authentication.
KINK使用Kerberos机制提供相互身份验证和重播保护。对于建立SAs，KINK为Kerberos AP-REQ有效负载之后的有效负载提供机密性。KINK的设计通过在使用任何公钥操作和安装任何状态之前要求经过身份验证的交换来减轻拒绝服务攻击。KINK还提供了一种在服务器和KDC之间没有共享密钥时使用Kerberos用户对用户机制的方法。这通常是但不限于IPsec对等方使用PKINIT进行初始身份验证的情况。
KINK directly reuses Quick Mode payloads defined in section 5.5 of [IKE], with some minor changes and omissions. In most cases, KINK exchanges are a single command and its response. An optional third message is required when creating SAs, only if the responder rejects the first proposal from the initiator or wants to contribute the keying materials. KINK also provides rekeying and dead peer detection.
KINK直接重用了[IKE]第5.5节中定义的快速模式有效载荷，但有一些细微的更改和遗漏。在大多数情况下，扭结交换是单个命令及其响应。创建SA时需要可选的第三条消息，仅当响应者拒绝发起者的第一个建议或希望提供密钥材料时。KINK还提供密钥更新和死点检测。
All KINK message flows follow the same pattern between the two peers: a command, a response, and an optional acknowledgement in a CREATE flow. A command is a GETTGT, CREATE, DELETE, or STATUS message; a response is a REPLY message; and an acknowledgement is an ACK message.
所有扭结消息流在两个对等方之间遵循相同的模式：创建流中的命令、响应和可选确认。命令是GETTGT、CREATE、DELETE或STATUS消息；响应是回复消息；确认是ACK消息。
KINK uses Kerberos as the authentication mechanism; therefore, a KINK host needs to get a service ticket for each peer before actual key negotiations. This is basically a pure Kerberos exchange and the actual KDC traffic here is for illustrative purposes only. In practice, when a principal obtains various tickets is a subject of
KINK使用Kerberos作为身份验证机制；因此，在实际的密钥协商之前，纠结主机需要为每个对等方获得一个服务票证。这基本上是一个纯Kerberos交换，这里的实际KDC流量仅用于说明目的。在实践中，当一名校长获得各种罚单时，这是一个问题
Kerberos and local policy consideration. As an exception, the GETTGT message flow of KINK (described in section 3.1) is used when a User-to-User authentication is required. In this flow, we assume that both A and B have ticket-granting tickets (TGTs) from their KDCs.
Kerberos和本地策略考虑。作为例外，当需要用户对用户身份验证时，使用KINK的GETTGT消息流（如第3.1节所述）。在这个流程中，我们假设A和B都有来自其KDC的票证授予票证（TGT）。
After a service ticket is obtained, KINK uses the CREATE message flow (section 3.2), DELETE message flow (section 3.3), and STATUS message flow (section 3.4) to manage SAs. In these flows, we assume that A has a service ticket for B.
获得服务票证后，KINK使用创建消息流（第3.2节）、删除消息流（第3.3节）和状态消息流（第3.4节）来管理SAs。在这些流中，我们假设A有B的服务票证。
This flow is used to retrieve a TGT from the remote peer in User-to-User authentication mode.
此流用于在用户到用户身份验证模式下从远程对等方检索TGT。
If the initiator determines that it will not be able to get a normal (non-User-to-User) service ticket for the responder, it can try a User-to-User authentication. In this case, it first fetches a TGT from the responder in order to get a User-to-User service ticket:
If the initiator determines that it will not be able to get a normal (non-User-to-User) service ticket for the responder, it can try a User-to-User authentication. In this case, it first fetches a TGT from the responder in order to get a User-to-User service ticket:translate error, please retry
A B KDC
------ ------ ---
1 GETTGT+KINK_TGT_REQ------>
A B KDC
------ ------ ---
1 GETTGT+KINK_TGT_REQ------>
2 <-------REPLY+KINK_TGT_REP
2 <-------REPLY+KINK_TGT_REP
3 TGS-REQ+TGT(B)------------------------------------>
3 TGS-REQ+TGT(B)------------------------------------>
4 <-------------------------------------------TGS-REP
4 <-------------------------------------------TGS-REP
Figure 1: GETTGT Message Flow
图1:GETTGT消息流
The initiator MAY support the following events as triggers to go to the User-to-User path. Note that the two errors described below will not be authenticated, and how to act on them depends on the policy.
启动器可以支持以下事件作为触发器，以转到用户到用户路径。请注意，下面描述的两个错误将不会进行身份验证，如何处理它们取决于策略。
o The local policy says that the responder requires a User-to-User authentication.
o 本地策略表示响应者需要用户对用户的身份验证。
o A KRB_AP_ERR_USER_TO_USER_REQUIRED error is returned from the responder.
o 响应程序返回KRB_AP_ERR_USER_TO_USER_REQUIRED错误。
o A KDC_ERR_MUST_USE_USER2USER error is returned from the KDC.
o KDC返回KDC_ERR_MUST_USE_USER2USER错误。
This flow creates SAs. The CREATE command takes an "optimistic" approach, where SAs are initially created on the expectation that the responder will choose the initial proposed payload. The optimistic proposal is placed in the first transform payload(s) of the first proposal. The initiator MUST check to see if the optimistic proposal was selected by comparing all transforms and attributes, which MUST be identical to those in the initiator's optimistic proposal with the exceptions of LIFE_KILOBYTES and LIFE_SECONDS. Each of these attributes MAY be set to a lower value by the responder and still expect optimistic keying, but MUST NOT be set to a higher value that MUST generate a NO-PROPOSAL-CHOSEN error. The initiator MUST use the shorter lifetime.
此流创建SAs。CREATE命令采用“乐观”方法，其中SA最初是在预期响应者将选择初始建议有效负载的情况下创建的。乐观方案放置在第一个方案的第一个变换有效载荷中。发起者必须通过比较所有转换和属性来检查是否选择了乐观方案，这些转换和属性必须与发起者乐观方案中的转换和属性相同，但寿命千字节和寿命秒除外。响应者可以将这些属性中的每一个设置为较低的值，并且仍然希望使用乐观键控，但不能将其设置为较高的值，因为该值必须生成未选择的错误。启动器必须使用较短的生存期。
When a CREATE command contains an existing Security Parameter Index (SPI), the responder MUST reject it and SHOULD return an ISAKMP notification with INVALID-SPI.
当CREATE命令包含现有安全参数索引（SPI）时，响应程序必须拒绝该命令，并应返回带有INVALID-SPI的ISAKMP通知。
When a key exchange (KE) payload is sent from the initiator but the responder does not support it, the responder MUST reject it with an ISAKMP notification of INVALID-PAYLOAD-TYPE containing a KE payload type as its notification data. When the initiator receives this error, it MAY retry without a KE payload (as another transaction) if its policy allows that.
当从发起方发送密钥交换（KE）有效负载但响应方不支持它时，响应方必须使用包含KE有效负载类型作为其通知数据的INVALID-payload-TYPE的ISAKMP通知拒绝它。当启动器收到此错误时，如果其策略允许，它可以在没有KE负载的情况下重试（作为另一个事务）。
A B KDC
------ ------ ---
A B KDC
------ ------ ---
A creates an optimistic inbound SA (B->A) unless using a KE.
A创建乐观入站SA（B->A），除非使用KE。
1 CREATE+ISAKMP------------>
1 CREATE+ISAKMP------------>
B creates an inbound SA (A->B). B creates an outbound SA (B->A) if optimistic and not using a KE.
B创建入站SA（A->B）。如果乐观且不使用KE，B将创建出站SA（B->A）。
2 <-------------REPLY+ISAKMP
2 <-------------REPLY+ISAKMP
A creates an outbound SA (A->B). A replaces an inbound SA (B->A) if non-optimistic. A creates an inbound SA (B->A) if using a KE.
A创建出站SA（A->B）。如果不乐观，A将替换入站SA（B->A）。如果使用KE，A将创建入站SA（B->A）。
3 [ ACK---------------------> ]
3 [ ACK---------------------> ]
[ B creates an outbound SA (B->A). ]
[B创建出站SA（B->A）。]
Figure 2: CREATE Message Flow
图2：创建消息流
Creating SAs has two modes: 2-way handshake and 3-way handshake. The initiator usually begins a negotiation expecting a 2-way handshake. When the optimistic proposal is not chosen by the responder, the negotiation is switched to a 3-way handshake. When and only when the initiator uses a KE payload, 3-way handshake is expected from the beginning.
创建SAs有两种模式：双向握手和三向握手。发起人通常开始协商，期望双向握手。当响应者没有选择乐观的提议时，协商切换为三方握手。当且仅当启动器使用KE有效负载时，从一开始就需要三方握手。
A 2-way handshake is performed in the following steps:
按以下步骤执行双向握手：
1) The host A creates an inbound SA (B->A) in its SA database using the optimistic proposal in the ISAKMP SA proposal. It is then ready to receive any messages from B. 2) A then sends the CREATE message to B. 3) If B agrees to A's optimistic proposal, B creates an inbound SA (A->B) and an outbound SA (B->A) in its database. If B does not choose the first proposal or wants to add a Nonce payload, switch to step 3 of the 3-way handshake described below. 4) B then sends a REPLY to A without a Nonce payload and without requesting an ACK. 5) Upon receipt of the REPLY, A creates an outbound SA (A->B).
1) 主机A使用ISAKMP SA建议中的乐观建议在其SA数据库中创建入站SA（B->A）。然后，它准备接收来自B的任何消息。2）A然后将创建消息发送给B。3）如果B同意A的乐观建议，B将在其数据库中创建入站SA（A->B）和出站SA（B->A）。如果B不选择第一个方案或想要添加一个Nonce有效载荷，则切换到下面描述的三向握手的步骤3。4） 然后，B向a发送一个应答，而无需当前有效负载，也无需请求ACK。5） 收到回复后，A创建出站SA（A->B）。
A 3-way handshake is performed in the following steps:
按以下步骤执行三向握手：
1) The host A sends the CREATE message to B without creating any SA. 2) B chooses one proposal according to its policy. 3) B creates an inbound SA (A->B) and sends the actual choice in the REPLY. It SHOULD send the optional Nonce payload (as it does not increase message count and generally increases entropy sources) and MUST request that the REPLY be acknowledged. 4) Upon receipt of the REPLY, A creates the inbound SA (B->A) (or modifies it as necessary, if switched from 2-way), and the outbound SA (A->B). 5) A now sends the ACK message. 6) Upon receipt of the ACK, B installs the final outbound SA (B->A).
1) 主机A向B发送创建消息，而不创建任何SA。2） B根据其政策选择一个方案。3） B创建入站SA（A->B）并在回复中发送实际选择。它应该发送可选的Nonce有效负载（因为它不会增加消息计数，通常会增加熵源），并且必须请求确认应答。4） 收到回复后，A创建入站SA（B->A）（或根据需要修改它，如果从双向切换），以及出站SA（A->B）。5） A现在发送ACK消息。6） 收到ACK后，B安装最终出站SA（B->A）。
If B does not choose the first proposal, adds a nonce, or accepts the KE exchange, then it MUST request an ACK (i.e., set the ACKREQ bit) so that it can install the final outbound SA. The initiator MUST always generate an ACK if the ACKREQ bit is set in the KINK header, even if it believes that the responder was in error.
如果B不选择第一个方案、添加nonce或接受KE交换，则必须请求ACK（即设置ACKREQ位），以便安装最终出站SA。如果在扭结报头中设置了ACKREQ位，则发起方必须始终生成ACK，即使它认为响应方出错。
The CREATE command's optimistic approach allows an SA to be created in two messages rather than three. The implication of a two-message exchange is that B will not contribute to the key since A must set up
CREATE命令的乐观方法允许在两条消息而不是三条消息中创建SA。两个消息交换的含义是，B不会对密钥作出贡献，因为a必须设置
the inbound SA before it receives any additional keying material from B. This may be suspect under normal circumstances; however, KINK takes advantage of the fact that the KDC provides a reliable source of randomness which is used in key derivation. In many cases, this will provide an adequate session key so that B will not require an acknowledgement. Since B is always at liberty to contribute to the keying material, this is strictly a trade-off between the key strength versus the number of messages, which KINK implementations may decide as a matter of policy.
入站SA在收到B提供的任何额外钥匙材料之前进行检查。在正常情况下，这可能是可疑的；然而，KINK利用了KDC提供用于密钥导出的可靠随机性源这一事实。在许多情况下，这将提供足够的会话密钥，以便B不需要确认。由于B始终可以自由地贡献键控材料，因此这严格来说是键强度与消息数量之间的权衡，扭结实现可能根据策略决定。
The DELETE command deletes existing SAs. The domain of interpretation (DOI)-specific payloads describe the actual SA to be deleted. For the IPsec DOI, those payloads will include an ISAKMP payload containing the list of the SPIs to be deleted.
DELETE命令删除现有SA。特定于解释域（DOI）的有效载荷描述了要删除的实际SA。对于IPsec DOI，这些有效负载将包括包含要删除的SPI列表的ISAKMP有效负载。
A B KDC
------ ------ ---
A B KDC
------ ------ ---
A deletes outbound SA to B.
A将出站SA删除到B。
1 DELETE+ISAKMP------------>
1 DELETE+ISAKMP------------>
B deletes inbound and outbound SA to A.
B将入站和出站SA删除到A。
2 <-------------REPLY+ISAKMP
2 <-------------REPLY+ISAKMP
A deletes inbound SA to B.
A将入站SA删除到B。
Figure 3: DELETE Message Flow
图3：删除消息流
The DELETE command takes a "pessimistic" approach, which does not delete inbound SAs until it receives acknowledgement that the other host has received the DELETE. The exception to the pessimistic approach is if the initiator wants to immediately cease all activity on an inbound SA. In this case, it MAY delete the inbound SA as well in step 1, above.
DELETE命令采用“悲观”方法，在接收到另一台主机已接收到删除的确认之前，不会删除入站SAs。悲观方法的例外情况是，如果发起方希望立即停止入站SA上的所有活动。在这种情况下，它也可以在上面的步骤1中删除入站SA。
The ISAKMP payload contains ISAKMP Delete payload(s) that indicate the inbound SA(s) for the initiator of this flow. KINK does not allow half-open SAs; thus, when the responder receives a DELETE command, it MUST delete SAs of both directions, and MUST reply with ISAKMP Delete payload(s) that indicate the inbound SA(s) for the responder of this flow. If the responder cannot find an appropriate SPI to be deleted, it MUST return an ISAKMP notification with INVALID_SPI, which also serves to inform the initiator that it can delete the inbound SA.
ISAKMP有效负载包含ISAKMP Delete有效负载，用于指示此流的启动器的入站SA。扭结不允许半开SAs；因此，当响应程序收到DELETE命令时，它必须删除两个方向的SA，并且必须使用ISAKMP DELETE有效负载进行回复，该有效负载指示该流响应程序的入站SA。如果响应程序找不到要删除的适当SPI，则必须返回带有无效_SPI的ISAKMP通知，该通知还用于通知启动器它可以删除入站SA。
A race condition with the DELETE flow exists. Due to network reordering, etc., packets in flight while the DELETE operation is taking place may arrive after the diagrams above, which recommend deleting the inbound SA. A KINK implementation SHOULD implement a grace timer that SHOULD be set to a period of at least two times the average round-trip time, or to a configurable value. A KINK implementation MAY choose to set the grace period to zero at appropriate times to delete an SA ungracefully. The behavior described here is referred from the behavior of the TCP [RFC793] flags FIN and RST.
存在具有删除流的竞争条件。由于网络重新排序等原因，在执行删除操作时飞行中的数据包可能会在上图之后到达，这建议删除入站SA。扭结实现应实现一个宽限计时器，该计时器应设置为至少两倍平均往返时间的周期，或设置为可配置值。扭结实现可以选择在适当的时间将宽限期设置为零，以不正常地删除SA。这里描述的行为来自TCP[RFC793]标志FIN和RST的行为。
This flow is used to send any information to a peer or to elicit any information from a peer. An initiator may send a STATUS command to the responder at any time, optionally with DOI-specific ISAKMP payloads. In the case of the IPsec DOI, these are generally in the form of ISAKMP Notification payloads. A STATUS command is also used as a means of dead peer detection described in section 3.7.
此流用于向对等方发送任何信息或从对等方获取任何信息。发起方可以随时向响应方发送状态命令，可以选择使用特定于DOI的ISAKMP有效负载。在IPsec DOI的情况下，这些通常以ISAKMP通知有效负载的形式出现。状态命令也可用作第3.7节所述的死点检测手段。
A B KDC
------ ------ ---
A B KDC
------ ------ ---
1 STATUS[+ISAKMP]---------->
1 STATUS[+ISAKMP]---------->
2 <-----------REPLY[+ISAKMP]
2 <-----------REPLY[+ISAKMP]
Figure 4: STATUS Message Flow
图4：状态消息流
When the responder detects an error in a received command, it can send a DOI-specific payload to indicate the error in a REPLY message. There are three types of payloads that can indicate errors: KINK_KRB_ERROR payloads for Kerberos errors, KINK_ERROR payloads for KINK errors, and KINK_ISAKMP payloads for ISAKMP errors. Details are described in sections 4.2.3, 4.2.8, and 4.2.6, respectively.
当响应程序在接收到的命令中检测到错误时，它可以发送特定于DOI的负载，以在应答消息中指示错误。有三种类型的有效负载可以指示错误：Kerberos错误的KINK_KRB_错误有效负载、KINK_错误有效负载和ISAKMP错误的KINK_ISAKMP有效负载。详细信息分别在第4.2.3、4.2.8和4.2.6节中描述。
If the initiator detects an error in a received reply, there is no means to report it back to the responder. The initiator SHOULD log the event and MAY take a remedial action by reinitiating the initial command.
如果发起方在收到的回复中检测到错误，则无法将其报告给响应方。启动器应记录事件，并可通过重新初始化初始命令采取补救措施。
If the server clock and the client clock are off by more than the policy-determined clock skew limit (usually 5 minutes), the server MUST return a KRB_AP_ERR_SKEW. The optional client's time in the KRB-ERROR SHOULD be filled out. If the server protects the error by adding the Cksum field and returning the correct client's time, the
如果服务器时钟和客户端时钟的关闭时间超过策略确定的时钟偏移限制（通常为5分钟），则服务器必须返回KRB_AP_ERR_偏移。应填写KRB错误中的可选客户端时间。如果服务器通过添加Cksum字段并返回正确的客户端时间来保护错误，则
client SHOULD compute the difference (in seconds) between the two clocks based upon the client and server time contained in the KRB-ERROR message. The client SHOULD store this clock difference and use it to adjust its clock in subsequent messages. If the error is not protected, the client MUST NOT use the difference to adjust subsequent messages, because doing so would allow an attacker to construct authenticators that can be used to mount replay attacks.
客户机应根据KRB-ERROR消息中包含的客户机和服务器时间计算两个时钟之间的差（秒）。客户端应存储此时钟差，并使用它在后续消息中调整其时钟。如果错误未受到保护，则客户端不得使用差异来调整后续消息，因为这样做将允许攻击者构造可用于装载重播攻击的身份验证程序。
KINK expects the initiator of an SA to be responsible for rekeying the SA for two reasons. The first reason is to prevent needless duplication of SAs as the result of collisions due to an initiator and responder both trying to renew an existing SA. The second reason is due to the client/server nature of Kerberos exchanges, which expects the client to get and maintain tickets. While KINK expects that a KINK host is able to get and maintain tickets, in practice it is often advantageous for servers to wait for clients to initiate sessions so that they do not need to maintain a large ticket cache.
KINK希望SA的发起人负责重新设置SA的密钥，原因有两个。第一个原因是防止由于发起方和响应方都试图更新现有SA而导致冲突，从而导致不必要的SA复制。第二个原因是Kerberos交换的客户机/服务器性质，它期望客户机获取并维护票据。虽然KINK希望KINK主机能够获取和维护票证，但实际上，服务器通常会等待客户端启动会话，这样它们就不需要维护大型票证缓存。
There are no special semantics for rekeying SAs in KINK. That is, in order to rekey an existing SA, the initiator must CREATE a new SA followed by either deleting the old SA with the DELETE flow or letting it time out. When identical flow selectors are available on different SAs, KINK implementations SHOULD choose the SA most recently created. It should be noted that KINK avoids most of the problems of [IKE] rekeying by having a reliable delete mechanism.
在KINK中重新设置sa的密钥没有特殊的语义。也就是说，为了重新设置现有SA的密钥，启动器必须创建一个新SA，然后使用删除流删除旧SA或让其超时。当不同SA上有相同的流选择器时，扭结实现应选择最近创建的SA。应该注意的是，KINK通过具有可靠的删除机制避免了[IKE]重设密钥的大部分问题。
Normally, a KINK implementation that rekeys existing SAs will try to rekey the SA ahead of an SA termination, which may include the hard lifetime in time/bytecount or the overflow of the sequence number counter. We call this time "soft lifetime". The soft lifetime MUST be randomized to avoid synchronization with similar implementations. In the case of the lifetime in time, one reasonable approach to determine the soft lifetime is picking a random time between T-rekey and T-retrans and subtracting it from the hard lifetime. Here, T-rekey is the reasonable maximum rekeying margin, and T-retrans is the amount of time it would take to go through a full retransmission cycle. T-rekey SHOULD be at least twice as high as T-retrans.
通常，对现有SA重新设置密钥的扭结实现将在SA终止之前尝试对SA重新设置密钥，这可能包括时间/字节数的硬生存期或序列号计数器的溢出。我们称之为“软生命”。软生命周期必须随机化，以避免与类似实现同步。在时间生命周期的情况下，确定软生命周期的一个合理方法是在T-rekey和T-retrans之间选择一个随机时间，并从硬生命周期中减去它。这里，T-rekey是合理的最大重新键控余量，T-retrans是经过完整的重新传输周期所需的时间量。T-rekey应至少是T-retrans的两倍。
In order to determine that a KINK peer has lost its security database information, KINK peers MUST record the current epoch for which they have valid SA information for a peer and reflect that epoch in each AP-REQ and AP-REP message. When a KINK peer creates state for a given SA, it MUST also record the principal's epoch. If it discovers
为了确定扭结对等方已丢失其安全数据库信息，扭结对等方必须记录其具有对等方有效SA信息的当前历元，并在每个AP-REQ和AP-REP消息中反映该历元。当扭结对等体为给定SA创建状态时，它还必须记录主体的历元。如果发现
on a subsequent message that the principal's epoch has changed, it MUST consider all SAs created by that principal as invalid, and take some action such as tearing those SAs down.
在随后的消息中，校长的时代已经改变，它必须考虑所有SAS创建的主体无效，并采取一些行动，如撕裂那些SAS下来。
While a KINK peer SHOULD use feedback from routing (in the form of ICMP messages) as a trigger to check whether or not the peer is still alive, a KINK peer MUST NOT conclude the peer is dead simply based on unprotected routing information (said ICMP messages).
尽管纠结对等方应使用路由反馈（以ICMP消息的形式）作为触发器来检查对等方是否仍然存在，但纠结对等方不得仅根据未受保护的路由信息（所述ICMP消息）断定对等方已死亡。
If there is suspicion that a peer may be dead (based on any information available to the KINK peer, including lack of IPsec traffic, etc.), the KINK STATUS message SHOULD be used to coerce an acknowledgement out of the peer. Since nothing is negotiated about dead peer detection in KINK, each peer can decide its own metric for "suspicion" and also what timeouts to use before declaring a peer dead due to lack of response to the STATUS message. This is desirable, and does not break interoperability.
如果怀疑对等方可能已死亡（基于纠结对等方可用的任何信息，包括缺少IPsec通信等），则应使用纠结状态消息强制对等方确认。由于在KINK中没有关于死亡对等检测的协商，因此每个对等方可以决定其自己的“怀疑”度量，以及由于对状态消息没有响应而在宣布对等方死亡之前使用什么超时。这是可取的，并且不会破坏互操作性。
The STATUS message has a twofold effect. First, it elicits a cryptographically secured (and replay-protected) response from the peer, which tells us whether or not the peer is reachable/alive. Second, it carries the epoch number of the peer, so we know whether or not the peer has rebooted and lost all state. This is crucial to the KINK protocol: In IKE, if a peer reboots, we lose all cryptographic context, and no cryptographically secure communication is possible without renegotiating keys. In KINK, due to Kerberos tickets, we can communicate securely with a peer, even if the peer rebooted, as the shared cryptographic key used is carried in the Kerberos ticket. Thus, active cryptographic communication is not an indication that the peer has not rebooted and lost all state, and the epoch is needed.
状态消息具有双重效果。首先，它从对等方引出一个加密安全（和重播保护）响应，它告诉我们对等方是否可访问/活动。其次，它携带对等机的历元编号，因此我们知道对等机是否已重新启动并失去所有状态。这对于KINK协议至关重要：在IKE中，如果对等机重新启动，我们将丢失所有加密上下文，并且如果不重新协商密钥，就不可能进行加密安全通信。在KINK中，由于Kerberos票据，我们可以安全地与对等方通信，即使对等方重新启动，因为使用的共享加密密钥在Kerberos票据中携带。因此，主动加密通信并不表示对等方没有重新启动并失去所有状态，因此需要epoch。
Assume a Peer A sending a STATUS and a peer B sending the REPLY (see section 3.4). Peer B MAY assume that the sender is alive, and the epoch in the STATUS message will indicate whether or not the peer A has lost state. Peer B MUST acknowledge the STATUS message with a REPLY message, as described in section 3.4.
假设对等方a发送状态，对等方B发送回复（见第3.4节）。对等方B可以假设发送方是活动的，状态消息中的纪元将指示对等方A是否已丢失状态。对等方B必须通过回复消息确认状态消息，如第3.4节所述。
The REPLY message will indicate to peer A that the peer is alive, and the epoch in the REPLY will indicate whether peer B has lost its state or not. If peer A does not receive a REPLY message from peer B in a suitable timeout, peer A MAY send another STATUS message. It is up to peer A to decide how aggressively to declare peer B dead. The level of aggressiveness may depend on many factors such as rapid fail over versus number of messages sent by nodes with large numbers of SAs.
应答消息将向对等方A指示对等方处于活动状态，应答中的历元将指示对等方B是否已失去其状态。如果对等方A在适当的超时时间内没有收到来自对等方B的回复消息，则对等方A可以发送另一个状态消息。由对等方A决定如何积极宣布对等方B死亡。攻击性的级别可能取决于许多因素，例如快速故障切换与具有大量SA的节点发送的消息数量。
Note that peer B MUST NOT make any inferences about a lack of STATUS message from peer A. Peer B MAY use a STATUS message from peer A as an indication of A's aliveness, but peer B MUST NOT expect another STATUS message at any time (i.e., dead peer detection is not periodic keepalives).
请注意，对等方B不得对缺少来自对等方a的状态消息做出任何推断。对等方B可以使用来自对等方a的状态消息作为a有效性的指示，但对等方B不得在任何时候期待另一个状态消息（即，死对等方检测不是周期性的保留）。
Strategies for sending STATUS messages are the following: Peer A may decide to send a STATUS message only after a prolonged period where no traffic was sent in either direction over the IPsec SAs with the peer. Once there is traffic, peer A may want to know if the traffic is going into a black hole, and send a STATUS message. Alternatively, peer A may use an idle timer to detect lack of traffic with the peer, and send STATUS messages in the quiet phase to make sure the peer is still alive for when traffic needs to finally be sent.
发送状态消息的策略如下：对等方A可能仅在经过一段较长的时间后才决定发送状态消息，在该时间段内，没有通过IPsec SAs向任一方向发送通信量。一旦出现流量，对等A可能想知道流量是否进入黑洞，并发送状态消息。或者，对等方A可以使用空闲定时器来检测对等方的通信量不足，并在安静阶段发送状态消息，以确保对等方在需要最终发送通信量时仍然处于活动状态。
When an initiator uses a User-to-User ticket and a responder has lost its previous TGT, the usual dead peer detection (DPD) mechanism does not work, because the responder cannot decrypt the ticket with its new TGT. In this case, the following actions are taken.
当发起方使用用户对用户票证，而响应方丢失了其先前的TGT时，通常的死对等检测（DPD）机制不起作用，因为响应方无法使用其新TGT解密票证。在这种情况下，将采取以下措施。
o When the responder receives a KINK command with a User-to-User ticket that cannot be decrypted with its TGT, it returns a REPLY with a KINK_TGT_REP payload containing the TGT.
o 当响应程序接收到一个包含用户对用户票证的扭结命令，并且该票证不能用其TGT解密时，它返回一个包含TGT的扭结TGT REP有效负载的回复。
o When the initiator receives a KINK_TGT_REP, it retrieves a new service ticket with the TGT and retries the command.
o 当启动器接收到扭结TGT REP时，它将使用TGT检索新的服务票证并重试该命令。
This does not directly define a method to detect a dead User-to-User peer, but to recover from the situation that the responder does not have an appropriate TGT to decrypt a service ticket sent from the initiator. After recovery, they can exchange their epochs, and usual DPD mechanism will detect a dead peer if it really has been dead.
这并没有直接定义一种方法来检测死掉的用户对用户对等点，而是从响应者没有合适的TGT来解密从发起方发送的服务票证的情况中恢复。恢复后，他们可以交换他们的时代，通常的DPD机制将检测到一个死掉的对等体是否真的死掉了。
The initiator MUST NOT think the peer has been dead on the receipt of a KINK_TGT_REP because of two reasons. One is that the message is not authenticated, and the other is that losing a TGT does not necessarily mean losing the SA database information. The initiator SHOULD NOT forget the previous service ticket until the new one is successfully obtained in order to reduce the cost when a forged KINK_TGT_REP is received.
发起者不能因为两个原因而认为对方在收到扭结代表时已经死亡。一个是消息没有经过身份验证，另一个是丢失TGT并不一定意味着丢失SA数据库信息。发起者在成功获得新的服务票据之前不应忘记以前的服务票据，以便在收到伪造的扭结TGT代表时降低成本。
All values in KINK are formatted in network byte order (most significant byte first). The RESERVED fields MUST be set to zero (0) when a packet is sent. The receiver MUST ignore these fields.
扭结中的所有值均按网络字节顺序格式化（最高有效字节优先）。当数据包被设置为0时，必须发送（0）个字段。接收者必须忽略这些字段。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | MjVer |RESRVED| Length |
+---------------+---------------+---------------+---------------+
| Domain of Interpretation (DOI) |
+-------------------------------+-------------------------------+
| Transaction ID (XID) |
+---------------+-+-------------+-------------------------------+
| NextPayload |A| RESERVED2 | CksumLen |
+---------------+-+-------------+-------------------------------+
| |
~ A series of payloads ~
| |
+-------------------------------+-------------------------------+
| |
~ Cksum (variable) ~
| |
+-------------------------------+-------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | MjVer |RESRVED| Length |
+---------------+---------------+---------------+---------------+
| Domain of Interpretation (DOI) |
+-------------------------------+-------------------------------+
| Transaction ID (XID) |
+---------------+-+-------------+-------------------------------+
| NextPayload |A| RESERVED2 | CksumLen |
+---------------+-+-------------+-------------------------------+
| |
~ A series of payloads ~
| |
+-------------------------------+-------------------------------+
| |
~ Cksum (variable) ~
| |
+-------------------------------+-------------------------------+
Figure 5: Format of a KINK Message
图5：扭结消息的格式
Fields:
领域：
o Type (1 octet) -- The type of this message.
o 类型（1个八位组）--此消息的类型。
Type Value
----- -----
RESERVED 0
CREATE 1
DELETE 2
REPLY 3
GETTGT 4
ACK 5
STATUS 6
RESERVED TO IANA 7 - 127
Private Use 128 - 255
Type Value
----- -----
RESERVED 0
CREATE 1
DELETE 2
REPLY 3
GETTGT 4
ACK 5
STATUS 6
RESERVED TO IANA 7 - 127
Private Use 128 - 255
o MjVer (4 bits) -- Major protocol version number. This MUST be set to 1.
o MjVer（4位）--主要协议版本号。这必须设置为1。
o RESRVED (4 bits) -- Reserved and MUST be zero when sent, MUST be ignored when received.
o Reserved（4位）--保留，发送时必须为零，接收时必须忽略。
o Length (2 octets) -- Length of the message in octets. It is not forbidden in KINK that there are unnecessary data after the message, but the Length field MUST represent the actual length of the message.
o 长度（2个八位字节）——消息的长度（以八位字节为单位）。在KINK中不禁止在消息之后有不必要的数据，但长度字段必须表示消息的实际长度。
o DOI (4 octets) -- The domain of interpretation. All DOIs must be registered with the IANA in the ISAKMP Domain of Interpretation section of the isakmp-registry [ISAKMP-REG]. The IANA Assigned Number for the Internet IP Security DOI [IPDOI] is one (1). This field defines the context of all sub-payloads in this message. If sub-payloads have a DOI field (e.g., Security Association Payload), then the DOI in that sub-payload MUST be checked against the DOI in this header, and the values MUST be the same.
o DOI（4个八位组）——解释的领域。所有DOI必须在ISAKMP注册表[ISAKMP-REG]的ISAKMP解释域部分向IANA注册。IANA为互联网IP安全DOI[IPDOI]分配的编号为一（1）。此字段定义此消息中所有子有效载荷的上下文。如果子有效负载具有DOI字段（例如，安全关联有效负载），则必须对照此标头中的DOI检查该子有效负载中的DOI，并且值必须相同。
o XID (4 octets) -- The transaction ID. A KINK transaction is bound together by a transaction ID, which is created by the command initiator and replicated in subsequent messages in the transaction. A transaction is defined as a command, a reply, and an optional acknowledgement. Transaction IDs are used by the initiator to discriminate between multiple outstanding requests to a responder. It is not used for replay protection because that functionality is provided by Kerberos. The value of XID is chosen by the initiator and MUST be unique with all outstanding transactions. XIDs MAY be constructed by using a monotonic counter or random number generator.
o XID（4个八位字节）——事务ID。扭结事务由事务ID绑定在一起，事务ID由命令启动器创建，并在事务中的后续消息中复制。事务定义为命令、应答和可选确认。发起方使用事务ID来区分发送给响应方的多个未完成请求。它不用于重播保护，因为该功能由Kerberos提供。XID的值由发起人选择，并且对于所有未完成的事务必须是唯一的。XIDs可以通过使用单调计数器或随机数生成器来构造。
o NextPayload (1 octet) -- Indicates the type of the first payload after the message header.
o NextPayload（1个八位字节）——指示消息头之后的第一个有效负载的类型。
o A, or ACKREQ (1 bit) -- ACK Request. Set to one if the responder requires an explicit acknowledgement that a REPLY was received. An initiator MUST NOT set this flag, nor should a responder except for a REPLY to a CREATE when the optimistic proposal is chosen.
o A、 或ACKREQ（1位）——ACK请求。如果响应者要求明确确认已收到回复，则设置为1。当选择乐观方案时，发起人不得设置此标志，响应者也不应设置此标志，但对方案的回复除外。
o RESERVED2 (7 bits) -- Reserved and MUST be zero on send, MUST be ignored by a receiver.
o RESERVED2（7位）——保留，发送时必须为零，接收器必须忽略。
o CksumLen (2 octets) -- CksumLen is the length in octets of the cryptographic checksum of the message. A CksumLen of zero implies that the message is unauthenticated.
o CksumLen（2个八位字节）——CksumLen是消息的加密校验和的长度（以八位字节为单位）。CksumLen为零表示消息未经身份验证。
o Cksum (variable) -- Kerberos keyed checksum over the entire message excluding the Cksum field itself. When any padding bytes are required between the last payload and the Cksum field, they MUST be included in the calculation. This field MUST always be present whenever a key is available via an AP-REQ or AP-REP payload. The key used MUST be the session key in the ticket. When a key is not available, this field is not present, and the CksumLen field is set to zero. The content of this field is the output of the Kerberos 5 get_mic function [KCRYPTO]. The get_mic function used is specified by a checksum type, which is a "required checksum mechanism" of the etype for the Kerberos session key in the Kerberos ticket. If the checksum type is not a keyed algorithm, the message MUST be rejected.
o Cksum（变量）--整个消息上的Kerberos键控校验和，不包括Cksum字段本身。当最后一个有效负载和Cksum字段之间需要任何填充字节时，必须将它们包括在计算中。只要通过AP-REQ或AP-REP有效负载有密钥，该字段必须始终存在。使用的密钥必须是票证中的会话密钥。当密钥不可用时，此字段不存在，并且CksumLen字段设置为零。此字段的内容是Kerberos 5 get_mic函数[KCRYPTO]的输出。使用的get_mic函数由校验和类型指定，这是Kerberos票证中Kerberos会话密钥的etype的“必需校验和机制”。如果校验和类型不是键控算法，则必须拒绝消息。
To compute the checksum, the CksumLen field is zeroed out and the Length field is filled with the total packet length without the checksum. Then, the packet is passed to the get_mic function and its output is appended to the packet. Any KINK padding after the Cksum field is not allowed, except the Kerberos internal one, which may be included in the output of the get_mic function. Finally, the CksumLen field is filled with the checksum length and the Length field is filled with the total packet length including the checksum.
为了计算校验和，将CksumLen字段调零，并用不带校验和的数据包总长度填充长度字段。然后，将数据包传递给get_mic函数，并将其输出附加到数据包。不允许在Cksum字段之后进行任何扭结填充，Kerberos内部字段除外，该字段可能包含在get_mic函数的输出中。最后，CksumLen字段用校验和长度填充，长度字段用包括校验和的总数据包长度填充。
To verify the checksum, a length-without-checksum is calculated from the value of Length field, subtracting the CksumLen. The Length field is filled with the length-without-checksum value and the CksumLen field is zeroed out. Then, the packet without checksum (offset from 0 to length-without-checksum minus 1 of the received packet) and the checksum (offset from length-without-checksum to the last) are passed to the verify_mic function. If verification fails, the message MUST be dropped.
要验证校验和，将从长度字段的值减去CksumLen计算不带校验和的长度。长度字段用不带校验和值的长度填充，CksumLen字段为零。然后，将不带校验和的数据包（从0到不带校验和的长度的偏移量减去接收数据包的1）和校验和（从不带校验和的长度到最后一个的偏移量）传递给verify_mic函数。如果验证失败，则必须删除该消息。
The KINK header is followed immediately by a series of Type/Length/Value fields, defined in section 4.2.
扭结头后面紧跟着一系列类型/长度/值字段，定义见第4.2节。
KINK has the following rules regarding alignment and padding:
关于对齐和填充，KINK有以下规则：
o All length fields MUST reflect the actual number of octets in the structure; i.e., they do not account for padding bytes required by KINK alignments.
o 所有长度字段必须反映结构中八位字节的实际数量；i、 例如，它们不考虑纽结对齐所需的填充字节。
o KINK headers, payloads, and the Cksum field MUST be aligned on 4-octet boundaries.
o 扭结头、有效载荷和Cksum字段必须在4-octet边界上对齐。
o Variable length fields (except the Cksum field) MUST always start immediately after the last octet of the previous field. That is, they are not aligned to 4-octet boundaries.
o 可变长度字段（Cksum字段除外）必须始终在前一个字段的最后一个八位字节之后立即开始。也就是说，它们不与4-八位组边界对齐。
Immediately following the header, there is a list of Type/Length/Value (TLV) payloads. There can be any number of payloads following the header. Each payload MUST begin with a payload header. Each payload header is built on the generic payload header. Any data immediately follows the generic header. Payloads are all implicitly aligned to 4-octet boundaries, though the payload length field MUST accurately reflect the actual number of octets in the payload.
标题后面紧跟着类型/长度/值（TLV）有效载荷的列表。标题后面可以有任意数量的有效负载。每个有效负载必须以有效负载标头开始。每个有效负载标头构建在通用有效负载标头上。任何数据都紧跟在通用标题之后。有效负载都隐式地与4个八位字节边界对齐，尽管有效负载长度字段必须准确反映有效负载中八位字节的实际数量。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| value (variable) |
+---------------+---------------+---------------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| value (variable) |
+---------------+---------------+---------------+---------------+
Figure 6: Format of a KINK Payload
图6：扭结有效载荷的格式
Fields:
领域：
o Next Payload (1 octet) -- The type of the next payload.
o 下一个有效负载（1个八位字节）——下一个有效负载的类型。
NextPayload Value
---- -----
KINK_DONE 0
KINK_AP_REQ 1
KINK_AP_REP 2
KINK_KRB_ERROR 3
KINK_TGT_REQ 4
KINK_TGT_REP 5
KINK_ISAKMP 6
KINK_ENCRYPT 7
KINK_ERROR 8
RESERVED TO IANA 9 - 127
Private Use 128 - 255
NextPayload Value
---- -----
KINK_DONE 0
KINK_AP_REQ 1
KINK_AP_REP 2
KINK_KRB_ERROR 3
KINK_TGT_REQ 4
KINK_TGT_REP 5
KINK_ISAKMP 6
KINK_ENCRYPT 7
KINK_ERROR 8
RESERVED TO IANA 9 - 127
Private Use 128 - 255
Next Payload type KINK_DONE denotes that the current payload is the final payload in the message.
下一个有效负载类型KINK_DONE表示当前有效负载是消息中的最终有效负载。
o RESERVED (1 octet) -- Reserved and MUST be set to zero by a sender, MUST be ignored by a receiver.
o 保留（1个八位组）--保留，发送方必须将其设置为零，接收方必须忽略。
o Payload Length (2 octets) -- The length of this payload, including the type and length fields.
o 有效负载长度（2个八位字节）——此有效负载的长度，包括类型和长度字段。
o Value (variable) -- This value of this field depends on the type.
o 值（变量）——此字段的值取决于类型。
The KINK_AP_REQ payload relays a Kerberos AP-REQ to the responder. The AP-REQ MUST request mutual authentication.
扭结AP REQ负载将Kerberos AP-REQ中继到响应程序。AP-REQ必须请求相互认证。
This document does not specify how to generate the principal name. That is, complete principal names may be stored in local policy, Fully Qualified Domain Names (FQDNs) may be converted to principal names, IP addresses may be converted to principal names by secure name services, etc., but see the first paragraph of the Security Considerations section.
本文档未指定如何生成主体名称。也就是说，完整的主体名称可以存储在本地策略中，完全限定域名（FQDN）可以转换为主体名称，IP地址可以通过安全名称服务转换为主体名称，等等，但请参见安全注意事项部分的第一段。
If the peer's principal name for the KINK service is generated from an FQDN, the principal name, which the initiator starts from, will be "kink/fqdn@REALM"; where "kink" is a literal string for the KINK IPsec service, "fqdn" is the fully qualified domain name of the service host, and "REALM" is the Kerberos realm of the service. A principal name is case sensitive, and "fqdn" part MUST be lowercase as described in [KERBEROS].
如果对等方的扭结服务主体名称是从FQDN生成的，则发起方从其开始的主体名称将是“扭结”/fqdn@REALM"; 其中，“kink”是kink IPsec服务的文本字符串，“fqdn”是服务主机的完全限定域名，“REALM”是服务的Kerberos领域。主体名称区分大小写，“fqdn”部分必须是小写的，如[KERBEROS]中所述。
The value field of this payload has the following format:
此有效负载的值字段具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| EPOCH |
+---------------------------------------------------------------+
| |
~ AP-REQ ~
| |
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| EPOCH |
+---------------------------------------------------------------+
| |
~ AP-REQ ~
| |
+---------------------------------------------------------------+
Figure 7: KINK_AP_REQ Payload
图7：扭结AP请求有效载荷
Fields:
领域：
o Next Payload, RESERVED, Payload Length -- Defined in the beginning of this section.
o 下一个有效负载，保留，有效负载长度——在本节开头定义。
o EPOCH -- The absolute time at which the creator of the AP-REQ has valid SA information. Typically, this is when the KINK keying daemon started if it does not retain SA information across restarts. The value in this field is the least significant 4 octets of so-called POSIX time, which is the elapsed seconds (but without counting leap seconds) from 1970-01-01T00:00:00 UTC. For example, 2038-01-19T03:14:07 UTC is represented as 0x7fffffff.
o 历元——AP-REQ的创建者拥有有效SA信息的绝对时间。通常情况下，如果扭结键控守护程序在重新启动期间不保留SA信息，则会在此时启动。此字段中的值是所谓POSIX时间的最低有效4个八位字节，即从1970-01-01T00:00:00 UTC经过的秒数（但不计算闰秒）。例如，2038-01-19T03:14:07 UTC表示为0x7fffffff。
o AP-REQ -- The value field of this payload contains a raw Kerberos AP-REQ.
o AP-REQ——此有效负载的值字段包含原始Kerberos AP-REQ。
The KINK_AP_REP payload relays a Kerberos AP-REP to the initiator. The AP-REP MUST be checked for freshness as described in [KERBEROS].
KINK_AP_REP有效负载将Kerberos AP-REP中继到启动器。必须按照[KERBEROS]中的说明检查AP-REP的新鲜度。
The value field of this payload has the following format:
此有效负载的值字段具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| EPOCH |
+---------------------------------------------------------------+
| |
~ AP-REP ~
| |
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| EPOCH |
+---------------------------------------------------------------+
| |
~ AP-REP ~
| |
+---------------------------------------------------------------+
Figure 8: KINK_AP_REP Payload
图8：扭结AP REP有效载荷
Fields:
领域：
o Next Payload, RESERVED, Payload Length -- Defined in the beginning of this section.
o 下一个有效负载，保留，有效负载长度——在本节开头定义。
o EPOCH -- The absolute time at which the creator of the AP-REP has valid SA information. Typically, this is when the KINK keying daemon started if it does not retain SA information across restarts. The value in this field is the least significant 4 octets of so-called POSIX time, which is the elapsed seconds (but without counting leap seconds) from 1970-01-01T00:00:00 UTC. For example, 2038-01-19T03:14:07 UTC is represented as 0x7fffffff.
o 历元——AP-REP的创建者拥有有效SA信息的绝对时间。通常情况下，如果扭结键控守护程序在重新启动期间不保留SA信息，则会在此时启动。此字段中的值是所谓POSIX时间的最低有效4个八位字节，即从1970-01-01T00:00:00 UTC经过的秒数（但不计算闰秒）。例如，2038-01-19T03:14:07 UTC表示为0x7fffffff。
o AP-REP -- The value field of this payload contains a raw Kerberos AP-REP.
o AP-REP——此有效负载的值字段包含原始Kerberos AP-REP。
The KINK_KRB_ERROR payload relays Kerberos type errors back to the initiator. The initiator MUST be prepared to receive any valid Kerberos error type [KERBEROS].
扭结KRB_错误负载将Kerberos类型错误中继回启动器。启动器必须准备好接收任何有效的Kerberos错误类型[Kerberos]。
KINK implementations SHOULD make use of a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate service key is available. Especially in the case of clock skew errors, protecting the error at the server creates a better user experience because it does not require clocks to be synchronized. However, many Kerberos implementations do not make it easy to obtain the session key in order to protect error packets. For unauthenticated Kerberos errors, the initiator MAY choose to act on them, but SHOULD take precautions against make-work kinds of attacks.
当返回KINK_KRB_错误并且有适当的服务密钥可用时，扭结实现应该使用扭结校验和字段。特别是在时钟偏移错误的情况下，在服务器上保护错误可以创建更好的用户体验，因为它不需要同步时钟。但是，为了保护错误数据包，许多Kerberos实现不容易获取会话密钥。对于未经身份验证的Kerberos错误，发起方可以选择对其进行操作，但应采取预防措施，防止各种攻击。
Note that KINK does not make use of the text or e_data field of the Kerberos error message, though a compliant KINK implementation MUST be prepared to receive them and MAY log them.
请注意，KINK不使用Kerberos错误消息的text或e_数据字段，但必须准备一个兼容的KINK实现来接收它们，并可能记录它们。
The value field of this payload has the following format:
此有效负载的值字段具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| |
~ KRB-ERROR ~
| |
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| |
~ KRB-ERROR ~
| |
+---------------------------------------------------------------+
Figure 9: KINK_KRB_ERROR Payload
图9：扭结KRB_错误有效载荷
Fields:
领域：
o Next Payload, RESERVED, Payload Length -- Defined in the beginning of this section.
o 下一个有效负载，保留，有效负载长度——在本节开头定义。
o KRB-ERROR -- The value field of this payload contains a raw Kerberos KRB-ERROR.
o KRB-ERROR——此有效负载的值字段包含原始Kerberos KRB-ERROR。
The KINK_TGT_REQ payload provides a means to get a TGT from the peer in order to obtain a User-to-User service ticket from the KDC.
KINK_TGT_REQ有效负载提供了一种从对等方获取TGT的方法，以便从KDC获取用户对用户服务票证。
The value field of this payload has the following format:
此有效负载的值字段具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| |
~ PrincName (variable) ~
| |
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| |
~ PrincName (variable) ~
| |
+---------------------------------------------------------------+
Figure 10: KINK_TGT_REQ Payload
图10：扭结TGT请求有效载荷
Fields:
领域：
o Next Payload, RESERVED, Payload Length -- Defined in the beginning of this section.
o 下一个有效负载，保留，有效负载长度——在本节开头定义。
o PrincName -- The name of the principal that the initiator wants to communicate with. It is assumed that the initiator knows the responder's principal name (including the realm name) in the same way as the non-User-to-User case. The TGT returned MUST NOT be an inter-realm TGT and its cname and crealm MUST match the requested principal name, so that the initiator can rendezvous with the responder at the responder's realm.
o PrincName--发起程序要与之通信的主体的名称。假设发起方知道响应方的主体名称（包括领域名称），其方式与非用户对用户的情况相同。返回的TGT不能是域间TGT，其cname和crealm必须与请求的主体名称匹配，以便启动器可以在响应者的域与响应者会合。
PrincName values are octet string representations of a principal and realm name formatted just like the octet string used in the "NAME" component of Generic Security Service Application Program Interface (GSS-API) [RFC2743] exported name token for the Kerberos V5 GSS-API mechanism [RFC1964]. See RFC 1964, section 2.1.3.
PrincName值是主体和领域名称的八位字符串表示形式，其格式与通用安全服务应用程序接口（GSS-API）[RFC2743]导出的Kerberos V5 GSS-API机制的名称令牌[RFC1964]的“名称”组件中使用的八位字符串相同。见RFC 1964，第2.1.3节。
If the responder is not the requested principal and is unable to get a TGT for the name, it MAY return a KRB_AP_ERR_NOT_US. If the administrative policy prohibits returning a TGT, it MAY return a KINK_U2UDENIED.
如果响应者不是请求的主体，并且无法获取名称的TGT，则可能会返回KRB_AP_ERR_not_US。如果行政政策禁止返回TGT，则可能返回扭结。
The value field of this payload contains the TGT requested in a previous KINK_TGT_REQ payload of a GETTGT command.
此有效负载的值字段包含在GETTGT命令的前一个KINK_TGT_REQ有效负载中请求的TGT。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| |
~ TGT (variable) ~
| |
+---------------------------------------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| |
~ TGT (variable) ~
| |
+---------------------------------------------------------------+
Figure 11: KINK_TGT_REP Payload
图11：扭结TGT REP有效载荷
Fields:
领域：
o Next Payload, RESERVED, Payload Length -- Defined in the beginning of this section.
o 下一个有效负载，保留，有效负载长度——在本节开头定义。
o TGT -- The Distinguished Encoding Rules (DER)-encoded TGT of the responder.
o TGT——响应程序的可分辨编码规则（DER）编码的TGT。
The value field of this payload has the following format:
此有效负载的值字段具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+-------+-------+---------------+---------------+
| InnerNextPload| QMMaj | QMMin | RESERVED |
+---------------+-------+-------+---------------+---------------+
| Quick Mode Payloads (variable) |
+---------------+---------------+---------------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+-------+-------+---------------+---------------+
| InnerNextPload| QMMaj | QMMin | RESERVED |
+---------------+-------+-------+---------------+---------------+
| Quick Mode Payloads (variable) |
+---------------+---------------+---------------+---------------+
Figure 12: KINK_ISAKMP Payload
图12：扭结ISAKMP有效载荷
Fields:
领域：
o Next Payload, RESERVED, Payload Length -- Defined in the beginning of this section.
o 下一个有效负载，保留，有效负载长度——在本节开头定义。
o InnerNextPload -- First payload type of the inner series of ISAKMP payloads.
o InnerNextPload——ISAKMP有效载荷内部系列的第一种有效载荷类型。
o QMMaj -- The major version of the inner payloads. MUST be set to 1.
o QMMaj——内部有效负载的主要版本。必须设置为1。
o QMMin -- The minor version of the inner payloads. MUST be set to 0.
o QMMin——内部有效负载的次要版本。必须设置为0。
The KINK_ISAKMP payload encapsulates the IKE Quick Mode (phase 2) payloads to take the appropriate action dependent on the KINK command. There may be any number of KINK_ISAKMP payloads within a single KINK message. While [IKE] is somewhat fuzzy about whether multiple different SAs may be created within a single IKE message, KINK explicitly requires that a new ISAKMP header be used for each discrete SA operation. In other words, a KINK implementation MUST NOT send multiple Quick Mode transactions within a single KINK_ISAKMP payload.
扭结ISAKMP有效载荷封装IKE快速模式（第2阶段）有效载荷，以根据扭结命令采取适当的行动。单个扭结消息中可能有任意数量的扭结ISAKMP有效负载。虽然[IKE]对于是否可以在单个IKE消息中创建多个不同的SA有些模糊，但KINK明确要求为每个离散SA操作使用新的ISAKMP头。换句话说，扭结实现不能在单个扭结ISAKMP负载内发送多个快速模式事务。
The purpose of the Quick Mode version is to allow backward compatibility with IKE and ISAKMP if there are subsequent revisions. At the present time, the Quick Mode major and minor versions are set to one and zero (1.0), respectively. These versions do not correspond to the ISAKMP version in the ISAKMP header. A compliant KINK implementation MUST support receipt of 1.0 payloads. It MAY support subsequent versions (both sending and receiving), and SHOULD provide a means to resort back to Quick Mode version 1.0 if the KINK peer is unable to process future versions. A compliant KINK implementation MUST NOT mix Quick Mode versions in any given transaction.
快速模式版本的目的是允许在有后续修订的情况下向后兼容IKE和ISAKMP。目前，快速模式主版本和次版本分别设置为1和0（1.0）。这些版本与ISAKMP标头中的ISAKMP版本不对应。兼容的扭结实现必须支持接收1.0有效负载。它可能支持后续版本（包括发送和接收），如果扭结对等方无法处理未来版本，则应提供返回快速模式版本1.0的方法。兼容的扭结实现不能在任何给定事务中混合使用快速模式版本。
The KINK_ENCRYPT payload encapsulates other KINK payloads and is encrypted using the session key and the algorithm specified by its etype. This payload MUST be the final one in the outer payload chain of the message. The KINK_ENCRYPT payload MUST be encrypted before the final KINK checksum is applied.
扭结加密有效负载封装了其他扭结有效负载，并使用会话密钥及其etype指定的算法进行加密。该有效载荷必须是消息外部有效载荷链中的最后一个有效载荷。在应用最终的扭结校验和之前，必须对扭结加密有效负载进行加密。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| InnerNextPload| RESERVED2 |
+---------------+---------------+---------------+---------------+
| Payload (variable) |
+---------------+---------------+---------------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| InnerNextPload| RESERVED2 |
+---------------+---------------+---------------+---------------+
| Payload (variable) |
+---------------+---------------+---------------+---------------+
Figure 13: KINK_ENCRYPT Payload
图13：扭结加密有效负载
Fields:
领域：
o Next Payload, RESERVED, Payload Length -- Defined in the beginning of this section. This payload is the last one in a message, and accordingly, the Next Payload field must be KINK_DONE (0).
o 下一个有效负载，保留，有效负载长度——在本节开头定义。此有效负载是消息中的最后一个有效负载，因此，下一个有效负载字段必须为KINK_DONE（0）。
o InnerNextPload -- First payload type of the inner series of encrypted KINK payloads.
o InnerNextLoad——内部加密扭结有效负载系列的第一种有效负载类型。
o RESERVED2 -- Reserved and MUST be zero when sent, MUST be ignored when received.
o RESERVED2——保留，发送时必须为零，接收时必须忽略。
The coverage of the encrypted data begins at InnerNextPload so that the first payload's type is kept confidential. Thus, the number of encrypted octets is PayloadLength - 4.
加密数据的覆盖范围从InnerNextLoad开始，因此第一个有效负载的类型是保密的。因此，加密的八位字节数是PayloadLength-4。
The format of the encryption payload follows the normal Kerberos semantics. Its content is the output of an encrypt function defined in the Encryption Algorithm Profile section of [KCRYPTO]. Parameters such as encrypt function itself, specific-key, and initial state are defined with the etype. The encrypt function may have padding in itself and there may be some garbage data at the end of the decrypted plaintext. A KINK implementation MUST be prepared to ignore such padding after the last sub-payload inside the KINK_ENCRYPT payload. Note that each encrypt function has its own integrity protection mechanism. It is redundant with the checksum in the KINK header, but this is unavoidable because it is not always possible to remove the integrity protection part from the encrypt function.
加密负载的格式遵循正常的Kerberos语义。其内容是[KCRYPTO]的加密算法配置文件部分中定义的加密函数的输出。诸如加密函数本身、特定密钥和初始状态等参数是用etype定义的。encrypt函数本身可能有填充，并且在解密的明文末尾可能有一些垃圾数据。扭结实现必须准备好在扭结加密负载内的最后一个子负载之后忽略这种填充。请注意，每个加密函数都有自己的完整性保护机制。它与扭结头中的校验和是冗余的，但这是不可避免的，因为不可能总是从加密函数中删除完整性保护部分。
The KINK_ERROR payload type provides a protocol-level mechanism of returning an error condition. This payload should not be used for either Kerberos-generated errors or DOI-specific errors that have their own payloads defined. The error code is in network order.
扭结错误有效负载类型提供了返回错误条件的协议级机制。此有效负载不应用于Kerberos生成的错误或定义了自己有效负载的特定于DOI的错误。错误代码符合网络顺序。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| ErrorCode |
+---------------+---------------+---------------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| ErrorCode |
+---------------+---------------+---------------+---------------+
Figure 14: KINK_ERROR Payload
图14：扭结错误有效载荷
Fields:
领域：
o Next Payload, RESERVED, Payload Length -- Defined in the beginning of this section.
o 下一个有效负载，保留，有效负载长度——在本节开头定义。
o ErrorCode -- One of the following values in the network byte order:
o ErrorCode--网络字节顺序中的以下值之一：
ErrorCode Value Purpose
--------- ----- -------------------
KINK_OK 0 No error detected
KINK_PROTOERR 1 The message was malformed
KINK_INVDOI 2 Invalid DOI
KINK_INVMAJ 3 Invalid Major Version
RESERVED 4
KINK_INTERR 5 An unrecoverable internal error
KINK_BADQMVERS 6 Unsupported Quick Mode Version
KINK_U2UDENIED 7 Returning a TGT is prohibited
RESERVED TO IANA 8 - 8191
Private Use 8192 - 16383
RESERVED 16384 -
ErrorCode Value Purpose
--------- ----- -------------------
KINK_OK 0 No error detected
KINK_PROTOERR 1 The message was malformed
KINK_INVDOI 2 Invalid DOI
KINK_INVMAJ 3 Invalid Major Version
RESERVED 4
KINK_INTERR 5 An unrecoverable internal error
KINK_BADQMVERS 6 Unsupported Quick Mode Version
KINK_U2UDENIED 7 Returning a TGT is prohibited
RESERVED TO IANA 8 - 8191
Private Use 8192 - 16383
RESERVED 16384 -
The responder MUST NOT return KINK_OK. When received, the initiator MAY act as if the specific KINK_ERROR payload were not present. If the initiator supports multiple Quick Mode versions or DOIs, KINK_BADQMVERS or KINK_INVDOI is received, and the Cksum is verified, then it MAY retry with another version or DOI. A responder SHOULD return a KINK error with KINK_INVMAJ, when it receives an unsupported KINK version number in the header. When KINK_U2UDENIED is received, the initiator MAY retry with the non-User-to-User mode (if it has not yet been tried).
响应者不得返回扭结OK。收到时，启动器可能会表现得好像特定的扭结错误负载不存在一样。如果启动器支持多个快速模式版本或DOI，收到扭结BADQMVERS或扭结INVDOI，并验证校验和，则可以使用其他版本或DOI重试。当响应程序在标头中接收到不支持的纽结版本号时，应返回带有纽结INVMAJ的纽结错误。当收到扭结时，发起者可以使用非用户对用户模式重试（如果尚未尝试）。
In general, the responder MAY choose to return these errors in reply to unauthenticated commands, but SHOULD take care to avoid being involved in denial of service attacks. Similarly, the initiator MAY choose to act on unauthenticated errors, but SHOULD take care to avoid denial of service attacks.
一般来说，响应者可以选择返回这些错误以响应未经验证的命令，但应注意避免参与拒绝服务攻击。类似地，发起方可以选择对未经验证的错误采取行动，但应注意避免拒绝服务攻击。
KINK directly uses ISAKMP payloads to negotiate SAs. In particular, KINK uses IKE phase 2 payload types (aka Quick Mode). In general, there should be very few changes necessary to an IKE implementation to establish the SAs, and unless there is a note to the contrary in the memo, all capabilities and requirements in [IKE] MUST be supported. IKE phase 1 payloads MUST NOT be sent.
KINK直接使用ISAKMP有效载荷协商SAs。特别是，KINK使用IKE阶段2有效负载类型（也称为快速模式）。一般来说，为了建立SAs，IKE实现应该很少需要更改，除非备忘录中有相反的说明，否则必须支持[IKE]中的所有功能和要求。不得发送IKE阶段1有效载荷。
Unlike IKE, KINK defines specific commands for creation, deletion, and status of SAs, mainly to facilitate predictable SA creation/deletion (see sections 3.2 and 3.3). As such, KINK places certain restrictions on what payloads may be sent with which commands, and some additional restrictions and semantics of some of the payloads. Implementors should refer to [IKE] and [ISAKMP] for the actual format and semantics. If a particular IKE phase 2 payload is not mentioned here, it means that there are no differences in its use.
与IKE不同，KINK为SA的创建、删除和状态定义了特定的命令，主要用于促进可预测的SA创建/删除（参见第3.2和3.3节）。因此，KINK对哪些命令可以发送哪些有效负载以及某些有效负载的一些附加限制和语义设置了某些限制。实现者应该参考[IKE]和[ISAKMP]了解实际的格式和语义。如果此处未提及特定的IKE阶段2有效负载，则表示其使用没有差异。
o The Security Association Payload header for IP is defined in section 4.6.1 of [IPDOI]. For this memo, the Domain of Interpretation MUST be set to 1 (IPsec) and the Situation bitmap MUST be set to 1 (SIT_IDENTITY_ONLY). All other fields are omitted (because SIT_IDENTITY_ONLY is set).
o [IPDOI]的第4.6.1节定义了IP的安全关联有效负载头。对于此备忘录，解释域必须设置为1（IPsec），情况位图必须设置为1（仅SIT_IDENTITY_）。省略所有其他字段（因为只设置了SIT_IDENTITY_）。
o KINK also expands the semantics of IKE in that it defines an optimistic proposal for CREATE commands to allow SA creation to complete in two messages.
o KINK还扩展了IKE的语义，因为它为CREATE命令定义了一个乐观的方案，以允许SA创建在两条消息中完成。
o IKE Quick Mode (phase 2) uses the hash algorithm used in main mode (phase 1) to generate the keying material. For this purpose, KINK MUST use a pseudo-random function determined by the etype of the session key.
o IKE快速模式（第2阶段）使用主模式（第1阶段）中使用的哈希算法生成关键帧材料。为此，KINK必须使用由会话密钥的etype确定的伪随机函数。
o KINK does not use the HASH payload at all.
o KINK根本不使用哈希有效负载。
o KINK allows the Nonce payload Nr to be optional to facilitate optimistic keying.
o 扭结允许Nonce有效负载Nr是可选的，以便于乐观键控。
KINK supports the following SA attributes from [IPDOI]:
KINK支持[IPDOI]中的以下SA属性：
class value type
-------------------------------------------------
SA Life Type 1 B
SA Life Duration 2 V
Encapsulation Mode 4 B
Authentication Algorithm 5 B
Key Length 6 B
Key Rounds 7 B
class value type
-------------------------------------------------
SA Life Type 1 B
SA Life Duration 2 V
Encapsulation Mode 4 B
Authentication Algorithm 5 B
Key Length 6 B
Key Rounds 7 B
Refer to [IPDOI] for the actual definitions of these attributes.
有关这些属性的实际定义，请参阅[IPDOI]。
KINK directly uses the Proposal and Transform payloads with no differences. KINK, however, places additional relevance to the first proposal and first transform of each conjugate for optimistic keying.
KINK直接使用方案并转换有效负载，没有任何差异。然而，扭结为乐观键控的每个共轭的第一个建议和第一个变换提供了额外的相关性。
The Identification payload carries information that is used to identify the traffic that is to be protected by the SA that will be established. KINK restricts the ID types, which are defined in section 4.6.2.1 of [IPDOI], to the following values:
识别有效载荷携带用于识别将由将建立的SA保护的通信量的信息。扭结将[IPDOI]第4.6.2.1节中定义的ID类型限制为以下值：
ID Type Value
------- -----
ID_IPV4_ADDR 1
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
ID Type Value
------- -----
ID_IPV4_ADDR 1
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
The Nonce payload contains random data that MUST be used in key generation. It MUST be sent by the initiating KINK peer, and MAY be sent by the responding KINK peer. See section 7 for the discussion of its use in key generation.
Nonce有效负载包含密钥生成中必须使用的随机数据。它必须由发起的纽结对等方发送，也可以由响应的纽结对等方发送。有关在密钥生成中使用它的讨论，请参见第7节。
Notify payloads are used to transmit several informational data, such as error conditions and state transitions to a peer. For example, notification information transmit can be error messages specifying why an SA could not be established. It can also be status data that a process managing an SA database wishes to communicate with a peer process.
Notify有效载荷用于向对等方传输多个信息数据，例如错误条件和状态转换。例如，通知信息传输可以是错误消息，指定无法建立SA的原因。它也可以是管理SA数据库的进程希望与对等进程通信的状态数据。
Types in the range 0 - 16383 are intended for reporting errors [ISAKMP]. An implementation receiving a type in this range that it does not recognize in a response MUST assume that the corresponding request has failed entirely. Unrecognized error types in a request and status types in a request or response MUST be ignored, and they SHOULD be logged. Notify payloads with status types MAY be added to any message and MUST be ignored if not recognized. They are intended to indicate capabilities, and as part of SA negotiation are used to negotiate non-cryptographic parameters.
范围为0-16383的类型用于报告错误[ISAKMP]。接收到此范围内的类型但在响应中无法识别的实现必须假定相应的请求已完全失败。必须忽略请求中无法识别的错误类型以及请求或响应中的状态类型，并记录它们。具有状态类型的Notify payloads可添加到任何消息中，如果无法识别，则必须忽略。它们用于指示功能，作为SA协商的一部分，用于协商非加密参数。
The table below lists the Notification messages and their corresponding values. PAYLOAD-MALFORMED denotes some error types defined by [ISAKMP]. Hence INVALID-PROTOCOL-ID, for example, is not used in this document. INVALID-MAJOR-VERSION and INVALID-MINOR-VERSION are not used because KINK_BADQMVERS is used to tell the initiator that the version of IKE is not supported.
下表列出了通知消息及其相应的值。PAYLOAD-MALFORMED表示由[ISAKMP]定义的某些错误类型。因此，例如，本文档中未使用INVALID-PROTOCOL-ID。未使用INVALID-MARY-VERSION和INVALID-MARY-VERSION，因为KINK_BADQMERS用于告诉启动器IKE的版本不受支持。
NOTIFY MESSAGES - ERROR TYPES Value
----------------------------- -----
INVALID-PAYLOAD-TYPE 1
NOTIFY MESSAGES - ERROR TYPES Value
----------------------------- -----
INVALID-PAYLOAD-TYPE 1
Sent if the ISAKMP payload type is not recognized. It is also sent when the KE payload is not supported by the responder. Notification Data MUST contains the one-octet payload type.
如果无法识别ISAKMP有效负载类型，则发送。当响应者不支持KE有效负载时，也会发送该消息。通知数据必须包含一个八位字节的有效负载类型。
INVALID-SPI 11
无效-SPI 11
Sent if the responder has an SPI indicated by the initiator in case of CREATE flow, or if the responder does not have an SPI indicated by the initiator in case of DELETE flow.
在创建流的情况下，如果响应程序具有发起者指示的SPI，或者在删除流的情况下，如果响应程序没有发起者指示的SPI，则发送。
NO-PROPOSAL-CHOSEN 14
没有选择的建议14
Sent if none of the proposals in the SA payload was acceptable.
如果SA有效负载中的任何建议都不可接受，则发送。
PAYLOAD-MALFORMED 16
负载-畸形16
Sent if the KINK_ISAKMP payload received was invalid because some type, length, or value was out of range. It is also sent when the request was rejected for reason that was not matched with other error types.
如果接收到的扭结ISAKMP有效负载无效，因为某些类型、长度或值超出范围，则发送。当请求因与其他错误类型不匹配的原因而被拒绝时，也会发送该消息。
KINK directly uses ISAKMP Delete payloads with no changes.
KINK直接使用ISAKMP Delete有效载荷，不做任何更改。
IKE requires that perfect forward secrecy (PFS) be supported through the use of the KE payload. KINK retains the ability to use PFS, but relaxes the requirement from must implement to SHOULD implement. The reasons are described in the Security Considerations section.
IKE要求通过使用KE有效载荷来支持完美前向保密（PFS）。KINK保留了使用PFS的能力，但将需求从必须实现放宽到应该实现。安全注意事项部分描述了原因。
All commands, responses, and acknowledgements are bound together by the XID field of the message header. The XID is normally a monotonically incrementing field, and is used by the initiator to differentiate between outstanding requests to a responder. The XID field does not provide replay protection as that functionality is provided by the Kerberos mechanisms. In addition, commands and responses MUST use a cryptographic checksum over the entire message if the two peers share a key via a ticket exchange.
消息头的XID字段将所有命令、响应和确认绑定在一起。XID通常是一个单调递增的字段，发起者使用它来区分发送给响应者的未完成请求。XID字段不提供重播保护，因为该功能由Kerberos机制提供。此外，如果两个对等方通过票据交换共享密钥，则命令和响应必须在整个消息上使用加密校验和。
In all cases in this section, if a message contains a KINK_AP_REQ or KINK_AP_REP payload, other KINK payloads MAY be encapsulated in a KINK_ENCRYPT payload.
在本节中的所有情况下，如果消息包含扭结AP_REQ或扭结AP_REP有效载荷，则其他扭结有效载荷可封装在扭结加密有效载荷中。
The REPLY message is a generic reply that MUST contain either a KINK_AP_REP, a KINK_KRB_ERROR, or a KINK_ERROR payload. REPLY messages MAY contain additional DOI-specific payloads such as ISAKMP payloads that are defined in the following sections.
回复消息是一个通用回复，必须包含扭结AP_代表、扭结KRB_错误或扭结错误负载。回复消息可能包含其他特定于DOI的有效载荷，如以下章节中定义的ISAKMP有效载荷。
ACKs are sent only when the ACKREQ bit is set in a REPLY message. An ACK message MUST contain an AP-REQ payload and no other payload.
只有在应答消息中设置了ACKREQ位时，才会发送ACK。ACK消息必须包含AP-REQ有效负载，而不包含其他有效负载。
This message initiates an establishment of new security association(s). The CREATE message must contain an AP-REQ payload and any DOI-specific payloads.
此消息启动新安全关联的建立。创建消息必须包含AP-REQ有效负载和任何特定于DOI的有效负载。
CREATE KINK Header
KINK_AP_REQ
[KINK_ENCRYPT]
KINK_ISAKMP payloads
SA Payload
Proposal Payloads
Transform Payloads
Nonce Payload (Ni)
[KE]
[IDci, IDcr]
[Notification Payloads]
CREATE KINK Header
KINK_AP_REQ
[KINK_ENCRYPT]
KINK_ISAKMP payloads
SA Payload
Proposal Payloads
Transform Payloads
Nonce Payload (Ni)
[KE]
[IDci, IDcr]
[Notification Payloads]
Replies are of the following forms:
答复的形式如下：
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_ISAKMP payloads
SA Payload
Proposal Payloads
Transform Payload
[Nonce Payload (Nr)]
[KE]
[IDci, IDcr]
[Notification Payloads]
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_ISAKMP payloads
SA Payload
Proposal Payloads
Transform Payload
[Nonce Payload (Nr)]
[KE]
[IDci, IDcr]
[Notification Payloads]
Note that there MUST be at least a single proposal payload and a single transform payload in REPLY messages. There will be multiple proposal payloads only when an SA bundle is negotiated. Also: unlike IKE, the Nonce payload Nr is not required, and if it exists, an acknowledgement must be requested to indicate that the initiator's outgoing SAs must be modified. If any of the first proposals are not chosen by the recipient, it SHOULD include the Nonce payload.
请注意，回复消息中必须至少有一个建议负载和一个转换负载。只有在协商SA捆绑包时，才会有多个提案有效载荷。另外：与IKE不同，不需要Nonce有效负载Nr，如果存在，则必须请求确认以指示必须修改启动器的传出SA。如果收件人未选择任何第一个方案，则应包括当前有效载荷。
KINK, like IKE, allows the creation of many SAs in one create command. If any of the optimistic proposals are not chosen by the responder, it MUST request an ACK.
与IKE一样，KINK允许在一个create命令中创建多个SA。如果响应者未选择任何乐观方案，则必须请求确认。
If an IPsec DOI-specific error is encountered, the responder must reply with a Notify payload describing the error:
如果遇到特定于IPsec DOI的错误，响应者必须使用描述错误的Notify有效负载进行回复：
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payloads
[Notification Payloads]
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payloads
[Notification Payloads]
If the responder finds a Kerberos error for which it can produce a valid authenticator, the REPLY takes the following form:
如果响应程序发现一个Kerberos错误，它可以为该错误生成有效的身份验证器，则响应将采用以下形式：
REPLY KINK Header KINK_AP_REP [KINK_ENCRYPT] KINK_KRB_ERROR
回复扭结头扭结AP_REP[扭结加密]扭结KRB_错误
Finally, if the responder finds a Kerberos or KINK type of error for which it cannot create an AP-REP, it MUST reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
最后，如果响应程序发现Kerberos或扭结类型的错误，而无法为其创建AP-REP，则必须使用单独的扭结KRB_错误或扭结错误负载进行响应：
REPLY KINK Header [KINK_KRB_ERROR] [KINK_ERROR]
回复扭结头[KINK_KRB_ERROR][KINK_ERROR]
This message indicates that the sending peer has deleted or will shortly delete Security Association(s) with the other peer.
此消息表示发送对等方已删除或即将删除与其他对等方的安全关联。
DELETE KINK Header KINK_AP_REQ [KINK_ENCRYPT] KINK_ISAKMP payloads Delete Payloads [Notification Payloads]
删除扭结头扭结AP_请求[扭结加密]扭结ISAKMP有效载荷删除有效载荷[通知有效载荷]
There are three forms of replies for a DELETE. The normal form is:
删除有三种形式的答复。标准形式为：
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payloads
Delete Payloads
[Notification Payloads]
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payloads
Delete Payloads
[Notification Payloads]
If an IPsec DOI-specific error is encountered, the responder must reply with a Notify payload describing the error:
如果遇到特定于IPsec DOI的错误，响应者必须使用描述错误的Notify有效负载进行回复：
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payloads
[Notification Payloads]
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payloads
[Notification Payloads]
If the responder finds a Kerberos error for which it can produce a valid authenticator, the REPLY takes the following form:
如果响应程序发现一个Kerberos错误，它可以为该错误生成有效的身份验证器，则响应将采用以下形式：
REPLY KINK Header KINK_AP_REP [KINK_ENCRYPT] KINK_KRB_ERROR
回复扭结头扭结AP_REP[扭结加密]扭结KRB_错误
If the responder finds a KINK or Kerberos type of error, it MUST reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
如果响应程序发现扭结或Kerberos类型的错误，则必须使用单独的扭结KRB_错误或扭结错误负载进行响应：
REPLY KINK Header [KINK_KRB_ERROR] [KINK_ERROR]
回复扭结头[KINK_KRB_ERROR][KINK_ERROR]
The STATUS command is used in two ways:
STATUS命令有两种使用方式：
1) As a means to relay an ISAKMP Notification message.
1) 作为中继ISAKMP通知消息的一种方式。
2) As a means of probing a peer whether its epoch has changed for dead peer detection.
2) 作为探测对等点的一种手段，它的时代是否已经改变，以检测死点。
STATUS contains the following payloads: KINK Header KINK_AP_REQ [[KINK_ENCRYPT] KINK_ISAKMP payload [Notification Payloads]]
状态包含以下有效载荷：扭结头扭结AP_请求[[扭结加密]扭结ISAKMP有效载荷[通知有效载荷]]
There are three forms of replies for a STATUS. The normal form is:
有三种形式的状态回复。标准形式为：
REPLY KINK Header
KINK_AP_REP
[[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payload
[Notification Payloads]]
REPLY KINK Header
KINK_AP_REP
[[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payload
[Notification Payloads]]
If the responder finds a Kerberos error for which it can produce a valid authenticator, the REPLY takes the following form:
如果响应程序发现一个Kerberos错误，它可以为该错误生成有效的身份验证器，则响应将采用以下形式：
REPLY KINK Header KINK_AP_REP [KINK_ENCRYPT] KINK_KRB_ERROR
回复扭结头扭结AP_REP[扭结加密]扭结KRB_错误
If the responder finds a KINK or Kerberos type of error, it MUST reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
如果响应程序发现扭结或Kerberos类型的错误，则必须使用单独的扭结KRB_错误或扭结错误负载进行响应：
REPLY KINK Header [KINK_KRB_ERROR] [KINK_ERROR]
回复扭结头[KINK_KRB_ERROR][KINK_ERROR]
A GETTGT command is only used to carry a Kerberos TGT and is not related to SA management; therefore, it contains only KINK_TGT_REQ payload and does not contain any DOI-specific payload.
GETTGT命令仅用于携带Kerberos TGT，与SA管理无关；因此，它只包含KINK_TGT_REQ负载，不包含任何特定于DOI的负载。
There are two forms of replies for a GETTGT. In the normal form, where the responder is allowed to return its TGT, the REPLY contains KINK_TGT_REP payload. If the responder is not allowed to return its TGT, it MUST reply with a KINK_ERROR payload.
GETTGT有两种答复形式。在正常形式中，如果允许响应者返回其TGT，则应答包含KINK_TGT_REP有效负载。如果不允许响应程序返回其TGT，则它必须使用扭结错误负载进行响应。
KINK uses the same key derivation mechanisms defined in section 5.5 of [IKE], which is:
KINK使用[IKE]第5.5节中定义的相同密钥派生机制，即：
KEYMAT = prf(SKEYID_d, [g(qm)^xy |] protocol | SPI | Ni_b [| Nr_b])
KEYMAT = prf(SKEYID_d, [g(qm)^xy |] protocol | SPI | Ni_b [| Nr_b])
The following differences apply:
以下差异适用：
o prf is the pseudo-random function corresponding to the session key's etype. They are defined in [KCRYPTO].
o prf是与会话密钥的etype对应的伪随机函数。它们在[KCRYPTO]中定义。
o SKEYID_d is the session key in the Kerberos service ticket from the AP-REQ. Note that subkeys are not used in KINK and MUST be ignored if received.
o SKEYID_d是来自AP-REQ的Kerberos服务票证中的会话密钥。请注意，子键不用于扭结，如果收到，则必须忽略。
o Both Ni_b and Nr_b are the part of the Nonce payloads (Ni and Nr, respectively) as described in section 3.2 of [IKE]. Nr_b is optional, which means that Nr_b is treated as if a zero length value was supplied when the responder's nonce (Nr) does not exist. When Nr exists, Nr_b MUST be included in the calculation.
o 如[IKE]第3.2节所述，Ni_b和Nr_b均为非有效载荷（分别为Ni和Nr）的一部分。Nr_b是可选的，这意味着当响应者的nonce（Nr）不存在时，Nr_b被视为提供了零长度值。当Nr存在时，计算中必须包括Nr_b。
Note that g(qm)^xy refers to the keying material generated when KE payloads are supplied using Diffie-Hellman key agreement. This is explained in section 5.5 of [IKE].
请注意，g（qm）^xy是指使用Diffie-Hellman密钥协议提供KE有效载荷时生成的密钥材料。[IKE]第5.5节对此进行了解释。
The rest of the key derivation (e.g., how to expand KEYMAT) follows IKE. How to use derived keying materials is up to each service (e.g., section 4.5.2 of [IPSEC]).
密钥派生的其余部分（例如，如何扩展KEYMAT）遵循IKE。如何使用衍生密钥材料取决于每项服务（例如，[IPSEC]第4.5.2节）。
Kerberos encrypt/decrypt functions and get_mic/verify_mic functions require "key usage numbers". They are used to generate specific keys for cryptographic operations so that different keys are used for different purposes/objects. KINK uses two usage numbers, listed below.
Kerberos加密/解密函数和获取/验证函数需要“密钥使用编号”。它们用于生成用于加密操作的特定密钥，以便不同的密钥用于不同的目的/对象。KINK使用两个用法编号，如下所示。
Purpose Usage number
------- ------------
KINK_ENCRYPT payload (for encryption) 39
Cksum field (for checksum) 40
Purpose Usage number
------- ------------
KINK_ENCRYPT payload (for encryption) 39
Cksum field (for checksum) 40
KINK uses UDP on port 910 to transport its messages. There is one timer T which SHOULD take into consideration round-trip considerations and MUST implement a truncated exponential back-off mechanism. The state machine is simple: any message that expects a response MUST retransmit the request using timer T. Since Kerberos requires that messages be retransmitted with new times for replay protection, the message MUST be re-created each time including the checksum of the message. Both commands and replies with the ACKREQ bit set are kept on retransmit timers. When a KINK initiator receives a REPLY with the ACKREQ bit set, it MUST retain the ability to regenerate the ACK message for the transaction for a minimum of its full retransmission timeout cycle or until it notices that packets have arrived on the newly constructed SA, whichever comes first.
KINK在端口910上使用UDP传输其消息。有一个定时器T，它应该考虑往返考虑，并且必须实现截断指数退避机制。状态机很简单：任何需要响应的消息都必须使用计时器T重新传输请求。由于Kerberos要求消息以新的时间重新传输以进行重播保护，因此每次都必须重新创建消息，包括消息的校验和。带有ACKREQ位集的命令和应答都保留在重传计时器上。当扭结启动器接收到设置了ACKREQ位的应答时，它必须在其整个重传超时周期的最短时间内或直到它注意到数据包已到达新构造的SA（以先到者为准）保持为事务重新生成ACK消息的能力。
When a KINK peer retransmits a message, it MUST create a new Kerberos authenticator for the AP-REQ so that the peer can differentiate between replays and dropped packets. This results in a potential race condition when a retransmission occurs before an in-flight reply is received/processed. To counter this race condition, the retransmitting party SHOULD keep a list of valid authenticators that are outstanding for any particular transaction.
当纠结对等方重新传输消息时，它必须为AP-REQ创建一个新的Kerberos身份验证器，以便对等方能够区分重播和丢弃的数据包。当在接收/处理飞行中应答之前发生重传时，这将导致潜在的竞争条件。为了应对这种竞争条件，重传方应该保留一个针对任何特定事务的有效身份验证程序列表。
When a KINK peer retransmits a command, it MUST use the same ticket within the retransmissions. This is to avoid race conditions on using different keys, which result in different KEYMATs between an initiator and a responder. For this reason, (1) an initiator MUST obtain a ticket whose lifetime is greater than the initiator's maximum transaction time including timeouts, or (2) it MUST continue to use the same ticket within a set of retransmissions, and iff it receives an error (most likely KRB_AP_ERR_TKT_EXPIRED) from the responder, it starts a new transaction with a new ticket.
当纽结对等点重新传输命令时，它必须在重新传输中使用相同的票证。这是为了避免在使用不同密钥时出现争用情况，这会导致启动器和响应程序之间出现不同的密钥垫。因此，（1）发起者必须获得生存期大于发起者的最大事务时间（包括超时）的票证，或者（2）发起者必须在一组重传中继续使用同一票证，并且如果它从响应者处收到错误（很可能是KRB_AP_ERR_TKT_过期），它用一个新的票证开始一个新的交易。
The principal names are the identities of the KINK services, but the traffic protected by SAs are identified by DOI-specific selectors (IP addresses, port numbers, etc.). This may lead to a breakaway of SA-protected data from authentication. For example, if two different hosts claim that they have the same IP address, it may be impossible to predict which principal's key protects the data. Thus, an implementation must take care for the binding between principal names and the SA selectors.
主要名称是扭结服务的标识，但SAs保护的流量由DOI特定选择器（IP地址、端口号等）标识。这可能导致SA保护的数据脱离身份验证。例如，如果两个不同的主机声称它们具有相同的IP地址，则可能无法预测哪个主体的密钥保护数据。因此，实现必须注意主体名称和SA选择器之间的绑定。
Sending errors without cryptographic protection must be handled very carefully. There is a trade-off between wanting to be helpful in diagnosing a problem and wanting to avoid being a dupe in a denial of service attack.
在没有加密保护的情况下发送错误必须非常小心地处理。在想要帮助诊断问题和想要避免在拒绝服务攻击中被骗之间存在一种权衡。
KINK cobbles together and reuses many parts of both Kerberos and IKE, the latter which in turn is cobbled together from many other memos. As such, KINK inherits many of the weaknesses and considerations of each of its components. However, KINK uses only IKE phase 2 payloads to create and delete SAs; the security considerations which pertain to IKE phase 1 may be safely ignored. However, being able to ignore IKE's authentication phase necessarily means that KINK inherits all of the security considerations of Kerberos authentication as outlined in [KERBEROS]. For one, a KDC, like an Authentication, Authorization, and Accounting (AAA) server, is a point of attack and all that implies. Much has been written about various shortcomings and mitigations of Kerberos, and they should be evaluated for any deployment.
扭结在一起并重用Kerberos和IKE的许多部分，后者又是从许多其他备忘录中拼凑而成的。因此，KINK继承了其每个组件的许多弱点和考虑因素。然而，KINK仅使用IKE阶段2有效载荷来创建和删除SA；与IKE阶段1相关的安全注意事项可以安全地忽略。然而，能够忽略IKE的身份验证阶段必然意味着KINK继承了[Kerberos]中概述的Kerberos身份验证的所有安全注意事项。首先，KDC就像身份验证、授权和计费（AAA）服务器一样，是一个攻击点。关于Kerberos的各种缺点和缓解措施已经有很多文章，应该针对任何部署对它们进行评估。
KINK's use of Kerberos presents a couple of considerations. First, KINK explicitly expects that the KDC will provide adequate entropy when it generates session keys. Second, Kerberos is used as a user authentication protocol with the possibility of dictionary attacks on user passwords. This memo does not describe a particular method to avoid these pitfalls, but recommends that suitable randomly generated
KINK对Kerberos的使用提出了几个考虑因素。首先，KINK明确地期望KDC在生成会话密钥时提供足够的熵。其次，Kerberos用作用户身份验证协议，可能会对用户密码进行字典攻击。本备忘录并未描述避免这些陷阱的特定方法，但建议随机生成合适的
keys should be used for the service principals such as using the -randomkey option with MIT's "kadmin addprinc" command as well as for clients when that is practical.
密钥应该用于服务主体，例如在MIT的“kadmin addprinc”命令中使用-randomkey选项，以及在实际情况下用于客户端。
Kerberos does not currently provide perfect forward secrecy in general. KINK with the KE payload can provide PFS for a service key from a Kerberos key, but the KE is not mandatory because of the computational cost. This is a trade-off and operators can choose the PFS over the cost, and vice versa. KINK itself should be secure from offline analysis from compromised principal passphrases if PFS is used, but from an overall system's standpoint, the existence of other Kerberized services that do not provide PFS makes this a less than optimal situation.
Kerberos目前通常不提供完美的前向保密性。带有KE有效负载的扭结可以为来自Kerberos密钥的服务密钥提供PFS，但由于计算成本的原因，KE不是强制性的。这是一种权衡，运营商可以选择PFS而不是成本，反之亦然。如果使用PFS，则从离线分析中，从受损的主要密码短语来看，扭结本身应该是安全的，但是从整个系统的角度来看，不提供PFS的其他Kerberized服务的存在使得这不是一个最佳情况。
The IANA has assigned a well-known port number for KINK.
IANA为KINK分配了一个众所周知的端口号。
The IANA has created a new registry for KINK parameters, and has registered the following identifiers.
IANA为扭结参数创建了一个新的注册表，并注册了以下标识符。
KINK Message Types (section 4) KINK Next Payload Types (section 4.2) KINK Error Codes (section 4.2.8)
扭结消息类型（第4节）扭结下一有效负载类型（第4.2节）扭结错误代码（第4.2.8节）
Changes and additions to this registry follow the policies described below. Their meanings are described in [BCP26].
此注册表的更改和添加遵循以下描述的策略。其含义见[BCP26]。
o Using the numbers in the "Private Use" range is Private Use.
o 使用“私人使用”范围内的数字属于私人使用。
o Assignment from the "RESERVED TO IANA" range needs Standards Action, or non-standards-track RFCs with Expert Review. (Though the full specification may be a public and permanent document of a standards body other than IETF, an RFC referring it is needed.)
o “保留给IANA”范围的任务需要标准行动，或非标准跟踪RFC，并由专家审查。（尽管完整规范可能是IETF以外的标准机构的公开和永久性文件，但需要RFC引用。）
o Other change requires Standards Action.
o 其他变化需要标准行动。
KINK can accommodate future versions of Quick Mode through the use of the version field in the ISAKMP payload as well as new domains of interpretation. In this memo, the only supported Quick Mode version is 1.0, which corresponds to [IKE]. Likewise, the only DOI supported is the IPsec domain of interpretation [IPDOI]. New Quick Mode versions and DOIs MUST be described in subsequent memos.
通过使用ISAKMP有效载荷中的版本字段以及新的解释域，KINK可以适应快速模式的未来版本。在此备忘录中，唯一支持的快速模式版本是1.0，对应于[IKE]。同样，唯一支持的DOI是IPsec解释域[IPDOI]。新的快速模式版本和DOI必须在后续备忘录中说明。
KINK implementations MUST reject ISAKMP versions that are greater than the highest currently supported version with a KINK_BADQMVERS error type. A KINK implementation that receives a KINK_BADQMVERS message SHOULD be capable of reverting back to version 1.0.
扭结实现必须拒绝大于当前支持的具有扭结错误类型的最高版本的ISAKMP版本。接收KINK_BADQMVERS消息的KINK实现应该能够恢复到版本1.0。
The IPsec working group is defining the next-generation IKE protocol [IKEv2], which does not use Quick Mode, but it is similar to the one in IKEv1. The difference between the two is summarized in Appendix A of [IKEv2]. Each of them must be considered in order to use IKEv2 with KINK.
IPsec工作组正在定义下一代IKE协议[IKEv2]，该协议不使用快速模式，但与IKEv1中的协议类似。[IKEv2]的附录A总结了两者之间的差异。为了使用带纽结的IKEv2，必须考虑其中的每一个。
The KINK message header contains a field called "Domain of Interpretation (DOI)" to allow other domains of interpretation to use KINK as a secure transport mechanism for keying.
扭结消息头包含一个名为“解释域（DOI）”的字段，以允许其他解释域使用扭结作为键控的安全传输机制。
As one example of a new DOI, the MSEC working group defined the Group Domain of Interpretation [GDOI], which defines a few new messages, which look like ISAKMP messages, but are not defined in ISAKMP.
作为新DOI的一个示例，MSEC工作组定义了解释的组域[GDOI]，它定义了一些新消息，这些消息看起来像ISAKMP消息，但没有在ISAKMP中定义。
In order to carry GDOI messages in KINK, the DOI field in the KINK header would indicate that GDOI is being used, instead of IPSEC-DOI, and the KINK_ISAKMP payload would contain the payloads defined in the GDOI document rather than the payloads used by [IKE] Quick Mode. The version number in the KINK_ISAKMP header is related to the DOI in the KINK header, so a maj.min version 1.0 under DOI GDOI is different from a maj.min version 1.0 under DOI IPSEC-DOI.
为了在KINK中传输GDOI消息，KINK报头中的DOI字段将指示正在使用GDOI，而不是IPSEC-DOI，KINK_ISAKMP有效载荷将包含GDOI文档中定义的有效载荷，而不是[IKE]快速模式使用的有效载荷。KINK_ISAKMP头中的版本号与KINK头中的DOI相关，因此DOI GDOI下的maj.min版本1.0不同于DOI IPSEC-DOI下的maj.min版本1.0。
The IPsec working group has defined a number of protocols that provide the ability to create and maintain cryptographically secure SAs at layer three (i.e., the IP layer). This effort has produced two distinct protocols:
IPsec工作组定义了许多协议，这些协议提供了在第三层（即IP层）创建和维护加密安全SAs的能力。这项工作产生了两种不同的协议：
o a mechanism for encrypting and authenticating IP datagram payloads that assumes a shared secret between the sender and receiver
o 一种加密和验证IP数据报有效负载的机制，假定发送方和接收方之间存在共享秘密
o a mechanism for IPsec peers to perform mutual authentication and exchange keying material
o IPsec对等方执行相互身份验证和交换密钥的机制
The IPsec working group has defined a peer-to-peer authentication and keying mechanism, IKE (RFC 2409). One of the drawbacks of a peer-to-peer protocol is that each peer must know and implement a site's
IPsec工作组定义了对等身份验证和密钥机制IKE（RFC 2409）。对等协议的缺点之一是，每个对等方必须知道并实现站点的
security policy, which in practice can be quite complex. In addition, the peer-to-peer nature of IKE requires the use of Diffie-Hellman (DH) to establish a shared secret. DH, unfortunately, is computationally quite expensive and prone to denial of service attacks. IKE also relies on X.509 certificates to realize scalable authentication of peers. Digital signatures are also computationally expensive, and certificate-based trust models are difficult to deploy in practice. While IKE does allow for a pre-shared key, key distribution is required between all peers -- an O(n^2) problem -- which is problematic for large deployments.
安全策略，实际上可能相当复杂。此外，IKE的点对点特性要求使用Diffie-Hellman（DH）来建立共享秘密。不幸的是，DH在计算上非常昂贵，并且容易受到拒绝服务攻击。IKE还依赖X.509证书来实现对等点的可伸缩身份验证。数字签名在计算上也很昂贵，并且基于证书的信任模型在实践中很难部署。虽然IKE允许预共享密钥，但需要在所有对等方之间分配密钥，这是一个O（n^2）问题，对于大型部署来说是个问题。
Many have contributed to the KINK effort, including our working group chairs Derek Atkins and Jonathan Trostle. The original inspiration came from CableLab's PacketCable effort, which defined a simplified version of Kerberized IPsec, including Sasha Medvinsky, Mike Froh, and Matt Hur and David McGrew. The inspiration for wholly reusing IKE phase 2 is the result of Tero Kivinen's document suggesting grafting Kerberos authentication onto Quick Mode.
许多人都为扭结的努力做出了贡献，包括我们的工作组主席德里克·阿特金斯和乔纳森·特罗斯特。最初的灵感来自CableLab的PacketCable工作，该工作定义了Kerberized IPsec的简化版本，包括Sasha Medvinsky、Mike Froh、Matt Hur和David McGrew。完全重用IKE阶段2的灵感来自Tero Kivinen的文档，该文档建议将Kerberos身份验证移植到快速模式。
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[BCP26]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[IPDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[IPDOI]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[ISAKMP]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[ISAKMP-REG] IANA, "Internet Security Association and Key Management Protocol (ISAKMP) Identifiers", <http://www.iana.org/assignments/isakmp-registry>.
[ISAKMP-REG]IANA，“互联网安全协会和密钥管理协议（ISAKMP）标识符”<http://www.iana.org/assignments/isakmp-registry>.
[KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[KCRYPTO]Raeburn，K.，“Kerberos 5的加密和校验和规范”，RFC 3961，2005年2月。
[KERBEROS] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[KERBEROS]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“KERBEROS网络身份验证服务（V5）”，RFC41202005年7月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]Linn，J.，“Kerberos版本5 GSS-API机制”，RFC19641996年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[GDOI]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2003年7月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[PKINIT] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos", Work in Progress, February 2006.
[PKINIT]Zhu，L.和B.Tung，“Kerberos中用于初始身份验证的公钥加密”，正在进行的工作，2006年2月。
[REQ4KINK] Thomas, M., "Requirements for Kerberized Internet Negotiation of Keys", RFC 3129, June 2001.
[REQ4KINK]Thomas，M.“密钥的Kerberized Internet协商要求”，RFC 31292001年6月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
Authors' Addresses
作者地址
Shoichi Sakane Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi, Tokyo 180-8750 Japan
日本东京武藏市中町2-9-32号坂根横河电机株式会社，180-8750
EMail: Shouichi.Sakane@jp.yokogawa.com
EMail: Shouichi.Sakane@jp.yokogawa.com
Ken'ichi Kamada Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi, Tokyo 180-8750 Japan
日本东京武藏野市中町2-9-32号横川电机公司Ken'ichi Kamada Yokogawa Electric Corporation 180-8750
EMail: Ken-ichi.Kamada@jp.yokogawa.com
EMail: Ken-ichi.Kamada@jp.yokogawa.com
Michael Thomas Cisco Systems 170 West Tasman Drive San Jose, CA 95134
迈克尔·托马斯·思科系统公司加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: mat@cisco.com
EMail: mat@cisco.com
Jan Vilhuber Cisco Systems 170 West Tasman Drive San Jose, CA 95134
加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: vilhuber@cisco.com
EMail: vilhuber@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。