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)
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.
この文書では、キーのKerberos対応インターネット交渉（KINK）プロトコルを記述しています。 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は、一貫したセキュリティポリシーを維持することが重要である一元管理された環境内で通信するエンティティ間のキーを確立するためのセキュアでスケーラブルなメカニズムを提供するように設計されています。 KINKのセキュリティ目標は、プライバシー、認証、および鍵管理メッセージの再生保護を提供するために、可能な限りサービスの脆弱性の拒否を避けるためです。プロトコルのパフォーマンス目標は、低計算コスト、低遅延、および小さなフットプリントを持っています。これは、公開鍵操作の使用を回避または最小限に抑えることもあります。具体的には、プロトコルは、最小限の計算量を持つ2つのメッセージにIPsecセキュリティアソシエーション（SA）を確立するための機能を提供します。これらの要件は、[REQ4KINK] RFC 3129に記述されています。
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]は、信頼できるサードパーティのモデルを使用して、クライアントとサーバーのための効率的な認証メカニズムを提供します。ケルベロスはまた、ネイティブレルム間の認証のためのメカニズムを提供します。クライアントがオンライン認証サーバーからチケットを取得し、キー配布センター（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.
それは計算コストを制限し、公開鍵暗号[IKE]を使用するIKEの必要性対複雑さを制限するためケルベロスによって提供される中央キー管理が効率的です。 KDCへの最初の認証はケルベロス[PKINIT]で初期認証のために公開鍵暗号を使用して対称鍵、または非対称キーのいずれかを使用して行うことができます。しかし、チケットだけでなく、クライアントとサーバの間で認証交換のための後続の要求は常に対称暗号化を利用しています。したがって、公開鍵操作（もしあれば）が限定され、KDCに初期認証動作で取得した資格証明の有効期間にわたって償却されます。例えば、クライアントが効率的にKDCの分野で多くの他のサーバと複数のSAを確立するために、KDCとの単一の公開鍵交換を使用することができます。ケルベロスはまた、対称鍵が使用される場合、直接ピア・ツー・ピア・キーイングよりも良好なスケール。 「n」はクライアントの数であり、「m」は数ある理由のキーをKDCに格納されているので、主キーの数はO（N + M）ではなくO（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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を作成、削除、および維持することができ、コマンド/応答プロトコルです。各コマンドまたは応答は、タイプレングス値ペイロードのセットとともに共通ヘッダを含んでいます。コマンドまたは応答のタイプは、為替のメッセージで送信ペイロードを制約します。 KINK自体は、各コマンドまたは応答がKINKハード状態のストレージを必要としないことでステートレスプロトコルです。これは、最初のインターネットセキュリティ協会と、後続のクイックモード交換に続いて鍵管理プロトコル（ISAKMP）SAを確立するためのメインモードを使用してIKEとは対照的です。
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メカニズムを使用しています。 SAを確立するために、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で定義されたクイックモードのペイロードを再利用します。ほとんどの場合、KINK交換は、単一のコマンドとその応答しています。レスポンダはイニシエータからの第1の提案を拒否し、またはキーイング材料に寄与したい場合にのみ、SAを作成するときに、オプションの第3のメッセージが必要です。 KINKはまた、再入力して死んだピアの検出を提供します。
All KINK message flows follow the same pattern between the two peers: a command, a response, and an optional acknowledgement in a CREATE flow. A command is a GETTGT, CREATE, DELETE, or STATUS message; a response is a REPLY message; and an acknowledgement is an ACK message.
CREATEフローのコマンド、応答、および任意の確認応答：すべてのKINKメッセージは、2つのピア間で同じパターンに従って流れます。コマンドは、作成、削除、またはステータスメッセージ、GETTGTあります。応答は、応答メッセージです。そして、確認応答はACKメッセージです。
KINK uses Kerberos as the authentication mechanism; therefore, a KINK host needs to get a service ticket for each peer before actual key negotiations. This is basically a pure Kerberos exchange and the actual KDC traffic here is for illustrative purposes only. In practice, when a principal obtains various tickets is a subject of
KINKは、認証メカニズムとしてKerberosを使用しています。そのため、KINKホストは、実際のキー交渉する前に、各ピアのサービスチケットを取得する必要があります。これは基本的に純粋なKerberosの交換であり、ここで実際のKDCトラフィックは例示のみを目的としています。実際には、校長は、様々なチケットを取得した場合の対象であります
Kerberos and local policy consideration. As an exception, the GETTGT message flow of KINK (described in section 3.1) is used when a User-to-User authentication is required. In this flow, we assume that both A and B have ticket-granting tickets (TGTs) from their KDCs.
Kerberosおよびローカルポリシーの検討。ユーザ対ユーザ認証が要求される場合は例外として、（セクション3.1を参照）KINKのGETTGTメッセージフローが使用されます。このフローでは、AとBの両方が彼らのKDCからチケット認可チケット（のTGT）を持っていることを前提としています。
After a service ticket is obtained, KINK uses the CREATE message flow (section 3.2), DELETE message flow (section 3.3), and STATUS message flow (section 3.4) to manage SAs. In these flows, we assume that A has a service ticket for B.
サービスチケットを取得した後、KINKは、SAを管理するためのメッセージフロー（セクション3.3）、およびSTATUSメッセージフロー（セクション3.4）を削除メッセージを作成フロー（セクション3.2）を使用します。これらのフローでは、我々は、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:
イニシエータは、応答者のために、通常の（非ユーザ間）サービスチケットを取得することができないことを決定した場合、それはユーザ対ユーザ認証を試すことができます。この場合、第1ユーザ間のサービスのチケットを取得するためには、レスポンダから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 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_ERR_MUST_USE_USER2USERエラーがKDCから返されます。
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.
この流れは、SAを作成します。 CREATEコマンドは、SASが最初にレスポンダが最初の提案ペイロードを選ぶだろうという期待に作成された「楽観的」アプローチを取ります。楽観的な提案は、最初の提案の最初の変換ペイロード（S）内に配置されます。イニシエータは、楽観的な提案がLIFE_KILOBYTESとLIFE_SECONDSの例外を除いて、イニシエータの楽観的な提案のものと同一である必要があり、すべての変換および属性を、比較することによって、選択されたかどうかを確認するためにチェックしなければなりません。これらの属性はそれぞれ、応答者によって低い値に設定し、まだ楽観的キーイングを期待しますが、NO-提案型CHOSENエラーを生成しなければならない高い値に設定してはならないかもしれません。イニシエータは短い生涯を使用しなければなりません。
When a CREATE command contains an existing Security Parameter Index (SPI), the responder MUST reject it and SHOULD return an ISAKMP notification with INVALID-SPI.
CREATEコマンドは、既存のセキュリティパラメータインデックス（SPI）が含まれている場合、応答者はそれを拒絶しなければなりませんし、INVALID-SPIでのISAKMP通知を返すべきです。
When a key exchange (KE) payload is sent from the initiator but the responder does not support it, the responder MUST reject it with an ISAKMP notification of INVALID-PAYLOAD-TYPE containing a KE payload type as its notification data. When the initiator receives this error, it MAY retry without a KE payload (as another transaction) if its policy allows that.
鍵交換（KE）ペイロードは、イニシエータから送信されたが、応答者はそれをサポートしていない場合、応答者はその通知データとしてKEペイロードタイプを含むINVALID-PAYLOAD-TYPEのISAKMP通知でそれを拒絶しなければなりません。イニシエータがこのエラーを受信した場合、そのポリシーがそれを許可する場合、それは（別のトランザクションなど）KEペイロードなしで再試行することができます。
A B KDC
------ ------ ---
A creates an optimistic inbound SA (B->A) unless using a KE.
AはKEを使用しない限り、楽観インバウンド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）を作成します。 KEを使用して楽観的でない場合、Bは、アウトバウンド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）を作成します。非楽観的ならばAは、インバウンドSA（B-> 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.
2ウェイハンドシェイクと3ウェイハンドシェイク：SAを作成するには、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がAの楽観的な提案に同意した場合、Bは、インバウンドSA（A-> Bを作成し）、次にB. 3にCREATEメッセージを送信する）、次にB. 2から任意のメッセージを受信する準備ができている）およびアウトバウンドSA（B- >そのデータベース内のA）。 Bは、最初の提案を選択するか、ノンスペイロードを追加したいしない場合は、下記の3ウェイハンドシェイクの3段階に切り替えます。 4）Bは、次いで、ナンスペイロードなしでACKを要求することなく、Aに応答を送信します。 5）REPLYを受信すると、Aは、アウトバウンド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）ホストAは、任意のSAを作成せずにBために作成メッセージを送信します。 2）Bは、そのポリシーに従って一つの提案を選択します。 3）Bは、インバウンドSA（A-> B）を作成し、応答に実際の選択を送信します。それは（それがメッセージの数を増やすと、一般的にエントロピーソースを増加しないように）任意のナンスペイロードを送るべきであり、応答が認められることを要求しなければなりません。 4）REPLYを受信すると、Aは、インバウンドSA（B-> A）を作成する（または2-wayから切り替えた場合、必要に応じてそれを修正）、および発信SA（A-> B）。 5）Aは現在、ACKメッセージを送信します。 6）ACKを受信すると、Bは、最終的なアウトバウンドSA（B-> A）をインストールします。
If B does not choose the first proposal, adds a nonce, or accepts the KE exchange, then it MUST request an ACK (i.e., set the ACKREQ bit) so that it can install the final outbound SA. The initiator MUST always generate an ACK if the ACKREQ bit is set in the KINK header, even if it believes that the responder was in error.
Bは、最初の提案を選択しない場合は、ノンスを追加、またはKE交換を受け入れ、それが最終的なアウトバウンドSAをインストールできるように、それはACK（即ち、設定ACKREQビット）を要求しなければなりません。 ACKREQビットがKINKヘッダーに設定されている場合、イニシエータは常に、それは応答が誤りであったと考えている場合でも、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 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.
CREATEコマンドの楽観的なアプローチは、SAが二つのメッセージではなく、3で作成することができます。 2つのメッセージ交換の意味は、Bは、それがBから任意の追加のキーイング材料を受信する前に、Aは、インバウンドSAをセットアップしなければならないので、これは、通常の状態では疑わしいかもしれキーに寄与しないことです。しかしながら、KINKはKDCがキー導出に使用されるランダム性の信頼できるソースを提供するという事実を利用します。 Bは承認を必要としないように、多くの場合、これは、適切なセッションキーを提供します。 Bは、鍵素材に貢献して自由に常にあるので、これは厳密にはトレードオフKINK実装はポリシーの問題として決めることができるメッセージの数、対キーの強度との間にあります。
The DELETE command deletes existing SAs. The domain of interpretation (DOI)-specific payloads describe the actual SA to be deleted. For the IPsec DOI, those payloads will include an ISAKMP payload containing the list of the SPIs to be deleted.
DELETEコマンドは、SAを、既存の削除されます。解釈のドメイン（DOI）特異的ペイロードは、削除する実際のSAを記述する。 IPsecのDOIのために、それらのペイロードを削除するのSPIのリストを含むISAKMPペイロードを含むであろう。
A B KDC
------ ------ ---
A deletes outbound SA to B.
Aは、Bに発信SAを削除します
1 DELETE+ISAKMP------------>
B deletes inbound and outbound SA to A.
BはAにインバウンドとアウトバウンドSAを削除します
2 <-------------REPLY+ISAKMP
A deletes inbound SA to B.
B.へのインバウンドSAを削除
Figure 3: DELETE Message Flow
図3：メッセージフローをDELETE
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コマンドは、それが他のホストは、DELETEを受信したことを確認応答を受信するまで、インバウンドSAを削除しない「悲観的」アプローチを取ります。イニシエータはすぐに着信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削除ペイロード（複数可）を含有します。 KINKは、ハーフオープンSAを許可していません。レスポンダがDELETEコマンドを受信した場合、したがって、それは双方向のSAを削除する必要があり、このフローのレスポンダのインバウンドSA（単数または複数）を示すISAKMP削除ペイロード（S）で応答しなければなりません。応答者が削除する適切なSPIを見つけることができない場合、それはまた、インバウンドSAを削除できることをイニシエータに通知するのに役立つINVALID_SPI、とISAKMP通知を返さなければなりません。
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.
DELETEフローとの競合状態が存在します。 DELETE操作が行われている間、ネットワークの並べ替えなど、飛行中のパケットにインバウンドSAを削除することをお勧めします上記の図、後に到着するかもしれません。 KINK実装は、少なくとも2倍の平均ラウンドトリップ時間の期間に、または設定可能な値に設定する必要が猶予タイマーを実装する必要があります。 KINK実装は、不正にSAを削除するには、適切なタイミングで猶予期間をゼロに設定することを選択するかもしれません。ここで説明する動作はTCP [RFC793]フラグFIN及びRSTの挙動から参照されています。
This flow is used to send any information to a peer or to elicit any information from a peer. An initiator may send a STATUS command to the responder at any time, optionally with DOI-specific ISAKMP payloads. In the case of the IPsec DOI, these are generally in the form of ISAKMP Notification payloads. A STATUS command is also used as a means of dead peer detection described in section 3.7.
このフローは、ピアに情報を送信するために、またはピアから情報を引き出すために使用されます。開始剤はDOI固有ISAKMPペイロードで必要に応じて、いつでもレスポンダにSTATUSコマンドを送信することができます。 IPsecのDOIの場合、これらは、ISAKMP通知ペイロードの形で一般的。 STATUSコマンドはまた、セクション3.7で説明したデッド・ピア検出の手段として使用されます。
A B KDC
------ ------ ---
1 STATUS[+ISAKMP]---------->
2 <-----------REPLY[+ISAKMP]
Figure 4: STATUS Message Flow
図4：STATUSメッセージフロー
When the responder detects an error in a received command, it can send a DOI-specific payload to indicate the error in a REPLY message. There are three types of payloads that can indicate errors: KINK_KRB_ERROR payloads for Kerberos errors, KINK_ERROR payloads for KINK errors, and KINK_ISAKMP payloads for ISAKMP errors. Details are described in sections 4.2.3, 4.2.8, and 4.2.6, respectively.
応答者が受信したコマンドにエラーを検出した場合、それは、応答メッセージ内のエラーを示すためにDOI固有のペイロードを送信することができます。 KerberosのエラーについてKINK_KRB_ERRORペイロード、KINKエラーのKINK_ERRORペイロード、およびISAKMPエラーのKINK_ISAKMPペイロード：エラーを示すことができペイロードの3つのタイプがあります。詳細は、それぞれ、セクション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 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.
サーバクロックとクライアントのクロックがオフポリシー決定クロックスキュー限界（通常5分）を超えている場合、サーバはKRB_AP_ERR_SKEWを返さなければなりません。 KRB-ERRORでオプションのクライアントの時間を記入するべきです。サーバがCKSUMフィールドを追加し、正しいクライアントの時間を返すことによって、エラーを保護した場合、クライアントは、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.
KINKは、SAのイニシエータは二つの理由でSAを再入力するための責任を負うことを期待しています。最初の理由は、両方が既存のSAを更新しようとしているイニシエータとレスポンダに衝突の結果として、SAの不必要な重複を防ぐためです。第二の理由は、クライアントがチケットを取得し、維持することを期待ケルベロス交換のクライアント/サーバーの性質上、によるものです。 KINKはKINKホストがチケットを取得し、維持することが可能であることを期待していますが、実際には、サーバは、彼らが大きなチケットキャッシュを維持する必要がないようにセッションを開始するためにクライアントを待つためにしばしば有利です。
There are no special semantics for rekeying SAs in KINK. That is, in order to rekey an existing SA, the initiator must CREATE a new SA followed by either deleting the old SA with the DELETE flow or letting it time out. When identical flow selectors are available on different SAs, KINK implementations SHOULD choose the SA most recently created. It should be noted that KINK avoids most of the problems of [IKE] rekeying by having a reliable delete mechanism.
KINKでSAを再入力するための特別な意味はありません。これは、既存のSAキーを再生成するためには、イニシエータは、DELETE流れと古いSAを削除するか、それを時間を出してどちらかに続いて新しいSAを作成する必要があります。同じフローセレクタが異なるのSAで利用可能である場合には、KINK実装は、最近作成されたSAを選択する必要があります。 KINKが信頼削除機構を有することにより、[IKE]鍵の再生成の問題のほとんどを回避ことに留意すべきです。
Normally, a KINK implementation that rekeys existing SAs will try to rekey the SA ahead of an SA termination, which may include the hard lifetime in time/bytecount or the overflow of the sequence number counter. We call this time "soft lifetime". The soft lifetime MUST be randomized to avoid synchronization with similar implementations. In the case of the lifetime in time, one reasonable approach to determine the soft lifetime is picking a random time between T-rekey and T-retrans and subtracting it from the hard lifetime. Here, T-rekey is the reasonable maximum rekeying margin, and T-retrans is the amount of time it would take to go through a full retransmission cycle. T-rekey SHOULD be at least twice as high as T-retrans.
通常は、SAを既存のキー更新KINK実装は、前もって/：バイトでハード寿命やシーケンス番号カウンタのオーバーフローを含むことがSAの終了、のSAキーを再生成しようとします。私たちは、「ソフトな生涯」、この時間を呼び出します。ソフト寿命は同様の実装との同期を避けるために、ランダム化されなければなりません。時間の寿命の場合、一つの合理的なアプローチは、ソフト寿命がT-リキー及びT-RETRANS間のランダム時間を選ぶとハード寿命からそれを減算されるかを決定します。ここで、T-リキーは、合理的な最大再入力マージン、およびT-RETRANSが、それは完全な再送周期を通過するのにかかる時間の量です。 T-リキーは、T-RETRANSの少なくとも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 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.
KINKピアがそのセキュリティデータベースの情報が失われたことを決定するために、KINKピアは、それらがピアに対して有効なSA情報を持っている現在のエポックを記録し、各AP-REQ及びAP-REPメッセージ内のそのエポックを反映しなければなりません。 KINKピアが与えられたSAの状態を作成するとき、それはまた、校長のエポックを記録しなければなりません。それは校長のエポックが変更されたことを後続のメッセージに発見した場合は、無効としてそのプリンシパルによって作成されたすべてのSAを検討し、そのようなそれらのSAを切断として何らかのアクションを取る必要があります。
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).
KINKピアは、ピアがまだ生きているか否かを確認するためにトリガーとして（ICMPメッセージの形式で）ルーティングからのフィードバックを使用する必要がありますが、KINKピアはピアを締結してはいけません単に保護されていないルーティング情報にデッド基づいている（ICMPを前記メッセージ）。
If there is suspicion that a peer may be dead (based on any information available to the KINK peer, including lack of IPsec traffic, etc.), the KINK STATUS message SHOULD be used to coerce an acknowledgement out of the peer. Since nothing is negotiated about dead peer detection in KINK, each peer can decide its own metric for "suspicion" and also what timeouts to use before declaring a peer dead due to lack of response to the STATUS message. This is desirable, and does not break interoperability.
ピアが（等IPsecトラフィックの欠如、を含むKINKピアに利用可能な任意の情報に基づいて）死んでもよいことを疑いがある場合、キンクSTATUSメッセージは、ピアから肯定応答を強制するために使用されるべきです。何もKINKのデッドピア検出について交渉されていないので、各ピアが原因STATUSメッセージに対する応答がないために死んだ仲間を宣言する前に、使用するタイムアウト何も「疑い」のために、独自のメトリックを決定することができます。これが望ましい、との相互運用性を破壊しません。
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.
STATUSメッセージは、二重の効果があります。まず、それは相手が生き/到達可能であるかどうかを教えてくれるピアから暗号的に確保（およびリプレイで保護）応答を惹起します。第二に、それはピアのエポック番号を運ぶので、私たちは、ピアが再起動されたか否かを知ると、すべての状態を失いました。ピアがリブートした場合、IKEでは、我々はすべての暗号の文脈を失い、無暗号化された安全な通信は、キーを再交渉することなく可能である：これはKINKプロトコルに不可欠です。 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.
STATUSと応答を送信ピアBに送信ピアAを想定する（セクション3.4を参照）。ピアBは、送信者が生きていることを仮定してもよいし、STATUSメッセージにおけるエポックは、ピアAが状態を失ったかどうかを示します。セクション3.4で説明したように、ピアBは、REPLYメッセージとステータスメッセージを確認しなければなりません。
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.
応答メッセージがそのピアが生きている、およびREPLYにおけるエポックは、ピアBの状態が失われたか否かを示すことになるピアに指示します。ピアAは、適切なタイムアウトでピアBから応答メッセージを受信しない場合、別のSTATUSメッセージを送信することができるピア。これは、ピアBが死んで宣言する方法を積極的に決定するピアにアップしています。攻撃性のレベルは、急速にはSAの数が多いノードによって送信されるメッセージの数に対するフェイルオーバーのような多くの要因に依存し得ます。
Note that peer B MUST NOT make any inferences about a lack of STATUS message from peer A. Peer B MAY use a STATUS message from peer A as an indication of A's aliveness, but peer B MUST NOT expect another STATUS message at any time (i.e., dead peer detection is not periodic keepalives).
（そのピアBがAの稼働状態の指標として、ピアAからSTATUSメッセージを使用するかもしれピアA.ピアBからSTATUSメッセージの欠如についての推論をしない必要がありますが、ピア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.
STATUSメッセージを送信するための戦略は、以下の通りである：Aが唯一のトラフィックがピアとのIPsec SAの上でどちらの方向に送信されなかった長期間の後にステータスメッセージを送信することを決めるかもしれピア。トラフィックがあるならば、ピアAは、トラフィックがブラックホールに起こっているかどうかを知りたい、とSTATUSメッセージを送信することができます。また、ピア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.
応答者がそのTGTで復号化することができないユーザ対ユーザチケットとKINKコマンドを受信すると、O、それは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.
イニシエータがKINK_TGT_REPを受信すると、O、それは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の受信時に死んでいたと考えてはなりません。一つは、メッセージが認証されていないことであり、他は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のすべての値は、ネットワークバイト順（最上位バイトが最初）でフォーマットされています。 RESERVEDフィールドはゼロに設定しなければなりません（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 RESERVED（4ビット） - 送信されるとき、受信時に予約され、ゼロでなければならない、無視しなければなりません。
o Length (2 octets) -- Length of the message in octets. It is not forbidden in KINK that there are unnecessary data after the message, but the Length field MUST represent the actual length of the message.
O長（2つのオクテット） - オクテット内のメッセージの長さ。メッセージの後に不要なデータがあることをKINKでは禁止されていませんが、長さフィールドは、メッセージの実際の長さを表現しなければなりません。
o DOI (4 octets) -- The domain of interpretation. All DOIs must be registered with the IANA in the ISAKMP Domain of Interpretation section of the isakmp-registry [ISAKMP-REG]. The IANA Assigned Number for the Internet IP Security DOI [IPDOI] is one (1). This field defines the context of all sub-payloads in this message. If sub-payloads have a DOI field (e.g., Security Association Payload), then the DOI in that sub-payload MUST be checked against the DOI in this header, and the values MUST be the same.
O DOI（4つのオクテット） - 解釈のドメイン。すべてのDOIは、ISAKMP-レジストリの解釈部のISAKMPドメイン[ISAKMP-REG]にIANAに登録する必要があります。インターネットIPセキュリティDOI [IPDOI]のためのIANA割り当てられる番号は1である（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.
NextPayload（1つのオクテット）O - メッセージヘッダーの後の最初のペイロードのタイプを示します。
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リクエスト。応答者がREPLYを受信したことを明示的な承認を必要とする場合は1に設定します。イニシエータは、このフラグを設定してはいけません、またレスポンダは楽観的な提案が選択されたときに作成するために、REPLYを除く必要があります。
o RESERVED2 (7 bits) -- Reserved and MUST be zero on send, MUST be ignored by a receiver.
（7ビット）RESERVED2 O - 予約及び送信にゼロでなければならない、受信機によって無視されなければなりません。
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フィールド自体を除く、メッセージ全体にわたってケルベロスキー付きチェックサム。任意のパディングバイトが最後のペイロードと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.
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を減算する、長さフィールドの値から計算されます。 Lengthフィールドは、長さなしのチェックサム値で満たされているとCksumLenフィールドがゼロにされます。次いで、チェックサムなしのパケットはverify_mic関数に渡され（長せず、チェックサム最後からのオフセット）とチェックサム（0から受信したパケットのマイナス1せずチェックサム長さにオフセット）。検証が失敗した場合、メッセージは削除されなければなりません。
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すべての長さフィールドは、構造体のオクテットの実際の数を反映しなければなりません。すなわち、彼らはKINK整列で必要とされるパディングバイトを考慮していません。
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）ペイロードのリストがあります。ヘッダに続くペイロードの数に制限はありません。各ペイロードは、ペイロードヘッダで開始しなければなりません。各ペイロードヘッダは汎用ペイロードヘッダーの上に構築されています。任意のデータはすぐにジェネリックヘッダーに続きます。ペイロード長フィールドは正確にペイロードのオクテットの実際の数を反映しなければならないのにペイロードはすべて暗黙的に、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：KINKペイロードのフォーマット
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 RESERVED（1つのオクテット） - 予約と送信者によってゼロに設定する必要があり、受信機で無視しなければなりません。
o Payload Length (2 octets) -- The length of this payload, including the type and length fields.
Oペイロード長（2つのオクテット） - このペイロードの長さ、タイプと長さフィールドを含みます。
o Value (variable) -- This value of this field depends on the type.
O値（変数） - このフィールドの値は、タイプによって異なります。
The KINK_AP_REQ payload relays a Kerberos AP-REQ to the responder. The AP-REQ MUST request mutual authentication.
KINK_AP_REQペイロードは、レスポンダにケルベロスAP-REQを中継します。 AP-REQは、相互認証を要求しなければなりません。
This document does not specify how to generate the principal name. That is, complete principal names may be stored in local policy, Fully Qualified Domain Names (FQDNs) may be converted to principal names, IP addresses may be converted to principal names by secure name services, etc., but see the first paragraph of the Security Considerations section.
この文書では、プリンシパル名を生成する方法を指定しません。これは、完全なプリンシパル名は完全修飾ドメイン名（FQDN）がプリンシパル名に変換することができる、IPアドレス等、安全なネームサービスによってプリンシパル名に変換することができる、ローカルポリシーに保存されているが、最初の段落を参照することができるさSecurity Considerations部。
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].
KINKサービスのためのピアのプリンシパル名がFQDNから生成されている場合は、イニシエータから始まりプリンシパル名は、「キンク/ FQDNする@ REALM」になります。 「キンク」は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次ペイロード、RESERVED、ペイロード長 - このセクションの冒頭で定義されます。
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キーイングデーモンが起動したときに一般的に、これはあります。このフィールドの値が経過秒、いわゆるPOSIX時間の最下位4つのオクテットである（ただし、うるう秒をカウントせず）から1970-01-01T00：00：00 UTC。例えば、2038-01-19T03：14：07 UTCは0x7FFFFFFFでのように表されます。
o AP-REQ -- The value field of this payload contains a raw Kerberos AP-REQ.
O AP-REQ - このペイロードの値フィールドは、生のKerberos AP-REQを含んでいます。
The KINK_AP_REP payload relays a Kerberos AP-REP to the initiator. The AP-REP MUST be checked for freshness as described in [KERBEROS].
KINK_AP_REPペイロードは、イニシエータにケルベロス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次ペイロード、RESERVED、ペイロード長 - このセクションの冒頭で定義されます。
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.
AP-REPの作成者は、有効なSA情報を有する絶対時刻れる - O EPOCH。それが再起動してSA情報を保持していない場合KINKキーイングデーモンが起動したときに一般的に、これはあります。このフィールドの値が経過秒、いわゆるPOSIX時間の最下位4つのオクテットである（ただし、うるう秒をカウントせず）から1970-01-01T00：00：00 UTC。例えば、2038-01-19T03：14：07 UTCは0x7FFFFFFFでのように表されます。
o AP-REP -- The value field of this payload contains a raw Kerberos AP-REP.
O AP-REP - このペイロードの値フィールドは、生のKerberos AP-REPを含有します。
The KINK_KRB_ERROR payload relays Kerberos type errors back to the initiator. The initiator MUST be prepared to receive any valid Kerberos error type [KERBEROS].
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_KRB_ERRORを返すときKINK実装は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実装はそれらを受け取るために準備しなければなりませんし、それらを記録することがありますけれども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次ペイロード、RESERVED、ペイロード長 - このセクションの冒頭で定義されます。
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次ペイロード、RESERVED、ペイロード長 - このセクションの冒頭で定義されます。
o PrincName -- The name of the principal that the initiator wants to communicate with. It is assumed that the initiator knows the responder's principal name (including the realm name) in the same way as the non-User-to-User case. The TGT returned MUST NOT be an inter-realm TGT and its cname and crealm MUST match the requested principal name, so that the initiator can rendezvous with the responder at the responder's realm.
O PrincName - イニシエータが通信したいプリンシパルの名前。イニシエータが非ユーザ間の場合と同様に（レルム名を含む）応答のプリンシパル名を知っているものとします。 TGTは、レルム間TGTとそのCNAMEにすることはできません返されると、イニシエータは、レスポンダーのレルムでの応答とランデブーすることができるようcrealmは、要求されたプリンシパル名と一致しなければなりません。
PrincName values are octet string representations of a
principal and realm name formatted just like the octet string
used in the "NAME" component of Generic Security Service
Application Program Interface (GSS-API) [RFC2743] exported
name token for the Kerberos V5 GSS-API mechanism [RFC1964].
See RFC 1964, section 2.1.3.
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_U2UDENIEDを返す場合があります。
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次ペイロード、RESERVED、ペイロード長 - このセクションの冒頭で定義されます。
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次ペイロード、RESERVED、ペイロード長 - このセクションの冒頭で定義されます。
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メッセージ内KINK_ISAKMPペイロードの任意の数があるかもしれません。 [IKE]は複数の異なるSAが単一IKEメッセージ内で作成することができるかどうか多少あいまいであるが、KINKは、明示的に新たなISAKMPヘッダは各離散SA操作に使用されることを要求します。言い換えれば、KINK実装は、単一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と0（1.0）に設定されています。これらのバージョンは、ISAKMPヘッダーのISAKMPバージョンに対応していません。準拠したKINK実装は、1.0ペイロードの受信をサポートしなければなりません。それ以降のバージョン（送信と受信の両方）をサポートすることができ、キンクピアが将来のバージョンを処理できない場合クイックモードバージョン1.0に戻って頼るための手段を提供しなければなりません。準拠したKINK実装は、任意のトランザクションでクイックモードバージョンを混在してはなりません。
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ペイロードをカプセル化し、セッションキーとそのETYPEで指定されたアルゴリズムを使用して暗号化されます。このペイロードは、メッセージの外側のペイロードチェーンの最後の一つでなければなりません。最終KINKチェックサムが適用される前に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次ペイロード、RESERVED、ペイロード長 - このセクションの冒頭で定義されます。このペイロードは、メッセージの最後の一つであり、それに応じて、次にペイロードフィールドはKINK_DONE（0）でなければなりません。
o InnerNextPload -- First payload type of the inner series of encrypted KINK payloads.
O InnerNextPload - 暗号化されたKINKペイロードのインナーシリーズの最初のペイロードタイプ。
o RESERVED2 -- Reserved and MUST be zero when sent, MUST be ignored when received.
O RESERVED2 - 送られたときに受信した場合に予約され、ゼロでなければならない、無視しなければなりません。
The coverage of the encrypted data begins at InnerNextPload so that the first payload's type is kept confidential. Thus, the number of encrypted octets is PayloadLength - 4.
最初のペイロードのタイプは秘密にされるように、暗号化されたデータのカバレッジはInnerNextPloadから始まります。 4 - このように、暗号化されたオクテットの数がPayloadLengthです。
The format of the encryption payload follows the normal Kerberos semantics. Its content is the output of an encrypt function defined in the Encryption Algorithm Profile section of [KCRYPTO]. Parameters such as encrypt function itself, specific-key, and initial state are defined with the etype. The encrypt function may have padding in itself and there may be some garbage data at the end of the decrypted plaintext. A KINK implementation MUST be prepared to ignore such padding after the last sub-payload inside the KINK_ENCRYPT payload. Note that each encrypt function has its own integrity protection mechanism. It is redundant with the checksum in the KINK header, but this is unavoidable because it is not always possible to remove the integrity protection part from the encrypt function.
暗号ペイロードのフォーマットは通常のKerberosセマンティクスに従います。その内容は、[KCRYPTO]の暗号化アルゴリズムプロファイルセクションで定義された暗号化関数の出力です。このような暗号化関数自体、特定のキー、初期状態等のパラメータはETYPEで定義されています。暗号化機能は、それ自体でパディングを有していてもよいし、復号された平文の終わりにいくつかのごみデータが存在してもよいです。 KINK実装は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次ペイロード、RESERVED、ペイロード長 - このセクションの冒頭で定義されます。
o ErrorCode -- One of the following values in the network byte order:
ErrorCode O - ネットワークバイト順序で次のいずれかの値です。
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ペイロードが存在しないかのように、イニシエータが作用してもよいです。イニシエータは、複数のクイックモードのバージョンをサポートしていますかDOIの、KINK_BADQMVERSまたはKINK_INVDOIが受信され、CKSUMが確認された場合、それは別のバージョンまたはDOIを再試行するかもしれません。それはヘッダにサポートされていないKINKバージョン番号を受信した場合、レスポンダは、KINK_INVMAJとKINKエラーを返すべきです。 KINK_U2UDENIEDを受信した場合（それがまだ試されていない場合）、イニシエータは非ユーザ対ユーザモードで再試行することができます。
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.
一般的には、応答者は、認証されていないコマンドに応答して、これらのエラーを返すのを選ぶかもしれが、サービス拒否攻撃に関与されないように注意する必要があります。同様に、イニシエータが認証されていないエラーに基づいて行動することを選択するかもしれないが、サービス拒否（DoS）攻撃を避けるために世話をする必要があります。
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は、直接SAをネゴシエートするためにISAKMPペイロードを使用しています。特に、KINKはIKEフェーズ2つのペイロードタイプ（別名クイックモード）を使用します。一般的には、SAを確立するために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は（セクション3.2および3.3を参照）は、主に予測可能なSAの作成/削除を容易にするために、作成、削除、およびSAの状態のための特定のコマンドを定義します。そのため、KINKは、コマンド、およびペイロードのうちのいくつかのいくつかの追加の制限およびセマンティクスで送ることができるものをペイロードに一定の制限を課します。実装は、実際のフォーマット及びセマンティクスのために[IKE]と[ISAKMP]を参照すべきです。特定のIKEフェーズ2のペイロードは、ここで言及されていない場合は、その使用には差がないことを意味します。
o The Security Association Payload header for IP is defined in section 4.6.1 of [IPDOI]. For this memo, the Domain of Interpretation MUST be set to 1 (IPsec) and the Situation bitmap MUST be set to 1 (SIT_IDENTITY_ONLY). All other fields are omitted (because SIT_IDENTITY_ONLY is set).
O IPのセキュリティアソシエーションペイロードヘッダは、[IPDOI]のセクション4.6.1で定義されています。このメモのために、解釈のドメイン（IPsec）の1に設定しなければならなく、状況ビットマップ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 KINKは全くHASHペイロードを使用していません。
o KINK allows the Nonce payload Nr to be optional to facilitate optimistic keying.
O KINKはナンスペイロードNrが楽観的キーイングを容易にするために、オプションにすることができます。
KINK supports the following SA attributes from [IPDOI]:
KINKは、次のSAは、[IPDOI]から属性をサポートしています。
class value type
-------------------------------------------------
SA Life Type 1 B
SA Life Duration 2 V
Encapsulation Mode 4 B
Authentication Algorithm 5 B
Key Length 6 B
Key Rounds 7 B
Refer to [IPDOI] for the actual definitions of these attributes.
これらの属性の実際の定義については、[IPDOI]を参照してください。
KINK directly uses the Proposal and Transform payloads with no differences. KINK, however, places additional relevance to the first proposal and first transform of each conjugate for optimistic keying.
KINKは、直接提案を使用していないの違いでペイロードを変換します。 KINKは、しかし、最初の提案に追加の関連性を配置し、最初の楽観キーイングのための各コンジュゲートの変換します。
The Identification payload carries information that is used to identify the traffic that is to be protected by the SA that will be established. KINK restricts the ID types, which are defined in section 4.6.2.1 of [IPDOI], to the following values:
識別ペイロードが確立されるSAによって保護されるトラフィックを識別するために使用される情報を搬送します。 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.
ナンスのペイロードは、鍵の生成に使用しなければならないランダムなデータが含まれています。これは、開始KINKピアによって送らなければなりませんし、応答KINKピアによって送信されるかもしれません。鍵生成におけるその使用に関する議論についてはセクション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.
以下の表は、通知メッセージとそれに対応する値を示しています。ペイロードMALFORMEDは[ISAKMP]によって定義されるいくつかのエラーの種類を表します。したがってINVALID-PROTOCOL-IDは、例えば、この文書で使用されていません。 KINK_BADQMVERSはIKEのバージョンがサポートされていないことをイニシエータに伝えるために使用されているので、INVALID-MAJOR-VERSIONとINVALID-MINOR-VERSIONは使用されません。
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ペイロードが応答者によってサポートされていないときにも送信されます。通知データMUSTは1オクテットのペイロードタイプが含まれています。
INVALID-SPI 11
INVALID-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は、DELETEの流れの場合には、イニシエータによって示される場合に送信されます。
NO-PROPOSAL-CHOSEN 14
NO-提案型CHOSEN 14
Sent if none of the proposals in the SA payload was acceptable.
SAペイロードの提案のいずれも許容しない場合に送信されます。
PAYLOAD-MALFORMED 16
ペイロードMALFORMED 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削除ペイロードを使用しています。
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は完全転送秘密（PFS）はKEペイロードを使用して、サポートされている必要があります。 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は通常、単調にインクリメントフィールドであり、応答者への未処理の要求を区別するために、イニシエータによって使用されます。その機能は、Kerberosのメカニズムによって提供されるようXIDフィールドは、リプレイ保護を提供しません。 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ペイロードは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.
REPLYメッセージはKINK_AP_REP、KINK_KRB_ERROR、またはKINK_ERRORペイロードのいずれかを含まなければならない一般的な応答です。 REPLYメッセージは、次のセクションで定義されている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ビットがREPLYメッセージに設定されている場合にのみ送信されます。 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.
このメッセージは、新しいセキュリティアソシエーション（S）の確立を開始します。 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]
KINKヘッダーKINK_AP_REQ [KINK_ENCRYPT] KINK_ISAKMPペイロードSAペイロード提案ペイロードをCREATEペイロードノンスペイロードニッケル（Ni）[KE] [IDci、IDCR] [通知ペイロード]を変換
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]
KINKヘッダーKINK_AP_REP [KINK_ENCRYPT] KINK_ISAKMPペイロードSAペイロード提案ペイロードは、ペイロード[ノンスペイロード（NR）] [KE] [IDci、IDCR] [通知ペイロード]を変換REPLY
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.
少なくとも一つの提案ペイロードとREPLYメッセージ内の単一変換のペイロードが存在しなければならないことに注意してください。 SAバンドルが交渉されたのみで、複数の提案ペイロードがあります。また：IKEとは異なり、ナンスペイロードNrが必要とされていない、それが存在する場合は、確認応答は、イニシエータの送信SAが修正されなければならないことを示すために要求されなければなりません。最初の提案のいずれかが受信者によって選択されていない場合は、ナンスペイロードを含むべきです。
KINK, like IKE, allows the creation of many SAs in one create command. If any of the optimistic proposals are not chosen by the responder, it MUST request an ACK.
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]
KINKヘッダーKINK_AP_REP [KINK_ENCRYPT] [KINK_ERROR] KINK_ISAKMPペイロード[通知ペイロードを] REPLY
If the responder finds a Kerberos error for which it can produce a valid authenticator, the REPLY takes the following form:
応答者は、それが有効な認証システムを作り出すことができるのKerberosエラーを発見した場合、REPLYは次の形式を取ります。
REPLY KINK Header KINK_AP_REP [KINK_ENCRYPT] KINK_KRB_ERROR
KINKヘッダー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:
レスポンダは、それがAP-REPを作成できないため、エラーのKerberosやKINKタイプを見つけた場合、最終的に、それは孤立KINK_KRB_ERROR又はKINK_ERRORペイロードで返答しなければなりません。
REPLY KINK Header [KINK_KRB_ERROR] [KINK_ERROR]
REPLY KINKヘッダー[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:
DELETEのための応答の3つの形式があります。通常の形式は次のとおりです。
REPLY KINK Header KINK_AP_REP [KINK_ENCRYPT] [KINK_ERROR] KINK_ISAKMP payloads Delete Payloads [Notification Payloads]
KINKヘッダーKINK_AP_REP [KINK_ENCRYPT] [KINK_ERROR] KINK_ISAKMPペイロードは、ペイロード[通知ペイロードを]返信削除
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]
KINKヘッダーKINK_AP_REP [KINK_ENCRYPT] [KINK_ERROR] KINK_ISAKMPペイロード[通知ペイロードを] REPLY
If the responder finds a Kerberos error for which it can produce a valid authenticator, the REPLY takes the following form:
応答者は、それが有効な認証システムを作り出すことができるのKerberosエラーを発見した場合、REPLYは次の形式を取ります。
REPLY KINK Header KINK_AP_REP [KINK_ENCRYPT] KINK_KRB_ERROR
KINKヘッダー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:
レスポンダは、エラーのKINKまたはKerberosタイプを見つけた場合、それが唯一のKINK_KRB_ERRORまたはKINK_ERRORペイロードで返答しなければなりません：
REPLY KINK Header [KINK_KRB_ERROR] [KINK_ERROR]
REPLY KINKヘッダー[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]]
STATUSは、次のペイロードが含ま：KINKヘッダーKINK_AP_REQ [KINK_ENCRYPT] KINK_ISAKMPペイロード[通知ペイロード]
There are three forms of replies for a STATUS. The normal form is:
STATUSのための応答の3つの形式があります。通常の形式は次のとおりです。
REPLY KINK Header KINK_AP_REP [[KINK_ENCRYPT] [KINK_ERROR] KINK_ISAKMP payload [Notification Payloads]]
REPLY KINKヘッダーKINK_AP_REP [KINK_ENCRYPT] [KINK_ERROR] KINK_ISAKMPペイロード[通知ペイロード]
If the responder finds a Kerberos error for which it can produce a valid authenticator, the REPLY takes the following form:
応答者は、それが有効な認証システムを作り出すことができるのKerberosエラーを発見した場合、REPLYは次の形式を取ります。
REPLY KINK Header KINK_AP_REP [KINK_ENCRYPT] KINK_KRB_ERROR
KINKヘッダー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:
レスポンダは、エラーのKINKまたはKerberosタイプを見つけた場合、それが唯一のKINK_KRB_ERRORまたはKINK_ERRORペイロードで返答しなければなりません：
REPLY KINK Header [KINK_KRB_ERROR] [KINK_ERROR]
REPLY KINKヘッダー[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コマンドのみケルベロス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を返すことが許可されている通常の形態で、REPLYは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])
KEYMAT = PRF鍵（SKEYID_d、[G（QM）^ XY |]プロトコル| 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.
[IKE]のセクション3.2に記載したようにNi_bとNr_b O両方がナンスペイロード（NiとNrと、それぞれ）の一部です。 Nr_bはゼロ長さの値が与えられたかのように応答者のノンス（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はKEペイロードは、ディフィー・ヘルマン鍵合意を使用して供給されるときに生成鍵材料を意味することに注意してください。これは、[IKE]のセクション5.5で説明されています。
The rest of the key derivation (e.g., how to expand KEYMAT) follows IKE. How to use derived keying materials is up to each service (e.g., section 4.5.2 of [IPSEC]).
鍵導出（例えば、KEYMATを展開する方法）の残りの部分は、IKEに従います。各サービスまでどのように誘導されたキーイング材料を使用することである（例えば、セクション4.5.2 [IPSEC]）。
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.
ケルベロス暗号化は/機能と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があります。ステートマシンは単純です：Kerberosは、メッセージがリプレイ保護のための新たな時代に再送されることを必要とするので、応答がタイマーTを使用して要求を再送信しなければならない期待するメッセージは、メッセージがメッセージのチェックサムを含むたびに再作成する必要があります。 ACKREQビットが設定されたどちらのコマンドと応答が再送信タイマーに保管されています。 KINKイニシエータはACKREQビットが設定された応答を受信すると、それはその完全な再送タイムアウト周期の最小のトランザクションに対するACKメッセージを再生する能力を保持しなければならないか、パケットが新たに構築されたSAに到着したことに気付くまで、いずれか最初に来ます。
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ピアがメッセージを再送信するときに、ピアがリプレイを区別し、パケットをドロップすることができるように、それはAP-REQのための新しいケルベロスオーセンティケータを作成する必要があります。飛行中の応答が受信される前処理/再送が発生したとき、これは潜在的な競合状態になります。この競合状態に対抗するには、再送信の当事者は、特定の取引のために傑出している有効な認証者のリストを維持する必要があります。
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ピアがコマンドを再送信すると、それが再送信内の同じチケットを使用しなければなりません。これは、イニシエータとレスポンダーの間で異なるKEYMATsにつながる異なるキーを使用して競合状態を避けるためです。この理由のため、（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サービスのアイデンティティですが、SAをで保護されたトラフィックは（など、IPアドレス、ポート番号）セレクタDOI固有で識別されます。これは、認証からSA-保護されたデータの離脱につながる可能性があります。二つの異なるホストが、彼らは同じIPアドレスを持っていると主張している場合、データを保護するプリンシパルのキーを予測することは不可能かもしれません。したがって、実装はプリンシパル名とSAセレクタ間の結合のための世話をする必要があります。
Sending errors without cryptographic protection must be handled very carefully. There is a trade-off between wanting to be helpful in diagnosing a problem and wanting to avoid being a dupe in a denial of service attack.
暗号保護せずにエラーを送信すると、非常に慎重に扱わなければなりません。問題を診断し、サービス拒否攻撃でだまされやすい人であること回避したいというのに役立ちたいとの間にトレードオフがあります。
KINK cobbles together and reuses many parts of both Kerberos and IKE, the latter which in turn is cobbled together from many other memos. As such, KINK inherits many of the weaknesses and considerations of each of its components. However, KINK uses only IKE phase 2 payloads to create and delete SAs; the security considerations which pertain to IKE phase 1 may be safely ignored. However, being able to ignore IKE's authentication phase necessarily means that KINK inherits all of the security considerations of Kerberos authentication as outlined in [KERBEROS]. For one, a KDC, like an Authentication, Authorization, and Accounting (AAA) server, is a point of attack and all that implies. Much has been written about various shortcomings and mitigations of Kerberos, and they should be evaluated for any deployment.
キンク丸石一緒にKerberosとIKEの両方の多くの部分を再利用し、今度は他の多くのメモから一緒に石畳される後者。そのため、KINKは、その構成要素のそれぞれの弱点と考慮事項の多くを継承します。しかし、KINKは、SAを作成および削除する2つのペイロードのみIKEフェーズを使用しています。 IKEフェーズ1に関連するセキュリティ上の考慮事項は、安全に無視することができます。しかし、IKEの認証フェーズを無視することができるということは、必ずしも[KERBEROS]に概説されているようKINKは、Kerberos認証のセキュリティの考慮事項のすべてを継承することを意味します。一つは、KDCは、認証、許可、アカウンティング（AAA）サーバのように、攻撃とそれが意味全ての点です。多くは、様々な欠点とKerberosの緩和策について書かれている、と彼らはどんな展開に評価されるべきです。
KINK's use of Kerberos presents a couple of considerations. First, KINK explicitly expects that the KDC will provide adequate entropy when it generates session keys. Second, Kerberos is used as a user authentication protocol with the possibility of dictionary attacks on user passwords. This memo does not describe a particular method to avoid these pitfalls, but recommends that suitable randomly generated 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.
ケルベロスのKINKの使用が検討事項のカップルを提示しています。まず、KINKは、明示的にセッションキーを生成するときにKDCが十分なエントロピーを提供することを期待しています。第二に、Kerberosは、ユーザーのパスワードの辞書攻撃の可能性を持つユーザーの認証プロトコルとして使用されています。このメモは、これらの落とし穴を避けるために、特定の方法を説明し、それが実用的であるとき、適当なランダムに生成されたキーは、MITの「kadminのaddprinc」コマンドで-randomkeyオプションを使用するなど、サービスプリンシパルのためだけでなく、クライアントのために使用されるべきであることをお勧めしていません。
Kerberos does not currently provide perfect forward secrecy in general. KINK with the KE payload can provide PFS for a service key from a Kerberos key, but the KE is not mandatory because of the computational cost. This is a trade-off and operators can choose the PFS over the cost, and vice versa. KINK itself should be secure from offline analysis from compromised principal passphrases if PFS is used, but from an overall system's standpoint, the existence of other Kerberized services that do not provide PFS makes this a less than optimal situation.
Kerberosは、現在一般的に完全転送秘密を提供していません。 KEペイロードを持つKINKは、KerberosキーからサービスキーのPFSを提供することができますが、KEはため計算コストで必須ではありません。これは、コスト上のPFSを選択し、その逆もできるトレードオフと演算子です。 PFSを使用する場合はKINK自身が危険にさらさ主要なパスフレーズからオフライン解析から安全である必要がありますが、全体的なシステムの観点から、PFSを提供しない他のKerberos対応サービスの存在は、この最適とは言えない状況になります。
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）KINK次ペイロードタイプ（セクション4.2）KINKエラーコード（セクション4.2.8）
Changes and additions to this registry follow the policies described below. Their meanings are described in [BCP26].
このレジストリの変更や追加は、以下の方針に従ってください。その意味では、[BCP26]で説明されています。
o Using the numbers in the "Private Use" range is Private Use.
「私用」の範囲内の数値を使用してoを私用です。
o Assignment from the "RESERVED TO IANA" range needs Standards Action, or non-standards-track RFCs with Expert Review. (Though the full specification may be a public and permanent document of a standards body other than IETF, an RFC referring it is needed.)
「RESERVED IANA TO」の範囲からO割付は標準アクションを必要とする、または専門家レビューと非標準トラックの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ペイロード内のバージョンフィールドを使用してクイックモードの将来のバージョンと同様に解釈の新しいドメインを収容することができます。このメモでは、唯一のサポートクイックモードバージョンは、[IKE]に相当する1.0です。同様に、サポートされている唯一のDOIは、[IPDOI]解釈のIPsecのドメインです。新しいクイックモードのバージョンとの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メッセージを受信するKINK実装は、バージョン1.0に戻って元に戻すことができなければなりません。
The IPsec working group is defining the next-generation IKE protocol [IKEv2], which does not use Quick Mode, but it is similar to the one in IKEv1. The difference between the two is summarized in Appendix A of [IKEv2]. Each of them must be considered in order to use IKEv2 with KINK.
IPsecのワーキンググループは、クイックモードを使用しない次世代IKEプロトコル[IKEv2の]を、定義されているが、それはIKEv1の内の1つに類似しています。両者の違いは、〔のIKEv2]の付録Aにまとめられています。それらのそれぞれは、KINKでの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メッセージヘッダは、解釈の他のドメインは、キーイングのための安全なトランスポートメカニズムとしてKINKを使用できるように「解釈ドメイン（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で定義されていないいくつかの新しいメッセージを、定義解釈のグループドメイン[GDOI]を、定義されました。
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ペイロードはGDOI文書で定義されたペイロードはなくによって使用されるペイロードを含むであろうIKE]クイックモード。 KINK_ISAKMPヘッダ内のバージョン番号がKINKヘッダーでDOIに関連するので、DOI GDOI下maj.minバージョン1.0さDOI IPSEC-DOI下maj.minバージョン1.0と異なっています。
The IPsec working group has defined a number of protocols that provide the ability to create and maintain cryptographically secure SAs at layer three (i.e., the IP layer). This effort has produced two distinct protocols:
IPsecのワーキンググループは、レイヤ3（すなわち、IP層）で暗号的に安全なSAを作成し、維持する能力を提供するプロトコルの数を定義しています。この取り組みは、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
相互認証と交換キーイング材料を行うためのIPsecピアの機構O
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 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.
IPsecのワーキンググループは、IKE（RFC 2409）、ピア・ツー・ピア認証およびキー機構を定義しています。ピア・ツー・ピア・プロトコルの欠点の1つは、各ピアが知っていて、サイトのセキュリティポリシー、実際にはかなり複雑になる可能性が実装しなければならないということです。また、IKEのピア・ツー・ピアの性質は、共有秘密を確立するためのDiffie-Hellmanの（DH）を使用する必要があります。 DHは、残念ながら、計算が非常に高価で、サービス拒否攻撃を受けやすいです。 IKEはまた、ピアのスケーラブルな認証を実現するために、X.509証明書に依存しています。デジタル署名はまた、計算コストが高い、と証明書ベースの信頼モデルは、実際に展開することは困難です。 O（N ^ 2）問題 - - 大規模な展開のために問題があるIKE事前共有鍵を許可ないが、キー配布は、すべてのピア間で必要とされます。
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.
多くは、私たちのワーキンググループチェアデレクアトキンスとジョナサンTrostle含め、KINKの努力に貢献してきました。オリジナルのインスピレーションはサーシャMedvinsky、マイクFROH、そしてマット・ハーとDavidマグリュー含むKerberos対応のIPsecの簡易版を、定義された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、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.カレル、 "インターネットキー交換（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]モーガン、D.、Schertler、M.、シュナイダー、M.、およびJ.ターナー、 "インターネットセキュリティ協会と鍵管理プロトコル（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、 "インターネットSecurity AssociationとKey Managementプロトコル（ISAKMP）識別子"、<http://www.iana.org/assignments/isakmp-registry>。
[KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[KCRYPTO]レイバーン、K.、 "暗号化とケルベロス5チェックサムの仕様"、RFC 3961、2005年2月。
[KERBEROS] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[KERBEROS]ノイマン、C.、ゆう、T.、ハルトマン、S.、およびK.レイバーン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 4120、2005年7月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]リン、J.、 "Kerberosバージョン5 GSS-APIメカニズム"、RFC 1964、1996年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2003年7月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、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]朱、L.とB.桐、「ケルベロスにおける初期認証のための公開鍵暗号」、進歩、2006年2月に作業。
[REQ4KINK] Thomas, M., "Requirements for Kerberized Internet Negotiation of Keys", RFC 3129, June 2001.
[REQ4KINK]トーマス、M.、 "キーのKerberos対応インターネット交渉のための要件"、RFC 3129、2001年6月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート1"、RFC 2743、2000年1月。
Authors' Addresses
著者のアドレス
Shoichi Sakane Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi, Tokyo 180-8750 Japan
しょいち さかね よこがわ えぇｃｔりｃ こｒぽらちおん ２ー９ー３２ なかちょ、 むさしのーし、 ときょ １８０ー８７５０ じゃぱん
EMail: Shouichi.Sakane@jp.yokogawa.com
メールアドレス：Shouichi.Sakane@jp.yokogawa.com
Ken'ichi Kamada Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi, Tokyo 180-8750 Japan
けんいち かまだ よこがわ えぇｃｔりｃ こｒぽらちおん ２ー９ー３２ なかちょ、 むさしのーし、 ときょ １８０ー８７５０ じゃぱん
EMail: Ken-ichi.Kamada@jp.yokogawa.com
メールアドレス：Ken-ichi.Kamada@jp.yokogawa.com
Michael Thomas Cisco Systems 170 West Tasman Drive San Jose, CA 95134
マイケル・トーマスシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134
EMail: mat@cisco.com
メールアドレス：mat@cisco.com
Jan Vilhuber Cisco Systems 170 West Tasman Drive San Jose, CA 95134
ヤンVilhuberシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134
EMail: vilhuber@cisco.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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）によって提供されます。