RFC4430 日本語訳
4430 Kerberized Internet Negotiation of Keys (KINK). S. Sakane, K.Kamada, M. Thomas, J. Vilhuber. March 2006. (Format: TXT=91261 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Sakaneがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4430年のK.Kamadaカテゴリ: 2006年の標準化過程横河電機株式会社のM.トーマスのJ.Vilhuberシスコシステムズの行進
Kerberized Internet Negotiation of Keys (KINK)
キーのインターネット交渉をKerberizedしました。(もつれ)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはキーズ(KINK)プロトコルのKerberizedインターネットNegotiationについて説明します。 KINKは、ケルベロス認証システムを使用することでセキュリティ協会を設立して、維持するために計算上安価で、容易に暗号で管理された低遅延音のプロトコルを定義します。 KINKはインターネット・キー・エクスチェンジ(IKE)のクィックModeペイロードを再利用します。(インターネット・キー・エクスチェンジは、既存のIKE実装のかなりの再利用につながるべきです)。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Protocol Overview ...............................................4
3. Message Flows ...................................................4
3.1. GETTGT Message Flow ........................................5
3.2. CREATE Message Flow ........................................6
3.2.1. CREATE Key Derivation Considerations ................7
3.3. DELETE Message Flow ........................................8
3.4. STATUS Message Flow ........................................9
3.5. Reporting Errors ...........................................9
3.6. Rekeying Security Associations ............................10
3.7. Dead Peer Detection .......................................10
3.7.1. Coping with Dead User-to-User Peers ................12
1. 序論…3 1.1. このドキュメントで中古のコンベンション…3 2. 概要について議定書の中で述べてください…4 3. メッセージは流れます…4 3.1. GETTGTメッセージ流動…5 3.2. メッセージ流動を引き起こしてください…6 3.2.1. 主要な派生問題を作成してください…7 3.3. メッセージ流動を削除してください…8 3.4. ステータスメッセージ流動…9 3.5. 誤りを報告します…9 3.6. セキュリティ協会をRekeyingします…10 3.7. 死んでいる同輩検出…10 3.7.1. ユーザによって死ぬ対処するのはじっと見ます…12
Sakane, et al. Standards Track [Page 1] RFC 4430 KINK March 2006
Sakane、他 標準化過程[1ページ]RFC4430は2006年3月にねじれます。
4. KINK Message Format ............................................13
4.1. KINK Alignment Rules ......................................15
4.2. KINK Payloads .............................................16
4.2.1. KINK_AP_REQ Payload ................................17
4.2.2. KINK_AP_REP Payload ................................18
4.2.3. KINK_KRB_ERROR Payload .............................19
4.2.4. KINK_TGT_REQ Payload ...............................20
4.2.5. KINK_TGT_REP Payload ...............................21
4.2.6. KINK_ISAKMP Payload ................................21
4.2.7. KINK_ENCRYPT Payload ...............................22
4.2.8. KINK_ERROR Payload .................................23
5. Differences from IKE Quick Mode ................................25
5.1. Security Association Payloads .............................26
5.2. Proposal and Transform Payloads ...........................26
5.3. Identification Payloads ...................................26
5.4. Nonce Payloads ............................................26
5.5. Notify Payloads ...........................................27
5.6. Delete Payloads ...........................................28
5.7. KE Payloads ...............................................28
6. Message Construction and Constraints for IPsec DOI .............28
6.1. REPLY Message .............................................28
6.2. ACK Message ...............................................28
6.3. CREATE Message ............................................29
6.4. DELETE Message ............................................30
6.5. STATUS Message ............................................31
6.6. GETTGT Message ............................................32
7. ISAKMP Key Derivation ..........................................32
8. Key Usage Numbers for Kerberos Key Derivation ..................33
9. Transport Considerations .......................................33
10. Security Considerations .......................................34
11. IANA Considerations ...........................................35
12. Forward Compatibility Considerations ..........................35
12.1. New Versions of Quick Mode ...............................36
12.2. New DOI ..................................................36
13. Related Work ..................................................36
14. Acknowledgements ..............................................37
15. References ....................................................37
15.1. Normative References .....................................37
15.2. Informative References ...................................38
4. メッセージ・フォーマットをねじれさせてください…13 4.1. 整列規則をねじれさせてください…15 4.2. 有効搭載量をねじれさせてください…16 4.2.1. _AP_REQ有効搭載量をねじれさせてください…17 4.2.2. _AP_レップ有効搭載量をねじれさせてください…18 4.2.3. _KRB_誤り有効搭載量をねじれさせてください…19 4.2.4. _TGT_REQ有効搭載量をねじれさせてください…20 4.2.5. _TGT_レップ有効搭載量をねじれさせてください…21 4.2.6. _ISAKMP有効搭載量をねじれさせてください…21 4.2.7. もつれ_は有効搭載量を暗号化します…22 4.2.8. _誤り有効搭載量をねじれさせてください…23 5. IKEの迅速なモードからの違い…25 5.1. セキュリティ協会有効搭載量…26 5.2. 提案と変換有効搭載量…26 5.3. 識別有効搭載量…26 5.4. 一回だけの有効搭載量…26 5.5. 有効搭載量に通知してください…27 5.6. 有効搭載量を削除してください…28 5.7. KE有効搭載量…28 6. IPsec DOIのメッセージ工事と規制…28 6.1. 回答メッセージ…28 6.2. ACKメッセージ…28 6.3. メッセージを作成してください…29 6.4. メッセージを削除してください…30 6.5. ステータスメッセージ…31 6.6. GETTGTメッセージ…32 7. ISAKMPの主要な派生…32 8. ケルベロスの主要な派生の主要な用法番号…33 9. 問題を輸送してください…33 10. セキュリティ問題…34 11. IANA問題…35 12. 互換性問題を進めてください…35 12.1. 迅速なモードの新しいバージョン…36 12.2. 新しいDOI…36 13. 仕事を関係づけます…36 14. 承認…37 15. 参照…37 15.1. 標準の参照…37 15.2. 有益な参照…38
Sakane, et al. Standards Track [Page 2] RFC 4430 KINK March 2006
Sakane、他 標準化過程[2ページ]RFC4430は2006年3月にねじれます。
1. Introduction
1. 序論
KINK is designed to provide a secure, scalable mechanism for establishing keys between communicating entities within a centrally managed environment in which it is important to maintain consistent security policy. The security goals of KINK are to provide privacy, authentication, and replay protection of key management messages and to avoid denial of service vulnerabilities whenever possible. The performance goals of the protocol are to have a low computational cost, low latency, and a small footprint. It is also to avoid or minimize the use of public key operations. In particular, the protocol provides the capability to establish IPsec security associations (SAs) in two messages with minimal computational effort. These requirements are described in RFC 3129 [REQ4KINK].
KINKは、一貫した安全保障政策を維持するのが重要である中心で管理された環境以内で実体を伝えるとき安全で、スケーラブルなメカニズムをキーを設立するのに提供するように設計されています。 KINKのセキュリティ目標は、可能であるときはいつも、かぎ管理メッセージのプライバシー、認証、および反復操作による保護を提供して、サービスの弱点の否定を避けることです。 プロトコルの性能目標は低いコンピュータの費用、低遅延、および小さい足跡を持つことです。 また、それは、公開鍵操作の使用を避けることになっているか、または最小にすることになっています。 特に、プロトコルは最小量の計算量でIPsecセキュリティ協会(SAs)を2つのメッセージに設立する能力を提供します。 これらの要件はRFC3129[REQ4KINK]で説明されます。
Kerberos [KERBEROS] provides an efficient authentication mechanism for clients and servers using a trusted third-party model. Kerberos also provides a mechanism for cross-realm authentication natively. A client obtains a ticket from an online authentication server, the Key Distribution Center (KDC). The ticket is then used to construct a credential for authenticating the client to the server. As a result of this authentication operation, the server will also share a secret key with the client. KINK uses this property as the basis of distributing keys for IPsec.
ケルベロス[ケルベロス]は、信じられた第三者モデルを使用することで効率的な認証機構をクライアントとサーバに提供します。 また、ケルベロスはネイティブに交差している分野認証にメカニズムを提供します。 クライアントはオンライン認証サーバ、Key Distributionセンター(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]でInitial AuthenticationにPublic Key Cryptographyを使用することで対称鍵か非対称のキーのどちらかを使用することで実行されるかもしれません。 しかしながら、クライアントとサーバの間の認証された交換と同様にチケットを求めるその後の要求はいつも左右対称の暗号を利用します。 したがって、(もしあれば)の公開鍵操作は、制限されていて、初期の認証操作でKDCに取得された資格証明書の生涯清算されます。 例えば、クライアントは、他の多くのサーバがKDCの分野にある状態で効率的に複数のSAsを証明するのにKDCとのただ一つの公開鍵交換を使用するかもしれません。 また、対称鍵が使用されているとき、ケルベロスはダイレクトピアツーピアの合わせるよりよく比例します。 理由はキーがKDCに保存されるので主要なキーの数が「n」がクライアントの数であり、「m」がサーバの数であるO(n*m)よりむしろO(n+m)であることです。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Sakane, et al. Standards Track [Page 3] RFC 4430 KINK March 2006
Sakane、他 標準化過程[3ページ]RFC4430は2006年3月にねじれます。
It is assumed that the readers are familiar with the terms and concepts described in Kerberos Version 5 [KERBEROS], IPsec [IPSEC], and IKE [IKE].
読者がケルベロスバージョン5[ケルベロス]、IPsec[IPSEC]、およびIKE[IKE]で説明された用語と概念に詳しいと思われます。
2. Protocol Overview
2. プロトコル概要
KINK is a command/response protocol that can create, delete, and maintain IPsec SAs. Each command or response contains a common header along with a set of type-length-value payloads. The type of a command or a response constrains the payloads sent in the messages of the exchange. KINK itself is a stateless protocol in that each command or response does not require storage of hard state for KINK. This is in contrast to IKE, which uses Main Mode to first establish an Internet Security Association and Key Management Protocol (ISAKMP) SA followed by subsequent Quick Mode exchanges.
KINKはIPsec SAsを作成して、削除して、維持できるコマンド/応答プロトコルです。 各コマンドか応答が1セットのタイプ長さの価値のペイロードに伴う一般的なヘッダーを含んでいます。 コマンドか応答のタイプは交換に関するメッセージで送られたペイロードを抑制します。 各コマンドか応答がKINKのために固い状態のストレージを必要としないので、KINK自身は状態がないプロトコルです。 これはIKEと対照的になっています。IKEは、最初にその後のクィックMode交換があとに続いたインターネットSecurity AssociationとKey Managementプロトコル(ISAKMP)SAを証明するのにMain Modeを使用します。
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は、互いの認証と反復操作による保護を提供するのにケルベロスメカニズムを使用します。 SAsを設立するために、KINKはケルベロスAP-REQペイロードに続くペイロードに秘密性を供給します。 KINKのデザインは、どんな公開鍵操作の使用とどんな状態のインストールの前にも認証された交換を必要とすることによって、サービス不能攻撃を緩和します。 また、KINKはサーバとKDCの間で共有されたキーがないときケルベロスUserからユーザへのメカニズムを使用する手段を提供します。 通常、これは他、IPsec同輩が初期の認証にPKINITを使用しているそうです。
KINK directly reuses Quick Mode payloads defined in section 5.5 of [IKE], with some minor changes and omissions. In most cases, KINK exchanges are a single command and its response. An optional third message is required when creating SAs, only if the responder rejects the first proposal from the initiator or wants to contribute the keying materials. KINK also provides rekeying and dead peer detection.
KINKは直接いくつかのマイナーチェンジと省略で[IKE]のセクション5.5で定義されたクィックModeペイロードを再利用します。 多くの場合、KINK交換は、ただ一つのコマンドとその応答です。 SAsを作成するとき、3番目の任意のメッセージが必要です、応答者が創始者から最初の提案を拒絶したいか、または合わせることの材料を寄付したい場合にだけ。 また、KINKは「再-合わせ」るのと死んでいる同輩検出を提供します。
3. Message Flows
3. メッセージ流れ
All KINK message flows follow the same pattern between the two peers: a command, a response, and an optional acknowledgement in a CREATE flow. A command is a GETTGT, CREATE, DELETE, or STATUS message; a response is a REPLY message; and an acknowledgement is an ACK message.
すべてのKINKメッセージ流れが2人の同輩の間の同じパターンに続いて起こります: CREATEでのコマンド、応答、および任意の承認は流れます。 コマンドは、GETTGT、CREATE、DELETE、またはSTATUSメッセージです。 応答はREPLYメッセージです。 そして、承認は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は認証機構としてケルベロスを使用します。 したがって、KINKホストは、実際のキー交渉の前にそれぞれの同輩のサービスチケットを手に入れる必要があります。 これは基本的に純粋なケルベロス交換です、そして、ここの実際のKDCトラフィックは説明に役立った目的だけのためのものです。 実際には、元本がいつ様々なチケットを得るかは、対象です。
Sakane, et al. Standards Track [Page 4] RFC 4430 KINK March 2006
Sakane、他 標準化過程[4ページ]RFC4430は2006年3月にねじれます。
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.
ケルベロスと地方の方針の考慮。 Userがユーザー認証に必要であるときに、例外として、KINK(セクション3.1で、説明される)のGETTGTメッセージ流動は使用されています。 この流れでは、私たちは、AとBの両方には彼らのKDCsからのチケットを与えるチケット(TGTs)があると思います。
After a service ticket is obtained, KINK uses the CREATE message flow (section 3.2), DELETE message flow (section 3.3), and STATUS message flow (section 3.4) to manage SAs. In these flows, we assume that A has a service ticket for B.
サービスチケットを得た後に、KINKは、SAsを管理するのに、CREATEメッセージ流動(セクション3.2)、DELETEメッセージ流動(セクション3.3)、およびSTATUSメッセージ流動(セクション3.4)を使用します。 これらの流れでは、私たちは、AにはBのサービスチケットがあると思います。
3.1. GETTGT Message Flow
3.1. GETTGTメッセージ流動
This flow is used to retrieve a TGT from the remote peer in User-to- User authentication mode.
この流れは、リモート同輩からUserからユーザー認証へのモードで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:
創始者が、応答者の通常(ユーザへの非ユーザの)のサービスチケットを手に入れることができないと決心しているなら、それはUserからユーザー認証を試すことができます。 この場合、最初に、Userからユーザへのサービスチケットを手に入れるために応答者からTGTをとって来ます:
A B KDC
------ ------ ---
1 GETTGT+KINK_TGT_REQ------>
B KDC------ ------ --- 1 GETTGT+もつれ_TGT_REQ------>。
2 <-------REPLY+KINK_TGT_REP
2 <。-------回答+もつれ_TGT_レップ
3 TGS-REQ+TGT(B)------------------------------------>
3 TGS-REQ+TGT(B)------------------------------------>。
4 <-------------------------------------------TGS-REP
4 <。-------------------------------------------TGS-レップ
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.
創始者は、Userからユーザへの道に行くために引き金として以下のイベントをサポートするかもしれません。 以下で説明された2つの誤りが認証されないで、どうそれらに影響するかが方針によることに注意してください。
o The local policy says that the responder requires a User-
to-User authentication.
o ローカルの方針は、応答者がユーザー認証であることでUserを必要とすると言います。
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_は_誤りがKDCから返されるUSE_USER2USERがそうしなければなりません。
Sakane, et al. Standards Track [Page 5] RFC 4430 KINK March 2006
Sakane、他 標準化過程[5ページ]RFC4430は2006年3月にねじれます。
3.2. CREATE Message Flow
3.2. メッセージ流動を引き起こしてください。
This flow creates SAs. The CREATE command takes an "optimistic" approach, where SAs are initially created on the expectation that the responder will choose the initial proposed payload. The optimistic proposal is placed in the first transform payload(s) of the first proposal. The initiator MUST check to see if the optimistic proposal was selected by comparing all transforms and attributes, which MUST be identical to those in the initiator's optimistic proposal with the exceptions of LIFE_KILOBYTES and LIFE_SECONDS. Each of these attributes MAY be set to a lower value by the responder and still expect optimistic keying, but MUST NOT be set to a higher value that MUST generate a NO-PROPOSAL-CHOSEN error. The initiator MUST use the shorter lifetime.
この流れはSAsを作成します。 CREATEコマンドは「楽観的な」アプローチを取ります、SAsが応答者が初期の提案されたペイロードを選ぶ期待のときに初めは作成されるところで。 楽観的な提案は最初の提案の最初の変換ペイロードに置かれます。 創始者は、楽観的な提案がすべての変換と属性を比較することによって選択されたかどうか確認するためにチェックしなければなりません。属性は創始者の楽観的な提案がLIFE_KILOBYTESとLIFE_SECONDSの例外でそれらと同じであるに違いありません。 それぞれのこれらの属性を、応答者が下側の値に設定するかもしれなくて、まだ楽観的な合わせることを予想していますが、PROPOSAL-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コマンドが既存のSecurity Parameter Index(SPI)を含んでいると、応答者はそれを拒絶しなければなりません、そして、SHOULDは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有効搭載量TYPEのISAKMP通知でそれを拒絶しなければなりません。 創始者がこの誤りを受けるとき、方針がそれを許容するなら、それはKEペイロード(別のトランザクションとしての)なしで再試行されるかもしれません。
A B KDC
------ ------ ---
B KDC------ ------ ---
A creates an optimistic inbound SA (B->A) unless using a KE.
KEを使用しない場合、Aは楽観的な本国行きのSA(B>A)を作成します。
1 CREATE+ISAKMP------------>
1 + ISAKMPを作成してください。------------>。
B creates an inbound SA (A->B).
B creates an outbound SA (B->A) if optimistic and not using a KE.
Bは本国行きのSA(1>のB)を作成します。 楽観的であるならBは外国行きのSA(B>A)を作成しますが、KEを使用するのが作成しません。
2 <-------------REPLY+ISAKMP
2 <。-------------回答+ISAKMP
A creates an outbound SA (A->B).
A replaces an inbound SA (B->A) if non-optimistic.
A creates an inbound SA (B->A) if using a KE.
Aは外国行きのSA(A>B)を作成します。 非楽観的であるなら、Aは本国行きのSA(B>A)を取り替えます。 KEを使用するなら、Aは本国行きのSA(B>A)を作成します。
3 [ ACK---------------------> ]
3 [ACK、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>]
[ B creates an outbound SA (B->A). ]
[Bは外国行きのSA(B>A)を作成します。]
Figure 2: CREATE Message Flow
図2: メッセージ流動を引き起こしてください。
Sakane, et al. Standards Track [Page 6] RFC 4430 KINK March 2006
Sakane、他 標準化過程[6ページ]RFC4430は2006年3月にねじれます。
Creating SAs has two modes: 2-way handshake and 3-way handshake. The initiator usually begins a negotiation expecting a 2-way handshake. When the optimistic proposal is not chosen by the responder, the negotiation is switched to a 3-way handshake. When and only when the initiator uses a KE payload, 3-way handshake is expected from the beginning.
SAsを作成するのにおいて、2つのモードがあります: 2ウェイ握手と3ウェイ握手。 通常、創始者は、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は、SAデータベースでISAKMP SA提案における楽観的な提案を使用することで本国行きのSA(B>A)を作成します。 それはその時、B.2)からどんなメッセージも受け取る準備ができています。 そして、AはB.3)にCREATEメッセージを送ります。 BがAの楽観的な提案に同意するなら、Bはデータベースで本国行きのSA(1>のB)と外国行きのSA(B>A)を作成します。 Bが最初の提案を選びたくはありませんし、またNonceペイロードを加えたいなら、以下で説明された3ウェイ握手のステップ3に切り替わってください。 4) そして、BはNonceペイロードなしでACKを要求することなしでREPLYをAに送ります。 5) REPLYを受け取り次第、Aは外国行きのSA(1>の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) どんなSAも作成しないで、ホストAはCREATEメッセージをBに送ります。 2) 方針によると、Bは1つの提案を選びます。 3) Bは、本国行きのSA(1>のB)を作成して、REPLYでの実際の選択を送ります。 それ、SHOULDは、任意のNonceペイロード(メッセージカウントと一般にエントロピーが出典を明示する増加を増強しないのに従って)を送って、REPLYが承認されるよう要求しなければなりません。 4) REPLYを受け取り次第、Aは本国行きのSA(B>A)を作成します。 (または、2ウェイから切り換えられるなら、必要に応じてそれを変更します), そして、外国行きのSA(1>のB)。 5) 現在はACKメッセージを送ります。 6) ACKを受け取り次第、Bは最終的な外国行きのSA(B>A)をインストールします。
If B does not choose the first proposal, adds a nonce, or accepts the KE exchange, then it MUST request an ACK (i.e., set the ACKREQ bit) so that it can install the final outbound SA. The initiator MUST always generate an ACK if the ACKREQ bit is set in the KINK header, even if it believes that the responder was in error.
Bが最初の提案を選ばないか、一回だけを加えるか、またはKE交換を受け入れるなら、それは、最終的な外国行きのSAをインストールできるように、ACK(すなわち、ACKREQビットを設定する)を要求しなければなりません。 ACKREQビットがKINKヘッダーに設定されるなら、創始者はいつもACKを生成しなければなりません、応答者が間違っていたのが信じても。
3.2.1. CREATE Key Derivation Considerations
3.2.1. 主要な派生問題を作成してください。
The CREATE command's optimistic approach allows an SA to be created in two messages rather than three. The implication of a two-message exchange is that B will not contribute to the key since A must set up
CREATEコマンドの楽観的なアプローチは、SAが3よりむしろ2つのメッセージで作成されるのを許容します。 2交換処理の含意はAにセットアップされなければならないのでBがキーに貢献しないということです。
Sakane, et al. Standards Track [Page 7] RFC 4430 KINK March 2006
Sakane、他 標準化過程[7ページ]RFC4430は2006年3月にねじれます。
the inbound SA before it receives any additional keying material from B. This may be suspect under normal circumstances; however, KINK takes advantage of the fact that the KDC provides a reliable source of randomness which is used in key derivation. In many cases, this will provide an adequate session key so that B will not require an acknowledgement. Since B is always at liberty to contribute to the keying material, this is strictly a trade-off between the key strength versus the number of messages, which KINK implementations may decide as a matter of policy.
B.Thisからどんな追加合わせることの材料も受ける前に本国行きのSAは通常の状況下で疑わしいかもしれません。 しかしながら、KINKはKDCが主要な派生に使用される偶発性の信頼すべき筋を提供するという事実を利用します。 多くの場合、これは、Bが承認を必要としないように、適切なセッションキーを提供するでしょう。 これによる厳密に、メッセージの数に従った主要な強さの間のトレードオフ、どのKINK実装が決めるかもしれないかというBが合わせることの材料に貢献するのにおいていつも自由であるのでことです。政策の問題として。
3.3. DELETE Message Flow
3.3. メッセージ流動を削除してください。
The DELETE command deletes existing SAs. The domain of interpretation (DOI)-specific payloads describe the actual SA to be deleted. For the IPsec DOI, those payloads will include an ISAKMP payload containing the list of the SPIs to be deleted.
DELETEコマンドは既存のSAsを削除します。 削除されて、特定のペイロードが実際のSAについて説明する解釈(DOI)のドメイン。 IPsec DOIに関しては、それらのペイロードは、削除されるためにSPIsのリストを含むISAKMPペイロードを含むでしょう。
A B KDC
------ ------ ---
B KDC------ ------ ---
A deletes outbound SA to B.
Aは外国行きのSAをBに削除します。
1 DELETE+ISAKMP------------>
1 + ISAKMPを削除してください。------------>。
B deletes inbound and outbound SA to A.
Bは本国行きの、そして、外国行きのSAをAに削除します。
2 <-------------REPLY+ISAKMP
2 <。-------------回答+ISAKMP
A deletes inbound SA to B.
Aは本国行きのSAをBに削除します。
Figure 3: DELETE Message Flow
図3: メッセージ流動を削除してください。
The DELETE command takes a "pessimistic" approach, which does not delete inbound SAs until it receives acknowledgement that the other host has received the DELETE. The exception to the pessimistic approach is if the initiator wants to immediately cease all activity on an inbound SA. In this case, it MAY delete the inbound SA as well in step 1, above.
DELETEコマンドは「悲観的な」アプローチを取ります。(もう片方のホストがDELETEを受け取ったという承認を受けるまで、それは、本国行きのSAsを削除しません)。 悲観的なアプローチへの例外は創始者がすぐにすべての活動をやめたがっているかどうかという本国行きのSAに関することです。 この場合、それはまた、上のステップ1における本国行きのSAを削除するかもしれません。
The ISAKMP payload contains ISAKMP Delete payload(s) that indicate the inbound SA(s) for the initiator of this flow. KINK does not allow half-open SAs; thus, when the responder receives a DELETE command, it MUST delete SAs of both directions, and MUST reply with ISAKMP Delete payload(s) that indicate the inbound SA(s) for the responder of this flow. If the responder cannot find an appropriate SPI to be deleted, it MUST return an ISAKMP notification with INVALID_SPI, which also serves to inform the initiator that it can delete the inbound SA.
ISAKMPペイロードはこの流れの創始者のために本国行きのSA(s)を示すISAKMP Deleteペイロードを含んでいます。 KINKは半開きなSAsを許容しません。 したがって、応答者がDELETEコマンドを受け取るとき、それは、両方の方向のSAsを削除しなければならなくて、この流れの応答者のために本国行きのSA(s)を示すISAKMP Deleteペイロードで返答しなければなりません。 応答者が削除されるために適切なSPIを見つけることができないなら、それはINVALID_SPIとのISAKMP通知を返さなければなりません。(また、SPIは本国行きのSAを削除できることを創始者に知らせるのに役立ちます)。
Sakane, et al. Standards Track [Page 8] RFC 4430 KINK March 2006
Sakane、他 標準化過程[8ページ]RFC4430は2006年3月にねじれます。
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を削除することを勧めます。 SHOULDがSHOULDがある優雅タイマを実装するKINK実装は平均した往復の時間の少なくとも2回の期間、または、構成可能な値にセットしました。 KINK実装は、SAを無様に削除するために適切な時期でゼロに据置期間を設定するのを選ぶかもしれません。 ここで説明された振舞いはTCP[RFC793]旗のFINとRSTの動きから参照されます。
3.4. STATUS Message Flow
3.4. ステータスメッセージ流動
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 Notificationペイロードの形にあります。 また、死んでいる同輩検出の手段がセクション3.7で説明したようにSTATUSコマンドは使用されます。
A B KDC
------ ------ ---
B KDC------ ------ ---
1 STATUS[+ISAKMP]---------->
1 状態[+ ISAKMP]---------->。
2 <-----------REPLY[+ISAKMP]
2 <。-----------返信[+ ISAKMP]
Figure 4: STATUS Message Flow
図4: ステータスメッセージ流動
3.5. Reporting Errors
3.5. 誤りを報告します。
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.
応答者が容認されたコマンドにおける誤りを検出するとき、それは、REPLYメッセージにおける誤りを示すためにDOI特有のペイロードを送ることができます。 誤りを示すことができる3つのタイプのペイロードがあります: ケルベロス誤りのためのKINK_KRB_ERRORペイロード、KINK誤りのためのKINK_ERRORペイロード、およびISAKMP誤りのためのKINK_ISAKMPペイロード。 説明されたコネセクション4.2.3、4.2は、.8と、4.2です。詳細である、それぞれ.6。
If the initiator detects an error in a received reply, there is no means to report it back to the responder. The initiator SHOULD log the event and MAY take a remedial action by reinitiating the initial command.
創始者が容認された回答における誤りを検出するなら、応答者にそれの報告を持ちかえる手段が全くありません。 創始者SHOULDはイベントを登録します、そして、初期のコマンドを再開始することによって、改善措置を取るかもしれません。
If the server clock and the client clock are off by more than the policy-determined clock skew limit (usually 5 minutes), the server MUST return a KRB_AP_ERR_SKEW. The optional client's time in the KRB-ERROR SHOULD be filled out. If the server protects the error by adding the Cksum field and returning the correct client's time, the
サーバ時計とクライアント時計が方針で決定している時計斜行限界(通常5分)以上でオフであるなら、サーバはKRB_AP_ERR_SKEWを返さなければなりません。 外にいっぱいにされて、任意のクライアントのものはKRB-ERROR SHOULDで調節します。 サーバがCksum分野を加えて、クライアントの時間を正しさに返すことによって誤りを保護するなら
Sakane, et al. Standards Track [Page 9] RFC 4430 KINK March 2006
Sakane、他 標準化過程[9ページ]RFC4430は2006年3月にねじれます。
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.
クライアントSHOULDはクライアントに基づく2個の時計とKRB-ERRORメッセージに含まれたサーバ時間の間で違いを計算します(秒に)。 クライアントSHOULDは、その後のメッセージで時計を調整するのにこの時計差を保存して、それを使用します。 誤りが保護されないなら、クライアントはその後のメッセージを調整するのに違いを使用してはいけません、攻撃者がそうするのに、反射攻撃を取り付けるのに使用できる固有識別文字を構成できるでしょう、したがって。
3.6. Rekeying Security Associations
3.6. セキュリティ協会をRekeyingします。
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の創始者は2つの理由でSAを「再-合わせ」るのに責任があると予想します。 最初の理由は創始者と応答者による衝突の結果としてのSAsの不必要な複製がともに既存のSAを取り替えようとするのを防ぐことです。 2番目の理由はケルベロス交換(クライアントがチケットを手に入れて、維持すると予想するもの)のクライアント/サーバ本質のためです。 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.
どんなrekeying SAsに、特別な意味論もKINKにありません。 それはDELETE流動で古いSAを削除するのがいうことになった既存のSAをrekeyする創始者必須のCREATEのa新しいSAであるかそれをさせるのが、タイムアウトです。 同じ流れセレクタが異なったSAsで利用可能であるときに、KINK実装SHOULDはごく最近作成されたSAを選びます。 KINKが信頼できるaにメカニズムを削除させることによって[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.
通常、既存のSAsを「再-合わせ」るKINK実現はSA終了の前にrekeyにSAを試みるでしょう。終了は時間/bytecountか一連番号カウンタのオーバーフローに困難な生涯を含むかもしれません。 この時間「柔らかい生涯」と、私たちは呼びます。 同様の実現との同期を避けるために柔らかい生涯をランダマイズしなければなりません。 時間内にの生涯の場合では、柔らかい生涯を決定する1つの合理的なアプローチが、T-rekeyとT-retransの間で無作為の時間を選んで、困難な生涯からそれを引き算しています。 ここで、T-rekeyは手頃な最大の「再-合わせ」るマージンです、そして、T-retransは完全な「再-トランスミッション」サイクルを通るにはかかる時間です。 少なくとも二度T-rekey SHOULDはそうです。T-retransと同じくらい高いです。
3.7. Dead Peer Detection
3.7. 死んでいる同輩検出
In order to determine that a KINK peer has lost its security database information, KINK peers MUST record the current epoch for which they have valid SA information for a peer and reflect that epoch in each AP-REQ and AP-REP message. When a KINK peer creates state for a given SA, it MUST also record the principal's epoch. If it discovers
KINK同輩がセキュリティデータベース情報を失ったことを決定するために、KINK同輩は、同輩のために、彼らが有効なSA情報を持っている現在の時代を記録して、その時代にそれぞれのAP-REQとAP-REPメッセージで反射しなければなりません。 また、KINK同輩が与えられたSAのために状態を創設するとき、それは校長の時代を記録しなければなりません。 それは発見します。
Sakane, et al. Standards Track [Page 10] RFC 4430 KINK March 2006
Sakane、他 標準化過程[10ページ]RFC4430は2006年3月にねじれます。
on a subsequent message that the principal's epoch has changed, it MUST consider all SAs created by that principal as invalid, and take some action such as tearing those SAs down.
校長の時代が変化したというその後のメッセージでは、それは、その校長によって作成されたすべてのSAsが無効であるとみなして、それらのSAsを取りこわすことなどの何らかの行動を取らなければなりません。
While a KINK peer SHOULD use feedback from routing (in the form of ICMP messages) as a trigger to check whether or not the peer is still alive, a KINK peer MUST NOT conclude the peer is dead simply based on unprotected routing information (said ICMP messages).
SHOULDが同輩はまだ生きています、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同輩にとって、利用可能などんな情報にも基礎づけます)容疑があれば、KINK STATUSがSHOULDを通信させる、同輩からの承認。 何も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メッセージには、二つの効果があります。 まず最初に、それは同輩から暗号で安全にして(再生で保護される)の応答を聞き出します。(その同輩は、同輩が届くか、または生きているかどうか私たちに言います)。 2番目に、それが同輩の時代番号を運ぶので、私たちは、同輩がすべての状態をリブートして、失ったかどうかを知っています。 これはKINKプロトコルに重要です: IKEでは、同輩がリブートするなら、私たちはすべての暗号の文脈を失います、そして、キーを再交渉しないで、暗号で、安全なコミュニケーションは可能です。 KINKでは、ケルベロスチケットのため、私たちはしっかりと同輩とコミュニケートできます、同輩がリブートしたとしても、使用される共有された暗号化キーがケルベロスチケットの中に運ばれるとき。 したがって、アクティブな暗号のコミュニケーションは同輩がすべての状態をリブートして、失うというわけではなかったという指示ではありません、そして、時代が必要です。
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.
PeerがSTATUSと同輩BがREPLYを送るAであると仮定してください(セクション3.4を見てください)。 同輩Bは、送付者が生きていると仮定するかもしれません、そして、STATUSメッセージの新紀元は同輩Aが状態を失ったかどうかを示すでしょう。 同輩Bはセクション3.4で説明されるようにREPLYメッセージがあるSTATUSメッセージを承認しなければなりません。
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メッセージは、同輩が生きているのを同輩Aに示すでしょう、そして、REPLYの時代は同輩Bが状態を失ったかどうかを示すでしょう。 同輩Aが同輩Bから適当なタイムアウトでREPLYメッセージを受け取らないなら、同輩Aは別のSTATUSメッセージを送るかもしれません。 同輩Bが死んでいると積極的に宣言する方法を決めるのは、同輩A次第です。 攻撃性のレベルは多くのSAsと共にノードによって送られたメッセージの数に従った急速なフェイルオーバーなどの多くの要素に依存するかもしれません。
Sakane, et al. Standards Track [Page 11] RFC 4430 KINK March 2006
Sakane、他 標準化過程[11ページ]RFC4430は2006年3月にねじれます。
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.PeerからのSTATUSメッセージの不足に関する少しの推論もBにしてはいけないというメモは生きることのAのしるしとして同輩AからのSTATUSメッセージを使用するかもしれませんが、同輩Bはいつでも、別のSTATUSメッセージを予想してはいけません(すなわち、死んでいる同輩検出は周期的なkeepalivesではありません)。
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 SAsの上のどちらの方向にも送られなかったところにSTATUSメッセージを送ると決めるかもしれません。 交通がいったんあると、同輩Aは、交通がブラックホールに入るかどうかを知りたくて、STATUSメッセージを送るかもしれません。 あるいはまた、同輩Aは、同輩との交通の不足を検出するのに使用されていないタイマを使用して、同輩が交通が最終的に送られる必要がある時の間まだ生きているのを確実にする静かなフェーズにおけるメッセージをSTATUSに送るかもしれません。
3.7.1. Coping with Dead User-to-User Peers
3.7.1. ユーザからユーザへの死んでいる同輩に対処します。
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.
創始者がUserからユーザへのチケットを使用して、応答者が前のTGTをなくしたとき、普通の死んでいる同輩検出(DPD)メカニズムは動作しません、応答者が新しいTGTと共にチケットを解読することができないので。 この場合、以下の行動を取ります。
o When the responder receives a KINK command with a User-to-User
ticket that cannot be decrypted with its TGT, it returns a
REPLY with a KINK_TGT_REP payload containing the TGT.
o 応答者がUserからユーザへのTGTと共に解読することができないチケットでKINKコマンドを受け取るとき、それはKINK_TGT_REPペイロードがTGTを含んでいるREPLYを返します。
o When the initiator receives a KINK_TGT_REP, it retrieves a new
service ticket with the TGT and retries the command.
o 創始者がKINK_TGT_REPを受け取るとき、それは、TGTと共に新しいサービスチケットを検索して、コマンドを再試行します。
This does not directly define a method to detect a dead User-to-User peer, but to recover from the situation that the responder does not have an appropriate TGT to decrypt a service ticket sent from the initiator. After recovery, they can exchange their epochs, and usual DPD mechanism will detect a dead peer if it really has been dead.
これは直接Userからユーザへの死んでいる同輩を検出する方法を定義しませんが、応答者が持っていない状況から回復するために、サービスチケットを解読するのが適切であるTGTは創始者から発信しました。 回復の後に、彼らは自分達の時代を交換できます、そして、それが本当に死んでいるなら、普通のDPDメカニズムは死んでいる同輩を検出するでしょう。
The initiator MUST NOT think the peer has been dead on the receipt of a KINK_TGT_REP because of two reasons. One is that the message is not authenticated, and the other is that losing a TGT does not necessarily mean losing the SA database information. The initiator SHOULD NOT forget the previous service ticket until the new one is successfully obtained in order to reduce the cost when a forged KINK_TGT_REP is received.
創始者は、同輩が2つの理由でKINK_TGT_REPの領収書で死んでいると考えてはいけません。 1つはメッセージが認証されないで、もう片方がTGTをなくすのが、必ずSAデータベース情報を失うことを意味するというわけではないということであるということです。 創始者SHOULD NOTは偽造_KINK_TGT REPが受け取られているとき、生産費を切り下げるために首尾よく新しい方を得るまで前のサービスチケットを忘れます。
Sakane, et al. Standards Track [Page 12] RFC 4430 KINK March 2006
Sakane、他 標準化過程[12ページ]RFC4430は2006年3月にねじれます。
4. KINK Message Format
4. もつれメッセージ・フォーマット
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のすべての値がネットワークバイトオーダーでフォーマットされる、(最も重要なバイト、1番目) パケットを送るときには(0)のゼロを合わせるようにRESERVED分野を設定しなければなりません。 受信機はこれらの分野を無視しなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | MjVer |RESRVED| Length |
+---------------+---------------+---------------+---------------+
| Domain of Interpretation (DOI) |
+-------------------------------+-------------------------------+
| Transaction ID (XID) |
+---------------+-+-------------+-------------------------------+
| NextPayload |A| RESERVED2 | CksumLen |
+---------------+-+-------------+-------------------------------+
| |
~ A series of payloads ~
| |
+-------------------------------+-------------------------------+
| |
~ Cksum (variable) ~
| |
+-------------------------------+-------------------------------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| MjVer|RESRVED| 長さ| +---------------+---------------+---------------+---------------+ | 解釈(DOI)のドメイン| +-------------------------------+-------------------------------+ | 取引ID(XID)| +---------------+-+-------------+-------------------------------+ | NextPayload|A| RESERVED2| CksumLen| +---------------+-+-------------+-------------------------------+ | | ~ 一連のペイロード~| | +-------------------------------+-------------------------------+ | | ~ Cksum(可変)~| | +-------------------------------+-------------------------------+
Figure 5: Format of a KINK Message
図5: もつれメッセージの形式
Fields:
分野:
o Type (1 octet) -- The type of this message.
o (1つの八重奏)をタイプしてください--このメッセージのタイプ。
Type Value
----- -----
RESERVED 0
CREATE 1
DELETE 2
REPLY 3
GETTGT 4
ACK 5
STATUS 6
RESERVED TO IANA 7 - 127
Private Use 128 - 255
値をタイプしてください。----- ----- 予約されて、0は1を作成します。IANA7--127私用128に予約された2回答3GETTGT4ACK5状態6を削除してください--、255
o MjVer (4 bits) -- Major protocol version number. This MUST be
set to 1.
o MjVer(4ビット)--主要なプロトコルバージョン番号。 1にこれを設定しなければなりません。
Sakane, et al. Standards Track [Page 13] RFC 4430 KINK March 2006
Sakane、他 標準化過程[13ページ]RFC4430は2006年3月にねじれます。
o RESRVED (4 bits) -- Reserved and MUST be zero when sent, MUST
be ignored when received.
o RESRVED(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で不要なデータがメッセージの後にあるのが禁じられませんが、Length分野はメッセージの実際の長さを表さなければなりません。
o DOI (4 octets) -- The domain of interpretation. All DOIs must
be registered with the IANA in the ISAKMP Domain of
Interpretation section of the isakmp-registry [ISAKMP-REG].
The IANA Assigned Number for the Internet IP Security DOI
[IPDOI] is one (1). This field defines the context of all
sub-payloads in this message. If sub-payloads have a DOI
field (e.g., Security Association Payload), then the DOI in
that sub-payload MUST be checked against the DOI in this
header, and the values MUST be the same.
o DOI(4つの八重奏)--解釈のドメイン。 isakmp-登録のInterpretation部のISAKMP DomainのIANAにすべてのDOIsを登録しなければなりません[ISAKMP-REG]。 インターネットIP Security土井[IPDOI]へのIANA Assigned Numberは1つ(1)です。 この分野はこのメッセージのすべてのサブペイロードの文脈を定義します。 サブペイロードにDOI分野(例えば、Security Association有効搭載量)があるなら、このヘッダーで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は、複数の傑出している要求を応答者に区別するのに創始者によって使用されます。 それは、ケルベロスでその機能性を提供するので、反復操作による保護に使用されません。 XIDの値は、創始者によって選ばれていて、すべての傑出している取引にユニークであるに違いありません。 XIDsは、単調なカウンタか乱数発生器を使用することによって、組み立てられるかもしれません。
o NextPayload (1 octet) -- Indicates the type of the first
payload after the message header.
o NextPayload(1つの八重奏)--メッセージヘッダーの後に最初のペイロードのタイプを示します。
o A, or ACKREQ (1 bit) -- ACK Request. Set to one if the
responder requires an explicit acknowledgement that a REPLY
was received. An initiator MUST NOT set this flag, nor should
a responder except for a REPLY to a CREATE when the optimistic
proposal is chosen.
o ACKREQ(1ビット)--ACK Request。 応答者がREPLYを受け取ったという明白な承認を必要とするなら、1つにセットしてください。 創始者はこの旗を設定してはいけなくて、楽観的な提案が選ばれているCREATEへのREPLY以外の応答者もそうするべきではありません。
o RESERVED2 (7 bits) -- Reserved and MUST be zero on send, MUST
be ignored by a receiver.
o RESERVED2(7ビット)--予約されて、ゼロがオンであったなら予約されなければならないのは発信して、受信機で無視しなければなりません。
o CksumLen (2 octets) -- CksumLen is the length in octets of the
cryptographic checksum of the message. A CksumLen of zero
implies that the message is unauthenticated.
o CksumLen(2つの八重奏)--CksumLenはメッセージの暗号のチェックサムの八重奏で長さです。 ゼロのCksumLenは、メッセージが非認証されるのを含意します。
Sakane, et al. Standards Track [Page 14] RFC 4430 KINK March 2006
Sakane、他 標準化過程[14ページ]RFC4430は2006年3月にねじれます。
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分野はゼロに設定されます。 この分野の内容は5が_mic機能[KCRYPTO]を得るケルベロスの出力です。 _micを手に入れてください。使用される機能はチェックサムタイプ(ケルベロスチケットの中に主要なケルベロスセッションのためのetypeの「必要なチェックサムメカニズム」であるもの)によって指定されます。 チェックサムタイプが合わせられたアルゴリズムでないなら、メッセージを拒絶しなければなりません。
To compute the checksum, the CksumLen field is zeroed out and
the Length field is filled with the total packet length
without the checksum. Then, the packet is passed to the
get_mic function and its output is appended to the packet.
Any KINK padding after the Cksum field is not allowed, except
the Kerberos internal one, which may be included in the output
of the get_mic function. Finally, the CksumLen field is
filled with the checksum length and the Length field is filled
with the total packet length including the checksum.
チェックサムを計算するために、CksumLen分野のゼロが外で合わせられていて、Length分野はチェックサムのない総パケット長で満たされます。 次に、パケットが通過される、_micに機能を得てください。そうすれば、出力をパケットに追加します。 Cksum分野の後のどんなKINK詰め物も許容されていなくて、ケルベロスの内部のものを除く、_mic機能を得てください。(ものは出力に含まれるかもしれません)。 最終的に、CksumLen分野はチェックサムの長さで満たされます、そして、Length分野はチェックサムを含む総パケット長で満たされます。
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分野の値から計算されます。 Length分野はチェックサムのない長さの値で満たされます、そして、CksumLen分野のゼロは外で合わせられています。 次に、チェックサム(0〜長さまでチェックサムのない容認されたパケットのマイナス1つを相殺する)のないパケットとチェックサムに通過される、(チェックサムのない長さから最終になりまで相殺します)_mic機能について確かめてください。 検証が失敗するなら、メッセージを落とさなければなりません。
The KINK header is followed immediately by a series of Type/Length/Value fields, defined in section 4.2.
すぐセクション4.2で定義された一連のType/長さ/値の分野がKINKヘッダーのあとに続いています。
4.1. KINK Alignment Rules
4.1. もつれ整列規則
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 4八重奏の境界でKINKヘッダー、ペイロード、およびCksum分野を並べなければなりません。
Sakane, et al. Standards Track [Page 15] RFC 4430 KINK March 2006
Sakane、他 標準化過程[15ページ]RFC4430は2006年3月にねじれます。
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八重奏の境界に並べられません。
4.2. KINK Payloads
4.2. もつれ有効搭載量
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.
すぐにヘッダーに続いて、Type/長さ/値(TLV)のペイロードのリストがあります。 ヘッダーに続くいろいろなペイロードがあることができます。 各ペイロードはペイロードヘッダーと共に始まらなければなりません。 それぞれのペイロードヘッダーは一般的なペイロードヘッダーの上に造られます。 どんなデータもすぐに、一般的なヘッダーに続きます。 有効搭載量はそれとなく4八重奏の境界にすべて並べられます、ペイロード長分野が正確にペイロードの八重奏の実数を反映しなければなりませんが。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| value (variable) |
+---------------+---------------+---------------+---------------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | 次の有効搭載量| 予約されます。| ペイロード長| +---------------+---------------+---------------+---------------+ | 値(可変)| +---------------+---------------+---------------+---------------+
Figure 6: Format of a KINK Payload
図6: もつれ有効搭載量の形式
Fields:
分野:
o Next Payload (1 octet) -- The type of the next payload.
o 次の有効搭載量(1つの八重奏)--次のペイロードのタイプ。
NextPayload Value
---- -----
KINK_DONE 0
KINK_AP_REQ 1
KINK_AP_REP 2
KINK_KRB_ERROR 3
KINK_TGT_REQ 4
KINK_TGT_REP 5
KINK_ISAKMP 6
KINK_ENCRYPT 7
KINK_ERROR 8
RESERVED TO IANA 9 - 127
Private Use 128 - 255
NextPayload値---- ----- 0もつれ_AP_REQ1もつれ_AP_レップ2もつれ_KRB_誤り3もつれ_TGT_REQ4もつれ_TGT_レップ5もつれ_ISAKMP6もつれ_が行われたもつれ_はIANA9--127私用128--255への控えられた7もつれ_誤り8をコード化します。
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つの八重奏)--予約されて、送付者でゼロにセットしてください、受信機で無視しなければならないということでなければなりません。
Sakane, et al. Standards Track [Page 16] RFC 4430 KINK March 2006
Sakane、他 標準化過程[16ページ]RFC4430は2006年3月にねじれます。
o Payload Length (2 octets) -- The length of this payload,
including the type and length fields.
o 有効搭載量Length(2つの八重奏)--タイプと長さの分野を含むこのペイロードの長さ。
o Value (variable) -- This value of this field depends on the
type.
o 値(可変)--この分野のこの値はタイプに頼っています。
4.2.1. KINK_AP_REQ Payload
4.2.1. もつれ_AP_REQ有効搭載量
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 MUSTは互いの認証を要求します。
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.
このドキュメントは主要な名前を発生させる方法を指定しません。 すなわち、完全な主要な名前はローカルの方針に格納されるかもしれませんが、Fully Qualified Domain Names(FQDNs)は主要な名前に変換されるかもしれませんが、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から発生すると、主要な名前(創始者は始める)は" kink/fqdn@REALM "でしょう。 「もつれ」がKINK IPsecサービスのための文字通りのストリングであるところでは、"fqdn"はサービス・ホストの完全修飾ドメイン名です、そして、「分野」はサービスのケルベロス分野です。 主要な名前は大文字と小文字を区別しています、そして、"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 ~
| |
+---------------------------------------------------------------+
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 +---------------+---------------+---------------+---------------+ | 次の有効搭載量| 予約されます。| ペイロード長| +---------------+---------------+---------------+---------------+ | 時代| +---------------------------------------------------------------+ | | ~ AP-REQ~| | +---------------------------------------------------------------+
Figure 7: KINK_AP_REQ Payload
図7: もつれ_AP_REQ有効搭載量
Fields:
分野:
o Next Payload, RESERVED, Payload Length -- Defined in the
beginning of this section.
o 次の有効搭載量、RESERVED、有効搭載量Length--このセクションの始めに定義されます。
Sakane, et al. Standards Track [Page 17] RFC 4430 KINK March 2006
Sakane、他 標準化過程[17ページ]RFC4430は2006年3月にねじれます。
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年から1901年まで、-、01T00:00:00 UTC。時間は経過した秒(しかし飛躍秒を数えないで)です。 2038-01-19 例えば、T03:14:07 UTCは0x7fffffffとして表されます。
o AP-REQ -- The value field of this payload contains a raw
Kerberos AP-REQ.
o AP-REQ--このペイロードの値の分野は生のケルベロスAP-REQを含んでいます。
4.2.2. KINK_AP_REP Payload
4.2.2. もつれ_AP_レップ有効搭載量
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を創始者にリレーします。 AP-REP MUST、[ケルベロス]で説明されるように新しさがないかどうかチェックされてください。
The value field of this payload has the following format:
このペイロードの値の分野には、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| EPOCH |
+---------------------------------------------------------------+
| |
~ AP-REP ~
| |
+---------------------------------------------------------------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | 次の有効搭載量| 予約されます。| ペイロード長| +---------------+---------------+---------------+---------------+ | 時代| +---------------------------------------------------------------+ | | ~ AP-レップ~| | +---------------------------------------------------------------+
Figure 8: KINK_AP_REP Payload
エイト環: もつれ_AP_レップ有効搭載量
Fields:
分野:
o Next Payload, RESERVED, Payload Length -- Defined in the
beginning of this section.
o 次の有効搭載量、RESERVED、有効搭載量Length--このセクションの始めに定義されます。
o EPOCH -- The absolute time at which the creator of the AP-REP
has valid SA information. Typically, this is when the KINK
keying daemon started if it does not retain SA information
across restarts. The value in this field is the least
significant 4 octets of so-called POSIX time, which is the
elapsed seconds (but without counting leap seconds) from
1970-01-01T00:00:00 UTC. For example, 2038-01-19T03:14:07 UTC
is represented as 0x7fffffff.
o EPOCH--AP-REPの創造者が有効なSA情報を持っている絶対時間。 これは通常、それが横切ってSA情報を保有しないなら始められたデーモンを合わせるKINKが再開する時です。 この分野の値がいわゆるPOSIX時間の最も重要でない4つの八重奏である、1970年から1901年まで、-、01T00:00:00 UTC。時間は経過した秒(しかし飛躍秒を数えないで)です。 2038-01-19 例えば、T03:14:07 UTCは0x7fffffffとして表されます。
Sakane, et al. Standards Track [Page 18] RFC 4430 KINK March 2006
Sakane、他 標準化過程[18ページ]RFC4430は2006年3月にねじれます。
o AP-REP -- The value field of this payload contains a raw
Kerberos AP-REP.
o AP-REP--このペイロードの値の分野は生のケルベロスAP-REPを含んでいます。
4.2.3. KINK_KRB_ERROR Payload
4.2.3. もつれ_KRB_誤り有効搭載量
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ペイロードはケルベロスタイプ誤りを創始者にリレーして戻します。 創始者はあらゆる有効なケルベロス誤りタイプ[ケルベロス]を受ける用意ができていなければなりません。
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.
_KRB_ERRORと適切なサービスキーをKINKに返すのが利用可能であるときに、KINK実現SHOULDはKINK Cksum分野を利用します。 特に時計斜行誤りの場合では、サーバにおける誤りを保護すると、連動するのが時計を必要としないので、より良いユーザー・エクスペリエンスは作成されます。 しかしながら、多くのケルベロス実現で、誤りパケットを保護するためにセッションキーを入手するのは簡単になりません。 非認証されたケルベロス誤りによって、創始者は、それらに影響するのを選ぶかもしれませんが、SHOULDは攻撃の不必要な作業種類に対して予防策を講します。
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がケルベロスエラーメッセージのテキストかe_データ・フィールドを利用しないことに注意してください、対応するKINK実現は、それらを受けるように準備しなければならなくて、それらを登録するかもしれませんが。
The value field of this payload has the following format:
このペイロードの値の分野には、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| |
~ KRB-ERROR ~
| |
+---------------------------------------------------------------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | 次の有効搭載量| 予約されます。| ペイロード長| +---------------+---------------+---------------+---------------+ | | ~ KRB-誤り~| | +---------------------------------------------------------------+
Figure 9: KINK_KRB_ERROR Payload
図9: もつれ_KRB_誤り有効搭載量
Fields:
分野:
o Next Payload, RESERVED, Payload Length -- Defined in the
beginning of this section.
o 次の有効搭載量、RESERVED、有効搭載量Length--このセクションの始めに定義されます。
o KRB-ERROR -- The value field of this payload contains a raw
Kerberos KRB-ERROR.
o KRB-ERROR--このペイロードの値の分野は生のケルベロスKRB-ERRORを含んでいます。
Sakane, et al. Standards Track [Page 19] RFC 4430 KINK March 2006
Sakane、他 標準化過程[19ページ]RFC4430は2006年3月にねじれます。
4.2.4. KINK_TGT_REQ Payload
4.2.4. もつれ_TGT_REQ有効搭載量
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からUserからユーザへのサービスチケットを得るために同輩から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) ~
| |
+---------------------------------------------------------------+
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 +---------------+---------------+---------------+---------------+ | 次の有効搭載量| 予約されます。| ペイロード長| +---------------+---------------+---------------+---------------+ | | ~ PrincName(可変)~| | +---------------------------------------------------------------+
Figure 10: KINK_TGT_REQ Payload
図10: もつれ_TGT_REQ有効搭載量
Fields:
分野:
o Next Payload, RESERVED, Payload Length -- Defined in the
beginning of this section.
o 次の有効搭載量、RESERVED、有効搭載量Length--このセクションの始めに定義されます。
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と、cnameとcrealmであったに違いないなら返されたTGTは要求された主要な名前に合わなければなりません、創始者が応答者の分野の応答者と共に集合できるように。
PrincName values are octet string representations of a
principal and realm name formatted just like the octet string
used in the "NAME" component of Generic Security Service
Application Program Interface (GSS-API) [RFC2743] exported
name token for the Kerberos V5 GSS-API mechanism [RFC1964].
See RFC 1964, section 2.1.3.
PrincName値は一般的なセキュリティー・サービス適用業務プログラム・インタフェース(GSS-アピ)[RFC2743]の「名前」コンポーネントで使用される八重奏ストリングがケルベロスV5 GSS-APIメカニズム[RFC1964]のためにまさしく名前象徴を輸出したようにフォーマットされた校長と分野名の八重奏ストリング表現です。 RFC1964、セクション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に__どんな米国も返さないかもしれません。 施政方針が、TGTを返すのを禁止するなら、それはKINK_U2UDENIEDを返すかもしれません。
Sakane, et al. Standards Track [Page 20] RFC 4430 KINK March 2006
Sakane、他 標準化過程[20ページ]RFC4430は2006年3月にねじれます。
4.2.5. KINK_TGT_REP Payload
4.2.5. もつれ_TGT_レップ有効搭載量
The value field of this payload contains the TGT requested in a previous KINK_TGT_REQ payload of a GETTGT command.
このペイロードの値の分野はGETTGTコマンドの前のKINK_TGT_REQペイロードで要求されたTGTを含んでいます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| |
~ TGT (variable) ~
| |
+---------------------------------------------------------------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | 次の有効搭載量| 予約されます。| ペイロード長| +---------------+---------------+---------------+---------------+ | | ~ TGT(可変)~| | +---------------------------------------------------------------+
Figure 11: KINK_TGT_REP Payload
図11: もつれ_TGT_レップ有効搭載量
Fields:
分野:
o Next Payload, RESERVED, Payload Length -- Defined in the
beginning of this section.
o 次の有効搭載量、RESERVED、有効搭載量Length--このセクションの始めに定義されます。
o TGT -- The Distinguished Encoding Rules (DER)-encoded TGT of
the responder.
o TGT--Distinguished Encoding Rules(DER)は応答者のTGTをコード化しました。
4.2.6. KINK_ISAKMP Payload
4.2.6. もつれ_ISAKMP有効搭載量
The value field of this payload has the following format:
このペイロードの値の分野には、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+-------+-------+---------------+---------------+
| InnerNextPload| QMMaj | QMMin | RESERVED |
+---------------+-------+-------+---------------+---------------+
| Quick Mode Payloads (variable) |
+---------------+---------------+---------------+---------------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | 次の有効搭載量| 予約されます。| ペイロード長| +---------------+-------+-------+---------------+---------------+ | InnerNextPload| QMMaj| QMMin| 予約されます。| +---------------+-------+-------+---------------+---------------+ | 迅速なモード有効搭載量(可変)| +---------------+---------------+---------------+---------------+
Figure 12: KINK_ISAKMP Payload
図12: もつれ_ISAKMP有効搭載量
Fields:
分野:
o Next Payload, RESERVED, Payload Length -- Defined in the
beginning of this section.
o 次の有効搭載量、RESERVED、有効搭載量Length--このセクションの始めに定義されます。
o InnerNextPload -- First payload type of the inner series of
ISAKMP payloads.
o InnerNextPload--最初に、内側のシリーズのISAKMPペイロードのペイロードタイプ。
Sakane, et al. Standards Track [Page 21] RFC 4430 KINK March 2006
Sakane、他 標準化過程[21ページ]RFC4430は2006年3月にねじれます。
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クィックMode(フェーズ2)ペイロードを要約します。 ただ一つのKINKメッセージの中にいろいろなKINK_ISAKMPペイロードがあるかもしれません。 [IKE]は複数の異なったSAsがただ一つのIKEメッセージの中で作成されるかもしれないかどうかいくらかあいまいですが、KINKは、新しいISAKMPヘッダーがそれぞれの離散的なSA操作に使用されるのを明らかに必要とします。 言い換えれば、KINK実現はただ一つのKINK_ISAKMPペイロードの中に複数のクィックMode取引を送ってはいけません。
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.
クィックModeバージョンの目的はその後の改正があればIKEとISAKMPとの後方の互換性を許容することです。 現在では、クィックModeが専攻して、小さい方のバージョンは、1つに設定されて、それぞれ(1.0)のゼロに合っています。 これらのバージョンはISAKMPヘッダーでISAKMPバージョンと食い違っています。 対応するKINK実現は1.0個のペイロードの領収書を支えなければなりません。 それはその後のバージョン(発信と受信の両方)を支持するかもしれません、そして、KINK同輩が将来のバージョンを処理できないなら、SHOULDはクィックModeバージョン1.0に訴えて戻る手段を提供します。 取引を考えて、対応するKINK実現はいずれでもクィックModeバージョンを混ぜてはいけません。
4.2.7. KINK_ENCRYPT Payload
4.2.7. もつれ_は有効搭載量をコード化します。
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) |
+---------------+---------------+---------------+---------------+
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 +---------------+---------------+---------------+---------------+ | 次の有効搭載量| 予約されます。| ペイロード長| +---------------+---------------+---------------+---------------+ | InnerNextPload| RESERVED2| +---------------+---------------+---------------+---------------+ | 有効搭載量(可変)| +---------------+---------------+---------------+---------------+
Figure 13: KINK_ENCRYPT Payload
図13: もつれ_は有効搭載量をコード化します。
Sakane, et al. Standards Track [Page 22] RFC 4430 KINK March 2006
Sakane、他 標準化過程[22ページ]RFC4430は2006年3月にねじれます。
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、有効搭載量Length--このセクションの始めに定義されます。 このペイロードはメッセージで最後のものです、そして、それに従って、Next有効搭載量分野は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で始まるので、最初のペイロードのタイプは秘密にされます。 したがって、コード化された八重奏の数はPayloadLengthです--4。
The format of the encryption payload follows the normal Kerberos semantics. Its content is the output of an encrypt function defined in the Encryption Algorithm Profile section of [KCRYPTO]. Parameters such as encrypt function itself, specific-key, and initial state are defined with the etype. The encrypt function may have padding in itself and there may be some garbage data at the end of the decrypted plaintext. A KINK implementation MUST be prepared to ignore such padding after the last sub-payload inside the KINK_ENCRYPT payload. Note that each encrypt function has its own integrity protection mechanism. It is redundant with the checksum in the KINK header, but this is unavoidable because it is not always possible to remove the integrity protection part from the encrypt function.
暗号化ペイロードの形式は正常なケルベロス意味論に従います。 内容が出力である、[KCRYPTO]のEncryption Algorithm Profile部で定義された機能をコード化してください。 機能自体をコード化するようなパラメタ、特定のキー、および初期状態はetypeで定義されます。 機能をコード化してください。解読された平文の終わりに本来詰め物を持っているかもしれなくて、いくつかのゴミデータがあってもよいです。 最後のサブペイロードの後にKINK_ENCRYPTペイロードの中にそのような詰め物を無視するようにKINK実現を準備しなければなりません。 それぞれが機能をコード化するというメモには、それ自身の保全保護メカニズムがあります。 それがKINKヘッダーでチェックサムで余分ですが、それが保全保護部分を取り除くのにおいていつも可能であるというわけではないのでこれが避けられない、機能をコード化してください。
4.2.8. KINK_ERROR Payload
4.2.8. もつれ_誤り有効搭載量
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ペイロードタイプはエラー条件を返すプロトコルレベルメカニズムを提供します。 定義されたそれら自身のペイロードを持っているケルベロスで発生している誤りかDOI特有の誤りのどちらかにこのペイロードを使用するべきではありません。 エラーコードがネットワークオーダーにあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| ErrorCode |
+---------------+---------------+---------------+---------------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | 次の有効搭載量| 予約されます。| ペイロード長| +---------------+---------------+---------------+---------------+ | ErrorCode| +---------------+---------------+---------------+---------------+
Figure 14: KINK_ERROR Payload
図14: もつれ_誤り有効搭載量
Sakane, et al. Standards Track [Page 23] RFC 4430 KINK March 2006
Sakane、他 標準化過程[23ページ]RFC4430は2006年3月にねじれます。
Fields:
分野:
o Next Payload, RESERVED, Payload Length -- Defined in the
beginning of this section.
o 次の有効搭載量、RESERVED、有効搭載量Length--このセクションの始めに定義されます。
o ErrorCode -- One of the following values in the network byte
order:
o ErrorCode--ネットワークバイトオーダーにおける以下の値の1つ:
ErrorCode Value Purpose
--------- ----- -------------------
KINK_OK 0 No error detected
KINK_PROTOERR 1 The message was malformed
KINK_INVDOI 2 Invalid DOI
KINK_INVMAJ 3 Invalid Major Version
RESERVED 4
KINK_INTERR 5 An unrecoverable internal error
KINK_BADQMVERS 6 Unsupported Quick Mode Version
KINK_U2UDENIED 7 Returning a TGT is prohibited
RESERVED TO IANA 8 - 8191
Private Use 8192 - 16383
RESERVED 16384 -
ErrorCode値の目的--------- ----- ------------------- KINK_OK0いいえ誤りはKINK_PROTOERR1を検出しました。メッセージは奇形のKINK_INVDOI2Invalid DOI KINK_INVMAJ3InvalidメージャーバージョンRESERVED4KINK_INTERR5のAnの復しない内部エラーKINK_BADQMVERS6UnsupportedクィックModeバージョンKINK_U2UDENIED7ザ・リターニング/死霊のキラー・スートンa TGTが禁止されたRESERVED TO IANA8--8191兵士のUse8192であるということでした--、16383RESERVED16384、-
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ペイロードが存在していないかのように創始者は行動するかもしれません。 創始者が複数のクィックModeバージョンかDOIs、KINK_BADQMVERSを支持するか、KINK_INVDOIが受け取られていて、またはCksumが確かめられるなら、それは別のバージョンかDOIと共に再試行されるかもしれません。 SHOULDがヘッダーにサポートされない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.
一般に、応答者は、非認証されたコマンドに対してこれらの誤りを返すのを選ぶかもしれませんが、SHOULDは、サービス不能攻撃にかかわるのを避けるために注意します。 同様に、創始者は、非認証された誤りに影響するのを選ぶかもしれませんが、SHOULDは、サービス不能攻撃を避けるために注意します。
Sakane, et al. Standards Track [Page 24] RFC 4430 KINK March 2006
Sakane、他 標準化過程[24ページ]RFC4430は2006年3月にねじれます。
5. Differences from IKE Quick Mode
5. IKEの迅速なモードからの違い
KINK directly uses ISAKMP payloads to negotiate SAs. In particular, KINK uses IKE phase 2 payload types (aka Quick Mode). In general, there should be very few changes necessary to an IKE implementation to establish the SAs, and unless there is a note to the contrary in the memo, all capabilities and requirements in [IKE] MUST be supported. IKE phase 1 payloads MUST NOT be sent.
KINKは、SAsを交渉するのに直接ISAKMPペイロードを使用します。 特に、KINKはIKEフェーズ2ペイロードタイプ(通称クィックMode)を使用します。 一般に、SAsを設立する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.
イケと異なって、KINKは、主に予測できるSA創造/削除を容易にするためにSAsの創造、削除、および状態のための特定のコマンドを定義します(セクション3.2と3.3を見てください)。 そういうものとして、KINKはいくつかのペイロードのどのコマンドと共にどんなペイロードを送るかもしれないかに関する、ある制限、いくつかの追加制限、および意味論を置きます。 作成者は実際の形式と意味論について[IKE]と[ISAKMP]について言及するべきです。 特定のIKEフェーズ2ペイロードがここに言及されないなら、それは、使用中である違いが全くないことを意味します。
o The Security Association Payload header for IP is defined in
section 4.6.1 of [IPDOI]. For this memo, the Domain of
Interpretation MUST be set to 1 (IPsec) and the Situation
bitmap MUST be set to 1 (SIT_IDENTITY_ONLY). All other fields
are omitted (because SIT_IDENTITY_ONLY is set).
o IPのためのSecurity Association有効搭載量ヘッダーは.1セクション4.6[IPDOI]で定義されます。 このメモにおいて、InterpretationのDomainは1(IPsec)に用意ができなければなりません、そして、1(SIT_IDENTITYだけ)にSituationビットマップを設定しなければなりません。 他のすべての分野が省略されます(SIT_IDENTITYだけが用意ができているので)。
o KINK also expands the semantics of IKE in that it defines an
optimistic proposal for CREATE commands to allow SA creation to
complete in two messages.
o また、SA創造が2つのメッセージで完成するのを許容するCREATEコマンドのための楽観的な提案を定義するので、KINKは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クィックMode(フェーズ2)は主なモード(フェーズ1)で合わせることの材料を発生させるのに使用される細切れ肉料理アルゴリズムを使用します。 このために、KINK MUSTはセッションキーの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は、NonceペイロードNrが楽観的な合わせることを容易にするために任意であることを許容します。
Sakane, et al. Standards Track [Page 25] RFC 4430 KINK March 2006
Sakane、他 標準化過程[25ページ]RFC4430は2006年3月にねじれます。
5.1. Security Association Payloads
5.1. セキュリティ協会有効搭載量
KINK supports the following SA attributes from [IPDOI]:
KINKは[IPDOI]から以下のSA属性を支持します:
class value type ------------------------------------------------- SA Life Type 1 B SA Life Duration 2 V Encapsulation Mode 4 B Authentication Algorithm 5 B Key Length 6 B Key Rounds 7 B
階級値タイプ------------------------------------------------- SA1つの生活型B SA寿命2Vカプセル化モード4B認証アルゴリズム5Bキー長6B主要なラウンド7B
Refer to [IPDOI] for the actual definitions of these attributes.
これらの属性の実際の定義について[IPDOI]を参照してください。
5.2. Proposal and Transform Payloads
5.2. 提案と変換有効搭載量
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は違いなしでProposalとTransformペイロードを直接使用します。 しかしながら、KINKは追加関連性を最初の提案に置きます、そして、最初に、それぞれの変換は楽観的な合わせるのに活用します。
5.3. Identification Payloads
5.3. 識別有効搭載量
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:
Identificationペイロードは設立されるSAによって保護されることになっている交通を特定するのに使用される情報を運びます。 KINKがIDタイプを制限する、どれ、定義されたコネセクション4.6.2は以下の値への.1[IPDOI]です:
ID Type Value
------- -----
ID_IPV4_ADDR 1
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
IDタイプ価値------- ----- ID_IPV4_ADDR1ID_IPV4_ADDR_サブネット4ID_IPV6_ADDR5ID_IPV6_ADDR_サブネット6ID_IPV4_ADDR_範囲の7ID_IPV6_ADDR_範囲8
5.4. Nonce Payloads
5.4. 一回だけの有効搭載量
The Nonce payload contains random data that MUST be used in key generation. It MUST be sent by the initiating KINK peer, and MAY be sent by the responding KINK peer. See section 7 for the discussion of its use in key generation.
Nonceペイロードはキー生成に使用しなければならない無作為のデータを含んでいます。 開始で送って、KINKがじっと見て、応じているKINK同輩によって送られるかもしれないということであるに違いありません。 キー生成における、使用の議論に関してセクション7を見てください。
Sakane, et al. Standards Track [Page 26] RFC 4430 KINK March 2006
Sakane、他 標準化過程[26ページ]RFC4430は2006年3月にねじれます。
5.5. Notify Payloads
5.5. 有効搭載量に通知してください。
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]を報告するために意図します。 それが応答で認識しないこの範囲でタイプを受ける実現は、対応する要求が完全に失敗したと仮定しなければなりません。 要求か応答で無視しなければならない要求と状態のタイプが、タイプする認識されていない誤り、および彼ら、SHOULD、登録されてください。 状態タイプがどんなメッセージにも追加されるかもしれなくて、無視しなければならないか、または見分けられている状態で、ペイロードに通知してください。 それらは、能力を示すことを意図して、非暗号のパラメタを交渉するのに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.
以下のテーブルはNotificationメッセージとそれらの換算値をリストアップします。 有効搭載量MALFORMEDは[ISAKMP]によって定義された何人かの誤りタイプを指示します。 したがって、例えばINVALID PROTOCOL IDは本書では使用されません。 KINK_BADQMVERSがIKEのバージョンが支持されないと創始者に言うのに使用されるので、INVALIDメージャーVERSIONとINVALID-MINORバージョンは使用されていません。
NOTIFY MESSAGES - ERROR TYPES Value ----------------------------- ----- INVALID-PAYLOAD-TYPE 1
メッセージに通知してください--誤りは値をタイプします。----------------------------- ----- 無効のペイロードタイプ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ペイロードを支えないとき、それを送ります。 Dataがそうしなければならない通知は1八重奏のペイロードタイプを含んでいます。
INVALID-SPI 11
無効のSPI11
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.
応答者が創始者にDELETE流動の場合にSPIを示させないなら応答者が創始者にCREATE流動の場合にSPIを示させるなら、発信しました。
NO-PROPOSAL-CHOSEN 14
選ばれなかった提案全く14
Sent if none of the proposals in the SA payload was
acceptable.
SAペイロードにおける提案のいずれも許容できなかったなら、発信しました。
Sakane, et al. Standards Track [Page 27] RFC 4430 KINK March 2006
Sakane、他 標準化過程[27ページ]RFC4430は2006年3月にねじれます。
PAYLOAD-MALFORMED 16
ペイロード奇形の16
Sent if the KINK_ISAKMP payload received was invalid because
some type, length, or value was out of range. It is also sent
when the request was rejected for reason that was not matched
with other error types.
タイプ、長さ、または値が範囲から脱していたのでISAKMPペイロードが受けたKINK_が無効であったなら、発信しました。 また、他の誤りタイプに合わせられなかった理由で要求を拒絶したとき、それを送ります。
5.6. Delete Payloads
5.6. 有効搭載量を削除してください。
KINK directly uses ISAKMP Delete payloads with no changes.
KINKは変化なしでISAKMP Deleteペイロードを直接使用します。
5.7. KE Payloads
5.7. KE有効搭載量
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を使用する能力を保有しますが、必須道具からSHOULD道具まで要件を弛緩します。 理由はSecurity Considerations部で説明されます。
6. Message Construction and Constraints for IPsec DOI
6. IPsec DOIのメッセージ工事と規制
All commands, responses, and acknowledgements are bound together by the XID field of the message header. The XID is normally a monotonically incrementing field, and is used by the initiator to differentiate between outstanding requests to a responder. The XID field does not provide replay protection as that functionality is provided by the Kerberos mechanisms. In addition, commands and responses MUST use a cryptographic checksum over the entire message if the two peers share a key via a ticket exchange.
すべてのコマンド、応答、および承認はメッセージヘッダーのXID分野のそばで一緒に制限されています。 XIDは、通常単調に増加している分野であり、傑出している要求を応答者に区別するのに創始者によって使用されます。 ケルベロスメカニズムでその機能性を提供するとき、XID分野は反復操作による保護を提供しません。さらに、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ペイロードで要約されるかもしれません。
6.1. REPLY Message
6.1. 応答メッセージ
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特有のペイロードを含むかもしれません。
6.2. ACK Message
6.2. ACKメッセージ
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.
REPLYメッセージにACKREQビットを設定するときだけ、ACKsを送ります。 AP-REQペイロードを含んでいますが、ACKメッセージは他のどんなペイロードも含んではいけません。
Sakane, et al. Standards Track [Page 28] RFC 4430 KINK March 2006
Sakane、他 標準化過程[28ページ]RFC4430は2006年3月にねじれます。
6.3. CREATE Message
6.3. メッセージを作成してください。
This message initiates an establishment of new security association(s). The CREATE message must contain an AP-REQ payload and any DOI-specific payloads.
このメッセージは新しいセキュリティ協会の設立を開始します。 CREATEメッセージはAP-REQペイロードとどんなDOI特有のペイロードも含まなければなりません。
CREATE KINK Header
KINK_AP_REQ
[KINK_ENCRYPT]
KINK_ISAKMP payloads
SA Payload
Proposal Payloads
Transform Payloads
Nonce Payload (Ni)
[KE]
[IDci, IDcr]
[Notification Payloads]
CREATE KINK Header KINK_AP_REQ[KINK_ENCRYPT]KINK_ISAKMPペイロードSA有効搭載量Proposal有効搭載量Transform有効搭載量Nonce有効搭載量(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]
REPLY KINK Header KINK_AP_REP[KINK_ENCRYPT]KINK_ISAKMPペイロードSA有効搭載量Proposal有効搭載量Transform有効搭載量[一回だけの有効搭載量(Nr)][KE][IDci、IDcr][通知有効搭載量]
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と異なって、NonceペイロードNrは必要ではありません、そして、存在しているなら、創始者の出発しているSAsを変更しなければならないのを示すよう承認を要求しなければなりません。 提案は1つの番目もののいずれであるならも受取人によって選ばれていなくて、それはSHOULDです。Nonceペイロードを含めてください。
KINK, like IKE, allows the creation of many SAs in one create command. If any of the optimistic proposals are not chosen by the responder, it MUST request an ACK.
IKEのように、KINKは1つの作成コマンドにおける、多くのSAsの創造を許します。 楽観的な提案のいずれも応答者によって選ばれていないなら、それはACKを要求しなければなりません。
If an IPsec DOI-specific error is encountered, the responder must reply with a Notify payload describing the error:
IPsec DOI特有の誤りが遭遇するなら、Notifyペイロードが誤りについて説明している状態で、応答者は返答しなければなりません:
Sakane, et al. Standards Track [Page 29] RFC 4430 KINK March 2006
Sakane、他 標準化過程[29ページ]RFC4430は2006年3月にねじれます。
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payloads
[Notification Payloads]
REPLY KINK Header KINK_AP_REP[KINK_ENCRYPT][KINK_ERROR]KINK_ISAKMPペイロード[通知有効搭載量]
If the responder finds a Kerberos error for which it can produce a valid authenticator, the REPLY takes the following form:
応答者がそれが有効な固有識別文字を作成できるケルベロス誤りを見つけるなら、REPLYは以下の形を取ります:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_KRB_ERROR
回答もつれヘッダーもつれ_AP_レップ[_がコード化するもつれ]もつれ_KRB_誤り
Finally, if the responder finds a Kerberos or KINK type of error for which it cannot create an AP-REP, it MUST reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
最終的に、応答者が、ケルベロスかKINKがそれがAP-REPを作成できない誤りのタイプであることがわかるなら、ひとりの_KINK_KRB ERRORかKINK_ERRORペイロードで返答しなければなりません:
REPLY KINK Header
[KINK_KRB_ERROR]
[KINK_ERROR]
回答もつれヘッダー[もつれ_KRB_誤り][もつれ_誤り]
6.4. DELETE Message
6.4. メッセージを削除してください。
This message indicates that the sending peer has deleted or will shortly delete Security Association(s) with the other peer.
このメッセージは、削除されて、送付同輩がそうしたのを示すか、またはまもなく、もう片方の同輩と共にSecurity Association(s)を削除するでしょう。
DELETE KINK Header
KINK_AP_REQ
[KINK_ENCRYPT]
KINK_ISAKMP payloads
Delete Payloads
[Notification Payloads]
DELETE KINK Header KINK_AP_REQ[KINK_ENCRYPT]KINK_ISAKMPペイロードDelete有効搭載量[通知有効搭載量]
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]
REPLY KINK Header KINK_AP_REP[KINK_ENCRYPT][KINK_ERROR]KINK_ISAKMPペイロードDelete有効搭載量[通知有効搭載量]
If an IPsec DOI-specific error is encountered, the responder must reply with a Notify payload describing the error:
IPsec DOI特有の誤りが遭遇するなら、Notifyペイロードが誤りについて説明している状態で、応答者は返答しなければなりません:
Sakane, et al. Standards Track [Page 30] RFC 4430 KINK March 2006
Sakane、他 標準化過程[30ページ]RFC4430は2006年3月にねじれます。
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payloads
[Notification Payloads]
REPLY KINK Header KINK_AP_REP[KINK_ENCRYPT][KINK_ERROR]KINK_ISAKMPペイロード[通知有効搭載量]
If the responder finds a Kerberos error for which it can produce a valid authenticator, the REPLY takes the following form:
応答者がそれが有効な固有識別文字を作成できるケルベロス誤りを見つけるなら、REPLYは以下の形を取ります:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_KRB_ERROR
回答もつれヘッダーもつれ_AP_レップ[_がコード化するもつれ]もつれ_KRB_誤り
If the responder finds a KINK or Kerberos type of error, it MUST reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
応答者が、KINKかケルベロスが誤りのタイプであることがわかるなら、ひとりの_KINK_KRB ERRORかKINK_ERRORペイロードで返答しなければなりません:
REPLY KINK Header
[KINK_KRB_ERROR]
[KINK_ERROR]
回答もつれヘッダー[もつれ_KRB_誤り][もつれ_誤り]
6.5. STATUS Message
6.5. ステータスメッセージ
The STATUS command is used in two ways:
STATUSコマンドは2つの方法で使用されます:
1) As a means to relay an ISAKMP Notification message.
1) ISAKMP Notificationメッセージをリレーする手段として。
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は以下のペイロードを含んでいます: ヘッダーもつれ_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]]
回答もつれヘッダーもつれ_AP_レップ[[KINK_ENCRYPT][KINK_ERROR]KINK_ISAKMPペイロード[通知有効搭載量]]
Sakane, et al. Standards Track [Page 31] RFC 4430 KINK March 2006
Sakane、他 標準化過程[31ページ]RFC4430は2006年3月にねじれます。
If the responder finds a Kerberos error for which it can produce a valid authenticator, the REPLY takes the following form:
応答者がそれが有効な固有識別文字を作成できるケルベロス誤りを見つけるなら、REPLYは以下の形を取ります:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_KRB_ERROR
回答もつれヘッダーもつれ_AP_レップ[_がコード化するもつれ]もつれ_KRB_誤り
If the responder finds a KINK or Kerberos type of error, it MUST reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
応答者が、KINKかケルベロスが誤りのタイプであることがわかるなら、ひとりの_KINK_KRB ERRORかKINK_ERRORペイロードで返答しなければなりません:
REPLY KINK Header
[KINK_KRB_ERROR]
[KINK_ERROR]
回答もつれヘッダー[もつれ_KRB_誤り][もつれ_誤り]
6.6. GETTGT Message
6.6. GETTGTメッセージ
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ペイロードで返答しなければなりません。
7. ISAKMP Key Derivation
7. ISAKMPの主要な派生
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、[^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はAP-REQからのケルベロスサービスチケットの中に主要なセッションです。 サブキーをKINKで使用しないで、受け取るなら無視しなければならないことに注意してください。
o Both Ni_b and Nr_b are the part of the Nonce payloads (Ni and
Nr, respectively) as described in section 3.2 of [IKE]. Nr_b
is optional, which means that Nr_b is treated as if a zero
length value was supplied when the responder's nonce (Nr) does
not exist. When Nr exists, Nr_b MUST be included in the
calculation.
o Ni_bとNr_bの両方が[IKE]のセクション3.2で説明されるようにNonceペイロード(それぞれNiとNr)の一部分です。 Nr_bは任意です(Nr_bが応答者の一回だけ(Nr)が存在しないとき、まるでゼロ・レングス値を供給するかのように扱われることを意味します)。 Nrが存在するとき、計算にNr_bを含まなければなりません。
Sakane, et al. Standards Track [Page 32] RFC 4430 KINK March 2006
Sakane、他 標準化過程[32ページ]RFC4430は2006年3月にねじれます。
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].
ディフィー-ヘルマンの主要な協定を使用することでKEペイロードを供給するとき、g(qm)^xyが材料が生成した合わせることについて言及することに注意してください。 これは[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に続きます。 どう誘導合わせることの材料を使用するかは各サービス(例えば、.2セクション4.5[IPSEC])まで達しています。
8. Key Usage Numbers for Kerberos Key Derivation
8. ケルベロスの主要な派生の主要な用法番号
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.
ケルベロスは、機能を暗号化するか、または解読して、_mic機能が「用法番号を合わせること」をmic/が、確かめる必要とする_を手に入れます。 それらが暗号の操作のための特定のキーを生成するのに使用されるので、異なったキーは異なる役割/オブジェクトに使用されます。 KINKは以下に記載された2つの用法番号を使用します。
Purpose Usage number
------- ------------
KINK_ENCRYPT payload (for encryption) 39
Cksum field (for checksum) 40
目的Usage番号------- ------------ KINK_ENCRYPTペイロード(暗号化のための)39Cksum分野(チェックサムのための)40
9. Transport Considerations
9. 輸送問題
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を使用します。 SHOULDが考慮の往復の問題へ行って、端が欠けている指数の下に後部メカニズムを実装しなければならないワンタイマーTがあります。 州のマシンは簡単です: タイマT.Sinceケルベロスを使用して、応答が要求を再送しなければならないと予想するどんなメッセージも、メッセージが反復操作による保護のために新しい時勢で再送されるのを必要として、その都度メッセージのチェックサムを含んでいて、メッセージを作り直さなければなりません。 ACKREQビットがセットしたことでのコマンドと回答の両方が再送信タイマの上に保たれます。 ACKREQビットがセットした状態でKINK創始者がREPLYを受け取るとき、最小完全な再送タイムアウトサイクルかパケットが新たに組み立てられたSAで到着したのに気付くまでトランザクションへのACKメッセージを作り直す能力を保有しなければなりません、どれが一番になっても。
When a KINK peer retransmits a message, it MUST create a new Kerberos authenticator for the AP-REQ so that the peer can differentiate between replays and dropped packets. This results in a potential race condition when a retransmission occurs before an in-flight reply is received/processed. To counter this race condition, the retransmitting party SHOULD keep a list of valid authenticators that are outstanding for any particular transaction.
KINK同輩がメッセージを再送するとき、同輩が再生と下げられたパケットを区別できて、それはAP-REQのために新しいケルベロス固有識別文字を作成しなければなりません。 機内の回答を受け取るか、または処理する前に「再-トランスミッション」が現れると、これは潜在的競合条件をもたらします。 この競合条件、再送を打ち返すために、パーティーSHOULDはどんな特定の取引においても、傑出している有効な固有識別文字のリストを保ちます。
Sakane, et al. Standards Track [Page 33] RFC 4430 KINK March 2006
Sakane、他 標準化過程[33ページ]RFC4430は2006年3月にねじれます。
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をもたらします)。 (2) (1) タイムアウトを含んでいて、創始者が寿命が創始者の最大のトランザクション時間より長いチケットを得なければならない、この理由で、それは、「再-トランスミッション」の1セットの中で同じチケットを使用し続けなければならなくて、iffに、それは応答者から誤り(たぶんKRB_AP_ERR_TKT_EXPIRED)を受けて、さもなければ、それは新しいチケットから新しいトランザクションを始めます。
10. Security Considerations
10. セキュリティ問題
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サービスのアイデンティティですが、DOI特有のセレクタ(IPアドレス、ポートナンバーなど)によってSAsによって保護されたトラフィックは特定されます。 これは認証からSAによって保護されたデータの離脱に通じるかもしれません。 例えば、2人の異なったホストが、彼らには同じIPアドレスがあると主張するなら、どの主体のキーがデータを保護するかを予測するのは不可能であるかもしれません。 したがって、実装は主要な名前とSAセレクタの間の結合のために注意されなければなりません。
Sending errors without cryptographic protection must be handled very carefully. There is a trade-off between wanting to be helpful in diagnosing a problem and wanting to avoid being a dupe in a denial of service attack.
非常に慎重に暗号の保護なしで誤りを送るのを扱わなければなりません。 問題を診断して、お人よしであることを避けたい際にサービス不能攻撃に役立ちたいとき、トレードオフがあります。
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.
KINKはケルベロスとIKEの両方(他の多くのメモから順番に急いで作り上げられる後者)の多くの部品を急いで作り上げて、再利用します。 そういうものとして、KINKはそれぞれのコンポーネントの弱点と問題の多くを引き継ぎます。 しかしながら、KINKはSAsを作成して、削除するのにIKEフェーズ2ペイロードだけを使用します。 IKEフェーズ1に関係するセキュリティ問題は安全に無視されるかもしれません。 しかしながら、IKEの認証フェーズを無視できるのは、必ずKINKが[ケルベロス]で概説されているようにケルベロス認証のセキュリティ問題のすべてを引き継ぐことを意味します。 個人的には、Authentication、Authorization、およびAccounting(AAA)サーバのように、KDCはそれが含意する攻撃とすべてのポイントです。 多くがケルベロスの様々な短所と緩和に関して書かれています、そして、それらはどんな展開のためにも評価されるべきです。
KINK's use of Kerberos presents a couple of considerations. First, KINK explicitly expects that the KDC will provide adequate entropy when it generates session keys. Second, Kerberos is used as a user authentication protocol with the possibility of dictionary attacks on user passwords. This memo does not describe a particular method to avoid these pitfalls, but recommends that suitable randomly generated
ケルベロスのKINKの使用は2、3の問題を提示します。 まず最初に、KINKは、セッションキーを生成するとKDCが適切なエントロピーを提供すると明らかに予想します。 2番目に、ケルベロスはユーザー認証プロトコルとしてユーザパスワードで辞書攻撃の可能性で使用されます。 このメモは、これらの落とし穴を避ける特定のメソッドを説明しませんが、適当なそれが手当たりしだいに生成したことを勧めます。
Sakane, et al. Standards Track [Page 34] RFC 4430 KINK March 2006
Sakane、他 標準化過程[34ページ]RFC4430は2006年3月にねじれます。
keys should be used for the service principals such as using the -randomkey option with MIT's "kadmin addprinc" command as well as for clients when that is practical.
それが実用的であるときに、キーはMITの"kadmin addprinc"コマンドによる-randomkeyオプションを使用などなどのサービス主体とクライアントに使用されるべきです。
Kerberos does not currently provide perfect forward secrecy in general. KINK with the KE payload can provide PFS for a service key from a Kerberos key, but the KE is not mandatory because of the computational cost. This is a trade-off and operators can choose the PFS over the cost, and vice versa. KINK itself should be secure from offline analysis from compromised principal passphrases if PFS is used, but from an overall system's standpoint, the existence of other Kerberized services that do not provide PFS makes this a less than optimal situation.
ケルベロスは現在、一般に、完全な前進の秘密保持を提供しません。 KEペイロードがあるKINKはケルベロスキーから主要なサービスにPFSを提供できますが、KEはコンピュータの費用のために義務的ではありません。 これはトレードオフです、そして、オペレータは費用に関してPFSを選ぶことができます、そして、逆もまた同様です。 PFSが使用されているなら、KINK自身はオフライン分析から感染している主要なパスフレーズから安全であるべきですが、総合体系の見地から、PFSを提供しない他のKerberizedサービスの存在はこれをあまり最適でない状況にします。
11. IANA Considerations
11. IANA問題
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)
もつれメッセージタイプ(セクション4)はもつれ誤りがコード化する次の有効搭載量タイプ(セクション4.2)をねじれさせます。(セクション4.2.8)
Changes and additions to this registry follow the policies described below. Their meanings are described in [BCP26].
この登録への変化と追加は以下で説明された方針に続いて起こります。 それらの意味は[BCP26]で説明されます。
o Using the numbers in the "Private Use" range is Private Use.
o 「私用」範囲で数を使用するのは、兵士のUseです。
o Assignment from the "RESERVED TO IANA" range needs Standards
Action, or non-standards-track RFCs with Expert Review.
(Though the full specification may be a public and permanent
document of a standards body other than IETF, an RFC referring
it is needed.)
o 「IANAに予約された」範囲からの課題は規格動作、または専門のレビューがある非標準化過程RFCsを必要とします。 (完全な仕様はIETF以外の標準化団体の公共の、そして、永久的なドキュメントであるかもしれませんが、それを参照するRFCが必要です。)
o Other change requires Standards Action.
o 他の変化はStandards Actionを必要とします。
12. Forward Compatibility Considerations
12. 下位互換問題
KINK can accommodate future versions of Quick Mode through the use of the version field in the ISAKMP payload as well as new domains of interpretation. In this memo, the only supported Quick Mode version is 1.0, which corresponds to [IKE]. Likewise, the only DOI supported is the IPsec domain of interpretation [IPDOI]. New Quick Mode versions and DOIs MUST be described in subsequent memos.
解釈の新しいドメインと同様にISAKMPペイロードにおけるバージョン分野の使用でKINKはクィックModeの将来のバージョンに対応できます。 このメモでは、唯一のサポートしているクィックModeバージョンが1.0です([IKE]に対応しています)。 同様に、サポートされた唯一のDOIが解釈[IPDOI]のIPsecドメインです。 その後のメモで新しいクィックModeバージョンとDOIsについて説明しなければなりません。
Sakane, et al. Standards Track [Page 35] RFC 4430 KINK March 2006
Sakane、他 標準化過程[35ページ]RFC4430は2006年3月にねじれます。
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実装はSHOULDを通信させます。バージョン1.0に戻って戻ることができてください。
12.1. New Versions of Quick Mode
12.1. 迅速なモードの新しいバージョン
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のものと同様です。(プロトコルはクィックModeを使用しません)。 2の違いは[IKEv2]のAppendix Aにまとめられます。 KINKとIKEv2を使用するためにそれぞれのそれらを考えなければなりません。
12.2. New DOI
12.2. 新しいDOI
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に関する1つの例と、MSECワーキンググループはInterpretation[GDOI]のGroup Domainを定義しました。(Interpretationはいくつかの新しいメッセージを定義します)。(ISAKMPメッセージに似ていますが、メッセージはISAKMPでは定義されません)。
In order to carry GDOI messages in KINK, the DOI field in the KINK header would indicate that GDOI is being used, instead of IPSEC-DOI, and the KINK_ISAKMP payload would contain the payloads defined in the GDOI document rather than the payloads used by [IKE] Quick Mode. The version number in the KINK_ISAKMP header is related to the DOI in the KINK header, so a maj.min version 1.0 under DOI GDOI is different from a maj.min version 1.0 under DOI IPSEC-DOI.
KINKのGDOIメッセージを伝えるために、KINKヘッダーのDOI分野は、GDOIがIPSEC-DOIの代わりに使用されているのを示すでしょう、そして、KINK_ISAKMPペイロードは[IKE]迅速なModeによって使用されたペイロードよりむしろGDOIドキュメントで定義されたペイロードを含んでいるでしょう。 KINK_ISAKMPヘッダーのバージョン番号がKINKヘッダーでDOIに関連するので、DOI GDOIの下のmaj.minバージョン1.0はDOI IPSEC-DOIの下のmaj.minバージョン1.0と異なっています。
13. Related Work
13. 関連仕事
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ワーキンググループは層three(すなわち、IP層)で暗号で安全なSAsを作成して、維持する能力を提供する多くのプロトコルを定義しました。 この取り組みは2つの異なったプロトコルを作成しました:
o a mechanism for encrypting and authenticating IP datagram
payloads that assumes a shared secret between the sender and
receiver
o IPデータグラムペイロードを暗号化して、認証するための送付者と受信機の間の共有秘密キーを仮定するメカニズム
o a mechanism for IPsec peers to perform mutual authentication
and exchange keying material
o IPsecのためのメカニズムは、互いの認証と材料を合わせる交換を実行するためにじっと見ます。
The IPsec working group has defined a peer-to-peer authentication and keying mechanism, IKE (RFC 2409). One of the drawbacks of a peer- to-peer protocol is that each peer must know and implement a site's
ピアツーピア認証とメカニズムを合わせるIKE(RFC2409)をIPsecワーキンググループは定義しました。 同輩への同輩プロトコルの欠点の1つは各同輩がサイトのものを知って、実装しなければならないということです。
Sakane, et al. Standards Track [Page 36] RFC 4430 KINK March 2006
Sakane、他 標準化過程[36ページ]RFC4430は2006年3月にねじれます。
security policy, which in practice can be quite complex. In addition, the peer-to-peer nature of IKE requires the use of Diffie- Hellman (DH) to establish a shared secret. DH, unfortunately, is computationally quite expensive and prone to denial of service attacks. IKE also relies on X.509 certificates to realize scalable authentication of peers. Digital signatures are also computationally expensive, and certificate-based trust models are difficult to deploy in practice. While IKE does allow for a pre-shared key, key distribution is required between all peers -- an O(n^2) problem -- which is problematic for large deployments.
安全保障政策。(その安全保障政策は実際にはかなり複雑である場合があります)。 さらに、IKEのピアツーピア自然は、共有秘密キーを証明するためにディフィー・ヘルマン(DH)の使用を必要とします。 残念ながら、DHはサービス不能攻撃に計算上かなり高価であって、傾向があります。 また、IKEは、同輩のスケーラブルな認証がわかるためにX.509証明書を当てにします。 また、デジタル署名も計算上高価です、そして、証明書ベースの信頼モデルは実際には配布するのが難しいです。 IKEがあらかじめ共有されたキーを考慮している間、主要な分配がすべての同輩の間で必要です--O(n^2)問題(大きい展開に問題が多いです)。
14. Acknowledgements
14. 承認
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取り組みに貢献しました。 オリジナルのインスピレーションはCableLabのPacketCable取り組みから来ました、サシャMedvinsky、マイクFroh、マットHur、およびデヴィッド・マグリューを含んでいて。(取り組みはKerberized IPsecの簡易型のバージョンを定義しました)。 完全にIKEフェーズ2を再利用するためのインスピレーションはTero Kivinenのドキュメントが、クィックModeにケルベロス認証を接ぎ木するのを示すという結果です。
15. References
15. 参照
15.1. Normative References
15.1. 引用規格
[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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[IPDOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[IPDOI]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[IPSEC] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J.
Turner, "Internet Security Association and Key
Management Protocol (ISAKMP)", RFC 2408, November 1998.
[ISAKMP] Maughan、D.、Schertler、M.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べます」、RFC2408、1998年11月。
[ISAKMP-REG] IANA, "Internet Security Association and Key Management
Protocol (ISAKMP) Identifiers",
<http://www.iana.org/assignments/isakmp-registry>.
[ISAKMP-レッジ]IANA、「インターネットセキュリティ協会とKey Managementプロトコル(ISAKMP)識別子」、<isakmp http://www.iana.org/課題/登録>。
[KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications
for Kerberos 5", RFC 3961, February 2005.
[KCRYPTO] レイバーンとK.と「暗号化とケルベロス5インチチェックサム仕様、RFC3961、2005年2月。」
Sakane, et al. Standards Track [Page 37] RFC 4430 KINK March 2006
Sakane、他 標準化過程[37ページ]RFC4430は2006年3月にねじれます。
[KERBEROS] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC
4120, July 2005.
[ケルベロス] ヌーマン、C.、ユー、T.、ハートマン、S.、およびK.レイバーン、「ケルベロスネットワーク認証サービス(V5)」、RFC4120 2005年7月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC1964] リン、J.、「ケルベロスバージョン5GSS-APIメカニズム」、RFC1964、1996年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
15.2. Informative References
15.2. 有益な参照
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney,
"The Group Domain of Interpretation", RFC 3547, July
2003.
2003年7月の[GDOI]BaugherとM.とウィスとB.とHardjono、T.とH.ハーニー、「解釈のグループドメイン」RFC3547。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[IKEv2] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[PKINIT] Zhu, L. and B. Tung, "Public Key Cryptography for
Initial Authentication in Kerberos", Work in Progress,
February 2006.
[PKINIT] 「ケルベロスにおける初期の認証のための公開鍵暗号」という朱、L.、およびB.タンは進歩、2006年2月に働いています。
[REQ4KINK] Thomas, M., "Requirements for Kerberized Internet
Negotiation of Keys", RFC 3129, June 2001.
[REQ4KINK] トーマス、M.、「キーのKerberizedインターネット交渉のための要件」、RFC3129、2001年6月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェースバージョン2、アップデート1インチ、RFC2743、2000年1月。」
Sakane, et al. Standards Track [Page 38] RFC 4430 KINK March 2006
Sakane、他 標準化過程[38ページ]RFC4430は2006年3月にねじれます。
Authors' Addresses
作者のアドレス
Shoichi Sakane Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi, Tokyo 180-8750 Japan
Shoichi Sakaneの横川の電気社2-9-32のNakacho、武蔵野市、日本東京180-8750
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
Ken'ichi Kamadaの横川の電気社2-9-32のNakacho、武蔵野市、日本東京180-8750
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の西タスマン・Driveサンノゼ、カリフォルニア 95134
EMail: mat@cisco.com
メール: mat@cisco.com
Jan Vilhuber Cisco Systems 170 West Tasman Drive San Jose, CA 95134
1月のVilhuberシスコシステムズ170の西タスマン・Driveサンノゼ、カリフォルニア 95134
EMail: vilhuber@cisco.com
メール: vilhuber@cisco.com
Sakane, et al. Standards Track [Page 39] RFC 4430 KINK March 2006
Sakane、他 標準化過程[39ページ]RFC4430は2006年3月にねじれます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Sakane, et al. Standards Track [Page 40]
Sakane、他 標準化過程[40ページ]
一覧
スポンサーリンク
