[要約] RFC 4430は、Kerberized Internet Negotiation of Keys（KINK）プロトコルに関するものであり、セキュアなキー交換を提供するために設計されています。KINKは、Kerberos認証を使用してネットワーク上でのセキュアな通信を確立するためのプロトコルです。
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インターネットのキーの交渉（キンク）
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.
この文書では、Keys（Kink）プロトコルのKerberizedインターネット交渉について説明します。Kinkは、Kerberos認証システムを使用してセキュリティアソシエーションを確立し維持するために、低遅延、計算上安価、簡単に管理され、暗号的にサウンドプロトコルを定義します。kinkは、インターネット鍵交換（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
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は、一貫したセキュリティポリシーを維持することが重要である中央管理環境内の通信エンティティ間のキーを確立するための安全でスケーラブルなメカニズムを提供するように設計されています。キンクのセキュリティ目標は、鍵管理メッセージのプライバシー、認証、および再生保護を提供し、可能な限りサービスの脆弱性を回避することです。プロトコルのパフォーマンス目標は、計算コスト、低遅延、および小さなフットプリントを持つことです。公開鍵操作の使用を回避または最小限に抑えることもあります。特に、プロトコルは、最小限の計算努力を備えた2つのメッセージでIPSecセキュリティアソシエーション（SAS）を確立する機能を提供します。これらの要件は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の公開鍵暗号化を使用する必要性を制限するので効率的です。 KDCへの最初の認証は、Kerberos [PkinIt]の初期認証のための公開鍵暗号を使用して、対称キー、または非対称キーを使用して実行することができます。ただし、クライアントとサーバーの間の認証された交換の後続の要求は、常に対称暗号化を利用します。したがって、公開鍵の操作（もしあれば）は制限され、最初の認証操作で取得した認証情報の寿命をKDCに償却する。例えば、クライアントは、KDCとの単一の公開鍵交換を使用して、KDCの領域に他の多くのサーバを有する複数のSAを効率的に確立することができる。 Kerberosはまた、対称鍵が使用されているときに直接ピアツーピアキーイングよりもスケールをスケーリングします。その理由は、キーがKDCに格納されているので、プリンシパルキー数はO（n * m）ではなくO（nm）であるため、 "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].
「必須」、「必須」、「必要ではない」、「しない」、「推奨する」、「推奨する」、「5月」、「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、[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 SAを作成、削除、および維持できるコマンド/レスポンスプロトコルです。各コマンドまたは応答には、一連のタイプ長値ペイロードと共に共通のヘッダーが含まれています。コマンドまたは応答のタイプは、Exchangeのメッセージに送信されたペイロードを制限します。KINK自体は、各コマンドまたは応答がキンクのハード状態の保存を必要としないという点でステートレスプロトコルです。これはIKEとは対照的に、メインモードを使用して、インターネットセキュリティアソシエーションとキー管理プロトコル（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ユーザーからユーザーへのメカニズムを使用する手段を提供します。これは通常、初期認証のためにPkinItを使用してIPsecピアを使用する場合に限定されません。
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で定義されているクイックモードペイロードを、いくつかのマイナーな変更や省略を採用しています。ほとんどの場合、キンク交換は単一のコマンドとその応答です。SASを作成するときには、オプションの3番目のメッセージが必要な場合に必要です.Responderがイニシエータから最初の提案を拒否したり、キーイングしたりしたい場合にのみ必要です。KINKは、RekingとDead Peerの検出も提供しています。
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.
すべてのKINKメッセージフローは、2つのピア間の同じパターンに従って、コマンド、応答、およびCREATE FLOWのオプションの確認応答に従います。コマンドは、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
キンクは認証メカニズムとしてKerberosを使用します。したがって、KINKホストは、実際のキー交渉の前に各ピアのサービスチケットを取得する必要があります。これは基本的には純粋なKerberos Exchangeであり、ここでの実際の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.
ケルベロスと地方政策の検討例外として、ユーザー間認証が必要な場合は、kinkのgettgtメッセージフロー（セクション3.1で説明）が使用されます。このフローでは、AとBの両方がKDCからチケットを付与するチケット（TGTS）を持っているとします。
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はSASを管理するためのメッセージフロー（セクション3.2）、メッセージフローの削除（セクション3.3）、およびステータスメッセージフロー（セクション3.4）を使用します。これらの流れでは、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:
イニシエータがレスポンダの通常の（ユーザ間）サービスチケットを取得できないと判断した場合は、ユーザ間認証を試すことができます。この場合、ユーザー間サービスチケットを取得するために、最初にレスポンダからTGTを取り出します。
A B KDC
------ ------ ---
1 GETTGT+KINK_TGT_REQ------>
2 <-------REPLY+KINK_TGT_REP
3 TGS-REQ+TGT(B)------------------------------------>
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.
イニシエータは、ユーザ間パスに移動するためのトリガとして次のイベントをサポートすることができる。以下の2つのエラーは認証されないことに注意しており、それらにどのように行動するかはポリシーによって異なります。
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コマンドは「楽観的」なアプローチを取ります。ここで、SASは最初にレスポンダが最初に提案されたペイロードを選択することを期待して作成されます。楽観的提案は、最初の提案の最初の変換ペイロードに配置されています。イニシエータは、すべての変換と属性を比較することによって楽観的な提案が選択されたかどうかを確認する必要があります。これらの各属性は、レスポンダによって低い値に設定され、それでも楽観的なキーイングを期待していますが、有効なノープロポーザルで選択されたエラーを生成しなければならない高い値に設定してはなりません。イニシエータは短い寿命を使用する必要があります。
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）が含まれている場合、レスポンダはそれを拒否し、無効な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ペイロードタイプを含む無効なペイロードタイプのISAKMP通知でそれを拒否しなければなりません。イニシエータがこのエラーを受信すると、そのポリシーでそれを許可する場合は、（別のトランザクションとして）keペイロードなしで再試行できます。
A B KDC
------ ------ ---
A creates an optimistic inbound SA (B->A) unless using a KE.
keを使用しない限り、Aは楽観的なインバウンドSA（B→A）を作成します。
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）を作成します。B楽観的で、keを使用していない場合は、アウトバウンドSA（B-> A）を作成します。
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）を作成します。非楽観的であれば、インバウンドSA（B→A）を置き換える。a keを使用している場合、aはインバウンドSA（B-> A）を作成します。
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の作成には、2つの方法ハンドシェイクと3方向ハンドシェイクの2つのモードがあります。イニシエータは通常、2方向ハンドシェイクを期待して交渉を開始します。楽観的提案がレスポンダによって選択されていないとき、ネゴシエーションは3方向ハンドシェイクに切り替えられる。イニシエータがKEペイロードを使用したときにのみ、最初から3方向ハンドシェイクが期待されます。
A 2-way handshake is performed in the following steps:
次の手順では、2ウェイハンドシェイクが実行されます。
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）からのメッセージを受信する準備ができていることから、CREATEメッセージをBに送信します.3）Bの楽観的提案に同意した場合、BはインバウンドSA（A-> B）とアウトバウンドSAを作成します（B-> A）そのデータベースに。Bが最初の提案を選択したり、非CCEペイロードを追加したい場合は、以下の3方向ハンドシェイクのステップ3に切り替えます。4）Bは、無制限のペイロードなしで、ACKを要求せずに返信を送信します。5）返信を受信すると、アウトバウンドSA（A-> B）を作成します。
A 3-way handshake is performed in the following steps:
3方向ハンドシェイクは次のステップで実行されます。
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) HOST Aは、SAを作成せずにCREATEメッセージをBに送信します。2）Bの方針に従って1つの提案を選択します。3）BインバウンドSA（A-> B）を作成し、返信に実際の選択を送信します。それはオプションのNonceペイロードを送信する必要があります（メッセージ数を増やしていないのでエントロピーソースを増やすため）、返信が確認されるように要求する必要があります。4）返信を受信すると、AはインバウンドSA（B-> A）を作成する（または、2方向から切り替えている場合は必要に応じて変更します）、およびアウトバウンドSA（A-> B）。5）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 Exchangeを受け入れてから、最終的なアウトバウンドSAをインストールできるようにACK（すなわち、ACKREQビットを設定されている）を要求する必要があります。ackreqビットが誤って誤っていると考えていても、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を3つではむしろ2つのメッセージで作成できます。2つのメッセージ交換の意味は、必ず設定されているので、Bがキーに寄与しないことです。
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.
それがBから追加のキーイング材料を受け取る前のインバウンドSA。これは通常の状況下では疑わしいかもしれません。しかしながら、KINKはKDCが鍵導出に使用される信頼できるランダム性源を提供するという事実を利用する。多くの場合、これは十分なセッションキーを提供し、Bが確認応答を必要としないようにする。Bは常にキーイング材料に貢献するためにLibertyにあるので、これは厳密にはメッセージ数とメッセージ数との間のトレードオフです。このキンクの実装は、ポリシーの問題として決定される可能性があります。
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コマンドは既存のSASを削除します。解釈の領域（DOI） - 特定のペイロードは、削除される実際のSAを記述する。IPsec DOIの場合、それらのペイロードは削除されるべきSPIのリストを含むISAKMPペイロードを含みます。
A B KDC
------ ------ ---
A deletes outbound SA to B.
aはBにアウトバウンドSAを削除します。
1 DELETE+ISAKMP------------>
B deletes inbound and outbound SA to A.
bインバウンドとアウトバウンドSAをAに削除します。
2 <-------------REPLY+ISAKMP
A deletes inbound SA to B.
BにインバウンドSAを削除します。
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コマンドは「pessimistic」アプローチを取ります。これは、他のホストが削除を受け取ったことを確認応答を受信するまでインバウンド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ペイロードには、このフローのイニシエータのインバウンドSAを示すISAKMP DELETEペイロードが含まれています。キンクは半展開SAを許可しません。したがって、レスポンダがDELETEコマンドを受信すると、両方向のSASを削除し、ISAKMPのDELETEペイロード（S）を使用する必要があります。レスポンダが削除されるべき適切なSPIを見つけることができない場合、Invalid_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を削除することをお勧めします。キンクの実装は、平均往復時間の少なくとも2倍の期間、または設定可能な値に設定する必要がある猶予タイマーを実装する必要があります。キンクの実装は、graceを適切な時にゼロに設定することを選択できます。ここで説明されている動作は、TCP [RFC793]フラグフィンと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
------ ------ ---
1 STATUS[+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_Errorのペイロード、Kink_Error for Kink_Errorペイロード、および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_SKEWを返す必要があります。krb-errorのオプションのクライアントの時間は記入されるべきです。サーバーが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メッセージに含まれるクライアントとサーバーの時間に基づいて、2つのクロックの間の差（秒単位）を計算する必要があります。クライアントはこのクロックの違いを保存し、それを使用して後続のメッセージで調整する必要があります。エラーが保護されていない場合、クライアントはその後のメッセージを調整するために違いを使用してはいけません。
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.
キンクは、SAのイニシエータがSAを2つの理由で回復させる責任があると期待しています。第1の理由は、イニシエーターおよびレスポンダによる衝突の結果としてSAの不必要な重複を防ぐことであり、既存のSAを更新しようとしている。2つ目の理由は、Kerberos交換のクライアント/サーバーの性質によるものです。これは、クライアントがチケットを取得および維持することを期待しています。キンクホストがチケットを取得および維持することができると期待しているが、実際には、サーバがクライアントがセッションを開始するのを待つことが多いため、大規模なチケットキャッシュを維持する必要がないようにすることが多い。
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.
キンクにSASを回復するための特別な意味論はありません。つまり、既存のSAを再確認するためには、イニシエータは新しいSAを作成し、続いて古いSAを削除し、削除フローで削除したり、タイムアウトしたりします。同一のフローセレクタが異なるSASで利用可能な場合、キンクの実装は最近作成されたSAを選択する必要があります。キンクは、信頼できる削除メカニズムを有することによって、[IKE] Rekeingの問題のほとんどを回避することに留意されたい。
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.
通常、既存のSASを回復させるキンクの実装は、SAの終了の前方にSAを再度キーに再び再度キーを起こそうとします。これは、時間/バイトカウントまたはシーケンス番号カウンタのオーバーフローを含めることができます。今回は「ソフトライフタイム」と呼びます。ソフトライフタイムは、同様の実装と同期を避けるためにランダム化されなければなりません。寿命の場合、柔らかい寿命を判断するための1つの合理的なアプローチは、T-RekeyとT-Retransの間のランダムな時間をピッキングし、それをハード寿命から差し引きます。ここで、T-Rekeyは合理的な最大の生後マージンであり、TRERANSは完全再送サイクルを通過するのにかかる時間です。T-Rekeyは、TRETRANSの少なくとも2倍の高さであるべきです。
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
Kink Peerがそのセキュリティデータベース情報を失ったと判断するために、Kinkピアは現在のエポックをピアに有効なSA情報を持ち、各AP-REQおよびAP-Repメッセージでそのエポックを反映している。Kink Peerが特定の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.
プリンシパルのエポックが変更された後のメッセージで、そのプリンシパルによって作成されたすべてのSAが無効として考慮され、それらの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メッセージの形式で）ルーティングからのフィードバックを使用する必要がありますが、非保護されていないルーティング情報に基づいてピアが死んでいないクワイトピアは終了してはいけません（is 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トラフィックの欠如などのキンクピアに利用可能な情報に基づいて）、キンクステータスメッセージを使用して、ピアからの確認応答を強制する必要があります。キンクでデッドピア検出についてネゴシエートされないので、各ピアは「疑い」に独自のメトリックを決定することができ、またステータスメッセージへの応答がないためにピアがデッドを宣言する前に使用するタイムアウトを決定できます。これは望ましいものであり、相互運用性を破ることはない。
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.
ステータスメッセージには2倍の効果があります。第1に、ピアから暗号的に保護された（および再生された）応答を誘発します。これは、ピアが到達可能/生きているかどうかを教えてくれます。第二に、それはピアのエポック番号を運びますので、ピアが再起動してすべての状態を失ったかどうかを知っています。これはKINK Protocolにとって非常に重要です.IKEでは、ピアが再起動すると、すべての暗号化コンテキストが失われ、暗号化されているキーを再交渉せずに暗号的に安全な通信はできません。KINKでは、Kerberosチケットのために、使用されている共有暗号鍵がKerberosチケットで搭載されているため、ピアが再起動したとしても、ピアで安全に通信できます。したがって、アクティブな暗号通信は、ピアが再起動していない状態ですべての状態を失い、エポックが必要とされているという表示ではありません。
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は別のステータスメッセージを送信することができます。ピアBの死者を宣言することを積極的に宣言することを決定するのは、ピアアaを推進しています。攻撃性のレベルは、大量のSASを持つノードによって送信されたメッセージの数に対して、迅速なフェイルオーバーなどの多くの要因によって異なります。
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を失った場合、レスポンダはその新しいTGTを使用してチケットを復号化できないため、通常のデッドピア検出（DPD）メカニズムは機能しません。この場合、以下の操作が行われます。
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で復号化できないユーザ間チケットを用いてレスポンダがkinkコマンドを受信すると、TGTを含むkink_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 イニシエータがkink_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.
イニシエータは、2つの理由から、ピアがkink_tgt_repの受領時に死んでいるとは思わないでください。1つはメッセージが認証されていないことであり、もう1つはTGTを失うことは必ずしもSAデータベース情報を失うことを意味するわけではありません。鍛造kink_tgt_repが受信されたときにコストを削減するために、新しいサービスチケットを忘れないでください。
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.
kinkのすべての値は、ネットワークバイトオーダー（最上位バイトの最初のバイト）でフォーマットされています。パケットが送信されると、予約フィールドはゼロ（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) ~
| |
+-------------------------------+-------------------------------+
Figure 5: Format of a KINK Message
図5：kinkメッセージのフォーマット
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
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 予約済み（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オクテット） - オクテット内のメッセージの長さ。メッセージの後に不要なデータがあることはキンクでは禁止されていませんが、長さフィールドはメッセージの実際の長さを表す必要があります。
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オクテット） - 解釈のドメイン。ISAKMP-Registry [ISAKMP-REG]のISAKMPドメインのIANAには、すべてのDOIをIANAに登録する必要があります。Iner In IP Security DOI [IPDOI]のIANAが割り当てられた番号は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。KINKトランザクションは、コマンドイニシエータによって作成され、トランザクション内の後続のメッセージでレプリケートされたトランザクションIDによってまとめられます。トランザクションは、コマンド、応答、およびオプションの確認応答として定義されます。トランザクションIDは、複数の未処理要求をレスポンダに区別するためにイニシエータによって使用されます。その機能はKerberosによって提供されているため、再生保護には使用されません。XIDの値はイニシエータによって選択され、未処理のすべてのトランザクションで固有のものでなければなりません。XIDは、単調カウンタまたは乱数発生器を使用することによって構築され得る。
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（変数） - Cksumフィールド自体を除くメッセージ全体のKerberosキー付きチェックサム。最後のペイロードと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フィールドの後のキンクパディングは、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を差し引いた長さフィールドの値からLENGTHNON-CHECKSUMが計算されます。LENGTHフィールドは長さのないチェックサム値で埋められ、CKSUMLENフィールドはゼロになります。次に、チェックサムなしのパケット（受信したパケットの0から長さのないチェックサムマイナス1から縮小されない）とチェックサム（最後までの長さ - チェックサムからのオフセット）がverify_mic関数に渡されます。検証が失敗した場合、メッセージは削除されなければなりません。
The KINK header is followed immediately by a series of Type/Length/Value fields, defined in section 4.2.
Kinkヘッダーは、セクション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 すべての長さのフィールドは、構造内の実際のオクテット数を反映しなければなりません。すなわち、彼らはキンクの整列に必要なパディングバイトを説明していません。
o KINK headers, payloads, and the Cksum field MUST be aligned on 4-octet boundaries.
o Kinkヘッダー、ペイロード、およびCksumフィールドは4オクテットの境界に揃えられている必要があります。
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）ペイロードのリストがあります。ヘッダーに続くペイロードの数が多い場合があります。各ペイロードはペイロードヘッダーから始める必要があります。各ペイロードヘッダーは、Generic Payloadヘッダー上に構築されています。任意のデータは汎用ヘッダーの後に続きます。ペイロード長フィールドは、ペイロード内の実際のオクテット数を正確に反映しなければならないが、ペイロードはすべて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) |
+---------------+---------------+---------------+---------------+
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
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 value（variable） - このフィールドのこの値は型によって異なります。
The KINK_AP_REQ payload relays a Kerberos AP-REQ to the responder. The AP-REQ MUST request mutual authentication.
kink_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）はプリンシパル名に変換されることがあります。セキュリティ上の考慮事項セクション。
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から生成された場合、イニシエータが開始するプリンシパル名は「kink / fqdn @ realm」になります。"kink"はKink IPsecサービスのリテラル文字列である場合、 "FQDN"はサービスホストの完全修飾ドメイン名であり、 "realm"はサービスのKerberosレルムです。主な名前は大文字と小文字が区別され、[Kerberos]で説明されているように「FQDN」部分は小文字でなければなりません。
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 ~
| |
+---------------------------------------------------------------+
Figure 7: KINK_AP_REQ Payload
図7：kink_ap_reqペイロード
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 EPOCH - AP-REQの作成者が有効なSA情報を持っている絶対時間。通常、これは、再起動にわたってSA情報を保持していない場合、Kinkキーイングデーモンが起動したときです。このフィールドの値は、1970-01-01t00：00：00 UTCの経過秒数である、いわゆるPOSIX時間の最下位4オクテットです。たとえば、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 - このペイロードの値フィールドには、RAW 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 ~
| |
+---------------------------------------------------------------+
Figure 8: KINK_AP_REP Payload
図8：kink_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 EPOCH - AP-REPの作成者が有効なSA情報を持っている絶対時間。通常、これは、再起動にわたってSA情報を保持していない場合、Kinkキーイングデーモンが起動したときです。このフィールドの値は、1970-01-01t00：00：00 UTCの経過秒数である、いわゆるPOSIX時間の最下位4オクテットです。たとえば、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].
KINK_KRB_ERRORペイロードをリレー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の実装は、kink_krb_errorを返すときにkink cksumフィールドを利用する必要があり、適切なサービスキーが利用可能です。特にクロックスキューエラーの場合、サーバーのエラーを保護すると、クロックを同期させる必要がないため、ユーザーエクスペリエンスが向上します。ただし、エラーパケットを保護するために、多くの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エラーメッセージのテキストまたはE_DATAフィールドを使用しないことに注意してください。
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 ~
| |
+---------------------------------------------------------------+
Figure 9: KINK_KRB_ERROR Payload
図9：kink_krb_errorペイロード
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ペイロードは、KDCからユーザ間サービスチケットを取得するためにピアから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 |
+---------------+---------------+---------------+---------------+
| |
~ PrincName (variable) ~
| |
+---------------------------------------------------------------+
Figure 10: KINK_TGT_REQ Payload
図10：kink_tgt_reqペイロード
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は、RealMm 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値は、Generic Security Serviceアプリケーションプログラムインタフェースの「名前」コンポーネント（GSS-API）で使用されるオクテット文字列のようにフォーマットされたプリンシパルとレルム名のOctet String表現です。[RFC2743]エクスポートされた名前のトークンメカニズム[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を返すことを禁止する場合、それはkink_u2udenedを返すかもしれません。
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) ~
| |
+---------------------------------------------------------------+
Figure 11: KINK_TGT_REP Payload
図11：kink_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) |
+---------------+---------------+---------------+---------------+
Figure 12: KINK_ISAKMP Payload
図12：kink_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.
kink_isakmpペイロードは、kinkコマンドに応じて適切なアクションを実行するために、IKEクイックモード（フェーズ2）ペイロードをカプセル化します。単一のキンクメッセージ内にkink_isakmpペイロードの数が多いかもしれません。[IKE]は、単一のIKEメッセージ内で複数の異なるSAが作成される可能性があるかどうかについて、キンクは明示的に新しいISAKMPヘッダーが各ディスクリートSA操作に使用される必要があります。言い換えれば、キンクの実装は、単一のkink_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、ゼロ（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.
kink_encryptペイロードは他のKink Payloadsをカプセル化し、セッションキーとそのetypeによって指定されたアルゴリズムを使用して暗号化されます。このペイロードは、メッセージの外部ペイロードチェーンの最後のものでなければなりません。kink_encryptペイロードは、最後のキンクチェックサムが適用される前に暗号化されなければなりません。
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：kink_encryptペイロード
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 innernextpload - インナーシリーズの暗号化キンクペイロードの最初のペイロードタイプ。
o RESERVED2 -- Reserved and MUST be zero when sent, MUST be ignored when received.
o Reserved2 - Reservedおよび送信時にゼロでなければならない場合は、受信時に無視する必要があります。
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.
暗号化されたデータのカバレッジは、最初のペイロードのタイプが機密に保たれるように、InnernextProptoadから始まります。したがって、暗号化されたオクテットの数は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]の「暗号化アルゴリズムプロファイル」セクションに定義されている暗号化関数の出力です。Encrypt機能自体、特定キー、および初期状態などのパラメータは、ETYPEで定義されています。暗号化機能はそれ自体パディングを持ち、復号化された平文の最後にいくつかのゴミデータがあるかもしれません。Kink_encryptペイロード内の最後のサブペイロードの後にそのようなパディングを無視するようにキンクの実装を準備する必要があります。各暗号化機能には独自の完全性保護メカニズムがあります。Kinkヘッダーのチェックサムでは冗長ですが、整合性保護部を暗号化機能から削除することは必ずしも可能ではないため、避けられません。
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.
kink_errorペイロードタイプは、エラー状態を返すプロトコルレベルのメカニズムを提供します。このペイロードは、自分のペイロードが定義されている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 |
+---------------+---------------+---------------+---------------+
Figure 14: KINK_ERROR Payload
図14：kink_errorペイロード
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 -
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).
レスポンダはkink_okを返さないでください。受信されると、イニシエータは特定のkink_errorペイロードが存在しなかったかのように機能します。イニシエータが複数のクイックモードバージョンまたはDOIS、KINK_BADQMVERSまたはKINK_INVDOIを受信し、CKSUMが検証されている場合は、別のバージョンまたはDOIで再試行することがあります。ヘッダーにサポートされていないキンクバージョン番号を受信したときに、レスポンダはKINK_INVMAJを使用してキンクエラーを返すはずです。kink_u2udenedが受信されると、イニシエータはユーザー間のモードで再試行できます（まだ試行されていない場合）。
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はSASを交渉するためにISAKMPペイロードを直接使用します。特に、キンクはIKEフェーズ2ペイロードタイプ（AKAクイックモード）を使用しています。一般的に、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は、SASの作成、削除、およびステータスの特定のコマンドを主に予測可能なSAの作成/削除を容易にします（セクション3.2と3.3を参照）。そのように、キンクはどのコマンドとどのコマンドとともにどのような制限といくつかのペイロードのいくつかの追加の制限と意味論を送信することができるかについて特定の制限を課す。実装者は、実際のフォーマットとセマンティクスの[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 IP用のセキュリティアソシエーションペイロードヘッダーは、[IPDOI]のセクション4.6.1で定義されています。このメモの場合、解釈のドメインを1（IPSec）に設定する必要があり、状況ビットマップは1（sit_identity_only）に設定する必要があります。他のすべてのフィールドは省略されています（sit_identity_onlyが設定されているため）。
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はまた、SAの作成を2つのメッセージで完了できるようにするためのCREATEコマンドの楽観的な提案を定義するという点で、IKEの意味論を拡大します。
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 キンクはハッシュペイロードをまったく使用しません。
o KINK allows the Nonce payload Nr to be optional to facilitate optimistic keying.
o KINKは、Optimistic Keyingを容易にするために、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
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.
キンクはその提案を直接使用し、違いのないペイロードを変換します。ただし、キンクは、最初の提案と最初の提案と、楽観的なキーイングの各コンジュゲートの変換との関連性を提供します。
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によって保護されるべきトラフィックを識別するために使用される情報を搬送します。KINKは、[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
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.
通知ペイロードは、エラー状態や状態遷移などのいくつかの情報データをピアに送信するために使用されます。例えば、通知情報送信は、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]。この範囲内のタイプを受け取る実装は、応答内で認識されないことが、対応する要求が完全に失敗したと仮定する必要があります。要求または応答内の要求とステータスタイプ内の認識されていないエラータイプは無視されなければならず、ログに記録する必要があります。ステータスタイプを持つペイロードを通知すると、任意のメッセージに追加でき、認識されていない場合は無視する必要があります。それらは機能を示すことを意図しており、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]で定義されているエラータイプを示します。したがって、例えばこの文書では無効なプロトコルIDは使用されていません。kink_badqmversは、IKEのバージョンがサポートされていないことをイニシエータに伝えるために使用されるため、無効 - メジャーバージョンと無効なマイナーバージョンは使用されません。
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ペイロードがレスポンダによってサポートされていない場合にも送信されます。通知データには、1オクテットペイロードタイプが含まれている必要があります。
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.
いくつかの型、長さ、または値が範囲外のために受信されたkink_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には、PEALPOLOADを使用して完璧な前方の秘密（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メカニズムによって機能が提供されているので、再生保護は提供されません。さらに、2つのピアがチケット交換を介してキーを共有した場合、コマンドと応答はメッセージ全体にわたって暗号チェックサムを使用する必要があります。
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.
このセクションのすべての場合において、メッセージにKINK_AP_REQまたはKINK_AP_REPペイロードが含まれている場合、他のキンクペイロードはKINK_ENCRYPTペイロードにカプセル化されてもよい。
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.
返信メッセージは、kink_ap_rep、kink_krb_error、またはkink_errorペイロードのいずれかを含める必要がある総称応答です。返信メッセージには、次のセクションで定義されているISAKMPペイロードなどの追加のDOI固有のペイロードが含まれている可能性があります。
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.
ACKは、ACKREQビットが応答メッセージに設定されている場合にのみ送信されます。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.
このメッセージは新しいセキュリティアソシエーションの確立を開始します。CREATEメッセージには、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]
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]
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.
返信メッセージでは、少なくとも1つのプロポーザルペイロードと単一の変換ペイロードがある必要があります。SAバンドルがネゴシエートされている場合にのみ、複数の提案ペイロードがあるでしょう。また、IKEとは異なり、NONCEペイロードNRは必要ありません。存在する場合は、イニシエータの発信SAを変更しなければならないことを示すために確認応答を要求しなければなりません。最初の提案のいずれかが受信者によって選択されていない場合、それはNONCEペイロードを含めるべきです。
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.
kinkは、ikeのように、1つのcreateコマンドで多くのSAを作成できます。楽観的提案のいずれかがレスポンダによって選択されていない場合、それはACKを要求する必要があります。
If an IPsec DOI-specific error is encountered, the responder must reply with a Notify payload describing the error:
IPsec DOI固有のエラーが発生した場合、レスポンダはエラーを記述する通知ペイロードで返信する必要があります。
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:
Responderが有効なオーセンティケータを作成できるKerberosエラーを見つけた場合、返信は次の形式を取ります。
REPLY KINK Header KINK_AP_REP [KINK_ENCRYPT] KINK_KRB_ERROR
返信キンクヘッダーkink_ap_rep [kink_encrypt] kink_krb_error.
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:
最後に、ResponderがAP-Repを作成できないKerberosまたはKinkタイプのエラーを見つけた場合は、Lone Kink_KRB_ERRORまたはKINK_ERRORペイロードで返信する必要があります。
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]
kinkヘッダーkink_ap_req [kink_encrypt] kink_isakmpペイロードのペイロードを削除する[通知ペイロード]
There are three forms of replies for a DELETE. The normal form is:
削除には3つのフォームの返信があります。通常の形式は次のとおりです。
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固有のエラーが発生した場合、レスポンダはエラーを記述する通知ペイロードで返信する必要があります。
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:
Responderが有効なオーセンティケータを作成できるKerberosエラーを見つけた場合、返信は次の形式を取ります。
REPLY KINK Header KINK_AP_REP [KINK_ENCRYPT] KINK_KRB_ERROR
返信キンクヘッダーkink_ap_rep [kink_encrypt] kink_krb_error.
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のタイプのエラーを見つけた場合は、LONE KINK_KRB_ERRORまたはKINK_ERRORペイロードで返信する必要があります。
REPLY KINK Header [KINK_KRB_ERROR] [KINK_ERROR]
返信キンクヘッダー[kink_krb_error] [kink_error]
The STATUS command is used in two ways:
statusコマンドは2つの方法で使用されます。
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]]
ステータスには、次のペイロードが含まれています.Kinkヘッダーkink_ap_req [[kink_encrypt] kink_isakmpペイロード[通知ペイロード]]
There are three forms of replies for a STATUS. The normal form is:
ステータスには3つのフォームの返信があります。通常の形式は次のとおりです。
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:
Responderが有効なオーセンティケータを作成できるKerberosエラーを見つけた場合、返信は次の形式を取ります。
REPLY KINK Header KINK_AP_REP [KINK_ENCRYPT] KINK_KRB_ERROR
返信キンクヘッダーkink_ap_rep [kink_encrypt] kink_krb_error.
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のタイプのエラーを見つけた場合は、LONE KINK_KRB_ERRORまたはKINK_ERRORペイロードで返信する必要があります。
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には2つのフォームの返信があります。レスポンダがそのTGTを返すことを許可されている通常の形式では、応答にkink_tgt_repペイロードが含まれています。レスポンダがそのTGTを返すことを許可されていない場合は、kink_errorペイロードで返信する必要があります。
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])
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サービスチケットのセッションキーです。サブキーはkinkでは使用されていないため、受信した場合は無視する必要があります。
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 NI_BとNR_Bの両方が、[IKE]のセクション3.2で説明されているように、それぞれNOCEペイロード（それぞれNIとNR）の両方です。NR_Bはオプションです。つまり、RESONDERの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]).
鍵導出の残りの部分（例えば、キーマットの拡大方法）は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暗号化/復号化機能とget_mic / verify_mic関数には、「キー使用量番号」が必要です。それらは、異なる目的/オブジェクトに異なるキーが使用されるように、暗号化操作のための特定のキーを生成するために使用されます。Kinkは以下の2つの使用数を使用します。
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を使用します。往復の考慮事項を考慮に入れるべき1つのタイマTがあり、切り捨てられた指数関数的なバックオフメカニズムを実装する必要があります。ステートマシンは簡単です。レスポンスがタイマTを使用して要求を再送信する必要があるメッセージはすべて、メッセージのチェックサムを含む毎回メッセージを再作成する必要があります。ACKREQビットセットとのコマンドと応答はどちらも再送信タイマに保存されます。KINKイニシエータが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.
Kink Peerがメッセージを再送信すると、ピアがリプレイとドロップされたパケットを区別できるように、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.
KINK Peerがコマンドを再送信すると、再送信内で同じチケットを使用する必要があります。これは、さまざまなキーを使用している競合条件を回避することで、イニシエータとレスポンダとの間の異なるキーマットが異なります。このため、（1）イニシエータがイニシエータの最大トランザクション時間よりも大きいチケットを取得する必要がある、または（2）同じチケットを引き続き使用し続ける必要があります。（最も可能性の高いKRB_AP_ERR_TKT_Expired）レスポンダから、新しいチケットを使用して新しいトランザクションを開始します。
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.
プリンシパル名はKink ServicesのIDですが、SASによって保護されているトラフィックはDOI固有のセレクタ（IPアドレス、ポート番号など）によって識別されます。これにより、認証からのSA保護データが破壊される可能性があります。たとえば、2つの異なるホストが同じ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.
暗号保護なしでエラーを送信する必要があります。問題の診断やサービス拒否攻撃でDUPEであることを避けたいと思っている間には、トレードオフがあります。
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はSASを作成および削除するためにIKEフェーズ2ペイロードのみを使用します。IKEフェーズ1に関連するセキュリティ上の考慮事項は安全に無視されてもよい。ただし、IKEの認証フェーズを無視することができることは必然的にキンクがKerberos認証のすべてのセキュリティ上の考慮事項を[Kerberos]で概説されていることを意味します。1つの場合、認証、許可、および会計（AAA）サーバのようなKDCは、攻撃のポイントであり、それを意味するのはすべてです。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は現在完璧な前方秘密を一般的に提供していません。KEN Payloadを使用すると、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パラメータのための新しいレジストリを作成し、次の識別子を登録しました。
KINK Message Types (section 4) KINK Next Payload Types (section 4.2) KINK Error Codes (section 4.2.8)
kinkメッセージタイプ（セクション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 「Private Use」範囲の数字を使用することが個人用です。
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.
Kinkは、ISAKMPペイロードのバージョンフィールドと解釈の新しいドメインの使用を通じて、将来のバージョンのクイックモードに対応できます。このメモでは、サポートされているQuick Modeバージョンのみが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.
Kinkの実装は、kink_badqmversエラータイプを使用して現在サポートされている最高バージョンよりも大きいISAKMPバージョンを拒否しなければなりません。kink_badqmversメッセージを受信するキンクの実装は、バージョン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の場合と似ています。2つの差は[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.
Kink Messageヘッダーには、「解釈のドメイン（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ワーキンググループは、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フィールドは、IPsec-DOIの代わりにGDOIが使用されていることを示し、kink_isakmpペイロードには、[Payload]ではなくGDOI文書で定義されているペイロードが含まれています。Quick Mode。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ワーキンググループは、レイヤ3（すなわち、IP層）で暗号的に安全なSASを作成および維持する能力を提供するいくつかのプロトコルを定義した。この努力は2つの異なるプロトコルを作成しました：
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）を定義しました。ピアツーピアプロトコルの欠点の1つは、各ピアがサイトの知って実装しなければならないことです。
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.
私たちの作業グループの椅子のDerek AtkinsとJonathan Trostleを含むキンクの努力に貢献してきました。元のインスピレーションはCableLabのPacketcableの努力から来ました。IKEフェーズ2を再利用するためのインスピレーションは、Kerberos認証をクイックモードにグラフトすることを提案したTero Kivinenの文書の結果です。
[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、「RFCの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. Carrele、「インターネット鍵交換（IKE）」、RFC 2409、1998年11月。
[IPDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[IPDOI]パイパー、D.、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPsec]ケント、S.およびK. SEO、「インターネットプロトコルのためのセキュリティアーキテクチャ」、RFC 4301、2005年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.、Scherller、M.、Schneider、M.、およびJ.Turner、「Internet Security Association and Key Management Protocol（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/ashignments/isakmp-registry>。
[KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[KCRYPTO] Raeburn、K。、「Kerberos 5の暗号化とチェックサム仕様」、2005年2月、RFC 3961。
[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 Network認証サービス（V5）」、RFC 4120、2005年7月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964] LINN、J.、「Kerberos Version 5 GSS-APIメカニズム」、RFC 1964、1964年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）プロトコル」、RFC 4306、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.、「Kerber化されたインターネット交渉の要求」、RFC 3129、2001年6月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J.、 "Transmission Control Protocol"、STD 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.、「Generic Security Service Application Program Interface Version 2、Update 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
Ken'ichi Kamada Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi, Tokyo 180-8750 Japan
鎌田賢一横川電気株式会社2-9-32中町、武蔵野市、東京180-8750日本
EMail: Ken-ichi.Kamada@jp.yokogawa.com
Michael Thomas Cisco Systems 170 West Tasman Drive San Jose, CA 95134
Michael Thomas Cisco Systems 170 West Tasman Drive San Jose、CA 95134
EMail: mat@cisco.com
Jan Vilhuber Cisco Systems 170 West Tasman Drive San Jose, CA 95134
Jan Vilhuber Cisco Systems 170 West Tasman Drive San Jose、CA 95134
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事務局のコピーと利用可能なライセンスの保証、またはこの仕様書の実装者や利用者による一般的なライセンスまたは許可を得るための試みの結果を得ることができます。IETFオンラインIPRリポジトリから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-ipr@ietf.orgのIETFに情報に対処してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。