RFC4306 日本語訳
4306 Internet Key Exchange (IKEv2) Protocol. C. Kaufman, Ed.. December 2005. (Format: TXT=250941 bytes) (Obsoletes RFC2407, RFC2408, RFC2409) (Updated by RFC5282) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Kaufman, Ed. Request for Comments: 4306 Microsoft Obsoletes: 2407, 2408, 2409 December 2005 Category: Standards Track
ワーキンググループのC.コーフマン、エドをネットワークでつないでください。コメントのために以下を要求してください。 4306 マイクロソフトは以下を時代遅れにします。 2408、2409 2407、年2005年12月のカテゴリ: 標準化過程
Internet Key Exchange (IKEv2) Protocol
インターネット・キー・エクスチェンジ(IKEv2)プロトコル
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 (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs).
このドキュメントはインターネット・キー・エクスチェンジ(IKE)プロトコルのバージョン2について説明します。 IKEはセキュリティ協会を互いの認証を実行して、設立して、維持するのに使用されるIPsec(SAs)の部品です。
This version of the IKE specification combines the contents of what were previously separate documents, including Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network Address Translation (NAT) Traversal, Legacy authentication, and remote address acquisition.
IKE仕様のこのバージョンは何がインターネットSecurity Association、Key Managementプロトコル(ISAKMP、RFC2408)、IKE(RFC2409)、Interpretation(DOI、RFC2407)のインターネットDomain、Network Address Translation(NAT)縦断、Legacy認証、およびリモートアドレス獲得を含む以前に別々のドキュメントであるかに関するコンテンツを結合します。
Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port.
IKEのバージョン2はバージョン1で共同利用しませんが、それには、一般的の両方のバージョンが同じUDPポートの上で明白に実行できるヘッダー形式が十分あります。
Kaufman Standards Track [Page 1] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[1ページ]RFC4306IKEv2 December 2005
Table of Contents
目次
1. Introduction ....................................................3
1.1. Usage Scenarios ............................................5
1.2. The Initial Exchanges ......................................7
1.3. The CREATE_CHILD_SA Exchange ...............................9
1.4. The INFORMATIONAL Exchange ................................11
1.5. Informational Messages outside of an IKE_SA ...............12
2. IKE Protocol Details and Variations ............................12
2.1. Use of Retransmission Timers ..............................13
2.2. Use of Sequence Numbers for Message ID ....................14
2.3. Window Size for Overlapping Requests ......................14
2.4. State Synchronization and Connection Timeouts .............15
2.5. Version Numbers and Forward Compatibility .................17
2.6. Cookies ...................................................18
2.7. Cryptographic Algorithm Negotiation .......................21
2.8. Rekeying ..................................................22
2.9. Traffic Selector Negotiation ..............................24
2.10. Nonces ...................................................26
2.11. Address and Port Agility .................................26
2.12. Reuse of Diffie-Hellman Exponentials .....................27
2.13. Generating Keying Material ...............................27
2.14. Generating Keying Material for the IKE_SA ................28
2.15. Authentication of the IKE_SA .............................29
2.16. Extensible Authentication Protocol Methods ...............31
2.17. Generating Keying Material for CHILD_SAs .................33
2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA exchange ........34
2.19. Requesting an Internal Address on a Remote Network .......34
2.20. Requesting the Peer's Version ............................35
2.21. Error Handling ...........................................36
2.22. IPComp ...................................................37
2.23. NAT Traversal ............................................38
2.24. Explicit Congestion Notification (ECN) ...................40
3. Header and Payload Formats .....................................41
3.1. The IKE Header ............................................41
3.2. Generic Payload Header ....................................44
3.3. Security Association Payload ..............................46
3.4. Key Exchange Payload ......................................56
3.5. Identification Payloads ...................................56
3.6. Certificate Payload .......................................59
3.7. Certificate Request Payload ...............................61
3.8. Authentication Payload ....................................63
3.9. Nonce Payload .............................................64
3.10. Notify Payload ...........................................64
3.11. Delete Payload ...........................................72
3.12. Vendor ID Payload ........................................73
3.13. Traffic Selector Payload .................................74
3.14. Encrypted Payload ........................................77
1. 序論…3 1.1. 用法シナリオ…5 1.2. 初期の交換…7 1.3. _子供_SA交換を引き起こしてください…9 1.4. 情報の交換…11 1.5. IKE_SAにおける外の情報のMessages…12 2. IKEは詳細と変化について議定書の中で述べます…12 2.1. 再送信タイマーの使用…13 2.2. 一連番号のMessage IDの使用…14 2.3. 要求を重ね合わせるためのウィンドウサイズ…14 2.4. 同期と接続タイムアウトを述べてください…15 2.5. バージョン番号と前進の互換性…17 2.6. クッキー…18 2.7. 暗号アルゴリズム交渉…21 2.8. Rekeyingします…22 2.9. トラフィックセレクタ交渉…24 2.10. 一回だけ…26 2.11. 機敏さを扱って、移植してください…26 2.12. ディフィー-ヘルマンExponentialsの再利用…27 2.13. 材料を合わせながら、生成します。27 2.14. IKE_SAのために材料を合わせながら、生成します。28 2.15. IKE_SAの認証…29 2.16. 拡張認証プロトコルメソッド…31 2.17. 子供_SAsのために材料を合わせながら、生成します。33 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA交換…34 2.19. リモートネットワークに関する内部のアドレスを要求します…34 2.20. 同輩のバージョンを要求します…35 2.21. エラー処理…36 2.22. IPComp…37 2.23. NAT縦断…38 2.24. 明白な混雑通知(電子証券取引ネットワーク)…40 3. ヘッダーと有効搭載量形式…41 3.1. IKEヘッダー…41 3.2. ジェネリック有効搭載量ヘッダー…44 3.3. セキュリティ協会有効搭載量…46 3.4. 主要な交換有効搭載量…56 3.5. 識別有効搭載量…56 3.6. 有効搭載量を証明してください…59 3.7. 要求有効搭載量を証明してください…61 3.8. 認証有効搭載量…63 3.9. 一回だけの有効搭載量…64 3.10. 有効搭載量に通知してください…64 3.11. 有効搭載量を削除してください…72 3.12. ベンダーID有効搭載量…73 3.13. トラフィックセレクタ有効搭載量…74 3.14. 有効搭載量を暗号化します…77
Kaufman Standards Track [Page 2] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[2ページ]RFC4306IKEv2 December 2005
3.15. Configuration Payload ....................................79
3.16. Extensible Authentication Protocol (EAP) Payload .........84
4. Conformance Requirements .......................................85
5. Security Considerations ........................................88
6. IANA Considerations ............................................90
7. Acknowledgements ...............................................91
8. References .....................................................91
8.1. Normative References ......................................91
8.2. Informative References ....................................92
Appendix A: Summary of Changes from IKEv1 .........................96
Appendix B: Diffie-Hellman Groups .................................97
B.1. Group 1 - 768 Bit MODP ....................................97
B.2. Group 2 - 1024 Bit MODP ...................................97
3.15. 構成有効搭載量…79 3.16. 拡張認証プロトコル(EAP)有効搭載量…84 4. 順応要件…85 5. セキュリティ問題…88 6. IANA問題…90 7. 承認…91 8. 参照…91 8.1. 標準の参照…91 8.2. 有益な参照…92 付録A: IKEv1からの変化の概要…96 付録B: ディフィー-ヘルマンは分類します…97 B.1。 1--768ビットのMODPを分類してください…97 B.2。 1024年の2--ビットのMODPを分類してください…97
1. Introduction
1. 序論
IP Security (IPsec) provides confidentiality, data integrity, access control, and data source authentication to IP datagrams. These services are provided by maintaining shared state between the source and the sink of an IP datagram. This state defines, among other things, the specific services provided to the datagram, which cryptographic algorithms will be used to provide the services, and the keys used as input to the cryptographic algorithms.
IP Security(IPsec)は秘密性、データ保全、アクセスコントロール、およびデータ送信端末認証をIPデータグラムに供給します。IPデータグラムのソースと流し台の間の共有された状態を維持することによって、これらのサービスを提供します。 特に、特定のサービスは、この州が、どの暗号アルゴリズムがサービス、および暗号アルゴリズムに入力されるように利用されたキーを提供するのに使用されるかを定義するのをデータグラムに供給しました。
Establishing this shared state in a manual fashion does not scale well. Therefore, a protocol to establish this state dynamically is needed. This memo describes such a protocol -- the Internet Key Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was defined in RFCs 2407, 2408, and 2409 [Pip98, MSST98, HC98]. This single document is intended to replace all three of those RFCs.
この共有された状態を手動のファッションに設置するのはよく比例しません。 したがって、ダイナミックにこの状態を確立するプロトコルが必要です。 このメモはそのようなプロトコルについて説明します--インターネット・キー・エクスチェンジ(IKE)。 これはIKEのバージョン2です。 IKEのバージョン1はRFCs2407、2408年、および2409年[Pip98、MSST98、HC98]に定義されました。 このただ一つのドキュメントがそれらのすべての3RFCsを取り替えることを意図します。
Definitions of the primitive terms in this document (such as Security Association or SA) can be found in [RFC4301].
[RFC4301]でこのドキュメント(Security AssociationかSAなどの)との原始の用語の定義を見つけることができます。
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [Bra97].
キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「」 現れる「5月」は中[Bra97]で説明されるように本書では解釈されることになっているべきです。
The term "Expert Review" is to be interpreted as defined in [RFC2434].
「専門のレビュー」という用語は[RFC2434]で定義されるように解釈されることになっています。
IKE performs mutual authentication between two parties and establishes an IKE security association (SA) that includes shared secret information that can be used to efficiently establish SAs for Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication Header (AH) [RFC4302] and a set of cryptographic algorithms to be used by the SAs to protect the traffic that they carry. In this document, the term "suite" or "cryptographic suite" refers to a
IKEは2回のパーティーの間の互いの認証を実行して、彼らが運ぶというEncapsulating Security有効搭載量(超能力)[RFC4303]、そして/または、Authentication Header(AH)[RFC4302]と暗号アルゴリズムのセットがトラフィックを保護するのにSAsによって使用されるように効率的にSAsを証明するのに使用できる共有秘密キー情報を含んでいるIKEセキュリティ協会(SA)を設立します。 本書では、「スイート」か「暗号のスイート」という用語はaについて言及します。
Kaufman Standards Track [Page 3] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[3ページ]RFC4306IKEv2 December 2005
complete set of algorithms used to protect an SA. An initiator proposes one or more suites by listing supported algorithms that can be combined into suites in a mix-and-match fashion. IKE can also negotiate use of IP Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA. We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get set up through that IKE_SA we call "CHILD_SAs".
完全なセットのアルゴリズムは以前はよくSAを保護していました。 創始者は、ミックスとマッチファッションでスイートに結合できるサポートしているアルゴリズムを記載することによって、1つ以上のスイートを提案します。 また、IKEは超能力、そして/または、AH SAに関してIP Compression(IPComp)[IPCOMP]の使用を交渉できます。 私たちは、IKE SAを「イケ_SA」と呼びます。 そのIKE_SA私たち呼び出し「子供_SAs」を通してセットアップされる超能力、そして/または、AHのためのSAs。
All IKE communications consist of pairs of messages: a request and a response. The pair is called an "exchange". We call the first messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL exchanges. In the common case, there is a single IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four messages) to establish the IKE_SA and the first CHILD_SA. In exceptional cases, there may be more than one of each of these exchanges. In all cases, all IKE_SA_INIT exchanges MUST complete before any other exchange type, then all IKE_AUTH exchanges MUST complete, and following that any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur in any order. In some scenarios, only a single CHILD_SA is needed between the IPsec endpoints, and therefore there would be no additional exchanges. Subsequent exchanges MAY be used to establish additional CHILD_SAs between the same authenticated pair of endpoints and to perform housekeeping functions.
すべてのIKEコミュニケーションが組のメッセージから成ります: 要求と応答。 組は「交換」と呼ばれます。 私たちは、イケ_SA IKE_SA_INITを設立する最初のメッセージ、イケ_AUTH交換、およびその後のIKE交換をSAかINFORMATIONALが交換するCREATE_CHILD_と呼びます。 よくある例には、IKE_SAと最初のCHILD_SAを証明するために、ただ一つのイケ_SA_INIT交換とただ一つのイケ_AUTH交換(合計4つのメッセージ)があります。 例外的な場合には、それぞれのこれらの交換の1つ以上があるかもしれません。 すべての場合では、いかなる他のもタイプを交換して、次に、すべてがAUTH交換が完成しなければならないイケ_であり、それに続くのがCREATE_CHILD_SAのどんな数ともINFORMATIONAL交換になる前にINIT交換が完成しなければならないすべてのイケ_SA_が順不同に現れるかもしれません。 いくつかのシナリオでは、独身のCHILD_SAだけがIPsec終点の間で必要です、そして、したがって、どんな追加交換もないでしょう。 その後の交換は、同じ認証された組の終点の間の追加CHILD_SAsを証明して、ハウスキーピング機能を実行するのに使用されるかもしれません。
IKE message flow always consists of a request followed by a response. It is the responsibility of the requester to ensure reliability. If the response is not received within a timeout interval, the requester needs to retransmit the request (or abandon the connection).
IKEメッセージ流動は応答があとに続いた要求からいつも成ります。 信頼性を確実にするのは、リクエスタの責任です。 応答がタイムアウト間隔以内に受けられないなら、リクエスタは、要求を再送する必要があります(接続を捨ててください)。
The first request/response of an IKE session (IKE_SA_INIT) negotiates security parameters for the IKE_SA, sends nonces, and sends Diffie- Hellman values.
IKEセッション(イケ_SA_INIT)の最初の要求/応答は、IKE_SAのためのセキュリティパラメタを交渉して、一回だけを送って、ヘルマン値をディフィーに送ります。
The second request/response (IKE_AUTH) transmits identities, proves knowledge of the secrets corresponding to the two identities, and sets up an SA for the first (and often only) AH and/or ESP CHILD_SA.
2番目の要求/応答(イケ_AUTH)は、アイデンティティを伝えて、2つのアイデンティティに対応する秘密に関する知識を立証して、1番目と(しばしば唯一)のAH、そして/または、ESP CHILD_SAのためにSAをセットアップします。
The types of subsequent exchanges are CREATE_CHILD_SA (which creates a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error conditions, or does other housekeeping). Every request requires a response. An INFORMATIONAL request with no payloads (other than the empty Encrypted payload required by the syntax) is commonly used as a check for liveness. These subsequent exchanges cannot be used until the initial exchanges have completed.
その後の交換のタイプは、CREATE_CHILD_SA(CHILD_SAを作成する)とINFORMATIONAL(SAを削除するか、エラー条件を報告するか、または他の家事をする)です。 あらゆる要求が応答を必要とします。 ペイロード(構文によって必要とされた空のEncryptedペイロードを除いた)のないINFORMATIONAL要求は活性にチェックとして一般的に使用されます。 交換が完成した初期までこれらのその後の交換を使用できません。
Kaufman Standards Track [Page 4] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[4ページ]RFC4306IKEv2 December 2005
In the description that follows, we assume that no errors occur. Modifications to the flow should errors occur are described in section 2.21.
続く記述では、私たちは、誤りが全く発生しないと思います。 流れように、誤りは発生するべきです。変更、セクション2.21で、説明されます。
1.1. Usage Scenarios
1.1. 用法シナリオ
IKE is expected to be used to negotiate ESP and/or AH SAs in a number of different scenarios, each with its own special requirements.
多くの異なったシナリオで超能力、そして/または、AH SAsを交渉するのにIKEが使用されると予想されます、それぞれそれ自身の特別な要件で。
1.1.1. Security Gateway to Security Gateway Tunnel
1.1.1. セキュリティゲートウェイトンネルへのセキュリティゲートウェイ
+-+-+-+-+-+ +-+-+-+-+-+
! ! IPsec ! !
Protected !Tunnel ! tunnel !Tunnel ! Protected
Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet
! ! ! !
+-+-+-+-+-+ +-+-+-+-+-+
++++++++++++! IPsec!、Protected!Tunnel!トンネル!Tunnel!Protected Subnet<-->!Endpoint!、<。---------->!終点!<-->サブネット!++++++++++++
Figure 1: Security Gateway to Security Gateway Tunnel
図1: セキュリティゲートウェイトンネルへのセキュリティゲートウェイ
In this scenario, neither endpoint of the IP connection implements IPsec, but network nodes between them protect traffic for part of the way. Protection is transparent to the endpoints, and depends on ordinary routing to send packets through the tunnel endpoints for processing. Each endpoint would announce the set of addresses "behind" it, and packets would be sent in tunnel mode where the inner IP header would contain the IP addresses of the actual endpoints.
このシナリオでは、IP接続のどちらの終点もIPsecを実装しませんが、それらの間のネットワーク・ノードは方法の一部にトラフィックを保護します。 保護は、処理のためにトンネル終点を通してパケットを送るために終点に透明であり、普通のルーティングによります。 各終点は、それ、およびパケットがそうするアドレス“behind"のセットが内側のIPヘッダーが実際の終点のIPアドレスを含むトンネルモードで送られると発表するでしょう。
1.1.2. Endpoint-to-Endpoint Transport
1.1.2. 終点から終点への輸送
+-+-+-+-+-+ +-+-+-+-+-+
! ! IPsec transport ! !
!Protected! or tunnel mode SA !Protected!
!Endpoint !<---------------------------------------->!Endpoint !
! ! ! !
+-+-+-+-+-+ +-+-+-+-+-+
++++++++++++! IPsecはProtected!かトンネルモードSA!Protected!を輸送します! 終点!<。---------------------------------------->!終点!++++++++++++
Figure 2: Endpoint to Endpoint
図2: 終点への終点
In this scenario, both endpoints of the IP connection implement IPsec, as required of hosts in [RFC4301]. Transport mode will commonly be used with no inner IP header. If there is an inner IP header, the inner addresses will be the same as the outer addresses. A single pair of addresses will be negotiated for packets to be protected by this SA. These endpoints MAY implement application layer access controls based on the IPsec authenticated identities of the participants. This scenario enables the end-to-end security that has been a guiding principle for the Internet since [RFC1958],
このシナリオでは、IP接続の両方の終点は必要に応じて[RFC4301]でホストにIPsecを実装します。 交通機関は内側のIPヘッダーなしで一般的に使用されるでしょう。 内側のIPヘッダーがあると、内側のアドレスは外側のアドレスと同じになるでしょう。 パケットがこのSAによって保護されるように、1組のアドレスは交渉されるでしょう。 これらの終点はIPsecに基づいたアクセス制御が認証した応用層に関係者のアイデンティティを実装するかもしれません。 このシナリオは終わりから終わりへの以来インターネットへの指導原理であるセキュリティ[RFC1958]を可能にします。
Kaufman Standards Track [Page 5] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[5ページ]RFC4306IKEv2 December 2005
[RFC2775], and a method of limiting the inherent problems with complexity in networks noted by [RFC3439]. Although this scenario may not be fully applicable to the IPv4 Internet, it has been deployed successfully in specific scenarios within intranets using IKEv1. It should be more broadly enabled during the transition to IPv6 and with the adoption of IKEv2.
[RFC2775]、および[RFC3439]によって注意されたネットワークが複雑さに関する固有の問題を制限するメソッド。 このシナリオは完全にIPv4インターネットに適切であるかもしれないというわけではありませんが、それは、イントラネットの中で特定のシナリオでIKEv1を使用することで首尾よく配布されました。 それは変遷の間、IPv6とIKEv2の採用で、より広く可能にされるべきです。
It is possible in this scenario that one or both of the protected endpoints will be behind a network address translation (NAT) node, in which case the tunneled packets will have to be UDP encapsulated so that port numbers in the UDP headers can be used to identify individual endpoints "behind" the NAT (see section 2.23).
UDPになるようにトンネルを堀られたパケットにはどのケースがネットワークアドレス変換(NAT)ノードの後ろに保護された終点の1か両方があるこのシナリオ、あるかで、NATが個々の終点“behind"を特定するのにUDPヘッダーのポートナンバーを使用できるように要約されていたのは(セクション2.23を見てください)、可能です。
1.1.3. Endpoint to Security Gateway Tunnel
1.1.3. セキュリティゲートウェイトンネルへの終点
+-+-+-+-+-+ +-+-+-+-+-+
! ! IPsec ! ! Protected
!Protected! tunnel !Tunnel ! Subnet
!Endpoint !<------------------------>!Endpoint !<--- and/or
! ! ! ! Internet
+-+-+-+-+-+ +-+-+-+-+-+
++++++++++++! IPsec!、Protected!Protected!トンネル!Tunnel!Subnet!Endpoint!<。------------------------>!終点!<。--- そして/または、インターネット++++++++++++
Figure 3: Endpoint to Security Gateway Tunnel
図3: セキュリティゲートウェイトンネルへの終点
In this scenario, a protected endpoint (typically a portable roaming computer) connects back to its corporate network through an IPsec- protected tunnel. It might use this tunnel only to access information on the corporate network, or it might tunnel all of its traffic back through the corporate network in order to take advantage of protection provided by a corporate firewall against Internet-based attacks. In either case, the protected endpoint will want an IP address associated with the security gateway so that packets returned to it will go to the security gateway and be tunneled back. This IP address may be static or may be dynamically allocated by the security gateway. In support of the latter case, IKEv2 includes a mechanism for the initiator to request an IP address owned by the security gateway for use for the duration of its SA.
このシナリオでは、保護された終点(通常携帯用のローミングコンピュータ)はIPsecの保護されたトンネルを通って企業ネットワークに接続して戻ります。 それがこのトンネルを使用するかもしれませんが、企業ネットワークの情報にアクセスするか、またはそれは、法人のファイアウォールによってインターネットを利用する攻撃に対して提供された保護を利用するために企業ネットワークを通した交通のすべてにトンネルを堀るかもしれません。 どちらの場合ではも、保護された終点は、それに返されたパケットがセキュリティゲートウェイに行って、トンネルを堀り返されるように、IPアドレスにセキュリティゲートウェイに関連していて欲しくなるでしょう。 このIPアドレスを静的であるかもしれないか、またはセキュリティゲートウェイはダイナミックに割り当てるかもしれません。 後者のケースを支持して、創始者がSAの持続時間の使用のためにセキュリティゲートウェイによって所有されていたIPアドレスを要求するように、IKEv2はメカニズムを含んでいます。
In this scenario, packets will use tunnel mode. On each packet from the protected endpoint, the outer IP header will contain the source IP address associated with its current location (i.e., the address that will get traffic routed to the endpoint directly), while the inner IP header will contain the source IP address assigned by the security gateway (i.e., the address that will get traffic routed to the security gateway for forwarding to the endpoint). The outer destination address will always be that of the security gateway, while the inner destination address will be the ultimate destination for the packet.
このシナリオでは、パケットはトンネルモードを使用するでしょう。 保護された終点からの各パケットの上では、外側のIPヘッダーは現在の位置(すなわち、直接交通を終点に発送するアドレス)に関連しているソースIPアドレスを含むでしょう、内側のIPヘッダーがアドレスがセキュリティゲートウェイ(すなわち、推進のためにセキュリティゲートウェイに終点に交通を発送するアドレス)で割り当てたソースIPを含むでしょうが。 外側の送付先アドレスはいつもセキュリティゲートウェイのものになるでしょう、内側の送付先アドレスがパケットのために最終仕向地になるでしょうが。
Kaufman Standards Track [Page 6] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[6ページ]RFC4306IKEv2 December 2005
In this scenario, it is possible that the protected endpoint will be behind a NAT. In that case, the IP address as seen by the security gateway will not be the same as the IP address sent by the protected endpoint, and packets will have to be UDP encapsulated in order to be routed properly.
このシナリオでは、NATの後ろに保護された終点があるのは、可能です。 その場合、セキュリティゲートウェイによって見られるIPアドレスはアドレスが保護された終点のそばで送って、パケットがUDPになるように持っているIPが適切に発送されるために要約されたのと同じにならないでしょう。
1.1.4. Other Scenarios
1.1.4. 他のシナリオ
Other scenarios are possible, as are nested combinations of the above. One notable example combines aspects of 1.1.1 and 1.1.3. A subnet may make all external accesses through a remote security gateway using an IPsec tunnel, where the addresses on the subnet are routed to the security gateway by the rest of the Internet. An example would be someone's home network being virtually on the Internet with static IP addresses even though connectivity is provided by an ISP that assigns a single dynamically assigned IP address to the user's security gateway (where the static IP addresses and an IPsec relay are provided by a third party located elsewhere).
他のシナリオは入れ子にされた組み合わせのように上記で可能です。 そして、1つの注目に値する例が1.1の局面を結合する、.1、1.1 .3。 サブネットは、リモートセキュリティゲートウェイを通してIPsecトンネル(サブネットに関するアドレスはインターネットの残りでセキュリティゲートウェイに発送される)を使用することですべての外部のアクセスをするかもしれません。 例はだれかの接続性が静的IPアドレスがあるインターネットですが、それがISPでユーザのセキュリティゲートウェイ(静的IPアドレスとIPsecリレーがほかの場所に位置した第三者によって提供されるところ)にダイナミックに割り当てられたただ一つのIPアドレスを割り当てるなら実際にはオンなホームネットワークです。
1.2. The Initial Exchanges
1.2. 初期の交換
Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH exchanges (known in IKEv1 as Phase 1). These initial exchanges normally consist of four messages, though in some scenarios that number can grow. All communications using IKE consist of request/response pairs. We'll describe the base exchange first, followed by variations. The first pair of messages (IKE_SA_INIT) negotiate cryptographic algorithms, exchange nonces, and do a Diffie-Hellman exchange [DH].
IKEを使用するコミュニケーションがいつもイケ_SA_INITとイケ_AUTH交換(IKEv1では、Phase1として知られている)で始まります。 その数はいくつかのシナリオで成長できますが、通常、これらの初期の交換は4つのメッセージから成ります。 IKEを使用するすべてのコミュニケーションが要求/応答組から成ります。 変化があとに続いて、私たちは最初に、塩基置換について説明するつもりです。 メッセージ(イケ_SA_INIT)の最初の組は、暗号アルゴリズムを交渉して、一回だけを交換して、ディフィー-ヘルマンの交換[DH]をします。
The second pair of messages (IKE_AUTH) authenticate the previous messages, exchange identities and certificates, and establish the first CHILD_SA. Parts of these messages are encrypted and integrity protected with keys established through the IKE_SA_INIT exchange, so the identities are hidden from eavesdroppers and all fields in all the messages are authenticated.
メッセージ(イケ_AUTH)の2番目の組は、前のメッセージ、交換のアイデンティティ、および証明書を認証して、最初のCHILD_SAを設立します。 これらのメッセージの部分はコード化されています、そして、キーがイケ_SA_INIT交換を通して設立されている状態で、保全は保護されました、そして、したがって、立ち聞きする者アイデンティティを隠されます、そして、すべてのメッセージのすべての分野が認証されます。
In the following descriptions, the payloads contained in the message are indicated by names as listed below.
以下の記述では、メッセージに含まれたペイロードは以下に記載されているように名前によって示されます。
Notation Payload
記法有効搭載量
AUTH Authentication CERT Certificate CERTREQ Certificate Request CP Configuration D Delete E Encrypted
AUTH認証本命証明書CERTREQ証明書要求CP構成Dはコード化されていた状態でEを削除します。
Kaufman Standards Track [Page 7] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[7ページ]RFC4306IKEv2 December 2005
EAP Extensible Authentication HDR IKE Header IDi Identification - Initiator IDr Identification - Responder KE Key Exchange Ni, Nr Nonce N Notify SA Security Association TSi Traffic Selector - Initiator TSr Traffic Selector - Responder V Vendor ID
EAPの広げることができる認証HDR IKEヘッダーIDi識別--創始者IDr識別--応答者のKEの主要な交換Ni、Nr一回だけNはSAセキュリティ協会TSi交通セレクタ--創始者TSr交通セレクタ--応答者V業者IDに通知します。
The details of the contents of each payload are described in section 3. Payloads that may optionally appear will be shown in brackets, such as [CERTREQ], indicate that optionally a certificate request payload can be included.
それぞれのペイロードのコンテンツの詳細はセクション3で説明されます。 任意に現れるかもしれない有効搭載量は括弧に示されるでしょう、[CERTREQ]などのように任意に、証明書要求ペイロードを含むことができるのを示してください。
The initial exchanges are as follows:
初期の交換は以下の通りです:
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
創始者応答者----------- ----------- HDR、SAi1、KEi、Ni-->。
HDR contains the Security Parameter Indexes (SPIs), version numbers, and flags of various sorts. The SAi1 payload states the cryptographic algorithms the initiator supports for the IKE_SA. The KE payload sends the initiator's Diffie-Hellman value. Ni is the initiator's nonce.
HDRは様々な種類のSecurity Parameter Indexes(SPIs)、バージョン番号、および旗を含んでいます。 SAi1ペイロードは創始者がIKE_SAのために支持する暗号アルゴリズムを述べます。 KEペイロードは創始者のディフィー-ヘルマン値を送ります。 Niは創始者の一回だけです。
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
<--HDR、SAr1、KEr、Nr[CERTREQ]
The responder chooses a cryptographic suite from the initiator's offered choices and expresses that choice in the SAr1 payload, completes the Diffie-Hellman exchange with the KEr payload, and sends its nonce in the Nr payload.
応答者は、創始者の提供された選択から暗号のスイートを選んで、SAr1ペイロードでその選択を言い表して、KErペイロードでディフィー-ヘルマンの交換を終了して、Nrペイロードで一回だけを送ります。
At this point in the negotiation, each party can generate SKEYSEED,
from which all keys are derived for that IKE_SA. All but the headers
of all the messages that follow are encrypted and integrity
protected. The keys used for the encryption and integrity protection
are derived from SKEYSEED and are known as SK_e (encryption) and SK_a
(authentication, a.k.a. integrity protection). A separate SK_e and
SK_a is computed for each direction. In addition to the keys SK_e
and SK_a derived from the DH value for protection of the IKE_SA,
another quantity SK_d is derived and used for derivation of further
keying material for CHILD_SAs. The notation SK { ... } indicates
that these payloads are encrypted and integrity protected using that
direction's SK_e and SK_a.
ここに、交渉では、各当事者はSKEYSEEDを発生させることができます。(すべてのキーがそのIKE_SAのためにSKEYSEEDから引き出されます)。 従うすべてのメッセージのヘッダーを除いた皆はコード化されていました、そして、保全は保護されました。 暗号化と保全保護に使用されるキーは、SKEYSEEDから得られて、SK_e(暗号化)とSK(認証、通称保全保護)として知られています。 別々のSK_eとSKは各指示のために計算されます。 IKE_SAの保護のためにDH値から得られたキーのSK_eとSKに加えて、別の量のSKはCHILD_SAsのためのさらなる合わせることの材料の派生に引き出されて、使用されます。 その指示のSK_eとSKを使用する…が示すコード化されたこれらのペイロードと保全が保護した記法SK。
Kaufman Standards Track [Page 8] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[8ページ]RFC4306IKEv2 December 2005
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr} -->
HDR、SK、IDi、AUTH、SAi2、TSi、[本命][CERTREQ][IDr]TSr--、>。
The initiator asserts its identity with the IDi payload, proves knowledge of the secret corresponding to IDi and integrity protects the contents of the first message using the AUTH payload (see section 2.15). It might also send its certificate(s) in CERT payload(s) and a list of its trust anchors in CERTREQ payload(s). If any CERT payloads are included, the first certificate provided MUST contain the public key used to verify the AUTH field. The optional payload IDr enables the initiator to specify which of the responder's identities it wants to talk to. This is useful when the machine on which the responder is running is hosting multiple identities at the same IP address. The initiator begins negotiation of a CHILD_SA using the SAi2 payload. The final fields (starting with SAi2) are described in the description of the CREATE_CHILD_SA exchange.
創始者は、IDiペイロードでアイデンティティについて断言して、IDiに対応する秘密に関する知識を立証します、そして、保全はAUTHペイロードを使用することで最初のメッセージのコンテンツを保護します(セクション2.15を見てください)。 また、それはCERTペイロードの証明書とCERTREQペイロードの信用アンカーのリストを送るかもしれません。 どれかCERTペイロードが含まれているなら、提供された最初の証明書はAUTH分野について確かめるのに使用される公開鍵を含まなければなりません。 任意のペイロードIDrは、創始者が、それが応答者のアイデンティティのどれと話したがっているかを指定するのを可能にします。 応答者が走っているマシンが同じIPアドレスの複数のアイデンティティを接待しているとき、これは役に立ちます。 創始者は、SAi2ペイロードを使用することでCHILD_SAの交渉を始めます。 最終的な分野(SAi2から始まる)はCREATE_CHILD_SA交換の記述で説明されます。
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
<--HDR、SKIDr、AUTH、SAr2、TSi、[本命]TSr
The responder asserts its identity with the IDr payload, optionally sends one or more certificates (again with the certificate containing the public key used to verify AUTH listed first), authenticates its identity and protects the integrity of the second message with the AUTH payload, and completes negotiation of a CHILD_SA with the additional fields described below in the CREATE_CHILD_SA exchange.
応答者は、IDrペイロードでアイデンティティについて断言して、AUTHペイロードで任意に、1通以上の証明書(再び証明書が最初に記載されたAUTHについて確かめるのに使用される公開鍵を含んでいる)を送って、アイデンティティを認証して、2番目のメッセージの保全を保護して、追加分野が以下でCREATE_CHILD_SA交換で説明されている状態で、CHILD_SAの交渉を終了します。
The recipients of messages 3 and 4 MUST verify that all signatures and MACs are computed correctly and that the names in the ID payloads correspond to the keys used to generate the AUTH payload.
メッセージ3と4の受取人はすべての署名とMACsが正しく計算されて、IDペイロードの名前がAUTHペイロードを発生させるのに使用されるキーに対応することを確かめなければなりません。
1.3. The CREATE_CHILD_SA Exchange
1.3. _子供_SA交換を引き起こしてください。
This exchange consists of a single request/response pair, and was referred to as a phase 2 exchange in IKEv1. It MAY be initiated by either end of the IKE_SA after the initial exchanges are completed.
この交換は1要求/応答組、およびIKEv1のフェーズと呼ばれた2交換から成ります。 初期の交換が終了した後にそれはIKE_SAのどちらの端までにも開始されるかもしれません。
All messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the first two messages of the IKE exchange. These subsequent messages use the syntax of the Encrypted Payload described in section 3.14. All subsequent messages included an Encrypted Payload, even if they are referred to in the text as "empty".
初期の交換に続くすべてのメッセージが、IKE交換に関する最初の2つのメッセージで交渉された暗号アルゴリズムとキーを使用することで暗号で保護されます。 これらのその後のメッセージはセクション3.14で説明されたEncrypted有効搭載量の構文を使用します。 それらがテキストに「空になってください」と呼ばれても、すべてのその後のメッセージがEncrypted有効搭載量を含んでいました。
Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this section the term "initiator" refers to the endpoint initiating this exchange.
どちらの終点もCREATE_CHILD_SA交換を起こすかもしれないので、このセクションで、「創始者」という用語はこの交換を起こす終点について言及します。
Kaufman Standards Track [Page 9] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[9ページ]RFC4306IKEv2 December 2005
A CHILD_SA is created by sending a CREATE_CHILD_SA request. The CREATE_CHILD_SA request MAY optionally contain a KE payload for an additional Diffie-Hellman exchange to enable stronger guarantees of forward secrecy for the CHILD_SA. The keying material for the CHILD_SA is a function of SK_d established during the establishment of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA exchange, and the Diffie-Hellman value (if KE payloads are included in the CREATE_CHILD_SA exchange).
CHILD_SAは、SAが要求するCREATE_CHILD_を送ることによって、作成されます。 SAが要求するCREATE_CHILD_は任意に追加ディフィー-ヘルマンの交換がCHILD_SAのために前進の秘密主義の、より強い保証を可能にするKEペイロードを含むかもしれません。 CHILD_SAのための合わせることの材料はSA、CREATE_CHILD_SA交換の間に交換された一回だけ、およびディフィー-ヘルマンが評価するIKE_の設立の間に設立されたSKの機能(KEペイロードがCREATE_CHILD_SA交換に含まれているなら)です。
In the CHILD_SA created as part of the initial exchange, a second KE payload and nonce MUST NOT be sent. The nonces from the initial exchange are used in computing the keys for the CHILD_SA.
初期の交換の一部として作成されたCHILD_SAでは、2番目のKEペイロードと一回だけを送ってはいけません。 初期の交換からの一回だけはCHILD_SAのためにキーを計算する際に使用されます。
The CREATE_CHILD_SA request contains:
SAが要求するCREATE_CHILD_は以下を含んでいます。
Initiator Responder
----------- -----------
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} -->
創始者応答者----------- ----------- HDR、SK、[N]、SA、Ni、[KEi][TSi、TSr]--、>。
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni payload, optionally a Diffie-Hellman value in the KEi payload, and the proposed traffic selectors in the TSi and TSr payloads. If this CREATE_CHILD_SA exchange is rekeying an existing SA other than the IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an existing SA, the N payload MUST be omitted. If the SA offers include different Diffie-Hellman groups, KEi MUST be an element of the group the initiator expects the responder to accept. If it guesses wrong, the CREATE_CHILD_SA exchange will fail, and it will have to retry with a different KEi.
創始者はSAペイロード、Niペイロードの一回だけで任意に申し出をSAに送ります。KEiペイロードのディフィー-ヘルマン値、およびTSiとTSrペイロードの提案された交通セレクタ。 このCREATE_CHILD_SA交換がIKE_SA以外の既存のSAを「再-合わせ」ているなら、タイプREKEY_SA MUSTの主なNペイロードは「再-合わせ」られるSAを特定します。 このCREATE_CHILD_SA交換が既存のSAを「再-合わせ」ていないなら、Nペイロードを省略しなければなりません。 SA申し出が異なったディフィー-ヘルマングループを含んでいるなら、KEiは受け入れる創始者が応答者を予想するグループの要素であるに違いありません。 勘違いすると、CREATE_CHILD_SA交換は失敗するでしょう、そして、それは異なったKEiと共に再試行されなければならないでしょう。
The message following the header is encrypted and the message including the header is integrity protected using the cryptographic algorithms negotiated for the IKE_SA.
ヘッダーに続くメッセージはコード化されています、そして、ヘッダーを含むメッセージはIKE_SAのために交渉された暗号アルゴリズムを使用することで保護された保全です。
The CREATE_CHILD_SA response contains:
CREATE_CHILD_SA応答は以下を含んでいます。
<-- HDR, SK {SA, Nr, [KEr],
[TSi, TSr]}
<--HDR、SKSA、Nr、[KEr][TSi、TSr]
The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the selected cryptographic suite includes that group. If the responder chooses a cryptographic suite with a different group, it MUST reject the request. The initiator SHOULD repeat the request, but now with a KEi payload from the group the responder selected.
応答者はSAペイロードにおける受け入れられた申し出で返答します、そして、(応じるのに同じMessage IDを使用します)KEiが要求と選択された暗号のスイートに含まれていたなら、KErペイロードのディフィー-ヘルマン値はそのグループを含んでいます。 応答者が異なったグループがある暗号のスイートを選ぶなら、それは要求を拒絶しなければなりません。 要求を繰り返しますが、創始者SHOULDは現在、応答者が選択したグループからのKEiペイロードでそうします。
Kaufman Standards Track [Page 10] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[10ページ]RFC4306IKEv2 December 2005
The traffic selectors for traffic to be sent on that SA are specified in the TS payloads, which may be a subset of what the initiator of the CHILD_SA proposed. Traffic selectors are omitted if this CREATE_CHILD_SA request is being used to change the key of the IKE_SA.
そのSAに送られる交通のための交通セレクタはTSペイロードで指定されます。(ペイロードはCHILD_SAの創始者が提案したことに関する部分集合であるかもしれません)。 CHILD_SAが要求するこのCREATE_がIKE_SAのキーを変えるのに使用されているなら、交通セレクタは省略されます。
1.4. The INFORMATIONAL Exchange
1.4. 情報の交換
At various points during the operation of an IKE_SA, peers may desire to convey control messages to each other regarding errors or notifications of certain events. To accomplish this, IKE defines an INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur after the initial exchanges and are cryptographically protected with the negotiated keys.
IKE_SAの操作の間の様々なポイントでは、同輩は、ある出来事の誤りか通知に関してコントロールメッセージを互いに伝えることを望むかもしれません。 これを達成するために、IKEはINFORMATIONAL交換を定義します。 INFORMATIONAL交換は、初期の交換の後に起こるだけでよくて、交渉されたキーで暗号で保護されます。
Control messages that pertain to an IKE_SA MUST be sent under that IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent under the protection of the IKE_SA which generated them (or its successor if the IKE_SA was replaced for the purpose of rekeying).
送られた下がそのIKE_SAであったならイケ_SA MUSTに関係するメッセージを制御してください。 彼らを発生させたIKE_SAの保護でCHILD_SAsに関係するコントロールメッセージを送らなければなりません(IKE_SAであるなら「再-合わせ」る目的のために後継者を取り替えました)。
Messages in an INFORMATIONAL exchange contain zero or more Notification, Delete, and Configuration payloads. The Recipient of an INFORMATIONAL exchange request MUST send some response (else the Sender will assume the message was lost in the network and will retransmit it). That response MAY be a message with no payloads. The request message in an INFORMATIONAL exchange MAY also contain no payloads. This is the expected way an endpoint can ask the other endpoint to verify that it is alive.
INFORMATIONAL交換におけるメッセージはゼロか、より多くのNotification、Delete、およびConfigurationペイロードを含んでいます。 INFORMATIONAL交換要求のRecipientは何らかの応答を送らなければなりません(ほかに、Senderは、メッセージがネットワークで失われて、それを再送すると仮定するでしょう)。 その応答はペイロードがなければメッセージであるかもしれません。 また、INFORMATIONAL交換における要求メッセージはペイロードを全く含まないかもしれません。 これは終点が、それが生きていることを確かめるようにもう片方の終点に頼むことができる予想された方法です。
ESP and AH SAs always exist in pairs, with one SA in each direction. When an SA is closed, both members of the pair MUST be closed. When SAs are nested, as when data (and IP headers if in tunnel mode) are encapsulated first with IPComp, then with ESP, and finally with AH between the same pair of endpoints, all of the SAs MUST be deleted together. Each endpoint MUST close its incoming SAs and allow the other endpoint to close the other SA in each pair. To delete an SA, an INFORMATIONAL exchange with one or more delete payloads is sent listing the SPIs (as they would be expected in the headers of inbound packets) of the SAs to be deleted. The recipient MUST close the designated SAs. Normally, the reply in the INFORMATIONAL exchange will contain delete payloads for the paired SAs going in the other direction. There is one exception. If by chance both ends of a set of SAs independently decide to close them, each may send a delete payload and the two requests may cross in the network. If a node receives a delete request for SAs for which it has already issued a delete request, it MUST delete the outgoing SAs while processing the request and the incoming SAs while processing the response. In that
超能力とAH SAsは1SAと共に各方向にいつも対になって存在しています。 SAが閉じられるとき、組の両方のメンバーは閉店しなければなりません。 データ(中なら、IPヘッダーはモードにトンネルを堀る)は最初にIPCompと共に要約されます、そして、超能力で時と、最終的なAHが間にどんな終点でも同じでなくSAsが入れ子にされるとき、SAsのすべてを一緒に削除しなければなりません。 各終点は、入って来るSAsを閉じて、もう片方の終点が各組でもう片方のSAを閉じるのを許容しなければなりません。 1以上でSA、INFORMATIONAL交換を削除するために、ペイロードを削除してください。削除されるために、SAsのSPIs(彼らが本国行きのパケットのヘッダーで予想されるように)を記載させます。 受取人は指定されたSAsを閉じなければなりません。 通常、交換が含むINFORMATIONALでの回答はもう片方の指示を調べる対にされたSAsのためにペイロードを削除します。 1つの例外があります。 SAsの1セットの両端が、彼らを閉じると独自に決めて、それぞれがaを送るかもしれないという機会で、ペイロードを削除してください。そうすれば、2つの要求がネットワークで交差してもよいなら。 ノードがaを受けるなら、応答を処理する既にどれを発行したかためにaが要求を削除して、それが要求を処理している間、出発しているSAsを削除しなければならないか、そして、入って来るSAsがゆったり過ごすSAsを求める要求を削除してください。 それで
Kaufman Standards Track [Page 11] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[11ページ]RFC4306IKEv2 December 2005
case, the responses MUST NOT include delete payloads for the deleted SAs, since that would result in duplicate deletion and could in theory delete the wrong SA.
ケース、応答はそうしてはいけません。インクルードは削除されたSAsのためにペイロードを削除します、それが写し削除をもたらして、理論上間違ったSAを削除するかもしれないので。
A node SHOULD regard half-closed connections as anomalous and audit their existence should they persist. Note that this specification nowhere specifies time periods, so it is up to individual endpoints to decide how long to wait. A node MAY refuse to accept incoming data on half-closed connections but MUST NOT unilaterally close them and reuse the SPIs. If connection state becomes sufficiently messed up, a node MAY close the IKE_SA; doing so will implicitly close all SAs negotiated under it. It can then rebuild the SAs it needs on a clean base under a new IKE_SA.
彼らが固執するなら、ノードSHOULDは半開きな接続が変則的であるとみなして、彼らの存在を監査します。 それに注意してください、この仕様は、待つためにどれくらい長い間、どこにも期間、決めるのが個々の終点に上がっているそうを指定するか。 ノードは、半開きな接続に関する受信データを受け入れるのを拒否するかもしれませんが、一方的に彼らを閉じて、SPIsを再利用してはいけません。 接続状態が十分台無しにされるようになるなら、ノードはIKE_SAを閉じるかもしれません。 そうするのはそれとなくそれの下で交渉されたすべてのSAsを閉じるでしょう。 そして、それは新しいIKE_SAの下のきれいなベースの上で必要とするSAsを再建できます。
The INFORMATIONAL exchange is defined as:
INFORMATIONAL交換は以下と定義されます。
Initiator Responder
----------- -----------
HDR, SK {[N,] [D,] [CP,] ...} -->
<-- HDR, SK {[N,] [D,] [CP], ...}
創始者応答者----------- ----------- HDR、SK、[N][D][CP]… --><--HDR、SK[N][D][CP]、…
The processing of an INFORMATIONAL exchange is determined by its component payloads.
コンポーネントペイロードに従って、INFORMATIONAL交換の処理は決定しています。
1.5. Informational Messages outside of an IKE_SA
1.5. IKE_SAにおける外の情報のMessages
If an encrypted IKE packet arrives on port 500 or 4500 with an unrecognized SPI, it could be because the receiving node has recently crashed and lost state or because of some other system malfunction or attack. If the receiving node has an active IKE_SA to the IP address from whence the packet came, it MAY send a notification of the wayward packet over that IKE_SA in an INFORMATIONAL exchange. If it does not have such an IKE_SA, it MAY send an Informational message without cryptographic protection to the source IP address. Such a message is not part of an informational exchange, and the receiving node MUST NOT respond to it. Doing so could cause a message loop.
コード化されたIKEパケットが認識されていないSPIと共に500か4500のポートの上で到着するならそれは受信ノードが最近状態を墜落して、失ったためかある他のシステム異常か攻撃からであるかもしれません。 受信ノードがアクティブなIKE_SAを起源からのIPアドレスに持っているなら、パケットは来て、それはINFORMATIONAL交換でそのIKE_SAの上に強情なパケットの通知を送るかもしれません。 そのようなIKE_SAを持っていないなら、それは暗号の保護なしでソースIPアドレスにInformationalメッセージを送るかもしれません。 そのようなメッセージは情報の交換の一部ではありません、そして、受信ノードはそれに応じてはいけません。 そうするのはメッセージ輪を引き起こす場合がありました。
2. IKE Protocol Details and Variations
2. IKEプロトコルの詳細と変化
IKE normally listens and sends on UDP port 500, though IKE messages may also be received on UDP port 4500 with a slightly different format (see section 2.23). Since UDP is a datagram (unreliable) protocol, IKE includes in its definition recovery from transmission errors, including packet loss, packet replay, and packet forgery. IKE is designed to function so long as (1) at least one of a series of retransmitted packets reaches its destination before timing out; and (2) the channel is not so full of forged and replayed packets so
IKEは、通常、聴いて、UDPが500を移植するのを転送します、また、UDPポート4500の上にわずかに異なった形式でIKEメッセージを受け取るかもしれませんが(セクション2.23を見てください)。 UDPがデータグラムの(頼り無い)のプロトコルであるので、IKEは定義回復に伝送エラーからパケット損失を含んでいるパケット再生、およびパケット偽造を含んでいます。 IKEは(1) 少なくとも一連の再送されたパケットの1つがタイミングの前の目的地を前に伸ばす限り、機能するように設計されています。 (2) そして、したがって、チャンネルは偽造していて再演されたパケットでそれほどいっぱいではありません。
Kaufman Standards Track [Page 12] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[12ページ]RFC4306IKEv2 December 2005
as to exhaust the network or CPU capacities of either endpoint. Even in the absence of those minimum performance requirements, IKE is designed to fail cleanly (as though the network were broken).
どちらかの終点の排気に関するネットワークかCPU能力。 それらの最小の性能要件がないときでさえ、IKEは、清潔に失敗するように設計されています(まるでネットワークが壊れているかのように)。
Although IKEv2 messages are intended to be short, they contain structures with no hard upper bound on size (in particular, X.509 certificates), and IKEv2 itself does not have a mechanism for fragmenting large messages. IP defines a mechanism for fragmentation of oversize UDP messages, but implementations vary in the maximum message size supported. Furthermore, use of IP fragmentation opens an implementation to denial of service attacks [KPS03]. Finally, some NAT and/or firewall implementations may block IP fragments.
IKEv2メッセージは簡単に言えば意図しますが、サイズ(特にX.509証明書)に困難な上限なしで構造を含んでいます、そして、IKEv2自身には、大きいメッセージを断片化するためのメカニズムがありません。 IPは特大のUDPメッセージの断片化のためにメカニズムを定義しますが、実現はサイズが支持した最大のメッセージで異なります。 その上、IP断片化の使用はサービス不能攻撃[KPS03]に実現を開きます。 最終的に、いくつかのNAT、そして/または、ファイアウォール実現はIP断片を妨げるかもしれません。
All IKEv2 implementations MUST be able to send, receive, and process IKE messages that are up to 1280 bytes long, and they SHOULD be able to send, receive, and process messages that are up to 3000 bytes long. IKEv2 implementations SHOULD be aware of the maximum UDP message size supported and MAY shorten messages by leaving out some certificates or cryptographic suite proposals if that will keep messages below the maximum. Use of the "Hash and URL" formats rather than including certificates in exchanges where possible can avoid most problems. Implementations and configuration should keep in mind, however, that if the URL lookups are possible only after the IPsec SA is established, recursion issues could prevent this technique from working.
すべてのIKEv2実現が、最大1280バイト長と、それらであるIKEメッセージを、送って、受け取って、処理できなければなりません。SHOULDは発信できて、受信します、そして、3000年のバイト長まで達しているメッセージを処理してください。 それが最大より下でメッセージを保つなら、IKEv2実現SHOULDは、サイズが支持した最大のUDPメッセージを意識していて、いくつかの証明書か暗号のスイート提案を置くことによって、メッセージを短くするかもしれません。 可能であるところに交換に証明書を含んでいるよりむしろ「細切れ肉料理とURL」形式の使用はほとんどの問題を避けることができます。しかしながら、実現と構成は、IPsec SAが設立された後にだけURLルックアップが可能であるなら、再帰問題が、このテクニックが働くのを防ぐかもしれないのを覚えておくべきです。
2.1. Use of Retransmission Timers
2.1. 再送信タイマーの使用
All messages in IKE exist in pairs: a request and a response. The setup of an IKE_SA normally consists of two request/response pairs. Once the IKE_SA is set up, either end of the security association may initiate requests at any time, and there can be many requests and responses "in flight" at any given moment. But each message is labeled as either a request or a response, and for each request/response pair one end of the security association is the initiator and the other is the responder.
IKEのすべてのメッセージが対になって存在しています: 要求と応答。 通常、IKE_SAのセットアップは2要求/応答組から成ります。 一度、IKE_SAはセットアップされます、そして、セキュリティ協会のどちらの終わりもいつでも要求を開始するかもしれません、そして、「飛行」における多くの要求と応答がいつなんどきでもあることができます。 しかし、各メッセージは要求か応答のどちらかとしてラベルされます、そして、それぞれの要求/応答組において、セキュリティ協会の片端は創始者です、そして、もう片方が応答者です。
For every pair of IKE messages, the initiator is responsible for retransmission in the event of a timeout. The responder MUST never retransmit a response unless it receives a retransmission of the request. In that event, the responder MUST ignore the retransmitted request except insofar as it triggers a retransmission of the response. The initiator MUST remember each request until it receives the corresponding response. The responder MUST remember each response until it receives a request whose sequence number is larger than the sequence number in the response plus its window size (see section 2.3).
すべての組のIKEメッセージにおいて、創始者はタイムアウトの場合、「再-トランスミッション」に責任があります。 要求の「再-トランスミッション」を受けない場合、応答者は応答を決して再送してはいけません。 その場合には、応答の「再-トランスミッション」の引き金となる限り、応答者は再送された要求を無視しなければなりません。 それが対応する応答を受けるまで、創始者は各要求を覚えていなければなりません。 それが一連番号が応答における一連番号とそのウィンドウサイズより大きい要求を受け取るまで(セクション2.3を見てください)、応答者は各応答を覚えていなければなりません。
Kaufman Standards Track [Page 13] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[13ページ]RFC4306IKEv2 December 2005
IKE is a reliable protocol, in the sense that the initiator MUST retransmit a request until either it receives a corresponding reply OR it deems the IKE security association to have failed and it discards all state associated with the IKE_SA and any CHILD_SAs negotiated using that IKE_SA.
IKEは信頼できるプロトコルです、創始者が失敗したIKEセキュリティ協会であると考える対応する回答ORを受けて、そのIKE_SAを使用することで交渉されるIKE_SAとどんなCHILD_SAsにも関連しているすべての状態を捨てるまで要求を再送しなければならないという意味で。
2.2. Use of Sequence Numbers for Message ID
2.2. 一連番号のMessage IDの使用
Every IKE message contains a Message ID as part of its fixed header. This Message ID is used to match up requests and responses, and to identify retransmissions of messages.
あらゆるIKEメッセージが固定ヘッダーの一部としてMessage IDを含んでいます。 このMessage IDは、要求と応答を合わせて、メッセージの「再-トランスミッション」を特定するのに使用されます。
The Message ID is a 32-bit quantity, which is zero for the first IKE request in each direction. The IKE_SA initial setup messages will always be numbered 0 and 1. Each endpoint in the IKE Security Association maintains two "current" Message IDs: the next one to be used for a request it initiates and the next one it expects to see in a request from the other end. These counters increment as requests are generated and received. Responses always contain the same message ID as the corresponding request. That means that after the initial exchange, each integer n may appear as the message ID in four distinct messages: the nth request from the original IKE initiator, the corresponding response, the nth request from the original IKE responder, and the corresponding response. If the two ends make very different numbers of requests, the Message IDs in the two directions can be very different. There is no ambiguity in the messages, however, because the (I)nitiator and (R)esponse bits in the message header specify which of the four messages a particular one is.
Message IDは32ビットの量です。(その量はIKEが各方向に要求する1番目のためのゼロです)。 IKE_SAの初期のセットアップメッセージは、いつも番号付の0と1になるでしょう。 IKE Security Associationの各終点は2「電流」Message IDを維持します: 次のそれが開始する要求に使用されるべきものとそれが要求でもう一方の端から見ると予想する次のもの。 カウンタが要求として増加するこれらを発生して、受け取ります。 応答はいつも対応する要求と同じメッセージIDを含んでいます。 それは、初期の交換の後に各整数nが4つの異なったメッセージのメッセージIDとして現れるかもしれないことを意味します: オリジナルのIKE創始者、対応する応答、オリジナルのIKE応答者からのn番目の要求、および対応する応答からのn番目の要求。 2つの終わりが非常に異なった数の要求をするなら、2つの方向へのMessage IDは非常に異なっている場合があります。 メッセージヘッダーの(I)nitiatorと(R)esponseビットが、特定のものが4つのメッセージのどれであるかを指定するので、しかしながら、メッセージにはあいまいさが全くありません。
Note that Message IDs are cryptographically protected and provide protection against message replays. In the unlikely event that Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be closed. Rekeying an IKE_SA resets the sequence numbers.
Message IDが暗号で保護されて、メッセージ再生に対する保護を提供することに注意してください。 Message IDが32ビット、イケ_SA MUSTで合うように大きくならせ過ぎるありそうもない出来事では、閉じられてください。 IKE_SAをRekeyingすると、一連番号はリセットされます。
2.3. Window Size for Overlapping Requests
2.3. 要求を重ね合わせるためのウィンドウサイズ
In order to maximize IKE throughput, an IKE endpoint MAY issue multiple requests before getting a response to any of them if the other endpoint has indicated its ability to handle such requests. For simplicity, an IKE implementation MAY choose to process requests strictly in order and/or wait for a response to one request before issuing another. Certain rules must be followed to ensure interoperability between implementations using different strategies.
IKEスループットを最大にするために、もう片方の終点がそのような要求を扱う性能を示したなら、IKE終点は返事をもらう前のそれらのどれかへの複数の要求を出すかもしれません。 簡単さのために、IKE実現は、厳密に整然とした状態で要求を処理する、そして/または、別のものを発行する前に1つの要求への応答を待つのを選ぶかもしれません。 異なった戦略を使用することで実現の間の相互運用性を確実にするためにある規則に従わなければなりません。
After an IKE_SA is set up, either end can initiate one or more requests. These requests may pass one another over the network. An IKE endpoint MUST be prepared to accept and process a request while
IKE_SAがセットアップされた後に、どちらの終わりも1つ以上の要求を開始できます。 これらの要求はネットワークの上にお互いを通過するかもしれません。 受け入れるように終点を準備しなければならないIKEと要求がゆったり過ごす過程
Kaufman Standards Track [Page 14] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[14ページ]RFC4306IKEv2 December 2005
it has a request outstanding in order to avoid a deadlock in this situation. An IKE endpoint SHOULD be prepared to accept and process multiple requests while it has a request outstanding.
それには、未払いの要求が、この状況における行き詰まりを避けるためにあります。 IKE終点SHOULDは受け入れるように準備されて、複数の要求を処理します。要求を傑出するようにしますが。
An IKE endpoint MUST wait for a response to each of its messages before sending a subsequent message unless it has received a SET_WINDOW_SIZE Notify message from its peer informing it that the peer is prepared to maintain state for multiple outstanding messages in order to allow greater throughput.
それが同輩が、より大きいスループットを許容して、複数の傑出しているメッセージのために状態を維持する用意ができていることをそれに知らせる同輩からSET_WINDOW_SIZE Notifyメッセージを受け取っていない場合その後のメッセージを送る前に、IKE終点はそれぞれに関するメッセージへの応答を待たなければなりません。
An IKE endpoint MUST NOT exceed the peer's stated window size for transmitted IKE requests. In other words, if the responder stated its window size is N, then when the initiator needs to make a request X, it MUST wait until it has received responses to all requests up through request X-N. An IKE endpoint MUST keep a copy of (or be able to regenerate exactly) each request it has sent until it receives the corresponding response. An IKE endpoint MUST keep a copy of (or be able to regenerate exactly) the number of previous responses equal to its declared window size in case its response was lost and the initiator requests its retransmission by retransmitting the request.
IKE終点は伝えられたIKE要求のために同輩の述べられたウィンドウサイズを超えてはいけません。 言い換えれば、応答者が、ウィンドウサイズがNであると述べたなら、創始者が、要求をXにする必要があると、それは要求X-Nを通してすべての要求への応答を受けるまで待たなければなりません。 対応する応答を受けるまで、IKE終点はそれが送ったそれぞれの(まさに作り直すことができてください)要求の写しを取っておかなければなりません。 応答が失われて、創始者が要求を再送することによって「再-トランスミッション」を要求するといけないので、IKE終点は前の応答の(まさに作り直すことができてください)番号の写しを宣言しているウィンドウサイズと等しく取っておかなければなりません。
An IKE endpoint supporting a window size greater than one SHOULD be capable of processing incoming requests out of order to maximize performance in the event of network failures or packet reordering.
処理入来ができた状態で1SHOULDよりすばらしいウィンドウサイズを支持するIKE終点はネットワーク失敗の場合、性能を最大にするために故障するかパケット再命令を要求します。
2.4. State Synchronization and Connection Timeouts
2.4. 州の同期と接続タイムアウト
An IKE endpoint is allowed to forget all of its state associated with an IKE_SA and the collection of corresponding CHILD_SAs at any time. This is the anticipated behavior in the event of an endpoint crash and restart. It is important when an endpoint either fails or reinitializes its state that the other endpoint detect those conditions and not continue to waste network bandwidth by sending packets over discarded SAs and having them fall into a black hole.
IKE終点はいつでも、IKE_SAに関連している状態と対応するCHILD_SAsの収集のすべてを忘れることができます。 終点クラッシュと再開の場合、これは予期された振舞いです。 終点が状態を失敗するか、または再初期化するとき、もう片方の終点が、それらの状態を検出して、捨てられたSAsの上にパケットを送って、彼らをブラックホールに落ちさせることによってネットワーク回線容量を浪費し続けていないのは、重要です。
Since IKE is designed to operate in spite of Denial of Service (DoS) attacks from the network, an endpoint MUST NOT conclude that the other endpoint has failed based on any routing information (e.g., ICMP messages) or IKE messages that arrive without cryptographic protection (e.g., Notify messages complaining about unknown SPIs). An endpoint MUST conclude that the other endpoint has failed only when repeated attempts to contact it have gone unanswered for a timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE_SA to the same authenticated identity. An endpoint SHOULD suspect that the other endpoint has failed based on routing information and initiate a request to see whether the other endpoint is alive. To check whether the other side is alive, IKE specifies an empty INFORMATIONAL message
IKEがサービス妨害(DoS)攻撃にもかかわらず、ネットワークから作動するように設計されているので、終点は、もう片方の終点が暗号の保護(例えば未知のSPIsの周りで不平を言うNotifyメッセージ)なしで到着するどんなルーティング情報(例えば、ICMPメッセージ)やIKEメッセージに基づいて失敗したと結論を下してはいけません。 終点は、それに連絡する繰り返された試みがタイムアウト時間か異なったIKE_SAに暗号で保護されたINITIAL_CONTACT通知を同じ認証されたアイデンティティに受け取る時答えがなくなったのにだけ、もう片方の終点が失敗したと結論を下さなければなりません。 もう片方の終点が生きているかどうかわかるというもう片方の終点が失敗した終点のSHOULD容疑者の要求はルーティング情報と開始に基づいていました。 反対側が生きているかどうかチェックするために、IKEは空のINFORMATIONALメッセージを指定します。
Kaufman Standards Track [Page 15] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[15ページ]RFC4306IKEv2 December 2005
that (like all IKE requests) requires an acknowledgement (note that within the context of an IKE_SA, an "empty" message consists of an IKE header followed by an Encrypted payload that contains no payloads). If a cryptographically protected message has been received from the other side recently, unprotected notifications MAY be ignored. Implementations MUST limit the rate at which they take actions based on unprotected messages.
それ(すべてのIKE要求のような)は承認を必要とします(IKE_SAの文脈の中では、「空」のメッセージがペイロードを全く含まないEncryptedペイロードが支えたIKEヘッダーから成ることに注意してください)。 最近反対側から暗号で保護されたメッセージを受け取ったなら、保護のない通知を無視するかもしれません。 実現はそれらが保護のないメッセージに基づいて行動を取るレートを制限しなければなりません。
Numbers of retries and lengths of timeouts are not covered in this specification because they do not affect interoperability. It is suggested that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up on an SA, but different environments may require different rules. To be a good network citizen, retranmission times MUST increase exponentially to avoid flooding the network and making an existing congestion situation worse. If there has only been outgoing traffic on all of the SAs associated with an IKE_SA, it is essential to confirm liveness of the other endpoint to avoid black holes. If no cryptographically protected messages have been received on an IKE_SA or any of its CHILD_SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. Receipt of a fresh cryptographically protected message on an IKE_SA or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its CHILD_SAs. Note that this places requirements on the failure modes of an IKE endpoint. An implementation MUST NOT continue sending on any SA if some failure prevents it from receiving on all of the associated SAs. If CHILD_SAs can fail independently from one another without the associated IKE_SA being able to send a delete message, then they MUST be negotiated by separate IKE_SAs.
相互運用性に影響しないので、再試行の数とタイムアウトの長さはこの仕様で含まれていません。 メッセージが再送されて、SAの、しかし、異なった環境に見切りをつける少なくとも数分前の期間の少なくとも12回が異なった規則を必要とするかもしれないということであると示唆されます。 良いネットワーク国民であるなら、retranmission回は、ネットワークをあふれさせて、既存の混雑状況をより悪くするのを避けるために指数関数的に増加しなければなりません。 外向的な交通がIKE_SAに関連しているSAsのすべてに単にあったなら、ブラックホールを避けるためにもう片方の終点の活性を確認するのは不可欠です。 最近IKE_SAかいずれにもCHILD_SAsについて暗号で保護されたメッセージを全く受け取っていないなら、システムは、死んでいる同輩にメッセージを送るのを防ぐために活性チェックを実行する必要があります。 IKE_SAかCHILD_SAsのどれかに関する新鮮な暗号で保護されたメッセージの領収書はIKE_SAの活性とCHILD_SAsのすべてを確実にします。 これがIKE終点の故障モードに要件を置くことに注意してください。 実現は、何らかの失敗が、それが関連SAsのすべてで受信されるのを防ぐならどんなSAも転送し続けてはいけません。 SAsがお互いからaを送ることができる関連IKE_SAなしで独自に失敗できるCHILD_がメッセージを削除するなら、別々のIKE_SAsは彼らを交渉しなければなりません。
There is a Denial of Service attack on the initiator of an IKE_SA that can be avoided if the initiator takes the proper care. Since the first two messages of an SA setup are not cryptographically protected, an attacker could respond to the initiator's message before the genuine responder and poison the connection setup attempt. To prevent this, the initiator MAY be willing to accept multiple responses to its first message, treat each as potentially legitimate, respond to it, and then discard all the invalid half-open connections when it receives a valid cryptographically protected response to any one of its requests. Once a cryptographically valid response is received, all subsequent responses should be ignored whether or not they are cryptographically valid.
創始者が適切な注意を払うなら避けることができるIKE_SAの創始者の上にサービス妨害攻撃があります。 SAセットアップに関する最初の2つのメッセージが暗号で保護されないので、攻撃者は、本物の応答者の前で創始者のメッセージに応じて、接続設定試みに毒を入れることができました。 要求のどれかへの有効な暗号で保護された応答を受けるとき、これを防ぐために、創始者は、最初のメッセージへの複数の応答を受け入れる、潜在的に正統であるとしてそれぞれを扱い、それに応じる、次に、すべての無効の半開きな接続を捨てても構わないと思っているかもしれません。 暗号で、有効回答が受け取られている、それらが暗号で無視されるか否かに関係なく、すべてのその後の応答が無視されるべきです。一度a、有効です。
Note that with these rules, there is no reason to negotiate and agree upon an SA lifetime. If IKE presumes the partner is dead, based on repeated lack of acknowledgement to an IKE message, then the IKE SA and all CHILD_SAs set up through that IKE_SA are deleted.
これらの規則で、SA生涯を交渉して、同意する理由が全くないことに注意してください。 IKEが、パートナーが承認の繰り返された不足に基づいてIKEメッセージに死んでいると推定するなら、そのIKE_SAを通してセットアップされたIKE SAとすべてのCHILD_SAsが削除されます。
Kaufman Standards Track [Page 16] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[16ページ]RFC4306IKEv2 December 2005
An IKE endpoint may at any time delete inactive CHILD_SAs to recover resources used to hold their state. If an IKE endpoint chooses to delete CHILD_SAs, it MUST send Delete payloads to the other end notifying it of the deletion. It MAY similarly time out the IKE_SA. Closing the IKE_SA implicitly closes all associated CHILD_SAs. In this case, an IKE endpoint SHOULD send a Delete payload indicating that it has closed the IKE_SA.
IKE終点は、彼らの状態を保持するために運用資金を回復するためにいつでも不活発なCHILD_SAsを削除するかもしれません。 IKE終点が、CHILD_SAsを削除するのを選ぶなら、それは削除についてそれに通知するもう一方の端までペイロードをDeleteに送らなければなりません。 同様にそうするかもしれない、タイムアウト、IKE_SA。 それとなくIKE_SAを閉じると、すべての関連CHILD_SAsが閉じます。 この場合SHOULDがIKE_SAを閉じたのを示すDeleteペイロードを送るIKE終点。
2.5. Version Numbers and Forward Compatibility
2.5. バージョン番号と下位互換
This document describes version 2.0 of IKE, meaning the major version number is 2 and the minor version number is zero. It is likely that some implementations will want to support both version 1.0 and version 2.0, and in the future, other versions.
このドキュメントはIKEのバージョン2.0について説明します、メジャーバージョン番号が2であり、マイナーバージョン番号がゼロであることを意味して。 いくつかの実装が2.0、および将来的で、他のバージョンのバージョン1.0とバージョンの両方をサポートしたくなりそうでしょう。
The major version number should be incremented only if the packet formats or required actions have changed so dramatically that an older version node would not be able to interoperate with a newer version node if it simply ignored the fields it did not understand and took the actions specified in the older specification. The minor version number indicates new capabilities, and MUST be ignored by a node with a smaller minor version number, but used for informational purposes by the node with the larger minor version number. For example, it might indicate the ability to process a newly defined notification message. The node with the larger minor version number would simply note that its correspondent would not be able to understand that message and therefore would not send it.
パケット・フォーマットか必要な動作が、それが単に分野を無視したかどうかを旧式のバージョンノードが、より新しいバージョンノードで共同利用できないくらいの劇的に変えたので、分からないで、より古い仕様で指定された行動を取る場合にだけ、メジャーバージョン番号は増加されるでしょうに。 マイナーバージョン番号を新しい能力を示して、よりわずかなマイナーバージョン番号があるノードによって無視されますが、情報の目的により大きいマイナーバージョン番号があるノードで使用しなければなりません。 例えば、それは新たに定義された通知メッセージを処理する能力を示すかもしれません。 より大きいマイナーバージョン番号があるノードは、通信員がそのメッセージを理解できないで、したがって、それを送らないことに単に注意するでしょう。
If an endpoint receives a message with a higher major version number, it MUST drop the message and SHOULD send an unauthenticated notification message containing the highest version number it supports. If an endpoint supports major version n, and major version m, it MUST support all versions between n and m. If it receives a message with a major version that it supports, it MUST respond with that version number. In order to prevent two nodes from being tricked into corresponding with a lower major version number than the maximum that they both support, IKE has a flag that indicates that the node is capable of speaking a higher major version number.
終点が、より高いメジャーバージョン番号でメッセージを受け取るなら、それはメッセージを下げなければなりません、そして、SHOULDは含む中でサポートする中でバージョン番号最も大きい非認証された通知メッセージを送ります。 終点が主要なバージョンn、および主要なバージョンmをサポートするなら、それはnとmの間のすべてのバージョンをサポートしなければなりません。 それがサポートする主要なバージョンでメッセージを受け取るなら、それはそのバージョン番号で応じなければなりません。 2つのノードがそれらの両方がサポートする最大より低メジャーバージョン番号に対応するようにだまされるのを防ぐために、IKEにはノードが、より高いメジャーバージョン番号を話すことができるのを示す旗があります。
Thus, the major version number in the IKE header indicates the version number of the message, not the highest version number that the transmitter supports. If the initiator is capable of speaking versions n, n+1, and n+2, and the responder is capable of speaking versions n and n+1, then they will negotiate speaking n+1, where the initiator will set the flag indicating its ability to speak a higher version. If they mistakenly (perhaps through an active attacker
したがって、IKEヘッダーのメジャーバージョン番号は送信機がサポートする中で最も大きいバージョン番号ではなく、メッセージのバージョン番号を示します。 創始者がバージョンn、n+1、およびn+2を話すことができて、応答者がバージョンnとn+1を話すことができると、それらは話すn+1を交渉するでしょう。そこでは、創始者が、旗が、より高いバージョンを話す性能を示すように設定するでしょう。 それらである、誤る、(恐らく活発な攻撃者
Kaufman Standards Track [Page 17] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[17ページ]RFC4306IKEv2 December 2005
sending error messages) negotiate to version n, then both will notice that the other side can support a higher version number, and they MUST break the connection and reconnect using version n+1.
送付エラーメッセージ) 次に、+1にバージョンnを使用することでともにバージョンnと交渉して、反対側が、より大きいバージョン番号をサポートできて、彼らが電話を切らなければならないのに気付いて、再接続するでしょう。
Note that IKEv1 does not follow these rules, because there is no way in v1 of noting that you are capable of speaking a higher version number. So an active attacker can trick two v2-capable nodes into speaking v1. When a v2-capable node negotiates down to v1, it SHOULD note that fact in its logs.
IKEv1がこれらの規則に従わないことに注意してください、道が全くあなたが、より大きいバージョン番号を話すことができることに注意するv1にないので。 それで、活発な攻撃者は、2つのv2できるノードがv1を話すようにだますことができます。 v2できるノードがいつ交渉するかはv1にダウンして、それはSHOULD注意です。ログのその事実。
Also for forward compatibility, all fields marked RESERVED MUST be
set to zero by a version 2.0 implementation and their content MUST be
ignored by a version 2.0 implementation ("Be conservative in what you
send and liberal in what you receive"). In this way, future versions
of the protocol can use those fields in a way that is guaranteed to
be ignored by implementations that do not understand them.
Similarly, payload types that are not defined are reserved for future
use; implementations of version 2.0 MUST skip over those payloads and
ignore their contents.
下位互換においても、分野が、RESERVED MUSTであるとマークしたのが、バージョン2.0実装でゼロにセットすることであり、バージョン2.0実装でそれらの内容を無視しなければなりません(「あなたが送るもので保守的であって、あなたが受けるもので寛容であってください」)。 このように、プロトコルの将来のバージョンはそれらを理解していない実装によって無視されるために保証される方法でそれらの分野を使用できます。 同様に、定義されないペイロードタイプは今後の使用のために予約されます。 バージョン2.0の実装は、それらのペイロードを飛ばして、それらのコンテンツを無視しなければなりません。
IKEv2 adds a "critical" flag to each payload header for further flexibility for forward compatibility. If the critical flag is set and the payload type is unrecognized, the message MUST be rejected and the response to the IKE request containing that payload MUST include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an unsupported critical payload was included. If the critical flag is not set and the payload type is unsupported, that payload MUST be ignored.
IKEv2は下位互換のためのさらなる柔軟性のために「重要な」旗をそれぞれのペイロードヘッダーに加えます。 重要な旗が設定されて、ペイロードタイプが認識されていないなら、メッセージを拒絶しなければなりません、そして、そのペイロードを含むIKE要求への応答はNotifyペイロードUNSUPPORTED_CRITICAL_有効搭載量を含まなければなりません、サポートされない重要なペイロードが含まれていたのを示して。 重要な旗が設定されないで、ペイロードタイプがサポートされないなら、そのペイロードを無視しなければなりません。
Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations MUST send the payloads defined in this specification in the order shown in the figures in section 2 and implementations SHOULD reject as invalid a message with those payloads in any other order.
新しいペイロードタイプは、将来、加えられて、分野がこの仕様に基づき定義されている状態で、はさみ込まれるように見えるかもしれませんが、実装は数字にセクション2で示されたオーダーにおけるこの仕様に基づき定義されたペイロードを送らなければなりません、そして、実装SHOULDはいかなる他のオーダーにおけるそれらのペイロードでも同じくらい無効のメッセージを拒絶します。
2.6. Cookies
2.6. クッキー
The term "cookies" originates with Karn and Simpson [RFC2522] in Photuris, an early proposal for key management with IPsec, and it has persisted. The Internet Security Association and Key Management Protocol (ISAKMP) [MSST98] fixed message header includes two eight- octet fields titled "cookies", and that syntax is used by both IKEv1 and IKEv2 though in IKEv2 they are referred to as the IKE SPI and there is a new separate field in a Notify payload holding the cookie. The initial two eight-octet fields in the header are used as a connection identifier at the beginning of IKE packets. Each endpoint
「クッキー」という用語はKarnの発案です、そして、Photuris、IPsecとのかぎ管理に、早めの提案、およびそれのシンプソン[RFC2522]は固執しました。 その構文は、クッキーを持ちながら、NotifyペイロードでインターネットSecurity AssociationとKey Managementプロトコル(ISAKMP)[MSST98]の固定メッセージヘッダーは「クッキー」と題をつけられた2つの8八重奏分野を入れて、IKEv2では、それらはIKE SPIと呼ばれます、そして、新しい別々の分野がありますが、IKEv1とIKEv2の両方によって使用されます。 ヘッダーの2つの初期の8八重奏の分野がIKEパケットの始めに接続識別子として使用されます。 各終点
Kaufman Standards Track [Page 18] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[18ページ]RFC4306IKEv2 December 2005
chooses one of the two SPIs and SHOULD choose them so as to be unique identifiers of an IKE_SA. An SPI value of zero is special and indicates that the remote SPI value is not yet known by the sender.
SPIsとSHOULDがIKE_SAのユニークな識別子になるように彼らを選ぶ2つのものの1つを選びます。 ゼロのSPI値は、特別であり、リモートSPI値が送付者によってまだ知られていないのを示します。
Unlike ESP and AH where only the recipient's SPI appears in the header of a message, in IKE the sender's SPI is also sent in every message. Since the SPI chosen by the original initiator of the IKE_SA is always sent first, an endpoint with multiple IKE_SAs open that wants to find the appropriate IKE_SA using the SPI it assigned must look at the I(nitiator) Flag bit in the header to determine whether it assigned the first or the second eight octets.
また、受取人のSPIだけがメッセージのヘッダー、IKEに現れる超能力とAHと異なって、あらゆるメッセージで送付者のSPIを送ります。 最初にいつもIKE_SAのオリジナルの創始者によって選ばれたSPIを送るので、適切なIKE_がSAであることがそれが割り当てたSPIを使用することでわかりたがっている開いている複数のIKE_SAsがある終点はそれが1番目か2番目の8つの八重奏を割り当てたかどうか決定するためにヘッダーでI(nitiator)フラグビットを見なければなりません。
In the first message of an initial IKE exchange, the initiator will not know the responder's SPI value and will therefore set that field to zero.
初期のIKE交換の最初のメッセージでは、創始者は、応答者のSPI値を知らないで、したがって、その分野をゼロに設定するでしょう。
An expected attack against IKE is state and CPU exhaustion, where the target is flooded with session initiation requests from forged IP addresses. This attack can be made less effective if an implementation of a responder uses minimal CPU and commits no state to an SA until it knows the initiator can receive packets at the address from which it claims to be sending them. To accomplish this, a responder SHOULD -- when it detects a large number of half-open IKE_SAs -- reject initial IKE messages unless they contain a Notify payload of type COOKIE. It SHOULD instead send an unprotected IKE message as a response and include COOKIE Notify payload with the cookie data to be returned. Initiators who receive such responses MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE containing the responder supplied cookie data as the first payload and all other payloads unchanged. The initial exchange will then be as follows:
IKEに対する予想された攻撃は、状態とCPU疲労困憊です、偽造IPアドレスからのセッション開始要求が目標に殺到するところで。 創始者がそれがそれらを送ると主張するアドレスでパケットを受けることができるのを知るまで、応答者の実装が最小量のCPUを使用して、状態を全くSAに遂行しないならそれほどこの攻撃を有効にすることができません。 応答者SHOULD--多くの半開きなIKE_SAsを検出するときの--これを達成するには、タイプCOOKIEのNotifyペイロードを含まないなら、初期のIKEメッセージを拒絶してください。 それ、SHOULDは代わりに応答として保護のないIKEメッセージを送って、返されるクッキーデータでCOOKIE Notifyペイロードを含んでいます。 そのような応答を受ける創始者は変わりがない状態でタイプCOOKIEのNotifyペイロードが応答者を含んでいるINITが最初のペイロードと他のすべてのペイロードとしてクッキーデータを提供したイケ_SA_を再試行しなければなりません。 初期の交換はその時、以下の通りになるでしょう:
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
創始者応答者----------- ----------- HDR(A、0)、SAi1、KEi、Ni-->。
<-- HDR(A,0), N(COOKIE)
<--HDR(A、0)、N(クッキー)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
HDR(A、0)、N(クッキー)、SAi1、KEi、Ni-->。
<-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ]
<--HDR(A、B)、SAr1、KEr、Nr[CERTREQ]
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr} -->
HDR(A、B)、SK、IDi、AUTH、SAi2、TSi、[本命][CERTREQ][IDr]TSr--、>。
<-- HDR(A,B), SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
<--HDR(A、B)、SKIDr、AUTH、SAr2、TSi、[本命]TSr
Kaufman Standards Track [Page 19] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[19ページ]RFC4306IKEv2 December 2005
The first two messages do not affect any initiator or responder state except for communicating the cookie. In particular, the message sequence numbers in the first four messages will all be zero and the message sequence numbers in the last two messages will be one. 'A' is the SPI assigned by the initiator, while 'B' is the SPI assigned by the responder.
最初の2つのメッセージはクッキーを伝える以外の少しの創始者や応答者状態にも影響しません。 特に、最初の4つのメッセージのメッセージ通番はすべてゼロになるでしょう、そして、最後の2つのメッセージのメッセージ通番は1になるでしょう。 ''SPIは'Bである間、創始者によって割り当てられます'は応答者によって割り当てられたSPIです。
An IKE implementation SHOULD implement its responder cookie generation in such a way as to not require any saved state to recognize its valid cookie when the second IKE_SA_INIT message arrives. The exact algorithms and syntax they use to generate cookies do not affect interoperability and hence are not specified here. The following is an example of how an endpoint could use cookies to implement limited DOS protection.
2番目のイケ_SA_INITメッセージが到着するとき、SHOULDが応答者クッキー世代をいずれも必要としないほどそのような方法で実装するIKE実装は、有効なクッキーを認識するために状態を節約しました。 それらがクッキーを生成するのに使用する正確なアルゴリズムと構文は、相互運用性に影響しないで、またしたがって、ここで指定されません。 ↓これは終点が限られたDOSが防護物であると実装するのにどうクッキーを使用するかもしれないかに関する例です。
A good way to do this is to set the responder cookie to be:
これをする早道は応答者クッキーにである:設定することです。
Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
クッキー=<VersionIDofSecret>。| ハッシュ(Ni|IPi|SPIi| <の秘密の>)
where <secret> is a randomly generated secret known only to the responder and periodically changed and | indicates concatenation. <VersionIDofSecret> should be changed whenever <secret> is regenerated. The cookie can be recomputed when the IKE_SA_INIT arrives the second time and compared to the cookie in the received message. If it matches, the responder knows that the cookie was generated since the last change to <secret> and that IPi must be the same as the source address it saw the first time. Incorporating SPIi into the calculation ensures that if multiple IKE_SAs are being set up in parallel they will all get different cookies (assuming the initiator chooses unique SPIi's). Incorporating Ni into the hash ensures that an attacker who sees only message 2 can't successfully forge a message 3.
そして<の秘密の>が応答者だけにおいて知られて、定期的に変えられた手当たりしだいに発生している秘密である。| 連結を示します。 <の秘密の>が作り直されるときはいつも、<VersionIDofSecret>を変えるべきです。 クッキーをイケ_SA_INITが2回目に到着すると再計算して、受信されたメッセージでクッキーと比較できます。 合っているなら、応答者は、<の秘密の>とそのIPiへの最後の変化がそれが1回目に見たソースアドレスと同じであるに違いないのでクッキーが生成されたのを知っています。 SPIiを計算に組み入れるのは、複数のIKE_SAsが平行にセットアップされていると彼らが皆、異なったクッキーを手に入れるのを確実にします(創始者を仮定すると、ユニークなSPIiのものは選ばれます)。 Niをハッシュに組み入れるのは、メッセージ2だけを見る攻撃者が首尾よくメッセージ3を作り出すことができないのを確実にします。
If a new value for <secret> is chosen while there are connections in the process of being initialized, an IKE_SA_INIT might be returned with other than the current <VersionIDofSecret>. The responder in that case MAY reject the message by sending another response with a new cookie or it MAY keep the old value of <secret> around for a short time and accept cookies computed from either one. The responder SHOULD NOT accept cookies indefinitely after <secret> is changed, since that would defeat part of the denial of service protection. The responder SHOULD change the value of <secret> frequently, especially if under attack.
初期化されることの途中に接続がある間、<の秘密の>のための新しい値が選ばれているなら、現在の<VersionIDofSecret>を除いて、イケ_SA_INITはともに帰られるかもしれません。 応答者がその場合新しいクッキーで別の応答を送ることによってメッセージを拒絶するかもしれないか、それは、短い間<の秘密のおよそ>の古い値を保って、どちらかから計算されたクッキーを受け入れるかもしれません。 <の秘密の>を変えた後に応答者SHOULD NOTはクッキーを無期限に受け入れます、それがサービス保護の否定の一部を破るでしょう、したがって。 特に攻撃で応答者SHOULDは頻繁に<の秘密の>の値を変えます。
Kaufman Standards Track [Page 20] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[20ページ]RFC4306IKEv2 December 2005
2.7. Cryptographic Algorithm Negotiation
2.7. 暗号アルゴリズム交渉
The payload type known as "SA" indicates a proposal for a set of choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well as cryptographic algorithms associated with each protocol.
そして/または、"SA"として知られているペイロードタイプがIPsecプロトコルの選択のセットのために提案を示す、(イケ、超能力、ああ、)、それぞれに関連している暗号アルゴリズムと同様にSAに関して、議定書を作ってください。
An SA payload consists of one or more proposals. Each proposal includes one or more protocols (usually one). Each protocol contains one or more transforms -- each specifying a cryptographic algorithm. Each transform contains zero or more attributes (attributes are needed only if the transform identifier does not completely specify the cryptographic algorithm).
SAペイロードは1つ以上の提案から成ります。 各提案は1つ以上のプロトコル(通常1)を含んでいます。 各プロトコルが1つを含んでいるか、またはそれぞれ暗号アルゴリズムを指定して、以上は変形します。 各変換はゼロか、より多くの属性を含んでいます(変換識別子が完全に暗号アルゴリズムを指定するというわけではない場合にだけ、属性が必要です)。
This hierarchical structure was designed to efficiently encode proposals for cryptographic suites when the number of supported suites is large because multiple values are acceptable for multiple transforms. The responder MUST choose a single suite, which MAY be any subset of the SA proposal following the rules below:
この階層構造は、複数の変換において、複数の値が許容できるのでサポートしているスイートの数が大きいときに、効率的に暗号のスイートのための提案をコード化するように設計されました。応答者は単一のスイートを選ばなければなりません(以下での約束を守るSA提案のどんな部分集合であるかもしれませんも):
Each proposal contains one or more protocols. If a proposal is
accepted, the SA response MUST contain the same protocols in the
same order as the proposal. The responder MUST accept a single
proposal or reject them all and return an error. (Example: if a
single proposal contains ESP and AH and that proposal is accepted,
both ESP and AH MUST be accepted. If ESP and AH are included in
separate proposals, the responder MUST accept only one of them).
各提案は1つ以上のプロトコルを含んでいます。 提案を受け入れるなら、SA応答は提案として同次に同じプロトコルを含まなければなりません。 応答者は、ただ一つの提案を受け入れなければならないか、それらを皆、拒絶して、または誤りを返さなければなりません。 (例: ただ一つの提案が超能力、AH、およびそれを含んでいるなら提案を受け入れて、両方が、超能力とAH MUSTです。受け入れます。 超能力とAHが別々の提案に含まれているなら、応答者はそれらの1つだけを受け入れなければなりません。).
Each IPsec protocol proposal contains one or more transforms.
Each transform contains a transform type. The accepted
cryptographic suite MUST contain exactly one transform of each
type included in the proposal. For example: if an ESP proposal
includes transforms ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES
w/keysize 256, AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted
suite MUST contain one of the ENCR_ transforms and one of the
AUTH_ transforms. Thus, six combinations are acceptable.
それぞれのIPsecプロトコル提案が1つを含んでいるか、または以上は変形します。各変換は変換タイプを含んでいます。 受け入れられた暗号のスイートはまさに提案に各タイプを含む1つの変換を含まなければなりません。 例えば: 256、AUTH_HMAC_MD5、およびAUTH_HMAC_SHA、受け入れられたスイートは_が変えるENCRの1つと_が変えるAUTHの1つを含まなければなりません。インクルードは超能力提案であるならENCR_3DESを変えます、ENCR_AES、128をkeysizeする、ENCR_AES、keysizeする、その結果、6つの組み合わせが許容できます。
Since the initiator sends its Diffie-Hellman value in the IKE_SA_INIT, it must guess the Diffie-Hellman group that the responder will select from its list of supported groups. If the initiator guesses wrong, the responder will respond with a Notify payload of type INVALID_KE_PAYLOAD indicating the selected group. In this case, the initiator MUST retry the IKE_SA_INIT with the corrected Diffie-Hellman group. The initiator MUST again propose its full set of acceptable cryptographic suites because the rejection message was unauthenticated and otherwise an active attacker could trick the endpoints into negotiating a weaker suite than a stronger one that they both prefer.
創始者がイケ_SA_INITでディフィー-ヘルマン値を送るので、それは応答者がサポートしているグループのリストから選択するディフィー-ヘルマングループを推測しなければなりません。 創始者が勘違いすると、応答者はタイプINVALIDのNotifyペイロードで_選択されたグループを示すKE_有効搭載量を反応させるでしょう。 この場合、創始者は直っているディフィー-ヘルマングループと共にイケ_SA_INITを再試行しなければなりません。 拒絶メッセージが非認証されて、さもなければ、活発な攻撃者がそれらの両方が好むより強いものより弱いスイートを交渉するのに終点をだますことができたので、創始者は再び許容できる暗号のスイートのフルセットを提案しなければなりません。
Kaufman Standards Track [Page 21] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[21ページ]RFC4306IKEv2 December 2005
2.8. Rekeying
2.8. Rekeyingします。
IKE, ESP, and AH security associations use secret keys that SHOULD be used only for a limited amount of time and to protect a limited amount of data. This limits the lifetime of the entire security association. When the lifetime of a security association expires, the security association MUST NOT be used. If there is demand, new security associations MAY be established. Reestablishment of security associations to take the place of ones that expire is referred to as "rekeying".
IKE、超能力、およびAHセキュリティ協会は時間の数量限定だけ、限られた量のデータを保護するのにおいて使用されていた状態でSHOULDがある秘密鍵を使用します。 これは全体のセキュリティ協会の生涯を制限します。 セキュリティ協会の寿命が期限が切れるとき、セキュリティ協会を使用してはいけません。 要求があれば、新しいセキュリティ協会は設立されるかもしれません。 期限が切れるものの代理をするセキュリティ協会の再建は「「再-合わせ」る」と呼ばれます。
To allow for minimal IPsec implementations, the ability to rekey SAs without restarting the entire IKE_SA is optional. An implementation MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA has expired or is about to expire and rekeying attempts using the mechanisms described here fail, an implementation MUST close the IKE_SA and any associated CHILD_SAs and then MAY start new ones. Implementations SHOULD support in-place rekeying of SAs, since doing so offers better performance and is likely to reduce the number of packets lost during the transition.
最小量のIPsec実装を考慮するために、全体のIKE_SAを再開することのないrekey SAsへの能力は任意です。 実装はIKE_SAの中で_CHILD_SA要求をすべてのCREATEに拒否するかもしれません。 SAが期限が切れたか、または期限が切れようとしているためにあって、「再-合わせ」るのが、使用するのを試みるならここで説明されたメカニズムが失敗して、実装は、IKE_SAとどんな関連CHILD_SAsも閉じなければならなくて、次に、新しいものを始めるかもしれません。 SHOULDがそうするのが、より良い性能を提供して、パケットの数を減少させそうであるのでSAsを「再-合わせ」ながら適所でサポートする実装は変遷の間、損をしました。
To rekey a CHILD_SA within an existing IKE_SA, create a new, equivalent SA (see section 2.17 below), and when the new one is established, delete the old one. To rekey an IKE_SA, establish a new equivalent IKE_SA (see section 2.18 below) with the peer to whom the old IKE_SA is shared using a CREATE_CHILD_SA within the existing IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's CHILD_SAs. Use the new IKE_SA for all control messages needed to maintain the CHILD_SAs created by the old IKE_SA, and delete the old IKE_SA. The Delete payload to delete itself MUST be the last request sent over an IKE_SA.
既存のIKE_SAの中のrekey a CHILD_SAに、新しくて、同等なSAを作成してください、そして、(下のセクション2.17を見てください)新しい方が確立されたら古い方を削除してください。 IKE_SAをrekeyするには、古いIKE_SAが既存のIKE_SAの中でCREATE_CHILD_SAを使用することで共有される同輩と共に新しい同等なIKE_SA(下のセクション2.18を見る)を設立してください。 そのように作成されたIKE_SAはオリジナルのIKE_SAのCHILD_SAsのすべてを引き継ぎます。 すべてのコントロールメッセージのためのSAが古いIKE_SAによって作成されたCHILD_SAsを維持する必要があった新しいIKE_を使用してください、そして、古いIKE_SAを削除してください。 それ自体を削除するDeleteペイロードはIKE_SAの上に送られた最後の要求であるに違いありません。
SAs SHOULD be rekeyed proactively, i.e., the new SA should be established before the old one expires and becomes unusable. Enough time should elapse between the time the new SA is established and the old one becomes unusable so that traffic can be switched over to the new SA.
SAs SHOULDはrekeyed proactively、古い方が期限が切れる前にすなわち、新しいSAが設立されるべきであるということであり、使用不可能になります。 十分な時間が新しいSAが設立されて、古い方が新しいSAに交通を転換できるように使用不可能になる時の間で経過するべきです。
A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and rekeying the SA when necessary. If the two ends have different lifetime policies, the end with the shorter lifetime will end up always being the one to request the rekeying. If an SA bundle has been inactive for a long time and if an endpoint would not initiate the SA in the absence of traffic, the endpoint MAY choose to close the SA instead of rekeying it when its lifetime expires. It SHOULD do so if there has been no traffic since the last time the SA was rekeyed.
IKEv1とIKEv2の違いはIKEv1 SAでは、寿命が交渉されたということです。 IKEv2では、SAのそれぞれの端はそれ自身の生涯方針にSAに押しつけて、必要であるときにSAを「再-合わせ」るのに責任があります。 2つの終わりに異なった生涯方針があると、より短い生涯がある終わりは、結局、「再-合わせ」ることを要求するためにいつもものになるでしょう。 SAバンドルが長い間不活発であり、終点が交通がないときSAを開始しないなら、終点は、寿命が期限が切れるとそれを「再-合わせ」ることの代わりにSAを閉じるのを選ぶかもしれません。 それ、SAが最後の時間「再-合わせ」られたので交通が全くなかったなら、SHOULDはそうします。
Kaufman Standards Track [Page 22] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[22ページ]RFC4306IKEv2 December 2005
If the two ends have the same lifetime policies, it is possible that both will initiate a rekeying at the same time (which will result in redundant SAs). To reduce the probability of this happening, the timing of rekeying requests SHOULD be jittered (delayed by a random amount of time after the need for rekeying is noticed).
2つの終わりに同じ生涯方針があるなら、両方が同時に(余分なSAsをもたらす)「再-合わせ」ることを開始するのは、可能です。 この出来事の確率を減少させるために、「再-合わせ」ることのタイミングは、SHOULDがjitteredされるよう(無作為の時間までには、「再-合わせ」る必要性が気付かれた後に延着します)要求します。
This form of rekeying may temporarily result in multiple similar SAs between the same pairs of nodes. When there are two SAs eligible to receive packets, a node MUST accept incoming packets through either SA. If redundant SAs are created though such a collision, the SA created with the lowest of the four nonces used in the two exchanges SHOULD be closed by the endpoint that created it.
このフォームを「再-合わせ」るのは一時同じ組のノードの間の複数の同様のSAsをもたらすかもしれません。 パケットを受ける資格がある2SAsがあるとき、ノードはSAを通して入って来るパケットを受け入れなければなりません。 そのような衝突ですが、余分なSAsが作成されるなら、閉じられて、4つの一回だけで最も低いのが2回の交換に使用されている状態で、SAはそれを作成した終点のそばでSHOULDを作成しました。
Note that IKEv2 deliberately allows parallel SAs with the same traffic selectors between common endpoints. One of the purposes of this is to support traffic quality of service (QoS) differences among the SAs (see [RFC2474], [RFC2475], and section 4.1 of [RFC2983]). Hence unlike IKEv1, the combination of the endpoints and the traffic selectors may not uniquely identify an SA between those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on the basis of duplicate traffic selectors SHOULD NOT be used.
一般的な終点の間には、同じ交通セレクタがある状態でIKEv2が故意に平行なSAsを許容することに注意してください。 この目的の1つはSAsの中で交通サービスの質(QoS)差を支持する([RFC2983]の[RFC2474]、[RFC2475]、およびセクション4.1を見てください)ことです。 したがって、IKEv1と異なって、終点と交通セレクタの組み合わせは唯一発見的にそのように、それらの終点の間のSA、IKEv1 rekeyingを特定しないかもしれません。写し交通セレクタSHOULD NOTに基づいてSAsを削除して、使用されてください。
The node that initiated the surviving rekeyed SA SHOULD delete the replaced SA after the new one is established.
新しい方が確立された後に生き残っているrekeyed SA SHOULDを開始したノードは取り替えられたSAを削除します。
There are timing windows -- particularly in the presence of lost packets -- where endpoints may not agree on the state of an SA. The responder to a CREATE_CHILD_SA MUST be prepared to accept messages on an SA before sending its response to the creation request, so there is no ambiguity for the initiator. The initiator MAY begin sending on an SA as soon as it processes the response. The initiator, however, cannot receive on a newly created SA until it receives and processes the response to its CREATE_CHILD_SA request. How, then, is the responder to know when it is OK to send on the newly created SA?
特に無くなっているパケットがあるとき終点がSAの州に同意しないかもしれないタイミングウィンドウがあります。 CREATE_CHILD_SA MUSTへの応答者が創造要求に応答を送る前にSAに関するメッセージを受け入れる用意ができていて、したがって、創始者のためのあいまいさが全くありません。 創始者は、応答を処理するとすぐに、SAを転送し始めるかもしれません。 しかしながら、CHILD_SAが要求するCREATE_への応答を受けて、処理するまで、創始者は新たに作成されたSAで受信できません。 そして、応答者は、新たに作成されたSAを転送するのがいつOKであるかをどのように知ることになっていますか?
From a technical correctness and interoperability perspective, the responder MAY begin sending on an SA as soon as it sends its response to the CREATE_CHILD_SA request. In some situations, however, this could result in packets unnecessarily being dropped, so an implementation MAY want to defer such sending.
技術的な正当性と相互運用性見解から、応答者は、SAが要求するCREATE_CHILD_への応答を送るとすぐに、SAを転送し始めるかもしれません。 いくつかの状況で、しかしながら、これが不必要に落とされるパケットをもたらすかもしれないので、実現はそのような発信を延期したがっているかもしれません。
The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the new SA, or (2) the new SA rekeys an existing SA and it receives an IKE request to close the replaced SA. When rekeying an SA, the responder SHOULD continue to send messages on the old SA until one of those events occurs. When establishing a new SA, the responder MAY defer sending messages on a
応答者が受信したなら創始者がSAに関するメッセージを受け取る用意ができていると確信できる、暗号で、有効なメッセージ、(2) 既存のSAとそれがIKE要求を受け取る新しいSA、または新しいSA rekeysに、取り替えられたSAを閉じてください。 SAを「再-合わせ」るとき、応答者SHOULDは、それらの出来事の1つが起こるまで古いSAにメッセージを送り続けています。 新しいSAを設立するとき、応答者はaに関する送付メッセージを延期するかもしれません。
Kaufman Standards Track [Page 23] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[23ページ]RFC4306IKEv2 December 2005
new SA until either it receives one or a timeout has occurred. If an initiator receives a message on an SA for which it has not received a response to its CREATE_CHILD_SA request, it SHOULD interpret that as a likely packet loss and retransmit the CREATE_CHILD_SA request. An initiator MAY send a dummy message on a newly created SA if it has no messages queued in order to assure the responder that the initiator is ready to receive messages.
1かタイムアウトを受け取るまで、新しいSAは起こりました。 創始者が受信するなら、それがそうしていないSAに関するメッセージはCHILD_SAが要求するCREATE_への応答を受けました、それ。SHOULDはありそうなパケット損失としてそれを解釈して、SAが要求するCREATE_CHILD_を再送します。 創始者がメッセージを受け取る準備ができていることを応答者に知らせるためにそれでメッセージを全く列に並ばせないなら、創始者は新たに作成されたSAに擬似通報を送るかもしれません。
2.9. Traffic Selector Negotiation
2.9. 交通セレクタ交渉
When an IP packet is received by an RFC4301-compliant IPsec subsystem and matches a "protect" selector in its Security Policy Database (SPD), the subsystem MUST protect that packet with IPsec. When no SA exists yet, it is the task of IKE to create it. Maintenance of a system's SPD is outside the scope of IKE (see [PFKEY] for an example protocol), though some implementations might update their SPD in connection with the running of IKE (for an example scenario, see section 1.1.3).
IPパケットがRFC4301対応することのIPsecサブシステムで受け取られて、Security Policy Database(SPD)で「保護してください」というセレクタに合っていると、サブシステムはIPsecと共にそのパケットを保護しなければなりません。 どんなSAもまだ存在していないとき、それはそれを作成するIKEに関するタスクです。 IKEの範囲の外にシステムのSPDの維持があります(例のプロトコルに関して[PFKEY]を見てください)、いくつかの実現がIKEの走行に関してそれらのSPDをアップデートするかもしれませんが(例のシナリオに関して、セクション1.1.3を見てください)。
Traffic Selector (TS) payloads allow endpoints to communicate some of the information from their SPD to their peers. TS payloads specify the selection criteria for packets that will be forwarded over the newly set up SA. This can serve as a consistency check in some scenarios to assure that the SPDs are consistent. In others, it guides the dynamic update of the SPD.
交通Selector(TS)ペイロードで、終点はそれらのSPDから彼らの同輩まで何らかの情報を伝えることができます。 TSペイロードは新たにSAに設定されている上に送られるパケットの選択評価基準を指定します。 これはSPDsが一貫していることを保証するいくつかのシナリオにおける一貫性チェックとして機能できます。 他のものでは、それはSPDのダイナミックなアップデートを案内します。
Two TS payloads appear in each of the messages in the exchange that creates a CHILD_SA pair. Each TS payload contains one or more Traffic Selectors. Each Traffic Selector consists of an address range (IPv4 or IPv6), a port range, and an IP protocol ID. In support of the scenario described in section 1.1.3, an initiator may request that the responder assign an IP address and tell the initiator what it is.
2個のTSペイロードがCHILD_SA組を創設する交換における、それぞれに関するメッセージに現れます。 それぞれのTSペイロードは1Traffic Selectorsを含んでいます。 各Traffic Selectorはアドレスの範囲(IPv4かIPv6)、ポート範囲、およびIPプロトコルIDから成ります。 セクション1.1.3で説明されたシナリオを支持して、創始者は、応答者がIPアドレスを割り当てるよう要求して、それが何であるかを創始者に言うかもしれません。
IKEv2 allows the responder to choose a subset of the traffic proposed by the initiator. This could happen when the configurations of the two endpoints are being updated but only one end has received the new information. Since the two endpoints may be configured by different people, the incompatibility may persist for an extended period even in the absence of errors. It also allows for intentionally different configurations, as when one end is configured to tunnel all addresses and depends on the other end to have the up-to-date list.
IKEv2は応答者に創始者によって提案された交通の部分集合を選ばせます。 2つの終点の構成をアップデートしていますが、片端だけが新情報を受け取ったとき、これは起こることができました。 2つの終点が異なった人々によって構成されるかもしれないので、不一致は誤りがないときでさえ長期間の間、持続するかもしれません。 また、それは故意に異なった構成を考慮します、片端がすべてのアドレスにトンネルを堀るために構成されて、最新のリストを持つためにもう一方の端でよる時として。
The first of the two TS payloads is known as TSi (Traffic Selector- initiator). The second is known as TSr (Traffic Selector-responder). TSi specifies the source address of traffic forwarded from (or the destination address of traffic forwarded to) the initiator of the CHILD_SA pair. TSr specifies the destination address of the traffic
2個のTSペイロードの1番目はTSi(交通Selector創始者)として知られています。 2番目はTSr(交通Selector-応答者)として知られています。 TSiが交通のアドレスが転送したソースを指定する、(交通のアドレスが進めた目的地、)、CHILD_SA組の創始者。 TSrは交通の送付先アドレスを指定します。
Kaufman Standards Track [Page 24] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[24ページ]RFC4306IKEv2 December 2005
forwarded to (or the source address of the traffic forwarded from) the responder of the CHILD_SA pair. For example, if the original initiator request the creation of a CHILD_SA pair, and wishes to tunnel all traffic from subnet 192.0.1.* on the initiator's side to subnet 192.0.2.* on the responder's side, the initiator would include a single traffic selector in each TS payload. TSi would specify the address range (192.0.1.0 - 192.0.1.255) and TSr would specify the address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was acceptable to the responder, it would send identical TS payloads back. (Note: The IP address range 192.0.2.* has been reserved for use in examples in RFCs and similar documents. This document needed two such ranges, and so also used 192.0.1.*. This should not be confused with any actual address.)
進める、(交通のアドレスが転送したソース、)、CHILD_SA組の応答者。 例えば、オリジナルの創始者であるならサブネットからすべての交通にトンネルを堀るようCHILD_SA組、および願望の創造に要求してください、192.0、.1. サブネットへの創始者の側の*、192.0、.2. *応答者の側では、創始者がそれぞれのTSペイロードで単一の交通セレクタを入れるでしょう。 TSiがアドレスの範囲を指定するだろう、(192.0、.1、.0--192.0に、.1の.255と)TSrがアドレスの範囲を指定するだろう、(192.0 .2 .0--192.0 .2 .255)。 応答者にとって、提案が許容できたと仮定する場合、それは同じTSペイロードを返送するでしょう。 (以下に注意してください。 IPアドレスの範囲、192.0、.2. *はRFCsの例と同様のドキュメントにおける使用のために予約されました。 また、このドキュメントは、そのような2つの範囲を必要とするので、192.0.1*を使用しました。これはどんな絶対番地にも混乱するべきではありません。)
The responder is allowed to narrow the choices by selecting a subset of the traffic, for instance by eliminating or narrowing the range of one or more members of the set of traffic selectors, provided the set does not become the NULL set.
応答者は交通の部分集合を選択することによって、選択を狭くすることができます、例えば、排泄するか、または狭くするのによる交通セレクタのセットの1人以上のメンバーの範囲、セットがNULLセットにならないなら。
It is possible for the responder's policy to contain multiple smaller ranges, all encompassed by the initiator's traffic selector, and with the responder's policy being that each of those ranges should be sent over a different SA. Continuing the example above, the responder might have a policy of being willing to tunnel those addresses to and from the initiator, but might require that each address pair be on a separately negotiated CHILD_SA. If the initiator generated its request in response to an incoming packet from 192.0.1.43 to 192.0.2.123, there would be no way for the responder to determine which pair of addresses should be included in this tunnel, and it would have to make a guess or reject the request with a status of SINGLE_PAIR_REQUIRED.
それを応答者の方針が創始者の交通セレクタによってすべて取り囲まれた複数の、より小さい範囲を含むのにおいて可能であり、それぞれそれである応答者のそれらの範囲の方針で異なったSAの上に送るべきです。 例を続けていて、応答者は、上では、創始者と創始者からのそれらのアドレスにトンネルを堀ることを望むことの方針を持っていますが、それぞれのアドレス組が別々に交渉されたCHILD_SAにあるのを必要とするかもしれません。 創始者が192.0からの入って来るパケットに対応して要求を発生させた、.1、.43、192.0 .2 .123 応答者が、アドレスのどの組がこのトンネルに含まれるべきであるかを決心する方法が全くなくて、それは、SINGLE_PAIR_REQUIREDの状態で推測をしなければならないか、または要求を拒絶しなければならないでしょう。
To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first traffic selector in each of TSi and TSr a very specific traffic selector including the addresses in the packet triggering the request. In the example, the initiator would include in TSi two traffic selectors: the first containing the address range (192.0.1.43 - 192.0.1.43) and the source port and IP protocol from the packet and the second containing (192.0.1.0 - 192.0.1.255) with all ports and IP protocols. The initiator would similarly include two traffic selectors in TSr.
応答者がこの場合適切な範囲を選ぶのを可能にするために、要求の引き金となりながらパケットにアドレスを含んでいて、創始者がデータ・パケットのためSAを要求したなら、創始者SHOULDは最初の交通セレクタとしてそれぞれのTSiとTSrに非常に特定の交通セレクタを含んでいます。 例では、創始者はTSi two交通でセレクタを入れるでしょう: 最初にアドレスの範囲を含む、(192.0 .1 .43と)ソースが移植する.1とIPがパケットと2番目の含有から議定書の中で述べる.43--192.0、(192.0 .1 .0--192.0 .1 .255) すべてのポートとIPプロトコルで。 創始者は同様にTSrの2個の交通セレクタを入れるでしょう。
If the responder's policy does not allow it to accept the entire set of traffic selectors in the initiator's request, but does allow him to accept the first selector of TSi and TSr, then the responder MUST narrow the traffic selectors to a subset that includes the
応答者の方針で創始者の要求で全体のセットの交通セレクタを受け入れるのを許容しませんが、彼がTSiとTSrの最初のセレクタを受け入れるなら、応答者はそれが含む部分集合に交通セレクタを狭くしなければなりません。
Kaufman Standards Track [Page 25] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[25ページ]RFC4306IKEv2 December 2005
initiator's first choices. In this example, the responder might respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and IP protocols.
創始者の最初の選択。 この例では、応答者がTSi存在と共に応じるかもしれない、(192.0 .1 .43--192.0 .1 .43) すべてのポートとIPプロトコルで。
If the initiator creates the CHILD_SA pair not in response to an arriving packet, but rather, say, upon startup, then there may be no specific addresses the initiator prefers for the initial tunnel over any other. In that case, the first values in TSi and TSr MAY be ranges rather than specific values, and the responder chooses a subset of the initiator's TSi and TSr that are acceptable. If more than one subset is acceptable but their union is not, the responder MUST accept some subset and MAY include a Notify payload of type ADDITIONAL_TS_POSSIBLE to indicate that the initiator might want to try again. This case will occur only when the initiator and responder are configured differently from one another. If the initiator and responder agree on the granularity of tunnels, the initiator will never request a tunnel wider than the responder will accept. Such misconfigurations SHOULD be recorded in error logs.
創始者が到着パケットに対応して創設するのではなく、むしろ、たとえばCHILD_SA組を創設するなら、始動には、いかなる他のも上に創始者が初期のトンネルとして好むどんな特定のアドレスもないかもしれません。 その場合、TSiとTSrにおける最初の値は特定の値よりむしろ範囲であるかもしれません、そして、応答者は創始者の許容できるTSiとTSrの部分集合を選びます。 1つ以上の部分集合が許容できますが、それらの組合が許容できるというわけではないなら、応答者は、何らかの部分集合を受け入れなければならなくて、創始者が再試行したがっているかもしれないのを示すためにタイプADDITIONALのNotifyペイロードに_TS_POSSIBLEを入れるかもしれません。 創始者と応答者がお互いと異なって構成されるときだけ、本件は現れるでしょう。 創始者と応答者がトンネルの粒状に同意すると、創始者は応答者が受け入れるより広いトンネルを決して要求しないでしょう。 そのようなmisconfigurations SHOULD、障害記録に記録されてください。
2.10. Nonces
2.10. 一回だけ
The IKE_SA_INIT messages each contain a nonce. These nonces are used
as inputs to cryptographic functions. The CREATE_CHILD_SA request
and the CREATE_CHILD_SA response also contain nonces. These nonces
are used to add freshness to the key derivation technique used to
obtain keys for CHILD_SA, and to ensure creation of strong pseudo-
random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST
be randomly chosen, MUST be at least 128 bits in size, and MUST be at
least half the key size of the negotiated prf. ("prf" refers to
"pseudo-random function", one of the cryptographic algorithms
negotiated in the IKE exchange.) If the same random number source is
used for both keys and nonces, care must be taken to ensure that the
latter use does not compromise the former.
イケ_SA_INITメッセージはそれぞれ一回だけを含んでいます。 これらの一回だけは入力として暗号の機能に使用されます。 また、SAが要求するCREATE_CHILD_とCREATE_CHILD_SA応答は一回だけを含んでいます。 これらの一回だけは、主要な派生のテクニックへの新しさがCHILD_SAにキーを入手して、以前はよくディフィー-ヘルマンキーからの強い疑似無作為のビットの創造を確実にしていたと言い足すのに使用されます。 IKEv2で使用される一回だけは、手当たりしだいに選ばなければならなくて、サイズにおける少なくとも128ビットでなければならなく、少なくとも交渉されたprfの主要なサイズの半分であるに違いありません。 ("prf"は「擬似ランダム機能」、IKE交換で交渉された暗号アルゴリズムの1つを示します。) 同じ乱数ソースがキーと一回だけの両方に使用されるなら、後者の使用が前者で妥協しないのを保証するために注意しなければなりません。
2.11. Address and Port Agility
2.11. アドレスとポートの機敏さ
IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses it runs over. The IP addresses and ports in the outer header are, however, not themselves cryptographically protected, and IKE is designed to work even through Network Address Translation (NAT) boxes. An implementation MUST accept incoming requests even if the source port is not 500 or 4500, and MUST respond to the address and port from which the request was received. It MUST specify the address and port at which the request was received as the source address and port in the response. IKE functions identically over IPv4 or IPv6.
しかしながら、IKEがそれが. IPアドレスの上を走って、外側のヘッダーで移植する同じIPアドレスがそうので超能力とAH協会で500と4500のUDPポートに、それとなく自分たちではなく暗号でセットを経営している、保護、IKEは、Network Address Translation(NAT)箱さえ終えるように設計されています。 実現は、ソース港が500でなくて、また4500でもないなら入って来る要求を受け入れなければならなくて、要求が受け取られたアドレスとポートに応じなければなりません。 それは要求がソースアドレスとポートとして応答で受け取られたアドレスとポートを指定しなければなりません。 IKEは同様にIPv4かIPv6の上で機能します。
Kaufman Standards Track [Page 26] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[26ページ]RFC4306IKEv2 December 2005
2.12. Reuse of Diffie-Hellman Exponentials
2.12. ディフィー-ヘルマンExponentialsの再利用
IKE generates keying material using an ephemeral Diffie-Hellman exchange in order to gain the property of "perfect forward secrecy". This means that once a connection is closed and its corresponding keys are forgotten, even someone who has recorded all of the data from the connection and gets access to all of the long-term keys of the two endpoints cannot reconstruct the keys used to protect the conversation without doing a brute force search of the session key space.
IKEは、「完全な前進の秘密主義」の資産を獲得するのにはかないディフィー-ヘルマンの交換を使用することで合わせることの材料を発生させます。 これは、いったん接続が閉じられて、対応するキーが忘れられていると、接続からデータのすべてを記録して、2つの終点の長期のキーのすべてに近づく手段を得るだれかさえセッションの主要なスペースの獣の力の検索をしないで会話を保護するのに使用されるキーを再建できないことを意味します。
Achieving perfect forward secrecy requires that when a connection is closed, each endpoint MUST forget not only the keys used by the connection but also any information that could be used to recompute those keys. In particular, it MUST forget the secrets used in the Diffie-Hellman calculation and any state that may persist in the state of a pseudo-random number generator that could be used to recompute the Diffie-Hellman secrets.
完全な前進の秘密主義を達成するのは、接続が閉じられるとき、各終点が接続によって使用されたキーだけではなく、それらのキーを再計算するのに使用できたどんな情報も忘れなければならないのを必要とします。 特に、それはディフィー-ヘルマンの計算とディフィー-ヘルマン秘密を再計算するのに使用できた疑似乱数生成器の状態に固執するかもしれないどんな州でも使用される秘密を忘れなければなりません。
Since the computing of Diffie-Hellman exponentials is computationally expensive, an endpoint may find it advantageous to reuse those exponentials for multiple connection setups. There are several reasonable strategies for doing this. An endpoint could choose a new exponential only periodically though this could result in less-than- perfect forward secrecy if some connection lasts for less than the lifetime of the exponential. Or it could keep track of which exponential was used for each connection and delete the information associated with the exponential only when some corresponding connection was closed. This would allow the exponential to be reused without losing perfect forward secrecy at the cost of maintaining more state.
ディフィー-ヘルマンexponentialsのコンピューティングが計算上高価であるので、終点は、複数の接続設定のためにそれらのexponentialsを再利用するのが有利であることがわかるかもしれません。 これをするためのいくつかの合理的な戦略があります。 これが以下をもたらすかもしれませんが、終点が定期的だけに新しく指数でaを選ぶかもしれない、-、-完全な前進の秘密保持が接続であるなら指数の生涯以下で持続するより。 または、どれの指数で動向をおさえるかもしれないか、対応する接続が閉店したときだけ、各接続に使用されて、指数に関連している情報を削除します。 これは、指数が損をしている完全な前進の秘密保持なしで、より多くの状態を維持する費用で再利用されるのを許容するでしょう。
Decisions as to whether and when to reuse Diffie-Hellman exponentials is a private decision in the sense that it will not affect interoperability. An implementation that reuses exponentials MAY choose to remember the exponential used by the other endpoint on past exchanges and if one is reused to avoid the second half of the calculation.
決定、再利用していつディフィー-ヘルマンexponentialsを再利用するかは、相互運用性に影響しないという意味で個人的な決定です。 exponentialsを再利用する実装は、過去の交換と1つが計算の後半を避けるために再利用されるかどうかのもう片方の終点によって使用される指数を覚えているのを選ぶかもしれません。
2.13. Generating Keying Material
2.13. 材料を合わせる生成すること
In the context of the IKE_SA, four cryptographic algorithms are negotiated: an encryption algorithm, an integrity protection algorithm, a Diffie-Hellman group, and a pseudo-random function (prf). The pseudo-random function is used for the construction of keying material for all of the cryptographic algorithms used in both the IKE_SA and the CHILD_SAs.
IKE_SAの文脈では、4つの暗号アルゴリズムが交渉されます: 暗号化アルゴリズム、保全保護アルゴリズム、ディフィー-ヘルマングループ、および擬似ランダムは機能します(prf)。 擬似ランダム機能はIKE_SAとCHILD_SAsの両方で使用される暗号アルゴリズムのすべてのための合わせることの材料の構造に使用されます。
Kaufman Standards Track [Page 27] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[27ページ]RFC4306IKEv2 December 2005
We assume that each encryption algorithm and integrity protection algorithm uses a fixed-size key and that any randomly chosen value of that fixed size can serve as an appropriate key. For algorithms that accept a variable length key, a fixed key size MUST be specified as part of the cryptographic transform negotiated. For algorithms for which not all values are valid keys (such as DES or 3DES with key parity), the algorithm by which keys are derived from arbitrary values MUST be specified by the cryptographic transform. For integrity protection functions based on Hashed Message Authentication Code (HMAC), the fixed key size is the size of the output of the underlying hash function. When the prf function takes a variable length key, variable length data, and produces a fixed-length output (e.g., when using HMAC), the formulas in this document apply. When the key for the prf function has fixed length, the data provided as a key is truncated or padded with zeros as necessary unless exceptional processing is explained following the formula.
私たちはそれぞれの暗号化アルゴリズムと保全保護アルゴリズムが固定サイズキーを使用して、どんなサイズが固定されたその手当たりしだいに選ばれた値も適切なキーとして機能できると思います。 可変長が主要であると受け入れるアルゴリズムにおいて、交渉された暗号の変換の一部として固定主要なサイズを指定しなければなりません。 すべての値が有効なキーであるというわけではない(主要な同等があるDESか3DESなどの)アルゴリズムとして、暗号の変換でキーが任意の値から得られるアルゴリズムを指定しなければなりません。 Hashedメッセージ立証コード(HMAC)に基づく保全保護機能のために、固定主要なサイズは基本的なハッシュ関数の出力のサイズです。 prf機能が可変ロングに主要で、可変な長さのデータがかかって、固定長出力を起こすとき(例えば、HMACを使用するとき)、定石は本書では適用されます。 prf機能のためのキーには固定長があって、公式に従って、例外的な処理が説明されない場合、キーとして提供されたデータは、先端を切られるか、またはゼロが必要な状態で水増しされます。
Keying material will always be derived as the output of the negotiated prf algorithm. Since the amount of keying material needed may be greater than the size of the output of the prf algorithm, we will use the prf iteratively. We will use the terminology prf+ to describe the function that outputs a pseudo-random stream based on the inputs to a prf as follows: (where | indicates concatenation)
材料を合わせるのは交渉されたprfアルゴリズムの出力としていつも引き出されるでしょう。 材料が必要とした合わせることの量がprfアルゴリズムの出力のサイズより大きいかもしれないので、私たちはprf iterativelyを使用するつもりです。 私たちは入力に基づく擬似ランダムストリームを以下のprfに出力する機能について説明するのに用語prf+を使用するつもりです: (どこ|、表示、連結)
prf+ (K,S) = T1 | T2 | T3 | T4 | ...
prf+(K、S)はT1と等しいです。| T2| T3| T4| ...
where: T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04)
どこ: T1=prf(S| K、0×01)T2=prf(K、T1|S|0×02)T3=prf(K、T2|S|0×03)T4はprfと等しいです。(K、T3|S|0×04)
continuing as needed to compute all required keys. The keys are taken from the output string without regard to boundaries (e.g., if the required keys are a 256-bit Advanced Encryption Standard (AES) key and a 160-bit HMAC key, and the prf function generates 160 bits, the AES key will come from T1 and the beginning of T2, while the HMAC key will come from the rest of T2 and the beginning of T3).
必要に応じてすべてを計算し続けているのがキーを必要としました。 関係のない出力ストリングから境界までキーを取ります(例えば、必要なキーが256ビットのエー・イー・エス(AES)キーと160ビットのHMACキーであり、prf機能が160ビットを生成すると、AESキーはT2のT1と始まりから来るでしょう、HMACキーはT2の残りとT3の始まりから来るでしょうが)。
The constant concatenated to the end of each string feeding the prf is a single octet. prf+ in this document is not defined beyond 255 times the size of the prf output.
prfに食べさせるそれぞれのストリングの端まで連結された定数はただ一つの八重奏です。prf+は本書ではprf出力のサイズの255倍を超えて定義されません。
2.14. Generating Keying Material for the IKE_SA
2.14. IKE_SAのために材料を合わせる生成すること
The shared keys are computed as follows. A quantity called SKEYSEED is calculated from the nonces exchanged during the IKE_SA_INIT exchange and the Diffie-Hellman shared secret established during that
共有されたキーは以下の通り計算されます。 SKEYSEEDと呼ばれる量はイケ_SA_INIT交換とそれの間に確立されたディフィー-ヘルマン共有秘密キーの間に交換された一回だけから計算されます。
Kaufman Standards Track [Page 28] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[28ページ]RFC4306IKEv2 December 2005
exchange. SKEYSEED is used to calculate seven other secrets: SK_d used for deriving new keys for the CHILD_SAs established with this IKE_SA; SK_ai and SK_ar used as a key to the integrity protection algorithm for authenticating the component messages of subsequent exchanges; SK_ei and SK_er used for encrypting (and of course decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are used when generating an AUTH payload.
交換。 SKEYSEEDは他の7つの秘密について計算するのに使用されます: CHILD_SAsのために新しいキーを引き出すのに使用されるSKはこのIKEと共に_SAを設立しました。 その後の交換に関するコンポーネントメッセージを認証するのに保全保護アルゴリズムのキーとして使用されるSK_aiとSK_ar。 SK_eiとSK_、えー、すべてのその後の交換を暗号化する(そして、もちろん解読する)ために、使用されます。 SK_パイとSK_pr。(AUTHペイロードを生成するとき、そのprは使用されています)。
SKEYSEED and its derivatives are computed as follows:
SKEYSEEDとその派生物は以下の通り計算されます:
SKEYSEED = prf(Ni | Nr, g^ir)
SKEYSEEDはprfと等しいです。(Ni| Nr、g^、不-、)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+
(SKEYSEED, Ni | Nr | SPIi | SPIr )
SK| SK_ai| SK_ar| SK_は| SKをeiします。_えー| SK_パイ|、SK_pr、=prf+(Ni|Nr|SPIi| SKEYSEED、SPIr)
(indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr are taken in order from the generated bits of the prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman exchange. g^ir is represented as a string of octets in big endian order padded with zeros if necessary to make it the length of the modulus. Ni and Nr are the nonces, stripped of any headers. If the negotiated prf takes a fixed-length key and the lengths of Ni and Nr do not add up to that length, half the bits must come from Ni and half from Nr, taking the first bits of each.
SK_prによるg^が不-あるということです。整然とした状態で取って、prf+の発生しているビット) . g^から、はかないディフィー-ヘルマンの交換からの共有秘密キーは不-来ています。そして、(それを示す、量のSK、SK_ai、ar_SK SK_はeiされます、SK_、えー、SK_パイ、ゼロで水増しされた、必要ならそれを係数の長さにしたビッグエンディアンオーダーにおける一連の八重奏として、表されます。 NiとNrはどんなヘッダーも奪い取られた一回だけです。 交渉されたprfが固定長キーを取って、NiとNrの長さがその長さを意味しないなら、ビットの半分がNiと半分からNrから来なければなりません、それぞれの最初の何ビットも取って。
The two directions of traffic flow use different keys. The keys used to protect messages from the original initiator are SK_ai and SK_ei. The keys used to protect messages in the other direction are SK_ar and SK_er. Each algorithm takes a fixed number of bits of keying material, which is specified as part of the algorithm. For integrity algorithms based on a keyed hash, the key size is always equal to the length of the output of the underlying hash function.
交通の流れの2つの方向が異なったキーを使用します。 オリジナルの創始者からメッセージを保護するのに使用されるキーは、SK_aiとSK_eiです。 他の方向によるメッセージを保護するのに使用されるキーは、SK_arとSK_です。えー。 各アルゴリズムは合わせることの材料の固定数のかけらで取ります。(かけらはアルゴリズムの一部として指定されます)。 合わせられたハッシュに基づく保全アルゴリズムにおいて、主要なサイズは基本的なハッシュ関数の出力の長さといつも等しいです。
2.15. Authentication of the IKE_SA
2.15. IKE_SAの認証
When not using extensible authentication (see section 2.16), the peers are authenticated by having each sign (or MAC using a shared secret as the key) a block of data. For the responder, the octets to be signed start with the first octet of the first SPI in the header of the second message and end with the last octet of the last payload in the second message. Appended to this (for purposes of computing the signature) are the initiator's nonce Ni (just the value, not the payload containing it), and the value prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding the fixed header. Note that neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the first message, starting with the first octet of the first SPI in the header and ending with the last octet of the last payload. Appended to this (for purposes of
広げることができる認証(セクション2.16を見る)を使用しないとき、それぞれを1ブロックの(または、キーとして共有秘密キーを使用するMAC)データに署名させることによって、同輩は認証されます。 応答者に関しては、署名される八重奏は2番目のメッセージと終わりのヘッダーにおける、2番目のメッセージにおける、最後のペイロードの最後の八重奏による最初のSPIの最初の八重奏から始まります。 'これ(署名を計算する目的のための)に追加しているのは、創始者の一回だけNi(それを含むペイロードではなく、まさしく値)と、値のprfです。(SK_がprされる、IDr、'、)、どこIDr、'固定ヘッダーを除いた応答者のIDペイロードはそうであるか。 '一回だけのNiも値もprfされないことに注意してください。(SK_がprされる、IDr、'、)、伝えられます。 同様に、創始者は最初のメッセージに署名します、ヘッダーと結末における、最後のペイロードの最後の八重奏による最初のSPIの最初の八重奏から始まって。 これに追加する、(目的
Kaufman Standards Track [Page 29] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[29ページ]RFC4306IKEv2 December 2005
computing the signature) are the responder's nonce Nr, and the value prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the entire ID payloads excluding the fixed header. It is critical to the security of the exchange that each side sign the other side's nonce.
'、署名を計算します)、応答者の一回だけNr、および値がprfである、(SK_パイ、IDi、'、) '上の計算では、固定ヘッダーを除いたIDiと'IDr'は全体のIDペイロードです。 それはそれぞれの側が反対側の一回だけに署名する交換のセキュリティに重要です。
Note that all of the payloads are included under the signature, including any payload types not defined in this document. If the first message of the exchange is sent twice (the second time with a responder cookie and/or a different Diffie-Hellman group), it is the second version of the message that is signed.
ペイロードのすべてが本書では定義されなかった少しのペイロードタイプも含む署名で含まれていることに注意してください。 (応答者クッキー、そして/または、異なったディフィー-ヘルマングループがある2回目)のときに二度交換の最初のメッセージを送るなら、それは署名されるメッセージの第2バージョンです。
Optionally, messages 3 and 4 MAY include a certificate, or certificate chain providing evidence that the key used to compute a digital signature belongs to the name in the ID payload. The signature or MAC will be computed using algorithms dictated by the type of key used by the signer, and specified by the Auth Method field in the Authentication payload. There is no requirement that the initiator and responder sign with the same cryptographic algorithms. The choice of cryptographic algorithms depends on the type of key each has. In particular, the initiator may be using a shared key while the responder may have a public signature key and certificate. It will commonly be the case (but it is not required) that if a shared secret is used for authentication that the same key is used in both directions. Note that it is a common but typically insecure practice to have a shared key derived solely from a user- chosen password without incorporating another source of randomness.
任意に、メッセージ3と4が証明書を含むかもしれませんか、またはキーが以前はよくデジタル署名を計算していたという証明書チェーン提供証拠はIDペイロードの名前に属します。 署名かMACが、署名者によって使用されるキーのタイプによって決められて、AuthenticationペイロードのAuth Method分野によって指定されたアルゴリズムを使用することで計算されるでしょう。 創始者と応答者が同じ暗号アルゴリズムと契約するという要件が全くありません。暗号アルゴリズムのこの選択はそれぞれが持っているキーのタイプ次第です。 応答者には公共の署名キーと証明書があるかもしれない間、特に、創始者は共有されたキーを使用しているかもしれません。 一般的に、共有秘密キーが認証に使用されるならそんなに同じキーが両方の方向に使用されるのは、事実(それは必要でない)でしょう。 唯一ユーザの選ばれたパスワードから偶発性の別の源を組み込まないで共有されたキーを引き出させるのが、一般的な、しかし、通常不安定な習慣であることに注意してください。
This is typically insecure because user-chosen passwords are unlikely to have sufficient unpredictability to resist dictionary attacks and these attacks are not prevented in this authentication method. (Applications using password-based authentication for bootstrapping and IKE_SA should use the authentication method in section 2.16, which is designed to prevent off-line dictionary attacks.) The pre- shared key SHOULD contain as much unpredictability as the strongest key being negotiated. In the case of a pre-shared key, the AUTH value is computed as:
ユーザによって選ばれたパスワードには辞書攻撃に抵抗できるくらいの予測不可能性がありそうにないので、これは通常不安定です、そして、これらの攻撃はこの認証方法で防がれません。 (ブートストラップ法にパスワードベースの認証を使用するアプリケーションとIKE_SAはセクション2.16で認証方法を使用するはずです。)(セクションは、オフライン辞書攻撃を防ぐように設計されています)。 あらかじめ共有された主要なSHOULDは交渉される中で最も強いキーと同じくらい多くの予測不可能性を含んでいます。 あらかじめ共有されたキーの場合では、AUTH値は以下として計算されます。
AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)
AUTHはprfと等しいです。(prf、(共有されたSecret、「IKEv2"のための主要なPad)、<msg八重奏>)、」
where the string "Key Pad for IKEv2" is 17 ASCII characters without null termination. The shared secret can be variable length. The pad string is added so that if the shared secret is derived from a password, the IKE implementation need not store the password in cleartext, but rather can store the value prf(Shared Secret,"Key Pad for IKEv2"), which could not be used as a password equivalent for protocols other than IKEv2. As noted above, deriving the shared secret from a password is not secure. This construction is used because it is anticipated that people will do it anyway. The
ストリング「IKEv2"に、主要なパッドはヌル終了がなければ17人のASCII文字どこであるか」。 共有秘密キーは可変長であるかもしれません。 パッドストリングがパスワードから共有秘密キーを得るなら、IKE実装がcleartextのパスワードを保存する必要はないように加えられますが、むしろ値のprfを保存できる、(共有されたSecret、「IKEv2"のための主要なPad)、IKEv2以外のプロトコルに、同等なパスワードとしてどれを使用できなかったか、」 上で述べたように、パスワードから共有秘密キーを得るのは安全ではありません。 人々がとにかくそれをすると予期されるので、この建築は使用されています。 The
Kaufman Standards Track [Page 30] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[30ページ]RFC4306IKEv2 December 2005
management interface by which the Shared Secret is provided MUST accept ASCII strings of at least 64 octets and MUST NOT add a null terminator before using them as shared secrets. It MUST also accept a HEX encoding of the Shared Secret. The management interface MAY accept other encodings if the algorithm for translating the encoding to a binary string is specified. If the negotiated prf takes a fixed-size key, the shared secret MUST be of that fixed size.
Shared Secretが提供される管理インタフェースは、少なくとも64の八重奏のASCIIストリングを受け入れなければならなくて、共有秘密キーとしてそれらを使用する前に、ヌルターミネータを加えてはいけません。 また、それはShared Secretをコード化するHEXを受け入れなければなりません。 2進のストリングにコード化を翻訳するためのアルゴリズムが指定されるなら、管理インタフェースは他のencodingsを受け入れるかもしれません。 交渉されたprfが固定サイズキーを取るなら、共有秘密キーはサイズが固定されたそれのものであるに違いありません。
2.16. Extensible Authentication Protocol Methods
2.16. 拡張認証プロトコルメソッド
In addition to authentication using public key signatures and shared secrets, IKE supports authentication using methods defined in RFC 3748 [EAP]. Typically, these methods are asymmetric (designed for a user authenticating to a server), and they may not be mutual. For this reason, these protocols are typically used to authenticate the initiator to the responder and MUST be used in conjunction with a public key signature based authentication of the responder to the initiator. These methods are often associated with mechanisms referred to as "Legacy Authentication" mechanisms.
公開鍵署名と共有秘密キーを使用する認証に加えて、IKEは、RFC3748[EAP]で定義されたメソッドを使用することで認証をサポートします。 これらのメソッドは通常、非対称です、そして、(サーバに認証するユーザのために、設計されています)それらは互いでないかもしれません。 この理由のために、これらのプロトコルを応答者に創始者を認証するのに通常使用されて、応答者の公開鍵署名に基づいている認証に関連して創始者に使用しなければなりません。 これらのメソッドはしばしば「レガシー認証」メカニズムと呼ばれたメカニズムに関連しています。
While this memo references [EAP] with the intent that new methods can be added in the future without updating this specification, some simpler variations are documented here and in section 3.16. [EAP] defines an authentication protocol requiring a variable number of messages. Extensible Authentication is implemented in IKE as additional IKE_AUTH exchanges that MUST be completed in order to initialize the IKE_SA.
意図がそんなに新しいこのメモ参照[EAP]である間、この仕様をアップデートしないで、将来メソッドを加えることができて、いくつかの、より簡単な変化がこことセクション3.16で記録されます。 [EAP]は可変数のメッセージを必要とする認証プロトコルを定義します。 広げることができるAuthenticationはIKE_SAを初期化するために終了しなければならない追加イケ_AUTH交換としてIKEで実装されます。
An initiator indicates a desire to use extensible authentication by leaving out the AUTH payload from message 3. By including an IDi payload but not an AUTH payload, the initiator has declared an identity but has not proven it. If the responder is willing to use an extensible authentication method, it will place an Extensible Authentication Protocol (EAP) payload in message 4 and defer sending SAr2, TSi, and TSr until initiator authentication is complete in a subsequent IKE_AUTH exchange. In the case of a minimal extensible authentication, the initial SA establishment will appear as follows:
創始者はメッセージ3からAUTHペイロードを置くことによって広げることができる認証を使用する願望を示します。 AUTHペイロードではなく、IDiペイロードを含んでいることによって、創始者は、アイデンティティを宣言しましたが、それを立証していません。 応答者が、広げることができる認証方法を使用しても構わないと思っていると、創始者認証がその後のイケ_AUTH交換で完全になるまで、それは、拡張認証プロトコル(EAP)ペイロードをメッセージ4に置いて、SAr2を送る、TSi、およびTSrを延期するでしょう。 最小量の広げることができる認証の場合では、初期のSA設立は以下の通りに見えるでしょう:
Kaufman Standards Track [Page 31] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[31ページ]RFC4306IKEv2 December 2005
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
創始者応答者----------- ----------- HDR、SAi1、KEi、Ni-->。
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
<--HDR、SAr1、KEr、Nr[CERTREQ]
HDR, SK {IDi, [CERTREQ,] [IDr,]
SAi2, TSi, TSr} -->
HDR、SK、IDi、SAi2、TSi、[CERTREQ][IDr]TSr--、>。
<-- HDR, SK {IDr, [CERT,] AUTH,
EAP }
<--HDR、SKIDr、AUTH、[本命]EAP
HDR, SK {EAP} -->
HDR、SK EAP-->。
<-- HDR, SK {EAP (success)}
<--HDR、SKEAP(成功)
HDR, SK {AUTH} -->
HDR、SK AUTH-->。
<-- HDR, SK {AUTH, SAr2, TSi, TSr }
<--HDR、SKAUTH、SAr2、TSi、TSr
For EAP methods that create a shared key as a side effect of authentication, that shared key MUST be used by both the initiator and responder to generate AUTH payloads in messages 7 and 8 using the syntax for shared secrets specified in section 2.15. The shared key from EAP is the field from the EAP specification named MSK. The shared key generated during an IKE exchange MUST NOT be used for any other purpose.
認証の副作用として共有されたキーを作成するEAPメソッドのために、創始者と応答者の両方でその共有されたキーを使用して、メッセージ7と8でセクション2.15で指定された共有秘密キーに構文を使用することでAUTHにペイロードを生成しなければなりません。 EAPからの共有されたキーはMSKというEAP仕様からの分野です。 いかなる他の目的にもIKE交換の間に生成された共有されたキーを使用してはいけません。
EAP methods that do not establish a shared key SHOULD NOT be used, as they are subject to a number of man-in-the-middle attacks [EAPMITM] if these EAP methods are used in other protocols that do not use a server-authenticated tunnel. Please see the Security Considerations section for more details. If EAP methods that do not generate a shared key are used, the AUTH payloads in messages 7 and 8 MUST be generated using SK_pi and SK_pr, respectively.
共有された主要なSHOULD NOTを設立しないEAPメソッドが使用されて、これらのEAPメソッドがサーバで認証されたトンネルを使用しない他のプロトコルに使用されるなら、それらのように[EAPMITM]を多くの介入者攻撃にかけてください。 その他の詳細に関してSecurity Considerations部を見てください。 共有されたキーを生成しないEAPメソッドが使用されているなら、SK_パイを使用して、SK_prであるとそれぞれメッセージ7と8のAUTHペイロードを生成しなければなりません。
The initiator of an IKE_SA using EAP SHOULD be capable of extending the initial protocol exchange to at least ten IKE_AUTH exchanges in the event the responder sends notification messages and/or retries the authentication prompt. Once the protocol exchange defined by the chosen EAP authentication method has successfully terminated, the responder MUST send an EAP payload containing the Success message. Similarly, if the authentication method has failed, the responder MUST send an EAP payload containing the Failure message. The responder MAY at any time terminate the IKE exchange by sending an EAP payload containing the Failure message.
EAP SHOULDを使用するIKE_SAの創始者は、初期のプロトコル交換を応答者が通知メッセージを送る出来事における少なくとも10回のイケ_AUTH交換まで広げることができる、そして/または、認証プロンプトを再試行します。 選ばれたEAP認証方法で定義されたプロトコル交換がいったん首尾よく終わると、応答者はSuccessメッセージを含むEAPペイロードを送らなければなりません。 同様に、認証方法が失敗したなら、応答者はFailureメッセージを含むEAPペイロードを送らなければなりません。 5月の何時でも応答者は、Failureメッセージを含むEAPペイロードを送ることによって、IKE交換を終えます。
Kaufman Standards Track [Page 32] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[32ページ]RFC4306IKEv2 December 2005
Following such an extended exchange, the EAP AUTH payloads MUST be included in the two messages following the one containing the EAP Success message.
そのような拡張交換に続いて、EAP Successメッセージを含むものに続く2つのメッセージにEAP AUTHペイロードを含まなければなりません。
2.17. Generating Keying Material for CHILD_SAs
2.17. 子供_SAsのために材料を合わせる発生
A single CHILD_SA is created by the IKE_AUTH exchange, and additional CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges. Keying material for them is generated as follows:
イケ_AUTH交換で独身のCHILD_SAを作成します、そして、CREATE_CHILD_SA交換で追加CHILD_SAsを任意に作成できます。 それらのために材料を合わせるのは以下の通り発生します:
KEYMAT = prf+(SK_d, Ni | Nr)
KEYMATはprf+と等しいです。(Ni| SK、Nr)
Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this request is the first CHILD_SA created or the fresh Ni and Nr from the CREATE_CHILD_SA exchange if this is a subsequent creation.
_NiとNrがイケからの一回だけであるところと、SA_INITはこれがその後の創造であるならCREATE_CHILD_SA交換からこの要求がSAが作成した最初のCHILD_かそれとも新鮮なNiであるか、そして、Nrを交換します。
For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman exchange, the keying material is defined as:
任意のディフィー-ヘルマンの交換を含むSAが交換するCREATE_CHILD_に関しては、合わせることの材料は以下と定義されます。
KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
KEYMATはprf+と等しいです。(SK、g^、不-、(新しい)| Ni| Nr、)
where g^ir (new) is the shared secret from the ephemeral Diffie- Hellman exchange of this CREATE_CHILD_SA exchange (represented as an octet string in big endian order padded with zeros in the high-order bits if necessary to make it the length of the modulus).
どこg^、不-、(新しい)であることは、このCREATE_CHILD_SA交換(ゼロが高位のビットにある状態でビッグエンディアンオーダーにおける八重奏ストリングが必要なら、それを係数の長さにするようにそっと歩いたので、表される)のはかないディフィーのヘルマンの交換からの共有秘密キーであるか。
A single CHILD_SA negotiation may result in multiple security associations. ESP and AH SAs exist in pairs (one in each direction), and four SAs could be created in a single CHILD_SA negotiation if a combination of ESP and AH is being negotiated.
ただ一つのCHILD_SA交渉は複数のセキュリティ協会をもたらすかもしれません。 超能力とAH SAsが対になって存在している、(あるコネ、各指示)、超能力とAHの組み合わせが交渉されているなら、4SAsがただ一つのCHILD_SA交渉で作成されるかもしれません。
Keying material MUST be taken from the expanded KEYMAT in the following order:
以下のオーダーで拡張KEYMATから材料を合わせるのを取らなければなりません:
All keys for SAs carrying data from the initiator to the responder
are taken before SAs going in the reverse direction.
創始者から応答者までデータを運ぶSAsのためのすべてのキーが反対の方向を調べるSAsに出頭します。
If multiple IPsec protocols are negotiated, keying material is
taken in the order in which the protocol headers will appear in
the encapsulated packet.
複数のIPsecプロトコルを交渉するなら、プロトコルヘッダーが要約のパケットに現れるオーダーで材料を合わせるのを取ります。
If a single protocol has both encryption and authentication keys,
the encryption key is taken from the first octets of KEYMAT and
the authentication key is taken from the next octets.
ただ一つのプロトコルに暗号化と認証キーの両方があるなら、KEYMATの最初の八重奏から暗号化キーを取ります、そして、次の八重奏から認証キーを取ります。
Each cryptographic algorithm takes a fixed number of bits of keying material specified as part of the algorithm.
各暗号アルゴリズムはアルゴリズムの一部として指定された合わせることの材料のかけらの定数を取ります。
Kaufman Standards Track [Page 33] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[33ページ]RFC4306IKEv2 December 2005
2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA exchange
2.18. Rekeying IKE_SAs UsingはCREATE_CHILD_SA交換です。
The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA (see section 2.8). New initiator and responder SPIs are supplied in the SPI fields. The TS payloads are omitted when rekeying an IKE_SA. SKEYSEED for the new IKE_SA is computed using SK_d from the existing IKE_SA as follows:
既存のIKE_SAをrekeyするのにCREATE_CHILD_SA交換を使用できます(セクション2.8を見てください)。 SPI分野で新しい創始者と応答者SPIsを供給します。 IKE_SAを「再-合わせ」るとき、TSペイロードは省略されます。 新しいIKE_SAのためのSKEYSEEDは以下の既存のIKE_SAからSKを使用することで計算されます:
SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)
SKEYSEEDはprfと等しいです。(SK(古い)、[g^、不-、(新しい]| Ni| Nr、)
where g^ir (new) is the shared secret from the ephemeral Diffie- Hellman exchange of this CREATE_CHILD_SA exchange (represented as an octet string in big endian order padded with zeros if necessary to make it the length of the modulus) and Ni and Nr are the two nonces stripped of any headers.
どこg^、不-、(新しい)であることが、このCREATE_CHILD_SA交換(ビッグエンディアンオーダーにおける八重奏ストリングが必要なら、それを係数の長さにするようにゼロでそっと歩いたので、表される)のはかないディフィーのヘルマンの交換からの共有秘密キーであり、NiとNrはどんなヘッダーも奪い取られた2つの一回だけであるか。
The new IKE_SA MUST reset its message counters to 0.
新しいイケ_SA MUSTはメッセージカウンタを0にリセットしました。
SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as specified in section 2.14.
SK、SK_ai、SK_ar、SK_ei、およびSK_、えー、セクション2.14の指定されるとしてのSKEYSEEDから、計算されます。
2.19. Requesting an Internal Address on a Remote Network
2.19. リモートネットワークに関する内部のアドレスを要求します。
Most commonly occurring in the endpoint-to-security-gateway scenario, an endpoint may need an IP address in the network protected by the security gateway and may need to have that address dynamically assigned. A request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload.
終点からセキュリティゲートウェイへのシナリオに最も一般的に起こって、終点は、セキュリティゲートウェイでネットワークにおけるIPアドレスを保護するのが必要であり、そのアドレスをダイナミックに割り当てさせる必要があるかもしれません。 CPペイロードを含んでいることによってCHILD_SA(メッセージ3に暗黙の要求を含んでいる)を作成するというどんな要求にもそのような仮の住所を求める要求を含むことができます。
This function provides address allocation to an IPsec Remote Access Client (IRAC) trying to tunnel into a network protected by an IPsec Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled address (and optionally other information concerning the protected network) in the IKE_AUTH exchange. The IRAS may procure an address for the IRAC from any number of sources such as a DHCP/BOOTP server or its own address pool.
この機能は、IPsec Remote Access Server(IRAS)によって保護されたネットワークにトンネルを堀ろうとしながら、IPsec Remote Access Client(IRAC)にアドレス配分を供給します。 イケ_AUTH交換がIKE_SAとCHILD_SAを作成するので、IRAC MUSTはイケ_AUTH交換におけるIRASで制御されたアドレス(そして、保護されたネットワークの任意に他の情報)を要求します。 IRASはDHCP/BOOTPサーバかそれ自身のアドレスプールなどのいろいろな源からIRACのためのアドレスを調達するかもしれません。
Initiator Responder
----------------------------- ---------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, CP(CFG_REQUEST),
SAi2, TSi, TSr} -->
創始者応答者----------------------------- --------------------------- HDR、SK、IDi、[CERTREQ][IDr]AUTH、CP(CFG_要求)、SAi2、TSi、[本命]TSr--、>。
<-- HDR, SK {IDr, [CERT,] AUTH,
CP(CFG_REPLY), SAr2,
TSi, TSr}
<--HDR、SKIDr、[本命]AUTH、CP(CFG_回答)、SAr2、TSi、TSr
Kaufman Standards Track [Page 34] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[34ページ]RFC4306IKEv2 December 2005
In all cases, the CP payload MUST be inserted before the SA payload. In variations of the protocol where there are multiple IKE_AUTH exchanges, the CP payloads MUST be inserted in the messages containing the SA payloads.
すべての場合では、SAペイロードの前にCPペイロードを挿入しなければなりません。 複数のイケ_AUTH交換があるプロトコルの変化では、SAペイロードを含むメッセージにCPペイロードを挿入しなければなりません。
CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute (either IPv4 or IPv6) but MAY contain any number of additional attributes the initiator wants returned in the response.
CP(CFG_REQUEST)は少なくともINTERNAL_ADDRESS属性(IPv4かIPv6のどちらか)を含まなければなりませんが、創始者必需品が応答で返したいろいろな追加属性を含むかもしれません。
For example, message from initiator to responder:
CP(CFG_REQUEST)=
INTERNAL_ADDRESS(0.0.0.0)
INTERNAL_NETMASK(0.0.0.0)
INTERNAL_DNS(0.0.0.0)
TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
例えば、創始者から応答者まで通信してください: CP(CFG_要求)が内部の_アドレスと等しい、(0.0の.0の.0の)内部の_ネットマスク、(0.0.0の.0の)内部の_DNS、(0.0.0.0)TSi=(0、0-65535、0.0.0.0-255.255.255.255)TSrは等しいです。(0, 0-65535,0.0.0.0-255.255.255.255)
NOTE: Traffic Selectors contain (protocol, port range, address range).
以下に注意してください。 交通Selectorsは(プロトコル、ポート範囲、アドレスの範囲)を含んでいます。
Message from responder to initiator:
応答者から創始者までのメッセージ:
CP(CFG_REPLY)=
INTERNAL_ADDRESS(192.0.2.202)
INTERNAL_NETMASK(255.255.255.0)
INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
CP(CFG_回答)が内部の_アドレスと等しい、(192.0の.2の.202の)内部の_ネットマスク、(255.255、.255、.0の)内部の_サブネット、(192.0.2.0/255.255.255.0)TSi=(0、0-65535、192.0.2.202-192.0.2.202)TSrは等しいです。(0, 0-65535,192.0.2.0-192.0.2.255)
All returned values will be implementation dependent. As can be seen in the above example, the IRAS MAY also send other attributes that were not included in CP(CFG_REQUEST) and MAY ignore the non-mandatory attributes that it does not support.
すべての戻り値が実現に依存するようになるでしょう。 上記の例で見ることができるように、IRASは、また、CP(CFG_REQUEST)に含まれていなかった他の属性を送って、それが支持しない非義務的な属性を無視するかもしれません。
The responder MUST NOT send a CFG_REPLY without having first received a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS to perform an unnecessary configuration lookup if the IRAC cannot process the REPLY. In the case where the IRAS's configuration requires that CP be used for a given identity IDi, but IRAC has failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the IKE exchange with a FAILED_CP_REQUIRED error.
CP(CFG_REQUEST)が最初に受信していなくて、応答者は創始者からCFG_REPLYを送ってはいけません、IRACがREPLYを処理できないなら私たちが、IRASに不要な構成ルックアップを実行して欲しいと思わないので。 IRASの構成が、CPがしかし、IDi、IRACがCPを送らない与えられたアイデンティティ(CFG_REQUEST)に使用されるのを必要とする場合では、IRASは、FAILED_CP_REQUIRED誤りで要求に失敗して、IKE交換を終えなければなりません。
2.20. Requesting the Peer's Version
2.20. 同輩のバージョンを要求します。
An IKE peer wishing to inquire about the other peer's IKE software version information MAY use the method below. This is an example of a configuration request within an INFORMATIONAL exchange, after the IKE_SA and first CHILD_SA have been created.
もう片方の同輩のIKEソフトウェアバージョン情報について問い合わせをしたがっているIKE同輩は以下の方法を使用するかもしれません。 これはINFORMATIONAL交換の中の構成要求に関する例です、IKE_SAと最初に、CHILD_SAが作成された後に。
Kaufman Standards Track [Page 35] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[35ページ]RFC4306IKEv2 December 2005
An IKE implementation MAY decline to give out version information prior to authentication or even after authentication to prevent trolling in case some implementation is known to have some security weakness. In that case, it MUST either return an empty string or no CP payload if CP is not supported.
IKE実現は、認証の前か認証の後にさえ何らかの実現には何らかのセキュリティ弱点があるのが知られているといけないので輪唱するのを防ぐためにバージョン情報を発表するのを断るかもしれません。 その場合、空のストリングを返しますが、CPが支持されないなら、それはどんなCPペイロードも返してはいけません。
Initiator Responder
----------------------------- --------------------------
HDR, SK{CP(CFG_REQUEST)} -->
<-- HDR, SK{CP(CFG_REPLY)}
創始者応答者----------------------------- -------------------------- HDR、SK CP(CFG_要求)--><--HDR、SKCP(CFG_回答)
CP(CFG_REQUEST)=
APPLICATION_VERSION("")
CP(CFG_要求)はアプリケーション_バージョンと等しいです。("")
CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar
Inc.")
CP(CFG_回答)アプリケーション_バージョン(「foobar v1.3beta、(c)Foo Bar Inc.」)
2.21. Error Handling
2.21. エラー処理
There are many kinds of errors that can occur during IKE processing. If a request is received that is badly formatted or unacceptable for reasons of policy (e.g., no matching cryptographic algorithms), the response MUST contain a Notify payload indicating the error. If an error occurs outside the context of an IKE request (e.g., the node is getting ESP messages on a nonexistent SPI), the node SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem.
IKE処理の間に発生できる多くの種類の誤りがあります。 要求が受信されているなら、それが方針(例えば、合っている暗号アルゴリズムがない)の理由でひどくフォーマットされているか、または容認できません、応答は誤りを示すNotifyペイロードを含まなければなりません。 誤りがIKE要求の文脈の外で発生するなら(例えば、ノードは実在しないSPIに関する超能力メッセージを得ています)、ノードSHOULDはNotifyペイロードが問題について説明しているINFORMATIONAL交換を起こします。
Errors that occur before a cryptographically protected IKE_SA is established must be handled very carefully. There is a trade-off between wanting to be helpful in diagnosing a problem and responding to it and wanting to avoid being a dupe in a denial of service attack based on forged messages.
非常に慎重に暗号で保護されたIKE_SAが設立される前に発生する誤りを扱わなければなりません。 問題を診断して、それに応じる際に役立ちたくて、偽造メッセージに基づくサービス不能攻撃でお人よしであることを避けたいとき、トレードオフがあります。
If a node receives a message on UDP port 500 or 4500 outside the context of an IKE_SA known to it (and not a request to start one), it may be the result of a recent crash of the node. If the message is marked as a response, the node MAY audit the suspicious event but MUST NOT respond. If the message is marked as a request, the node MAY audit the suspicious event and MAY send a response. If a response is sent, the response MUST be sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID copied. The response MUST NOT be cryptographically protected and MUST contain a Notify payload indicating INVALID_IKE_SPI.
ノードがそれ(そして、1つを始めるという要求でない)に知られているIKE_SAの文脈の外に500か4500のUDPポートに関するメッセージを受け取るなら、それはノードの最近のクラッシュの結果であるかもしれません。 メッセージが応答としてマークされるなら、ノードは、疑わしげな出来事を監査するかもしれませんが、応じてはいけません。 メッセージが要求としてマークされるなら、ノードは、疑わしげな出来事を監査して、応答を送るかもしれません。 応答を送るなら、応答を同じIKE SPIsとMessage IDがコピーされている状態でそれが来させた起源からIPアドレスとポートに送らなければなりません。 応答は、暗号で保護されてはいけなくて、INVALID_IKE_SPIを示すNotifyペイロードを含まなければなりません。
A node receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs. The message might be a forgery or might be a response the genuine correspondent was
そのような保護のないNotifyペイロードを受けるノードは、応じてはいけなくて、どんな既存のSAsの州も変えてはいけません。 メッセージは偽造であるかもしれませんか応答が本物であったかもしれないなら、通信員が偽造でした。
Kaufman Standards Track [Page 36] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[36ページ]RFC4306IKEv2 December 2005
tricked into sending. A node SHOULD treat such a message (and also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and SHOULD initiate a liveness test for any such IKE_SA. An implementation SHOULD limit the frequency of such tests to avoid being tricked into participating in a denial of service attack.
発信するようにだまされます。 そのIPへのSAsに関する問題があるかもしれないというヒントのようなメッセージ(そして、ICMPの目的地のように手の届かないネットワークメッセージも)が記述するノードSHOULDの御馳走とSHOULDはどんなそのようなIKE_SAのためにも活性テストを開始します。 サービス不能攻撃に参加するようにだまされながらSHOULDが避けるためにそのようなテストの頻度を制限する実現。
A node receiving a suspicious message from an IP address with which it has an IKE_SA MAY send an IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. The recipient MUST NOT change the state of any SA's as a result but SHOULD audit the event to aid in diagnosing malfunctions. A node MUST limit the rate at which it will send messages in response to unprotected messages.
IKE_SA MAYがそれでそのSAの上のIKE INFORMATIONAL交換でIKE Notifyペイロードを送るIPアドレスから疑わしげなメッセージを受け取るノード。 受取人はその結果どんなSAの州も変えてはいけませんが、SHOULDは、不調を診断する際に支援するために出来事を監査します。 ノードはそれが保護のないメッセージに対応してメッセージを送るレートを制限しなければなりません。
2.22. IPComp
2.22. IPComp
Use of IP compression [IPCOMP] can be negotiated as part of the setup of a CHILD_SA. While IP compression involves an extra header in each packet and a compression parameter index (CPI), the virtual "compression association" has no life outside the ESP or AH SA that contains it. Compression associations disappear when the corresponding ESP or AH SA goes away. It is not explicitly mentioned in any DELETE payload.
CHILD_SAのセットアップの一部としてIP圧縮[IPCOMP]の使用を交渉できます。 IP圧縮は各パケットと圧縮パラメタインデックス(CPI)に余分なヘッダーにかかわりますが、仮想の「圧縮協会」はそれを含む超能力かAH SAの外で人生を全く過しません。 対応する超能力であるときに、圧縮協会が見えなくなるか、またはAH SAは遠ざかります。 それはどんなDELETEペイロードでも明らかに言及されません。
Negotiation of IP compression is separate from the negotiation of cryptographic parameters associated with a CHILD_SA. A node requesting a CHILD_SA MAY advertise its support for one or more compression algorithms through one or more Notify payloads of type IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT occur in messages that do not contain SA payloads.
IP圧縮の交渉はCHILD_SAに関連している暗号のパラメタの交渉から別々です。 CHILD_SA MAYを要求するノードはタイプIPCOMP_SUPPORTEDの1個以上のNotifyペイロードを通して1つ以上の圧縮アルゴリズムのサポートの広告を出します。 応答はタイプIPCOMP_SUPPORTEDのNotifyペイロードでただ一つの圧縮アルゴリズムの承認を示すかもしれません。 これらのペイロードはSAペイロードを含まないメッセージに現れてはいけません。
Although there has been discussion of allowing multiple compression algorithms to be accepted and to have different compression algorithms available for the two directions of a CHILD_SA, implementations of this specification MUST NOT accept an IPComp algorithm that was not proposed, MUST NOT accept more than one, and MUST NOT compress using an algorithm other than one proposed and accepted in the setup of the CHILD_SA.
複数の圧縮アルゴリズムが受け入れられて、CHILD_SAの2つの方向に利用可能な異なった圧縮アルゴリズムを持っているのを許容する議論がありましたが、この仕様の実現は、提案されなかったIPCompアルゴリズムを受け入れてはいけなくて、1つ以上を受け入れてはいけなくて、湿布がCHILD_SAのセットアップで提案されて、受け入れられたもの以外のアルゴリズムを使用して、受け入れてはいけません。
A side effect of separating the negotiation of IPComp from cryptographic parameters is that it is not possible to propose multiple cryptographic suites and propose IP compression with some of them but not others.
暗号のパラメタとIPCompの交渉を切り離す副作用は他のものではなく、それらのいくつかで複数の暗号のスイートを提案して、IP圧縮を提案するのが可能でないということです。
Kaufman Standards Track [Page 37] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[37ページ]RFC4306IKEv2 December 2005
2.23. NAT Traversal
2.23. NAT縦断
Network Address Translation (NAT) gateways are a controversial subject. This section briefly describes what they are and how they are likely to act on IKE traffic. Many people believe that NATs are evil and that we should not design our protocols so as to make them work better. IKEv2 does specify some unintuitive processing rules in order that NATs are more likely to work.
ネットワークAddress Translation(NAT)ゲートウェイは論議の多い問題です。 このセクションは、それらが何であるか、そして、どのようにIKE交通に影響しそうであるかを簡潔に説明します。 多くの人々が、NATsが不吉であり、それらをうまくいかせるように私たちがプロトコルを設計するべきでないと信じています。 IKEv2は、NATsが、より働きそうなためにいくつかのunintuitive処理規則を指定します。
NATs exist primarily because of the shortage of IPv4 addresses, though there are other rationales. IP nodes that are "behind" a NAT have IP addresses that are not globally unique, but rather are assigned from some space that is unique within the network behind the NAT but that are likely to be reused by nodes behind other NATs. Generally, nodes behind NATs can communicate with other nodes behind the same NAT and with nodes with globally unique addresses, but not with nodes behind other NATs. There are exceptions to that rule. When those nodes make connections to nodes on the real Internet, the NAT gateway "translates" the IP source address to an address that will be routed back to the gateway. Messages to the gateway from the Internet have their destination addresses "translated" to the internal address that will route the packet to the correct endnode.
他の原理がありますが、NATsは主としてIPv4アドレスの不足のために存在しています。 他のNATsの後ろでノードによって再利用されて、NATがおそらくグローバルにユニークでないIPアドレスを持っていますが、いくつかからむしろ割り当てられる“behind"であるIPノード。 一般に、NATsの後ろのノードは、他のNATsの後ろでグローバルにユニークなアドレスで同じNATとノードがある他のノードとコミュニケートしますが、ノードでコミュニケートできません。 その規則への例外があります。 それらのノードが接続を本当のインターネットのノードにすると、NATゲートウェイはゲートウェイに発送して戻されるアドレスにIPソースアドレスを「翻訳します」。 インターネットからのゲートウェイへのメッセージは、それらの送付先アドレスが正しいendnodeにパケットを発送する内部のアドレスに「翻訳されること」を持っています。
NATs are designed to be "transparent" to endnodes. Neither software on the node behind the NAT nor the node on the Internet requires modification to communicate through the NAT. Achieving this transparency is more difficult with some protocols than with others. Protocols that include IP addresses of the endpoints within the payloads of the packet will fail unless the NAT gateway understands the protocol and modifies the internal references as well as those in the headers. Such knowledge is inherently unreliable, is a network layer violation, and often results in subtle problems.
NATsは、endnodesに「透明に」なるように設計されています。 NATの後ろのノードの上のソフトウェアもインターネットのノードも、NATを通って交信するために変更を必要としません。 この透明を達成するのはいくつかのプロトコルによって他のものより難しいです。 NATゲートウェイがヘッダーのそれらと同様にプロトコルを理解して、内部の参照を変更しないと、パケットのペイロードの中に終点のIPアドレスを含んでいるプロトコルが失敗するでしょう。 そのような知識は、本来頼り無く、ネットワーク層違反であり、しばしば微妙な問題をもたらします。
Opening an IPsec connection through a NAT introduces special problems. If the connection runs in transport mode, changing the IP addresses on packets will cause the checksums to fail and the NAT cannot correct the checksums because they are cryptographically protected. Even in tunnel mode, there are routing problems because transparently translating the addresses of AH and ESP packets requires special logic in the NAT and that logic is heuristic and unreliable in nature. For that reason, IKEv2 can negotiate UDP encapsulation of IKE and ESP packets. This encoding is slightly less efficient but is easier for NATs to process. In addition, firewalls may be configured to pass IPsec traffic over UDP but not ESP/AH or vice versa.
NATを通してIPsec接続を開くと、特別な問題は紹介されます。接続が交通機関へ駆け込むと、IPがパケットの上で扱う変化はチェックサムに失敗されるでしょう、そして、それらが暗号で保護されるので、NATはチェックサムを修正できません。 トンネルモードでさえ、その論理が現実に透過的にAHと超能力パケットのアドレスを翻訳するのがNATにおける特別な論理を必要として、発見的であって、頼り無いので、ルーティング問題があります。 その理由で、IKEv2はIKEと超能力パケットのUDPカプセル化を交渉できます。 このコード化は、わずかに効率的ではありませんが、NATsには、処理するのは、より簡単です。 さらに、ファイアウォールは超能力/AHではなく、UDPの上でトラフィックをIPsecに通過するために構成されるかもしれませんか、逆もまた同様です。
Kaufman Standards Track [Page 38] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[38ページ]RFC4306IKEv2 December 2005
It is a common practice of NATs to translate TCP and UDP port numbers as well as addresses and use the port numbers of inbound packets to decide which internal node should get a given packet. For this reason, even though IKE packets MUST be sent from and to UDP port 500, they MUST be accepted coming from any port and responses MUST be sent to the port from whence they came. This is because the ports may be modified as the packets pass through NATs. Similarly, IP addresses of the IKE endpoints are generally not included in the IKE payloads because the payloads are cryptographically protected and could not be transparently modified by NATs.
アドレスと同様にTCPとUDPポートナンバーを翻訳して、どの内部のノードが与えられたパケットを得るはずであるかを決めるのに本国行きのパケットのポートナンバーを使用するのは、NATsの一般的な習慣です。 ポートとUDPポート500にIKEパケットを送らなければなりませんが、それらはどんなポートからも来ることであるに違いありません、そして、受け入れられたこの理由で、応答は起源からポートに送って来たということであるに違いありません。 これはパケットがNATsを通り抜けるときポートが変更されるかもしれないからです。 同様に、IKE終点のIPアドレスをペイロードが暗号で保護されるので一般に、IKEペイロードに含まないで、NATsは透過的に変更できませんでした。
Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working through a NAT, it is generally better to pass IKE packets over port 4500 because some older NATs handle IKE traffic on port 500 cleverly in an attempt to transparently establish IPsec connections between endpoints that don't handle NAT traversal themselves. Such NATs may interfere with the straightforward NAT traversal envisioned by this document, so an IPsec endpoint that discovers a NAT between it and its correspondent MUST send all subsequent traffic to and from port 4500, which NATs should not treat specially (as they might with port 500).
ポート4500はUDPによってカプセル化された超能力とIKEのために予約されます。 NATを終えるとき、いくつかの、より古いNATsがポート500の上で透過的に自分たちでNAT縦断を扱わない終点の間のIPsec接続を確立する試みで賢くIKEトラフィックを扱うので、一般に、ポート4500の上をパケットがIKEに通るほうがよいです。 そのようなNATsがこのドキュメントによって思い描かれた簡単なNAT縦断を妨げるかもしれないので、それとその通信員の間のNATを発見するIPsec終点はポートとポート4500からすべてのその後のトラフィックを送らなければなりません(彼らがポート500でそうするかもしれないように)。特に、NATsはポートを扱うはずがありません。
The specific requirements for supporting NAT traversal [RFC3715] are listed below. Support for NAT traversal is optional. In this section only, requirements listed as MUST apply only to implementations supporting NAT traversal.
NATが縦断[RFC3715]であるとサポートするための決められた一定の要求は以下にリストアップされています。 NAT縦断のサポートは任意です。 このセクションだけで、NATが縦断であるとサポートする実装だけに適用しなければならないとき、要件はリストアップされました。
IKE MUST listen on port 4500 as well as port 500. IKE MUST
respond to the IP address and port from which packets arrived.
イケは、ポート4500の上で聴いて、500を移植しなければなりません。 イケはパケットが到着したIPアドレスとポートに応じなければなりません。
Both IKE initiator and responder MUST include in their IKE_SA_INIT
packets Notify payloads of type NAT_DETECTION_SOURCE_IP and
NAT_DETECTION_DESTINATION_IP. Those payloads can be used to
detect if there is NAT between the hosts, and which end is behind
the NAT. The location of the payloads in the IKE_SA_INIT packets
are just after the Ni and Nr payloads (before the optional CERTREQ
payload).
IKE創始者と応答者の両方がそれらの_タイプNAT_DETECTION_SOURCE_IPとNAT DETECTION_DESTINATIONのイケ_SA_INITパケットNotifyペイロードで_IPを入れなければなりません。 ホストの間には、NATがあって、NATの後ろにどの終わりがあるかを検出するのにそれらのペイロードを使用できます。 NiとNrペイロード(任意のCERTREQペイロードの前の)のすぐ後に、イケ_SA_INITパケットのペイロードの位置があります。
If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches
the hash of the source IP and port found from the IP header of the
packet containing the payload, it means that the other end is
behind NAT (i.e., someone along the route changed the source
address of the original packet to match the address of the NAT
box). In this case, this end should allow dynamic update of the
other ends IP address, as described later.
NAT_DETECTION_SOURCE_IPペイロードのいずれもソースIPとポートのハッシュがペイロードを含むパケットのIPヘッダーから見つけたマッチを受けなかったなら、それは、NATの後ろにもう一方の端があることを意味します(すなわち、ルートに沿っただれかがNAT箱のアドレスを合わせるためにオリジナルのパケットのソースアドレスを変えました)。 この場合、この終わりは後で説明されるようにもう片方の終わりのIPアドレスのダイナミックなアップデートを許すべきです。
Kaufman Standards Track [Page 39] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[39ページ]RFC4306IKEv2 December 2005
If the NAT_DETECTION_DESTINATION_IP payload received does not
match the hash of the destination IP and port found from the IP
header of the packet containing the payload, it means that this
end is behind a NAT. In this case, this end SHOULD start sending
keepalive packets as explained in [Hutt05].
DESTINATION_IPペイロードが受けたNAT_DETECTION_がIPとポートがペイロードを含むパケットのIPヘッダーから当たった目的地のハッシュに合っていないなら、それは、NATの後ろにこの終わりがあることを意味します。 この場合、この終わりのSHOULDは[Hutt05]で説明されるようにkeepaliveパケットを送り始めます。
The IKE initiator MUST check these payloads if present and if they
do not match the addresses in the outer packet MUST tunnel all
future IKE and ESP packets associated with this IKE_SA over UDP
port 4500.
存在しているなら、IKE創始者はこれらのペイロードをチェックしなければなりません、そして、合っていないなら、外側のパケットのアドレスはすべての未来にIKEにトンネルを堀らなければなりません、そして、UDPの上のこのIKE_SAに関連している超能力パケットは4500を移植します。
To tunnel IKE packets over UDP port 4500, the IKE header has four
octets of zero prepended and the result immediately follows the
UDP header. To tunnel ESP packets over UDP port 4500, the ESP
header immediately follows the UDP header. Since the first four
bytes of the ESP header contain the SPI, and the SPI cannot
validly be zero, it is always possible to distinguish ESP and IKE
messages.
IKEヘッダーはゼロの4つの八重奏をprependedさせます、そして、UDPの上でIKEパケットにトンネルを堀るために、4500を移植してください、そして、結果はすぐに、UDPヘッダーに続きます。 UDPの上で超能力パケットにトンネルを堀るために、4500を移植してください、そして、超能力ヘッダーはすぐに、UDPヘッダーについて来ます。 超能力ヘッダーの最初の4バイトがSPIを含んでいて、SPIが確実にゼロであるはずがないので、超能力とIKEメッセージを区別するのはいつも可能です。
The original source and destination IP address required for the
transport mode TCP and UDP packet checksum fixup (see [Hutt05])
are obtained from the Traffic Selectors associated with the
exchange. In the case of NAT traversal, the Traffic Selectors
MUST contain exactly one IP address, which is then used as the
original IP address.
交換に関連しているTraffic Selectorsから交通機関TCPとUDPパケットチェックサムfixup([Hutt05]を見る)に必要である一次資料と送付先IPアドレスを得ます。 NAT縦断の場合では、Traffic Selectorsはまさに1つのIPアドレスを含まなければなりません。(次に、それは、オリジナルのIPアドレスとして使用されます)。
There are cases where a NAT box decides to remove mappings that
are still alive (for example, the keepalive interval is too long,
or the NAT box is rebooted). To recover in these cases, hosts
that are not behind a NAT SHOULD send all packets (including
retransmission packets) to the IP address and port from the last
valid authenticated packet from the other end (i.e., dynamically
update the address). A host behind a NAT SHOULD NOT do this
because it opens a DoS attack possibility. Any authenticated IKE
packet or any authenticated UDP-encapsulated ESP packet can be
used to detect that the IP address or the port has changed.
ケースがNAT箱がまだ生きているマッピングを取り除くと決める(例えば、keepalive間隔が長過ぎますか、またはNAT箱はリブートされます)ところにあります。 これらの場合で回復するために、NAT SHOULDの後ろにいないホストはすべてのパケット(「再-トランスミッション」パケットを含んでいる)を最後の有効な認証されたパケットからもう一方の端からIPアドレスとポートに送ります(すなわち、ダイナミックにアドレスをアップデートしてください)。 DoS攻撃の可能性を開くので、NAT SHOULD NOTの後ろのホストはこれをします。 どんな認証されたIKEパケットかどんな認証されたUDPによってカプセル化された超能力パケットによるそれを検出するのに使用されて、IPアドレスかポートが変化したということであることができます。
Note that similar but probably not identical actions will likely
be needed to make IKE work with Mobile IP, but such processing is
not addressed by this document.
IKEをモバイルIPと共に働かせるのに同様の、しかし、たぶん同じでない動きがおそらく必要ですが、そのような処理がこのドキュメントによって扱われないことに注意してください。
2.24. Explicit Congestion Notification (ECN)
2.24. 明白な混雑通知(電子証券取引ネットワーク)
When IPsec tunnels behave as originally specified in [RFC2401], ECN usage is not appropriate for the outer IP headers because tunnel decapsulation processing discards ECN congestion indications to the detriment of the network. ECN support for IPsec tunnels for IKEv1- based IPsec requires multiple operating modes and negotiation (see
IPsecトンネルが元々[RFC2401]で指定されるように振る舞うとき、トンネル被膜剥離術処理が電子証券取引ネットワークの混雑指摘をネットワークの損傷に捨てるので、外側のIPヘッダーには、電子証券取引ネットワーク用法は適切ではありません。 IKEv1のベースのIPsecのためのIPsecトンネルの電子証券取引ネットワークのサポートが複数のオペレーティング・モードと交渉を必要とする、(見る。
Kaufman Standards Track [Page 40] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[40ページ]RFC4306IKEv2 December 2005
[RFC3168]). IKEv2 simplifies this situation by requiring that ECN be usable in the outer IP headers of all tunnel-mode IPsec SAs created by IKEv2. Specifically, tunnel encapsulators and decapsulators for all tunnel-mode SAs created by IKEv2 MUST support the ECN full- functionality option for tunnels specified in [RFC3168] and MUST implement the tunnel encapsulation and decapsulation processing specified in [RFC4301] to prevent discarding of ECN congestion indications.
[RFC3168。) 電子証券取引ネットワークがIKEv2によって作成されたすべてのトンネルモードIPsec SAsの外側のIPヘッダーで使用可能であることを必要とすることによって、IKEv2はこの状況を簡素化します。 明確に、IKEv2によって作成されたすべてのトンネルモードSAsのためのトンネルencapsulatorsとdecapsulatorsは、トンネルカプセル化と被膜剥離術が電子証券取引ネットワークの混雑指摘を捨てるのを防ぐために[RFC4301]で指定された処理であると電子証券取引ネットワークの完全な機能性が[RFC3168]で指定されたトンネルのためのオプションであるとサポートしなければならなくて、実装しなければなりません。
3. Header and Payload Formats
3. ヘッダーと有効搭載量形式
3.1. The IKE Header
3.1. IKEヘッダー
IKE messages use UDP ports 500 and/or 4500, with one IKE message per UDP datagram. Information from the beginning of the packet through the UDP header is largely ignored except that the IP addresses and UDP ports from the headers are reversed and used for return packets. When sent on UDP port 500, IKE messages begin immediately following the UDP header. When sent on UDP port 4500, IKE messages have prepended four octets of zero. These four octets of zero are not part of the IKE message and are not included in any of the length fields or checksums defined by IKE. Each IKE message begins with the IKE header, denoted HDR in this memo. Following the header are one or more IKE payloads each identified by a "Next Payload" field in the preceding payload. Payloads are processed in the order in which they appear in an IKE message by invoking the appropriate processing routine according to the "Next Payload" field in the IKE header and subsequently according to the "Next Payload" field in the IKE payload itself until a "Next Payload" field of zero indicates that no payloads follow. If a payload of type "Encrypted" is found, that payload is decrypted and its contents parsed as additional payloads. An Encrypted payload MUST be the last payload in a packet and an Encrypted payload MUST NOT contain another Encrypted payload.
IKEメッセージはUDPデータグラムあたり1つのIKEメッセージがある500、そして/または、4500のUDPポートを使用します。 ヘッダーからのIPアドレスとUDPポートがリターンパケットに逆にされて、使用されるのを除いて、パケットの始まりからUDPヘッダーの情報は主に無視されます。 UDPポート500に送ると、IKEメッセージはすぐに、UDPヘッダーに続き始めます。 転送すると、UDPは4500を移植して、IKEメッセージはゼロの4つの八重奏をprependedしました。 ゼロのこれらの4つの八重奏は、IKEメッセージの一部でなく、またIKEによって定義された長さの分野かチェックサムのいずれにも含まれていません。 HDRは、このメモでそれぞれのIKEメッセージがIKEヘッダーと共に始まるのを指示しました。 ヘッダーに続くのは、前のペイロードの「次の有効搭載量」分野によってそれぞれ特定された1個以上のIKEペイロードです。 有効搭載量はそれらがIKEメッセージにIKEヘッダーの「次の有効搭載量」分野と次にIKEペイロード自体の「次の有効搭載量」分野に従ってゼロの「次の有効搭載量」分野が、ペイロードが全く続かないのを示すまで適切な処理ルーチンを呼び出すことによって現れるオーダーで処理されます。 「暗号化された」タイプのペイロードが見つけられるなら、そのペイロードは解読されました、そして、コンテンツは追加ペイロードとして分析されました。 Encryptedペイロードはパケットで最後のペイロードであるに違いありません、そして、Encryptedペイロードは別のEncryptedペイロードを含んではいけません。
The Recipient SPI in the header identifies an instance of an IKE security association. It is therefore possible for a single instance of IKE to multiplex distinct sessions with multiple peers.
ヘッダーのRecipient SPIはIKEセキュリティ協会のインスタンスを特定します。 したがって、IKEのただ一つのインスタンスが複数の同輩との異なったセッションを多重送信するのは、可能です。
All multi-octet fields representing integers are laid out in big endian order (aka most significant byte first, or network byte order).
整数を表すマルチ八重奏分野がすべて、ビッグエンディアンオーダーで広げられる、(別名の最も重要なバイト、1番目、またはネットワークバイトオーダー、)
The format of the IKE header is shown in Figure 4.
IKEヘッダーの書式は図4に示されます。
Kaufman Standards Track [Page 41] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[41ページ]RFC4306IKEv2 December 2005
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IKE_SA Initiator's SPI !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IKE_SA Responder's SPI !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Message ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
創始者..応答者; 次..有効搭載量..交換..タイプ..旗..メッセージ..ID..長さ
Figure 4: IKE Header Format
図4: IKEヘッダー形式
o Initiator's SPI (8 octets) - A value chosen by the
initiator to identify a unique IKE security association. This
value MUST NOT be zero.
o 創始者のSPI(8つの八重奏)--ユニークなIKEセキュリティ協会を特定する創始者によって選ばれた値。 この値はゼロであるはずがありません。
o Responder's SPI (8 octets) - A value chosen by the
responder to identify a unique IKE security association. This
value MUST be zero in the first message of an IKE Initial
Exchange (including repeats of that message including a
cookie) and MUST NOT be zero in any other message.
o 応答者のSPI(8つの八重奏)--ユニークなIKEセキュリティ協会を特定する応答者によって選ばれた値。 この値は、IKE Initial Exchange(クッキーを含むそのメッセージの反復を含んでいる)の最初のメッセージのゼロでなければならなく、いかなる他のメッセージのゼロであるはずがありません。
o Next Payload (1 octet) - Indicates the type of payload that
immediately follows the header. The format and value of each
payload are defined below.
o 次の有効搭載量(1つの八重奏)--すぐにヘッダーに続くペイロードのタイプを示します。 それぞれのペイロードの書式と値は以下で定義されます。
o Major Version (4 bits) - Indicates the major version of the IKE
protocol in use. Implementations based on this version of IKE
MUST set the Major Version to 2. Implementations based on
previous versions of IKE and ISAKMP MUST set the Major Version
to 1. Implementations based on this version of IKE MUST reject
or ignore messages containing a version number greater than
2.
o 主要なバージョン(4ビット)--IKEプロトコルの主要なバージョンを使用中に示します。 イケのこのバージョンに基づく実装はメージャーバージョンを2に設定しなければなりません。 IKEとISAKMP MUSTの旧バージョンに基づく実装はメージャーバージョンを1に設定します。 イケのこのバージョンに基づく実装は、2以上のバージョン番号を含むメッセージを、拒絶しなければならないか、または無視しなければなりません。
o Minor Version (4 bits) - Indicates the minor version of the
IKE protocol in use. Implementations based on this version of
IKE MUST set the Minor Version to 0. They MUST ignore the
minor version number of received messages.
o 小さい方のバージョン(4ビット)--IKEプロトコルの小さい方のバージョンを使用中に示します。 イケのこのバージョンに基づく実装はMinorバージョンを0に設定しなければなりません。 彼らは受信されたメッセージのマイナーバージョン番号を無視しなければなりません。
o Exchange Type (1 octet) - Indicates the type of exchange being
used. This constrains the payloads sent in each message and
orderings of messages in an exchange.
o 交換Type(1つの八重奏)--使用される交換のタイプを示します。 これは交換におけるメッセージの各メッセージと受注業務で送られたペイロードを抑制します。
Kaufman Standards Track [Page 42] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[42ページ]RFC4306IKEv2 December 2005
Exchange Type Value
交換タイプ価値
RESERVED 0-33
IKE_SA_INIT 34
IKE_AUTH 35
CREATE_CHILD_SA 36
INFORMATIONAL 37
RESERVED TO IANA 38-239
Reserved for private use 240-255
私用240-255のためのRESERVED0-33イケ_SA_INIT34イケ_AUTH35CREATE_CHILD_SA36INFORMATIONAL37RESERVED TO IANA38-239Reserved
o Flags (1 octet) - Indicates specific options that are set
for the message. Presence of options are indicated by the
appropriate bit in the flags field being set. The bits are
defined LSB first, so bit 0 would be the least significant
bit of the Flags octet. In the description below, a bit
being 'set' means its value is '1', while 'cleared' means
its value is '0'.
o 旗(1つの八重奏)--メッセージに設定される特定のオプションを示します。 オプションの存在は設定される旗の分野で適切なビットによって示されます。 最初にビットが定義されたLSBであるので、ビット0はFlags八重奏の最下位ビットでしょう。 以下での記述では、セットが'クリアされる'間、'値が'1であることを意味する'という少し、'手段であることで、値は'0'です。
-- X(reserved) (bits 0-2) - These bits MUST be cleared
when sending and MUST be ignored on receipt.
-- X(予約されます)(ビット0-2)--これらのビットを発信するとき、きれいにしなければならなくて、領収書の上で無視しなければなりません。
-- I(nitiator) (bit 3 of Flags) - This bit MUST be set in
messages sent by the original initiator of the IKE_SA
and MUST be cleared in messages sent by the original
responder. It is used by the recipient to determine
which eight octets of the SPI were generated by the
recipient.
-- 私(nitiator)(Flagsのビット3)--このビットをIKE_SAのオリジナルの創始者によって送られたメッセージに設定しなければならなくて、オリジナルの応答者によって送られたメッセージできれいにしなければなりません。 それは、SPIのどの8つの八重奏が受取人によって生成されたかを決定するのに受取人によって使用されます。
-- V(ersion) (bit 4 of Flags) - This bit indicates that
the transmitter is capable of speaking a higher major
version number of the protocol than the one indicated
in the major version number field. Implementations of
IKEv2 must clear this bit when sending and MUST ignore
it in incoming messages.
-- V(ersion)(Flagsのビット4)--このビットは、送信機がメジャーバージョン番号分野で示されたものより高いメジャーバージョン番号にプロトコルについて話すことができるのを示します。 IKEv2の実装は、発信するとき、このビットをきれいにしなければならなくて、入力メッセージでそれを無視しなければなりません。
-- R(esponse) (bit 5 of Flags) - This bit indicates that
this message is a response to a message containing
the same message ID. This bit MUST be cleared in all
request messages and MUST be set in all responses.
An IKE endpoint MUST NOT generate a response to a
message that is marked as being a response.
-- R(esponse)(Flagsのビット5)--このビットは、このメッセージが同じメッセージIDを含むメッセージへの応答であることを示します。 このビットをすべての要求メッセージできれいにしなければならなくて、すべての応答で設定しなければなりません。 IKE終点は応答であるとしてマークされるメッセージへの応答を生成してはいけません。
-- X(reserved) (bits 6-7 of Flags) - These bits MUST be
cleared when sending and MUST be ignored on receipt.
-- X(予約されます)(Flagsのビット6-7)--これらのビットを発信するとき、きれいにしなければならなくて、領収書の上で無視しなければなりません。
Kaufman Standards Track [Page 43] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[43ページ]RFC4306IKEv2 December 2005
o Message ID (4 octets) - Message identifier used to control
retransmission of lost packets and matching of requests and
responses. It is essential to the security of the protocol
because it is used to prevent message replay attacks.
See sections 2.1 and 2.2.
o メッセージID(4つの八重奏)--メッセージ識別子は、要求と応答を無くなっているパケットのコントロール「再-トランスミッション」に使用して、合っていました。 それは、メッセージ反射攻撃を防ぐのに使用されるので、プロトコルのセキュリティに不可欠です。 セクション2.1と2.2を見てください。
o Length (4 octets) - Length of total message (header + payloads)
in octets.
o 長さ(4つの八重奏)--八重奏における、総メッセージ(ヘッダー+ペイロード)の長さ。
3.2. Generic Payload Header
3.2. ジェネリック有効搭載量ヘッダー
Each IKE payload defined in sections 3.3 through 3.16 begins with a generic payload header, shown in Figure 5. Figures for each payload below will include the generic payload header, but for brevity the description of each field will be omitted.
セクション3.3〜3.16で定義されたそれぞれのIKEペイロードは図5で見せられたジェネリックペイロードヘッダーと共に始まります。 以下の各ペイロードのための数字はジェネリックペイロードヘッダーを含むでしょうが、簡潔さにおいて、それぞれの分野の記述は省略されるでしょう。
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! ペイロード長!+++++++++++++++++++++++++++++++++を予約します。
Figure 5: Generic Payload Header
図5: 一般的な有効搭載量ヘッダー
The Generic Payload Header fields are defined as follows:
Generic有効搭載量Header分野は以下の通り定義されます:
o Next Payload (1 octet) - Identifier for the payload type of the
next payload in the message. If the current payload is the last
in the message, then this field will be 0. This field provides a
"chaining" capability whereby additional payloads can be added to
a message by appending it to the end of the message and setting
the "Next Payload" field of the preceding payload to indicate the
new payload's type. An Encrypted payload, which must always be
the last payload of a message, is an exception. It contains data
structures in the format of additional payloads. In the header of
an Encrypted payload, the Next Payload field is set to the payload
type of the first contained payload (instead of 0).
o 次の有効搭載量(1つの八重奏)--メッセージの次のペイロードのペイロードタイプへの識別子。 現在のペイロードがメッセージの最終であるなら、この分野は0になるでしょう。 この分野はメッセージの終わりに追加して、前のペイロードの「次の有効搭載量」分野に新しいペイロードのタイプを示すように設定することによって追加ペイロードをメッセージに追加できる「推論」能力を提供します。 Encryptedペイロード(いつもメッセージの最後のペイロードであるに違いない)は例外です。 それは追加ペイロードの形式にデータ構造を含んでいます。 Encryptedペイロードのヘッダーでは、Next有効搭載量分野は最初の含まれたペイロード(0の代わりに)のペイロードタイプに設定されます。
Payload Type Values
有効搭載量タイプ値
Next Payload Type Notation Value
次の有効搭載量タイプ記法価値
No Next Payload 0
次の有効搭載量がありません0。
RESERVED 1-32
Security Association SA 33
Key Exchange KE 34
Identification - Initiator IDi 35
予約された1-32 セキュリティ協会SA33の主要な交換KE34識別--創始者IDi35
Kaufman Standards Track [Page 44] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[44ページ]RFC4306IKEv2 December 2005
Identification - Responder IDr 36
Certificate CERT 37
Certificate Request CERTREQ 38
Authentication AUTH 39
Nonce Ni, Nr 40
Notify N 41
Delete D 42
Vendor ID V 43
Traffic Selector - Initiator TSi 44
Traffic Selector - Responder TSr 45
Encrypted E 46
Configuration CP 47
Extensible Authentication EAP 48
RESERVED TO IANA 49-127
PRIVATE USE 128-255
識別--応答者IDr36の本命37証明書要求CERTREQ38の認証のAUTHの39の一回だけの証明書Ni、40がD42業者ID V43交通セレクタを削除するようにN41に通知するNr--創始者TSi44交通セレクタ--応答者TSr45はIANA49-127私用128-255への予約された46Eの構成CP47の広げることができる認証EAP48をコード化しました。
Payload type values 1-32 should not be used so that there is no
overlap with the code assignments for IKEv1. Payload type values
49-127 are reserved to IANA for future assignment in IKEv2 (see
section 6). Payload type values 128-255 are for private use among
mutually consenting parties.
IKEv1のためのコード課題とのオーバラップが全くないように、有効搭載量タイプ値1-32を使用するべきではありません。 有効搭載量タイプ値49-127はIKEv2の将来の課題のためにIANAに予約されます(セクション6を見てください)。 有効搭載量タイプ値128-255が私的使用目的で互いに同意しているパーティーにあります。
o Critical (1 bit) - MUST be set to zero if the sender wants the
recipient to skip this payload if it does not understand the
payload type code in the Next Payload field of the previous
payload. MUST be set to one if the sender wants the recipient to
reject this entire message if it does not understand the payload
type. MUST be ignored by the recipient if the recipient
understands the payload type code. MUST be set to zero for
payload types defined in this document. Note that the critical
bit applies to the current payload rather than the "next" payload
whose type code appears in the first octet. The reasoning behind
not setting the critical bit for payloads defined in this document
is that all implementations MUST understand all payload types
defined in this document and therefore must ignore the Critical
bit's value. Skipped payloads are expected to have valid Next
Payload and Payload Length fields.
o (1ビット)--それがペイロードを理解しないなら送付者が、受取人にこのペイロードをスキップして欲しいならゼロに設定しなければならないのが前のペイロードのNext有効搭載量分野にコードをタイプすることに批判的です。 それがペイロードタイプを理解しないなら送付者が、受取人にこの全体のメッセージを拒絶して欲しいなら、1つに設定しなければなりません。 受取人がペイロードタイプコードを理解しているなら、受取人は無視しなければなりません。 本書では定義されたペイロードタイプのためのゼロに設定しなければなりません。 重要なビットがタイプコードが最初の八重奏に現れる「次」のペイロードよりむしろ現在のペイロードに適用されることに注意してください。 本書では定義されたペイロードに重要なビットを設定しない後ろの推理はすべての実現が本書では定義されたすべてのペイロードタイプを理解しなければならなくて、したがって、Criticalビットの値を無視しなければならないということです。 スキップされたペイロードには有効なNext有効搭載量と有効搭載量Length分野があると予想されます。
o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on
receipt.
o RESERVED(7ビット)--ゼロとして送らなければなりません。 領収書の上で無視しなければなりません。
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o 有効搭載量Length(2つの八重奏)--一般的なペイロードヘッダーを含む現在のペイロードの八重奏における長さ。
Kaufman Standards Track [Page 45] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[45ページ]RFC4306IKEv2 December 2005
3.3. Security Association Payload
3.3. セキュリティ協会有効搭載量
The Security Association Payload, denoted SA in this memo, is used to negotiate attributes of a security association. Assembly of Security Association Payloads requires great peace of mind. An SA payload MAY contain multiple proposals. If there is more than one, they MUST be ordered from most preferred to least preferred. Each proposal may contain multiple IPsec protocols (where a protocol is IKE, ESP, or AH), each protocol MAY contain multiple transforms, and each transform MAY contain multiple attributes. When parsing an SA, an implementation MUST check that the total Payload Length is consistent with the payload's internal lengths and counts. Proposals, Transforms, and Attributes each have their own variable length encodings. They are nested such that the Payload Length of an SA includes the combined contents of the SA, Proposal, Transform, and Attribute information. The length of a Proposal includes the lengths of all Transforms and Attributes it contains. The length of a Transform includes the lengths of all Attributes it contains.
SAは、このメモでSecurity Association有効搭載量がセキュリティ協会の属性を交渉するのに使用されるのを指示しました。 Security Association有効搭載量の議会はすばらしい心の平静を必要とします。 SAペイロードは複数の提案を含むかもしれません。 1つ以上があれば、最少より大部分から好まれるよう都合のよい状態でそれらを命令しなければなりません。 各提案は複数のIPsecプロトコル(プロトコルがIKE、超能力、またはAHであるところ)を含むかもしれません、そして、各プロトコルは複数の変換を含むかもしれません、そして、各変換は複数の属性を含むかもしれません。 SAを分析するとき、実現は、総有効搭載量Lengthがペイロードの内部の長さとカウントと一致しているのをチェックしなければなりません。 提案、Transforms、およびAttributesには、それぞれそれら自身の可変長encodingsがあります。 それらが入れ子にされるので、SAの有効搭載量LengthはSA、Proposal、Transform、およびAttribute情報の結合したコンテンツを含んでいます。 Proposalの長さはすべてのTransformsとそれが含むAttributesの長さを含んでいます。 Transformの長さはそれが含むすべてのAttributesの長さを含んでいます。
The syntax of Security Associations, Proposals, Transforms, and Attributes is based on ISAKMP; however, the semantics are somewhat different. The reason for the complexity and the hierarchy is to allow for multiple possible combinations of algorithms to be encoded in a single SA. Sometimes there is a choice of multiple algorithms, whereas other times there is a combination of algorithms. For example, an initiator might want to propose using (AH w/MD5 and ESP w/3DES) OR (ESP w/MD5 and 3DES).
Security Associations、Proposals、Transforms、およびAttributesの構文はISAKMPに基づいています。 しかしながら、意味論はいくらか異なっています。 複雑さと階層構造の理由はアルゴリズムの複数の可能な組み合わせが独身のSAでコード化されるのを許容することです。 複数のアルゴリズムの選択が時々ありますが、そこの他の回はアルゴリズムの組み合わせです。例えば、創始者は、OR(MD5と3DESがある超能力)を使用する(MD5とAHと超能力w/3DES)よう提案したがっているかもしれません。
One of the reasons the semantics of the SA payload has changed from ISAKMP and IKEv1 is to make the encodings more compact in common cases.
SAペイロードの意味論がISAKMPとIKEv1から変化した理由の1つはencodingsをよくある例が、よりコンパクトにすることです。
The Proposal structure contains within it a Proposal # and an IPsec protocol ID. Each structure MUST have the same Proposal # as the previous one or be one (1) greater. The first Proposal MUST have a Proposal # of one (1). If two successive structures have the same Proposal number, it means that the proposal consists of the first structure AND the second. So a proposal of AH AND ESP would have two proposal structures, one for AH and one for ESP and both would have Proposal #1. A proposal of AH OR ESP would have two proposal structures, one for AH with Proposal #1 and one for ESP with Proposal #2.
Proposal構造はそれの中にProposal#とIPsecプロトコルIDを含んでいます。 各構造は、前のものと同じProposal#を持っているか、1(1)であるに違いありません。よりすばらしい。 最初のProposalには、1つ(1)のProposal#がなければなりません。 2つの連続した構造に同じProposal番号があるなら、それは、提案が最初の構造と2番目から成ることを意味します。 それで、AH AND ESPの提案には、2つの提案構造があるでしょう、AHのためのもの、超能力と両方のための1つはProposal#1を持っているでしょう。 AH OR ESPの提案には、2つの提案構造、AHのためのものが超能力のためのProposal#1とものと共にあるでしょうProposal#2と共に。
Each Proposal/Protocol structure is followed by one or more transform structures. The number of different transforms is generally determined by the Protocol. AH generally has a single transform: an integrity check algorithm. ESP generally has two: an encryption algorithm and an integrity check algorithm. IKE generally has four
1つがそれぞれのProposal/プロトコル構造のあとに続いているか、または以上は構造を変えます。 一般に、異なった変換の数はプロトコルによって測定されます。 一般に、AHはシングルを変形させます: 保全チェックアルゴリズム。 超能力には、一般に、2があります: 暗号化アルゴリズムと保全はアルゴリズムをチェックします。 一般に、IKEには、4があります。
Kaufman Standards Track [Page 46] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[46ページ]RFC4306IKEv2 December 2005
transforms: a Diffie-Hellman group, an integrity check algorithm, a prf algorithm, and an encryption algorithm. If an algorithm that combines encryption and integrity protection is proposed, it MUST be proposed as an encryption algorithm and an integrity protection algorithm MUST NOT be proposed. For each Protocol, the set of permissible transforms is assigned transform ID numbers, which appear in the header of each transform.
変換: ディフィー-ヘルマングループ、保全チェックアルゴリズム、prfアルゴリズム、および暗号化アルゴリズム。 暗号化と保全保護を結合するアルゴリズムが提案されるなら、暗号化アルゴリズムとしてそれを提案しなければなりません、そして、保全保護アルゴリズムは提案されてはいけません。 各プロトコルにおいて、変換ID番号は許されている変換のセットに配属されます。(番号はそれぞれの変換のヘッダーに現れます)。
If there are multiple transforms with the same Transform Type, the proposal is an OR of those transforms. If there are multiple Transforms with different Transform Types, the proposal is an AND of the different groups. For example, to propose ESP with (3DES or IDEA) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two Transform Type 1 candidates (one for 3DES and one for IDEA) and two Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA). This effectively proposes four combinations of algorithms. If the initiator wanted to propose only a subset of those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that as multiple transforms within a single Proposal. Instead, the initiator would have to construct two different Proposals, each with two transforms.
同じTransform Typeとの複数の変換があれば、提案はそれらの変換のORです。異なったTransform Typesと複数のTransformsがあれば、提案は異なったグループのANDです。 例えば、(3DESかIDEA)がある超能力と(HMAC_MD5かHMAC_SHA)を提案するために、超能力提案は2Transform Type1候補(3DESのためのものとIDEAのためのもの)と2Transform Type2候補(HMAC_MD5のためのものとHMAC_SHAのためのもの)を含むでしょう。 事実上、これはアルゴリズムの4つの組み合わせを提案します。例えば(3DESとHMAC_MD5)、創始者がそれらの部分集合だけを提案したがっていたか、そして、(IDEAとHMAC_SHA)、独身のProposalの中にそれ同じくらい複数の変換をコード化する方法が全くありません。 代わりに、創始者はそれぞれ2つの変換で2異なったProposalsを組み立てなければならないでしょう。
A given transform MAY have one or more Attributes. Attributes are necessary when the transform can be used in more than one way, as when an encryption algorithm has a variable key size. The transform would specify the algorithm and the attribute would specify the key size. Most transforms do not have attributes. A transform MUST NOT have multiple attributes of the same type. To propose alternate values for an attribute (for example, multiple key sizes for the AES encryption algorithm), and implementation MUST include multiple Transforms with the same Transform Type each with a single Attribute.
与えられた変換には、1Attributesがあるかもしれません。 1つ以上の方法で変換を使用できるとき、属性が必要です、暗号化アルゴリズムには可変主要なサイズがある時として。 変換はアルゴリズムを指定するでしょう、そして、属性は主要なサイズを指定するでしょう。 ほとんどの変換には、属性がありません。 変換には、同じタイプの複数の属性があってはいけません。 (例えば、AES暗号化アルゴリズムのための複数の主要なサイズ)、および実現がそうしなければならない属性のために交互の値を提案するには、独身のAttributeと共にそれぞれ同じTransform Typeと複数のTransformsを含めてください。
Note that the semantics of Transforms and Attributes are quite different from those in IKEv1. In IKEv1, a single Transform carried multiple algorithms for a protocol with one carried in the Transform and the others carried in the Attributes.
TransformsとAttributesの意味論がIKEv1のそれらと全く異なっていることに注意してください。 IKEv1では、1つがTransformで運ばれて、他のものがAttributesで運ばれている状態で、独身のTransformはプロトコルのために複数のアルゴリズムを運びました。
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ <Proposals> ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 予約..ペイロード長..提案
Figure 6: Security Association Payload
図6: セキュリティ協会有効搭載量
Kaufman Standards Track [Page 47] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[47ページ]RFC4306IKEv2 December 2005
o Proposals (variable) - One or more proposal substructures.
o 提案(可変)--1つ以上の提案基礎。
The payload type for the Security Association Payload is thirty
three (33).
Security Association有効搭載量のためのペイロードタイプは33(33)です。
3.3.1. Proposal Substructure
3.3.1. 提案基礎
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 (last) or 2 ! RESERVED ! Proposal Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal # ! Protocol ID ! SPI Size !# of Transforms!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ <Transforms> ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+++++++++++++++++++++++++++++++++! 0(最終)か2が!提案#!+++++++++++++++++++++++++++++++++! 提案の長さ!プロトコルID!SPIサイズ#!を予約した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 7: Proposal Substructure
図7: 提案基礎
o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the
last Proposal Substructure in the SA. This syntax is inherited
from ISAKMP, but is unnecessary because the last Proposal could
be identified from the length of the SA. The value (2)
corresponds to a Payload Type of Proposal in IKEv1, and the
first 4 octets of the Proposal structure are designed to look
somewhat like the header of a Payload.
o 0 (最終)か2(より多くの)(1つの八重奏)--これがSAの最後のProposal Substructureであるかどうか指定します。 この構文は、ISAKMPから引き継がれますが、長さから最後のProposalを特定できたので、SAで不要です。 値(2)はIKEv1でProposalの有効搭載量Typeに対応しています、そして、Proposal構造の最初の4つの八重奏が、有効搭載量のヘッダーにいくらか似るように設計されています。
o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on
receipt.
o RESERVED(1つの八重奏)--ゼロとして送らなければなりません。 領収書の上で無視しなければなりません。
o Proposal Length (2 octets) - Length of this proposal, including
all transforms and attributes that follow.
o 提案Length(2つの八重奏)--すべての変換と続く属性を含むこの提案の長さ。
o Proposal # (1 octet) - When a proposal is made, the first
proposal in an SA payload MUST be #1, and subsequent proposals
MUST either be the same as the previous proposal (indicating an
AND of the two proposals) or one more than the previous
proposal (indicating an OR of the two proposals). When a
proposal is accepted, all of the proposal numbers in the SA
payload MUST be the same and MUST match the number on the
proposal sent that was accepted.
o 提案をするときの提案#(1つの八重奏)、SAペイロードにおける最初の提案は#1、に違いない、そして、その後の提案は前の提案(2つの提案のANDを示す)か1つと前の提案よりさらに同じでなければなりません(2つの提案のORを示して)。 提案を受け入れるとき、SAペイロードの提案番号のすべてが、同じでなければならなく、受け入れられた送られた提案の数に合わなければなりません。
Kaufman Standards Track [Page 48] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[48ページ]RFC4306IKEv2 December 2005
o Protocol ID (1 octet) - Specifies the IPsec protocol identifier
for the current negotiation. The defined values are:
o プロトコルID(1つの八重奏)--現在の交渉のためのIPsecプロトコル識別子を指定します。 定義された値は以下の通りです。
Protocol Protocol ID
RESERVED 0
IKE 1
AH 2
ESP 3
RESERVED TO IANA 4-200
PRIVATE USE 201-255
プロトコルプロトコルIDが0イケ1を予約した、ああ、超能力3がIANA4-200私用201-255に予約した2
o SPI Size (1 octet) - For an initial IKE_SA negotiation, this
field MUST be zero; the SPI is obtained from the outer header.
During subsequent negotiations, it is equal to the size, in
octets, of the SPI of the corresponding protocol (8 for IKE, 4
for ESP and AH).
o SPI Size(1つの八重奏)--初期のIKE_SA交渉のために、この分野はゼロでなければなりません。 外側のヘッダーからSPIを入手します。 その後の交渉の間、それはサイズと等しいです、対応するプロトコル(IKEのための8、超能力のための4、およびAH)のSPIの八重奏で。
o # of Transforms (1 octet) - Specifies the number of transforms
in this proposal.
o # Transforms(1つの八重奏)--この提案における、変換の数を指定します。
o SPI (variable) - The sending entity's SPI. Even if the SPI Size
is not a multiple of 4 octets, there is no padding applied to
the payload. When the SPI Size field is zero, this field is
not present in the Security Association payload.
o SPI(可変)--送付実体のSPI。 SPI Sizeが4つの八重奏の倍数でなくても、ペイロードに適用された水増しがありません。 SPI Size分野がゼロであるときに、この分野はSecurity Associationペイロードに存在していません。
o Transforms (variable) - One or more transform substructures.
o 変換(可変)--ものか以上が基礎を変えます。
3.3.2. Transform Substructure
3.3.2. 基礎を変えてください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 (last) or 3 ! RESERVED ! Transform Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!Transform Type ! RESERVED ! Transform ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Transform Attributes ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 (last) or 3 ! RESERVED ! Transform Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !Transform Type ! RESERVED ! Transform ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Transform Attributes ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Transform Substructure
エイト環: 基礎を変えてください。
o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the
last Transform Substructure in the Proposal. This syntax is
inherited from ISAKMP, but is unnecessary because the last
Proposal could be identified from the length of the SA. The
o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the last Transform Substructure in the Proposal. This syntax is inherited from ISAKMP, but is unnecessary because the last Proposal could be identified from the length of the SA. The
Kaufman Standards Track [Page 49] RFC 4306 IKEv2 December 2005
Kaufman Standards Track [Page 49] RFC 4306 IKEv2 December 2005
value (3) corresponds to a Payload Type of Transform in IKEv1,
and the first 4 octets of the Transform structure are designed
to look somewhat like the header of a Payload.
value (3) corresponds to a Payload Type of Transform in IKEv1, and the first 4 octets of the Transform structure are designed to look somewhat like the header of a Payload.
o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
o Transform Length - The length (in octets) of the Transform
Substructure including Header and Attributes.
o Transform Length - The length (in octets) of the Transform Substructure including Header and Attributes.
o Transform Type (1 octet) - The type of transform being
specified in this transform. Different protocols support
different transform types. For some protocols, some of the
transforms may be optional. If a transform is optional and the
initiator wishes to propose that the transform be omitted, no
transform of the given type is included in the proposal. If
the initiator wishes to make use of the transform optional to
the responder, it includes a transform substructure with
transform ID = 0 as one of the options.
o Transform Type (1 octet) - The type of transform being specified in this transform. Different protocols support different transform types. For some protocols, some of the transforms may be optional. If a transform is optional and the initiator wishes to propose that the transform be omitted, no transform of the given type is included in the proposal. If the initiator wishes to make use of the transform optional to the responder, it includes a transform substructure with transform ID = 0 as one of the options.
o Transform ID (2 octets) - The specific instance of the
transform type being proposed.
o Transform ID (2 octets) - The specific instance of the transform type being proposed.
Transform Type Values
Transform Type Values
Transform Used In
Type
RESERVED 0
Encryption Algorithm (ENCR) 1 (IKE and ESP)
Pseudo-random Function (PRF) 2 (IKE)
Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP)
Diffie-Hellman Group (D-H) 4 (IKE, optional in AH & ESP)
Extended Sequence Numbers (ESN) 5 (AH and ESP)
RESERVED TO IANA 6-240
PRIVATE USE 241-255
Transform Used In Type RESERVED 0 Encryption Algorithm (ENCR) 1 (IKE and ESP) Pseudo-random Function (PRF) 2 (IKE) Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP) Diffie-Hellman Group (D-H) 4 (IKE, optional in AH & ESP) Extended Sequence Numbers (ESN) 5 (AH and ESP) RESERVED TO IANA 6-240 PRIVATE USE 241-255
For Transform Type 1 (Encryption Algorithm), defined Transform IDs are:
For Transform Type 1 (Encryption Algorithm), defined Transform IDs are:
Name Number Defined In
RESERVED 0
ENCR_DES_IV64 1 (RFC1827)
ENCR_DES 2 (RFC2405), [DES]
ENCR_3DES 3 (RFC2451)
ENCR_RC5 4 (RFC2451)
ENCR_IDEA 5 (RFC2451), [IDEA]
ENCR_CAST 6 (RFC2451)
ENCR_BLOWFISH 7 (RFC2451)
ENCR_3IDEA 8 (RFC2451)
Name Number Defined In RESERVED 0 ENCR_DES_IV64 1 (RFC1827) ENCR_DES 2 (RFC2405), [DES] ENCR_3DES 3 (RFC2451) ENCR_RC5 4 (RFC2451) ENCR_IDEA 5 (RFC2451), [IDEA] ENCR_CAST 6 (RFC2451) ENCR_BLOWFISH 7 (RFC2451) ENCR_3IDEA 8 (RFC2451)
Kaufman Standards Track [Page 50] RFC 4306 IKEv2 December 2005
Kaufman Standards Track [Page 50] RFC 4306 IKEv2 December 2005
ENCR_DES_IV32 9
RESERVED 10
ENCR_NULL 11 (RFC2410)
ENCR_AES_CBC 12 (RFC3602)
ENCR_AES_CTR 13 (RFC3664)
ENCR_DES_IV32 9 RESERVED 10 ENCR_NULL 11 (RFC2410) ENCR_AES_CBC 12 (RFC3602) ENCR_AES_CTR 13 (RFC3664)
values 14-1023 are reserved to IANA. Values 1024-65535 are
for private use among mutually consenting parties.
values 14-1023 are reserved to IANA. Values 1024-65535 are for private use among mutually consenting parties.
For Transform Type 2 (Pseudo-random Function), defined Transform IDs are:
For Transform Type 2 (Pseudo-random Function), defined Transform IDs are:
Name Number Defined In
RESERVED 0
PRF_HMAC_MD5 1 (RFC2104), [MD5]
PRF_HMAC_SHA1 2 (RFC2104), [SHA]
PRF_HMAC_TIGER 3 (RFC2104)
PRF_AES128_XCBC 4 (RFC3664)
Name Number Defined In RESERVED 0 PRF_HMAC_MD5 1 (RFC2104), [MD5] PRF_HMAC_SHA1 2 (RFC2104), [SHA] PRF_HMAC_TIGER 3 (RFC2104) PRF_AES128_XCBC 4 (RFC3664)
values 5-1023 are reserved to IANA. Values 1024-65535 are for
private use among mutually consenting parties.
values 5-1023 are reserved to IANA. Values 1024-65535 are for private use among mutually consenting parties.
For Transform Type 3 (Integrity Algorithm), defined Transform IDs are:
For Transform Type 3 (Integrity Algorithm), defined Transform IDs are:
Name Number Defined In
NONE 0
AUTH_HMAC_MD5_96 1 (RFC2403)
AUTH_HMAC_SHA1_96 2 (RFC2404)
AUTH_DES_MAC 3
AUTH_KPDK_MD5 4 (RFC1826)
AUTH_AES_XCBC_96 5 (RFC3566)
Name Number Defined In NONE 0 AUTH_HMAC_MD5_96 1 (RFC2403) AUTH_HMAC_SHA1_96 2 (RFC2404) AUTH_DES_MAC 3 AUTH_KPDK_MD5 4 (RFC1826) AUTH_AES_XCBC_96 5 (RFC3566)
values 6-1023 are reserved to IANA. Values 1024-65535 are for
private use among mutually consenting parties.
values 6-1023 are reserved to IANA. Values 1024-65535 are for private use among mutually consenting parties.
For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs are:
For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs are:
Name Number
NONE 0
Defined in Appendix B 1 - 2
RESERVED 3 - 4
Defined in [ADDGROUP] 5
RESERVED TO IANA 6 - 13
Defined in [ADDGROUP] 14 - 18
RESERVED TO IANA 19 - 1023
PRIVATE USE 1024-65535
Name Number NONE 0 Defined in Appendix B 1 - 2 RESERVED 3 - 4 Defined in [ADDGROUP] 5 RESERVED TO IANA 6 - 13 Defined in [ADDGROUP] 14 - 18 RESERVED TO IANA 19 - 1023 PRIVATE USE 1024-65535
Kaufman Standards Track [Page 51] RFC 4306 IKEv2 December 2005
Kaufman Standards Track [Page 51] RFC 4306 IKEv2 December 2005
For Transform Type 5 (Extended Sequence Numbers), defined Transform IDs are:
For Transform Type 5 (Extended Sequence Numbers), defined Transform IDs are:
Name Number
No Extended Sequence Numbers 0
Extended Sequence Numbers 1
RESERVED 2 - 65535
Name Number No Extended Sequence Numbers 0 Extended Sequence Numbers 1 RESERVED 2 - 65535
3.3.3. Valid Transform Types by Protocol
3.3.3. Valid Transform Types by Protocol
The number and type of transforms that accompany an SA payload are dependent on the protocol in the SA itself. An SA payload proposing the establishment of an SA has the following mandatory and optional transform types. A compliant implementation MUST understand all mandatory and optional types for each protocol it supports (though it need not accept proposals with unacceptable suites). A proposal MAY omit the optional types if the only value for them it will accept is NONE.
The number and type of transforms that accompany an SA payload are dependent on the protocol in the SA itself. An SA payload proposing the establishment of an SA has the following mandatory and optional transform types. A compliant implementation MUST understand all mandatory and optional types for each protocol it supports (though it need not accept proposals with unacceptable suites). A proposal MAY omit the optional types if the only value for them it will accept is NONE.
Protocol Mandatory Types Optional Types
IKE ENCR, PRF, INTEG, D-H
ESP ENCR, ESN INTEG, D-H
AH INTEG, ESN D-H
Protocol Mandatory Types Optional Types IKE ENCR, PRF, INTEG, D-H ESP ENCR, ESN INTEG, D-H AH INTEG, ESN D-H
3.3.4. Mandatory Transform IDs
3.3.4. Mandatory Transform IDs
The specification of suites that MUST and SHOULD be supported for interoperability has been removed from this document because they are likely to change more rapidly than this document evolves.
The specification of suites that MUST and SHOULD be supported for interoperability has been removed from this document because they are likely to change more rapidly than this document evolves.
An important lesson learned from IKEv1 is that no system should only implement the mandatory algorithms and expect them to be the best choice for all customers. For example, at the time that this document was written, many IKEv1 implementers were starting to migrate to AES in Cipher Block Chaining (CBC) mode for Virtual Private Network (VPN) applications. Many IPsec systems based on IKEv2 will implement AES, additional Diffie-Hellman groups, and additional hash algorithms, and some IPsec customers already require these algorithms in addition to the ones listed above.
An important lesson learned from IKEv1 is that no system should only implement the mandatory algorithms and expect them to be the best choice for all customers. For example, at the time that this document was written, many IKEv1 implementers were starting to migrate to AES in Cipher Block Chaining (CBC) mode for Virtual Private Network (VPN) applications. Many IPsec systems based on IKEv2 will implement AES, additional Diffie-Hellman groups, and additional hash algorithms, and some IPsec customers already require these algorithms in addition to the ones listed above.
It is likely that IANA will add additional transforms in the future, and some users may want to use private suites, especially for IKE where implementations should be capable of supporting different parameters, up to certain size limits. In support of this goal, all implementations of IKEv2 SHOULD include a management facility that allows specification (by a user or system administrator) of Diffie- Hellman (DH) parameters (the generator, modulus, and exponent lengths and values) for new DH groups. Implementations SHOULD provide a
It is likely that IANA will add additional transforms in the future, and some users may want to use private suites, especially for IKE where implementations should be capable of supporting different parameters, up to certain size limits. In support of this goal, all implementations of IKEv2 SHOULD include a management facility that allows specification (by a user or system administrator) of Diffie- Hellman (DH) parameters (the generator, modulus, and exponent lengths and values) for new DH groups. Implementations SHOULD provide a
Kaufman Standards Track [Page 52] RFC 4306 IKEv2 December 2005
Kaufman Standards Track [Page 52] RFC 4306 IKEv2 December 2005
management interface via which these parameters and the associated transform IDs may be entered (by a user or system administrator), to enable negotiating such groups.
management interface via which these parameters and the associated transform IDs may be entered (by a user or system administrator), to enable negotiating such groups.
All implementations of IKEv2 MUST include a management facility that enables a user or system administrator to specify the suites that are acceptable for use with IKE. Upon receipt of a payload with a set of transform IDs, the implementation MUST compare the transmitted transform IDs against those locally configured via the management controls, to verify that the proposed suite is acceptable based on local policy. The implementation MUST reject SA proposals that are not authorized by these IKE suite controls. Note that cryptographic suites that MUST be implemented need not be configured as acceptable to local policy.
All implementations of IKEv2 MUST include a management facility that enables a user or system administrator to specify the suites that are acceptable for use with IKE. Upon receipt of a payload with a set of transform IDs, the implementation MUST compare the transmitted transform IDs against those locally configured via the management controls, to verify that the proposed suite is acceptable based on local policy. The implementation MUST reject SA proposals that are not authorized by these IKE suite controls. Note that cryptographic suites that MUST be implemented need not be configured as acceptable to local policy.
3.3.5. Transform Attributes
3.3.5. Transform Attributes
Each transform in a Security Association payload may include attributes that modify or complete the specification of the transform. These attributes are type/value pairs and are defined below. For example, if an encryption algorithm has a variable-length key, the key length to be used may be specified as an attribute. Attributes can have a value with a fixed two octet length or a variable-length value. For the latter, the attribute is encoded as type/length/value.
Each transform in a Security Association payload may include attributes that modify or complete the specification of the transform. These attributes are type/value pairs and are defined below. For example, if an encryption algorithm has a variable-length key, the key length to be used may be specified as an attribute. Attributes can have a value with a fixed two octet length or a variable-length value. For the latter, the attribute is encoded as type/length/value.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!A! Attribute Type ! AF=0 Attribute Length !
!F! ! AF=1 Attribute Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! AF=0 Attribute Value !
! AF=1 Not Transmitted !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !A! Attribute Type ! AF=0 Attribute Length ! !F! ! AF=1 Attribute Value ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! AF=0 Attribute Value ! ! AF=1 Not Transmitted ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Data Attributes
Figure 9: Data Attributes
o Attribute Type (2 octets) - Unique identifier for each type of
attribute (see below).
o Attribute Type (2 octets) - Unique identifier for each type of attribute (see below).
The most significant bit of this field is the Attribute Format
bit (AF). It indicates whether the data attributes follow the
Type/Length/Value (TLV) format or a shortened Type/Value (TV)
format. If the AF bit is zero (0), then the Data Attributes
are of the Type/Length/Value (TLV) form. If the AF bit is a
one (1), then the Data Attributes are of the Type/Value form.
The most significant bit of this field is the Attribute Format bit (AF). It indicates whether the data attributes follow the Type/Length/Value (TLV) format or a shortened Type/Value (TV) format. If the AF bit is zero (0), then the Data Attributes are of the Type/Length/Value (TLV) form. If the AF bit is a one (1), then the Data Attributes are of the Type/Value form.
Kaufman Standards Track [Page 53] RFC 4306 IKEv2 December 2005
Kaufman Standards Track [Page 53] RFC 4306 IKEv2 December 2005
o Attribute Length (2 octets) - Length in octets of the Attribute
Value. When the AF bit is a one (1), the Attribute Value is
only 2 octets and the Attribute Length field is not present.
o Attribute Length (2 octets) - Length in octets of the Attribute Value. When the AF bit is a one (1), the Attribute Value is only 2 octets and the Attribute Length field is not present.
o Attribute Value (variable length) - Value of the Attribute
associated with the Attribute Type. If the AF bit is a zero
(0), this field has a variable length defined by the Attribute
Length field. If the AF bit is a one (1), the Attribute Value
has a length of 2 octets.
o Attribute Value (variable length) - Value of the Attribute associated with the Attribute Type. If the AF bit is a zero (0), this field has a variable length defined by the Attribute Length field. If the AF bit is a one (1), the Attribute Value has a length of 2 octets.
Note that only a single attribute type (Key Length) is defined, and it is fixed length. The variable-length encoding specification is included only for future extensions. The only algorithms defined in this document that accept attributes are the AES-based encryption, integrity, and pseudo-random functions, which require a single attribute specifying key width.
Note that only a single attribute type (Key Length) is defined, and it is fixed length. The variable-length encoding specification is included only for future extensions. The only algorithms defined in this document that accept attributes are the AES-based encryption, integrity, and pseudo-random functions, which require a single attribute specifying key width.
Attributes described as basic MUST NOT be encoded using the variable-length encoding. Variable-length attributes MUST NOT be encoded as basic even if their value can fit into two octets. NOTE: This is a change from IKEv1, where increased flexibility may have simplified the composer of messages but certainly complicated the parser.
Attributes described as basic MUST NOT be encoded using the variable-length encoding. Variable-length attributes MUST NOT be encoded as basic even if their value can fit into two octets. NOTE: This is a change from IKEv1, where increased flexibility may have simplified the composer of messages but certainly complicated the parser.
Attribute Type Value Attribute Format
--------------------------------------------------------------
RESERVED 0-13 Key Length (in bits)
14 TV RESERVED 15-17
RESERVED TO IANA 18-16383 PRIVATE USE
16384-32767
Attribute Type Value Attribute Format -------------------------------------------------------------- RESERVED 0-13 Key Length (in bits) 14 TV RESERVED 15-17 RESERVED TO IANA 18-16383 PRIVATE USE 16384-32767
Values 0-13 and 15-17 were used in a similar context in IKEv1 and should not be assigned except to matching values. Values 18-16383 are reserved to IANA. Values 16384-32767 are for private use among mutually consenting parties.
Values 0-13 and 15-17 were used in a similar context in IKEv1 and should not be assigned except to matching values. Values 18-16383 are reserved to IANA. Values 16384-32767 are for private use among mutually consenting parties.
- Key Length
- Key Length
When using an Encryption Algorithm that has a variable-length key,
this attribute specifies the key length in bits (MUST use network
byte order). This attribute MUST NOT be used when the specified
Encryption Algorithm uses a fixed-length key.
When using an Encryption Algorithm that has a variable-length key, this attribute specifies the key length in bits (MUST use network byte order). This attribute MUST NOT be used when the specified Encryption Algorithm uses a fixed-length key.
Kaufman Standards Track [Page 54] RFC 4306 IKEv2 December 2005
Kaufman Standards Track [Page 54] RFC 4306 IKEv2 December 2005
3.3.6. Attribute Negotiation
3.3.6. Attribute Negotiation
During security association negotiation, initiators present offers to responders. Responders MUST select a single complete set of parameters from the offers (or reject all offers if none are acceptable). If there are multiple proposals, the responder MUST choose a single proposal number and return all of the Proposal substructures with that Proposal number. If there are multiple Transforms with the same type, the responder MUST choose a single one. Any attributes of a selected transform MUST be returned unmodified. The initiator of an exchange MUST check that the accepted offer is consistent with one of its proposals, and if not that response MUST be rejected.
During security association negotiation, initiators present offers to responders. Responders MUST select a single complete set of parameters from the offers (or reject all offers if none are acceptable). If there are multiple proposals, the responder MUST choose a single proposal number and return all of the Proposal substructures with that Proposal number. If there are multiple Transforms with the same type, the responder MUST choose a single one. Any attributes of a selected transform MUST be returned unmodified. The initiator of an exchange MUST check that the accepted offer is consistent with one of its proposals, and if not that response MUST be rejected.
Negotiating Diffie-Hellman groups presents some special challenges. SA offers include proposed attributes and a Diffie-Hellman public number (KE) in the same message. If in the initial exchange the initiator offers to use one of several Diffie-Hellman groups, it SHOULD pick the one the responder is most likely to accept and include a KE corresponding to that group. If the guess turns out to be wrong, the responder will indicate the correct group in the response and the initiator SHOULD pick an element of that group for its KE value when retrying the first message. It SHOULD, however, continue to propose its full supported set of groups in order to prevent a man-in-the-middle downgrade attack.
Negotiating Diffie-Hellman groups presents some special challenges. SA offers include proposed attributes and a Diffie-Hellman public number (KE) in the same message. If in the initial exchange the initiator offers to use one of several Diffie-Hellman groups, it SHOULD pick the one the responder is most likely to accept and include a KE corresponding to that group. If the guess turns out to be wrong, the responder will indicate the correct group in the response and the initiator SHOULD pick an element of that group for its KE value when retrying the first message. It SHOULD, however, continue to propose its full supported set of groups in order to prevent a man-in-the-middle downgrade attack.
Implementation Note:
Implementation Note:
Certain negotiable attributes can have ranges or could have
multiple acceptable values. These include the key length of a
variable key length symmetric cipher. To further interoperability
and to support upgrading endpoints independently, implementers of
this protocol SHOULD accept values that they deem to supply
greater security. For instance, if a peer is configured to accept
a variable-length cipher with a key length of X bits and is
offered that cipher with a larger key length, the implementation
SHOULD accept the offer if it supports use of the longer key.
ある交渉可能な属性に、範囲を持つことができるか、または複数の許容値があるかもしれません。 これらは可変キー長左右対称の暗号のキー長を含んでいます。 相互運用性を促進して、独自にアップグレードに終点をサポートするために、このプロトコルSHOULDのimplementersは彼らが、よりすばらしいセキュリティを供給すると考える値を受け入れます。 例えば、同輩はXビットのキー長で可変長の暗号を受け入れるために構成して、より大きいキー長と共にその暗号を提供するなら、より長いキーの使用をサポートするなら、実装SHOULDは申し出を受け入れます。
Support of this capability allows an implementation to express a concept of "at least" a certain level of security -- "a key length of _at least_ X bits for cipher Y".
この能力のサポートで、実装は「少なくとも」あるレベルのセキュリティの概念を言い表すことができます--、「_のキー長、暗号Y」のための少なくとも_Xビット。
Kaufman Standards Track [Page 55] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[55ページ]RFC4306IKEv2 December 2005
3.4. Key Exchange Payload
3.4. 主要な交換有効搭載量
The Key Exchange Payload, denoted KE in this memo, is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange. The Key Exchange Payload consists of the IKE generic payload header followed by the Diffie-Hellman public value itself.
KEは、このメモでKey Exchange有効搭載量がディフィー-ヘルマンの主要な交換の一部としてディフィー-ヘルマンの公共の番号を交換するのに使用されるのを指示しました。 Key Exchange有効搭載量はディフィー-ヘルマンの公共の値自体があとに続いたIKEジェネリックペイロードヘッダーから成ります。
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! DH Group # ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Key Exchange Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 予約されました!ペイロード長!+++++++++++++++++++++++++++++++++! DHは#、を分類します!予約されました!+++++++++++++++++++++++++++++++++! ~、は交換データ~!+++++++++++++++++++++++++++++++++を合わせます。
Figure 10: Key Exchange Payload Format
図10: 主要な交換有効搭載量形式
A key exchange payload is constructed by copying one's Diffie-Hellman public value into the "Key Exchange Data" portion of the payload. The length of the Diffie-Hellman public value MUST be equal to the length of the prime modulus over which the exponentiation was performed, prepending zero bits to the value if necessary.
主要な交換ペイロードは、ペイロードの「主要な交換データ」一部に人のディフィー-ヘルマンの公共の値をコピーすることによって、構成されます。 ディフィー-ヘルマンの公共の価値の長さは羃法が実行された主要な係数の長さと等しいに違いありません、必要なら、値にゼロ・ビットをprependingして。
The DH Group # identifies the Diffie-Hellman group in which the Key Exchange Data was computed (see section 3.3.2). If the selected proposal uses a different Diffie-Hellman group, the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD.
DH Group#はKey Exchange Dataが計算されたディフィー-ヘルマングループを特定します(セクション3.3.2を見てください)。 選択された提案が異なったディフィー-ヘルマングループを使用するなら、タイプINVALID_KE_有効搭載量のNotifyペイロードでメッセージを拒絶しなければなりません。
The payload type for the Key Exchange payload is thirty four (34).
Key Exchangeペイロードのためのペイロードタイプは34(34)です。
3.5. Identification Payloads
3.5. 識別有効搭載量
The Identification Payloads, denoted IDi and IDr in this memo, allow peers to assert an identity to one another. This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions.
IDiとIDrは、このメモで同輩がIdentification有効搭載量でお互いにアイデンティティについて断言できるのを指示しました。 このアイデンティティは、方針ルックアップに使用されるかもしれませんが、必ずCERTペイロードで何にも合う必要はありません。 両方の分野は実装によって使用されて、アクセス制御決定を実行するかもしれません。
NOTE: In IKEv1, two ID payloads were used in each direction to hold Traffic Selector (TS) information for data passing over the SA. In IKEv2, this information is carried in TS payloads (see section 3.13).
以下に注意してください。 IKEv1では、2個のIDペイロードが、SAを通り過ぎるデータのためのTraffic Selector(TS)情報を保持するのに各方向に使用されました。 IKEv2では、この情報はTSペイロードで運ばれます(セクション3.13を見てください)。
Kaufman Standards Track [Page 56] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[56ページ]RFC4306IKEv2 December 2005
The Identification Payload consists of the IKE generic payload header followed by identification fields as follows:
Identification有効搭載量は以下の識別分野があとに続いたIKEジェネリックペイロードヘッダーから成ります:
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Identification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 予約されました!ペイロード長!+++++++++++++++++++++++++++++++++! IDはタイプされます!予約されました。| 識別情報
Figure 11: Identification Payload Format
図11: 識別有効搭載量形式
o ID Type (1 octet) - Specifies the type of Identification being
used.
o ID Type(1つの八重奏)--使用されるIdentificationのタイプを指定します。
o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
o RESERVED--ゼロとして送らなければなりません。 領収書の上で無視しなければなりません。
o Identification Data (variable length) - Value, as indicated by the
Identification Type. The length of the Identification Data is
computed from the size in the ID payload header.
o 識別Data(可変長)--Identification Typeによって示されるように、評価します。 Identification Dataの長さはIDペイロードヘッダーでサイズから計算されます。
The payload types for the Identification Payload are thirty five (35) for IDi and thirty six (36) for IDr.
Identification有効搭載量のためのペイロードタイプは、IDiのための35(35)とIDrのための36(36)です。
The following table lists the assigned values for the Identification Type field, followed by a description of the Identification Data which follows:
以下のテーブルは続くIdentification Dataの記述があとに続いたIdentification Type分野に割り当てられた値を記載します:
ID Type Value
------- -----
RESERVED 0
IDタイプ価値------- ----- 予約された0
ID_IPV4_ADDR 1
ID_IPV4_ADDR1
A single four (4) octet IPv4 address.
ただ一つの4(4)八重奏IPv4アドレス。
ID_FQDN 2
ID_FQDN2
A fully-qualified domain name string. An example of a
ID_FQDN is, "example.com". The string MUST not contain any
terminators (e.g., NULL, CR, etc.).
完全修飾ドメイン名ストリング。 ID_FQDNに関する例がそうである、"example.com"。 ストリングはどんなターミネータ(例えば、NULL、CRなど)も含んではいけません。
Kaufman Standards Track [Page 57] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[57ページ]RFC4306IKEv2 December 2005
ID_RFC822_ADDR 3
ID_RFC822_ADDR3
A fully-qualified RFC822 email address string, An example of
a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST
not contain any terminators.
完全に適切なRFC822Eメールアドレスストリング、ID_RFC822_ADDRに関するAnの例がそうである、" jsmith@example.com "。 ストリングはどんなターミネータも含んではいけません。
Reserved to IANA 4
IANA4に予約されます。
ID_IPV6_ADDR 5
ID_IPV6_ADDR5
A single sixteen (16) octet IPv6 address.
ただ一つの16(16)八重奏IPv6アドレス。
Reserved to IANA 6 - 8
IANA6--8まで予約されます。
ID_DER_ASN1_DN 9
ID_DER_ASN1_DN9
The binary Distinguished Encoding Rules (DER) encoding of an
ASN.1 X.500 Distinguished Name [X.501].
ASN.1X.500 Distinguished Name[X.501]の2進のDistinguished Encoding Rules(DER)コード化。
ID_DER_ASN1_GN 10
ID_DER_ASN1_GN10
The binary DER encoding of an ASN.1 X.500 GeneralName
[X.509].
ASN.1X.500 GeneralName[X.509]の2進のDERコード化。
ID_KEY_ID 11
IDの_の主要な_ID11
An opaque octet stream which may be used to pass vendor-
specific information necessary to do certain proprietary
types of identification.
ある独占タイプの識別をするのに必要なベンダー特殊情報を通過するのに使用されるかもしれない不透明な八重奏ストリーム。
Reserved to IANA 12-200
IANA12-200に予約されます。
Reserved for private use 201-255
私的使用目的で201-255に予約されます。
Two implementations will interoperate only if each can generate a type of ID acceptable to the other. To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these types. Implementations SHOULD be capable of generating and accepting all of these types. IPv6-capable implementations MUST additionally be configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR.
それぞれがもう片方に許容できる一種のIDを生成することができる場合にだけ、2つの実装が共同利用するでしょう。 実装は、最大限のインターオペラビリティを保証するために、少なくともID_IPV4___ADDR、ID FQDN、ID RFC822_ADDRの1つ、またはID_KEY_IDを送るのにおいて構成可能でなければならなく、これらのタイプを皆、受け入れるのにおいて構成可能でなければなりません。 生成することができてこれらをすべて、受け入れている実装SHOULDはタイプします。 IPv6できる実装は_ID IPV6_ADDR. IPv6を受け入れるのにおいてさらに、構成可能でなければなりません。-実装だけが_IDだけIPV6_ADDRを送るのにおいて構成可能であるかもしれません。
Kaufman Standards Track [Page 58] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[58ページ]RFC4306IKEv2 December 2005
3.6. Certificate Payload
3.6. 証明書有効搭載量
The Certificate Payload, denoted CERT in this memo, provides a means to transport certificates or other authentication-related information via IKE. Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the term "Certificate Payload" is somewhat misleading, because not all authentication mechanisms use certificates and data other than certificates may be passed in this payload.
CERTは、このメモでCertificate有効搭載量がIKEを通して証明書を輸送する手段か他の認証関連の情報を提供するのを指示しました。 含まれていて、送付者にとって、同輩がほかの場所からHTTP_CERT_LOOKUP_SUPPORTED Notifyペイロードを使用することでこの情報を検索する能力を示していない場合証明書が利用可能であるなら、交換でペイロードSHOULDを証明してください。 「証明書有効搭載量」という用語がいくらか紛らわしいことに注意してください、すべての認証機構が証明書を使用するというわけではなくて、証明書以外のデータがこのペイロードで通過されるかもしれないので。
The Certificate Payload is defined as follows:
Certificate有効搭載量は以下の通り定義されます:
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Encoding ! !
+-+-+-+-+-+-+-+-+ !
~ Certificate Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 予約されました!
Figure 12: Certificate Payload Format
図12: 証明書有効搭載量形式
o Certificate Encoding (1 octet) - This field indicates the type
of certificate or certificate-related information contained in
the Certificate Data field.
o 証明書Encoding(1つの八重奏)--この分野は証明書かCertificate Data分野に保管されていた証明書関連の情報のタイプを示します。
Certificate Encoding Value
-------------------- -----
RESERVED 0
PKCS #7 wrapped X.509 certificate 1
PGP Certificate 2
DNS Signed Key 3
X.509 Certificate - Signature 4
Kerberos Token 6
Certificate Revocation List (CRL) 7
Authority Revocation List (ARL) 8
SPKI Certificate 9
X.509 Certificate - Attribute 10
Raw RSA Key 11
Hash and URL of X.509 certificate 12
Hash and URL of X.509 bundle 13
RESERVED to IANA 14 - 200
PRIVATE USE 201 - 255
値をコード化する証明書-------------------- ----- RESERVED0PKCS#7はX.509証明書1PGP Certificate2DNS Signed Key3X.509 Certificate--署名4ケルベロスToken6Certificate Revocation List(CRL)7Authority Revocation List(ARL)8SPKI Certificate9X.509 Certificate--属性10Raw RSA Key11Hashを包装しました、そして、X.509証明書12HashのURLとX.509のURLはIANA14--200PRIVATE USE201--255に13RESERVEDを添付します。
Kaufman Standards Track [Page 59] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[59ページ]RFC4306IKEv2 December 2005
o Certificate Data (variable length) - Actual encoding of
certificate data. The type of certificate is indicated by the
Certificate Encoding field.
o Data(可変長)を証明してください--証明書データの実際のコード化。 証明書のタイプはCertificate Encoding分野によって示されます。
The payload type for the Certificate Payload is thirty seven (37).
Certificate有効搭載量のためのペイロードタイプは37(37)です。
Specific syntax is for some of the certificate type codes above is not defined in this document. The types whose syntax is defined in this document are:
特定の構文は証明書タイプにおいて、上のコードが本書では定義されないということです。 構文が定義されるタイプは本書では以下の通りです。
X.509 Certificate - Signature (4) contains a DER encoded X.509
certificate whose public key is used to validate the sender's AUTH
payload.
コード化されて、署名(4)はDERを含んでいます。X.509証明書--、公開鍵が送付者のAUTHペイロードを有効にするのが使用されるX.509証明書。
Certificate Revocation List (7) contains a DER encoded X.509
certificate revocation list.
証明書Revocation List(7)はコード化されたX.509証明書取消しが記載するDERを含んでいます。
Raw RSA Key (11) contains a PKCS #1 encoded RSA key (see [RSA] and
[PKCS1]).
生のRSA Key(11)はPKCS#1のコード化されたRSAキーを含んでいます([RSA]と[PKCS1]を見てください)。
Hash and URL encodings (12-13) allow IKE messages to remain short
by replacing long data structures with a 20 octet SHA-1 hash (see
[SHA]) of the replaced value followed by a variable-length URL
that resolves to the DER encoded data structure itself. This
improves efficiency when the endpoints have certificate data
cached and makes IKE less subject to denial of service attacks
that become easier to mount when IKE messages are large enough to
require IP fragmentation [KPS03].
ハッシュとURL encodings(12-13)は長いデータ構造をコード化されたデータ構造自体をDERに決議する可変長のURLがあとに続いた取り替えられた価値の20八重奏SHA-1ハッシュ([SHA]を見る)に取り替えることによって短いままで残るメッセージをIKEに許容します。 IKEメッセージがIP断片化[KPS03]を必要とすることができるくらい大きいときに、これは、終点で証明書データをキャッシュするとき、能率を増進して、それほど取り付けるのが、より簡単になるサービス不能攻撃を条件としてIKEを作りません。
Use the following ASN.1 definition for an X.509 bundle:
X.509バンドルに以下のASN.1定義を使用してください:
CertBundle
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cert-bundle(34) }
CertBundleiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズ本命バンドル(34)
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
定義、明白なタグ:、:= 始まってください。
IMPORTS
Certificate, CertificateList
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
IMPORTS Certificate、CertificateList FROM PKIX1Explicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(18)。
Kaufman Standards Track [Page 60] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[60ページ]RFC4306IKEv2 December 2005
CertificateOrCRL ::= CHOICE {
cert [0] Certificate,
crl [1] CertificateList }
CertificateOrCRL:、:= 選択本命[0]証明書、crl[1]CertificateList
CertificateBundle ::= SEQUENCE OF CertificateOrCRL
CertificateBundle:、:= CertificateOrCRLの系列
END
終わり
Implementations MUST be capable of being configured to send and accept up to four X.509 certificates in support of authentication, and also MUST be capable of being configured to send and accept the first two Hash and URL formats (with HTTP URLs). Implementations SHOULD be capable of being configured to send and accept Raw RSA keys. If multiple certificates are sent, the first certificate MUST contain the public key used to sign the AUTH payload. The other certificates may be sent in any order.
実装は、認証を支持して最大4通のX.509証明書を送って、受け入れるために構成できなければならなくて、また、最初の2HashとURL形式を送って、受け入れるために構成できなければなりません(HTTP URLで)。 実装SHOULDは発信するために構成できて、Raw RSAキーを受け入れます。 複数の証明書を送るなら、最初の証明書はAUTHペイロードに署名するのに使用される公開鍵を含まなければなりません。 順不同に他の証明書を送るかもしれません。
3.7. Certificate Request Payload
3.7. 証明書要求有効搭載量
The Certificate Request Payload, denoted CERTREQ in this memo, provides a means to request preferred certificates via IKE and can appear in the IKE_INIT_SA response and/or the IKE_AUTH request. Certificate Request payloads MAY be included in an exchange when the sender needs to get the certificate of the receiver. If multiple CAs are trusted and the cert encoding does not allow a list, then multiple Certificate Request payloads SHOULD be transmitted.
CERTREQはこのメモでCertificate Request有効搭載量がIKEを通して都合のよい証明書を要求する手段を提供して、イケ_INIT_SA応答、そして/または、AUTHが要求するイケ_に現れることができるのを指示しました。 証明書Requestペイロードは送付者が証明書を手に入れる必要がある交換に含まれるかもしれません。. 複数のCAsが信じられるか、そして、本命コード化がリスト、当時の倍数Certificate RequestペイロードSHOULDを許容しない受信機では、伝えられてください。
The Certificate Request Payload is defined as follows:
Certificate Request有効搭載量は以下の通り定義されます:
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Encoding ! !
+-+-+-+-+-+-+-+-+ !
~ Certification Authority ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 予約..ペイロード長..本命..コード化..認証局
Figure 13: Certificate Request Payload Format
図13: 証明書要求有効搭載量形式
o Certificate Encoding (1 octet) - Contains an encoding of the type
or format of certificate requested. Values are listed in section
3.6.
o 証明書Encoding(1つの八重奏)--要求された証明書のタイプか形式のコード化を含んでいます。 値はセクション3.6で記載されています。
Kaufman Standards Track [Page 61] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[61ページ]RFC4306IKEv2 December 2005
o Certification Authority (variable length) - Contains an encoding
of an acceptable certification authority for the type of
certificate requested.
o 認証局(可変長)--要求された証明書のタイプにおいて、許容できる証明権威のコード化を含んでいます。
The payload type for the Certificate Request Payload is thirty eight (38).
Certificate Request有効搭載量のためのペイロードタイプは38(38)です。
The Certificate Encoding field has the same values as those defined in section 3.6. The Certification Authority field contains an indicator of trusted authorities for this certificate type. The Certification Authority value is a concatenated list of SHA-1 hashes of the public keys of trusted Certification Authorities (CAs). Each is encoded as the SHA-1 hash of the Subject Public Key Info element (see section 4.1.2.7 of [RFC3280]) from each Trust Anchor certificate. The twenty-octet hashes are concatenated and included with no other formatting.
Certificate Encoding分野には、セクション3.6で定義されたものと同じ値があります。 認証局分野はこの証明書タイプのための信じられた当局のインディケータを含んでいます。 認証局値は信じられたCertification Authorities(CAs)の公開鍵のSHA-1ハッシュの連結されたリストです。 それぞれがSubject Public Key Info要素のSHA-1ハッシュとしてコード化されます。(各Trust Anchorからの.7[RFC3280)が証明するセクション4.1.2を見てください。 20八重奏のハッシュは、他の形式なしで連結されて、含まれています。
Note that the term "Certificate Request" is somewhat misleading, in that values other than certificates are defined in a "Certificate" payload and requests for those values can be present in a Certificate Request Payload. The syntax of the Certificate Request payload in such cases is not defined in this document.
「証明書要求」という用語がいくらか紛らわしいことに注意してください、証明書以外の値が「証明書」ペイロードで定義されて、それらの値を求める要求がCertificate Request有効搭載量で存在している場合があるので。 Certificate Requestペイロードの構文はそのような場合本書では定義されません。
The Certificate Request Payload is processed by inspecting the "Cert Encoding" field to determine whether the processor has any certificates of this type. If so, the "Certification Authority" field is inspected to determine if the processor has any certificates that can be validated up to one of the specified certification authorities. This can be a chain of certificates.
Certificate Request有効搭載量は、プロセッサには何かこのタイプの証明書があるかどうか決定するために「本命コード化」分野を点検することによって、処理されます。 そうだとすれば、「認証局」分野は、プロセッサで何か指定された証明当局のひとりまで有効にすることができる証明書があるかどうか決定するために点検されます。 これは証明書のチェーンであるかもしれません。
If an end-entity certificate exists that satisfies the criteria specified in the CERTREQ, a certificate or certificate chain SHOULD be sent back to the certificate requestor if the recipient of the CERTREQ:
CERTREQ、証明書または証明書チェーンSHOULDで指定された評価基準を満たす終わり実体証明書が存在するなら、CERTREQの受取人であるなら証明書要請者に送り返されてください:
- is configured to use certificate authentication,
- 証明書認証を使用するために、構成されます。
- is allowed to send a CERT payload,
- CERTペイロードを送るのが許容されています。
- has matching CA trust policy governing the current negotiation, and
- そして合っているカリフォルニアに現在の交渉を治める方針を信じさせる。
- has at least one time-wise and usage appropriate end-entity
certificate chaining to a CA provided in the CERTREQ.
- 少なくとも1通の時間的、そして、用法の適切な終わり実体証明書にCERTREQに提供されたカリフォルニアにチェーニングさせます。
Certificate revocation checking must be considered during the chaining process used to select a certificate. Note that even if two peers are configured to use two different CAs, cross-certification relationships should be supported by appropriate selection logic.
証明書を選択するのに使用される推論プロセスの間、証明書取消しの照合を考えなければなりません。 2人の同輩が2異なったCAsを使用するために構成されても、相互認証関係が適切な選択論理によってサポートされるべきであることに注意してください。
Kaufman Standards Track [Page 62] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[62ページ]RFC4306IKEv2 December 2005
The intent is not to prevent communication through the strict adherence of selection of a certificate based on CERTREQ, when an alternate certificate could be selected by the sender that would still enable the recipient to successfully validate and trust it through trust conveyed by cross-certification, CRLs, or other out- of-band configured means. Thus, the processing of a CERTREQ should be seen as a suggestion for a certificate to select, not a mandated one. If no certificates exist, then the CERTREQ is ignored. This is not an error condition of the protocol. There may be cases where there is a preferred CA sent in the CERTREQ, but an alternate might be acceptable (perhaps after prompting a human operator).
意図はCERTREQに基づく証明書の選択の厳しい固守でコミュニケーションを防がないことです、受取人が相互認証で伝えられた信頼を通して首尾よくそれを有効にして、信じるのをまだ可能にしている送付者、CRLs、またはバンドの他の出ている構成された手段が代替の証明書を選択できたとき。 したがって、CERTREQの処理は強制されたものではなく、証明書が選択する提案と考えられるべきです。 証明書が全く存在していないなら、CERTREQは無視されます。 これはプロトコルのエラー条件ではありません。 ケースがCERTREQで送られた都合のよいカリフォルニアがあるところにあるかもしれませんが、補欠は許容できるかもしれません(恐らく人間のオペレータをうながした後の)。
3.8. Authentication Payload
3.8. 認証有効搭載量
The Authentication Payload, denoted AUTH in this memo, contains data used for authentication purposes. The syntax of the Authentication data varies according to the Auth Method as specified below.
AUTHは、このメモでAuthentication有効搭載量が認証目的に使用されるデータを含むのを指示しました。 Auth Methodによると、Authenticationデータの構文は以下で指定されるとして異なります。
The Authentication Payload is defined as follows:
Authentication有効搭載量は以下の通り定義されます:
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Auth Method ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Authentication Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 予約されました!
Figure 14: Authentication Payload Format
図14: 認証有効搭載量形式
o Auth Method (1 octet) - Specifies the method of authentication
used. Values defined are:
o Auth Method(1つの八重奏)--使用される認証のメソッドを指定します。 定義された値は以下の通りです。
RSA Digital Signature (1) - Computed as specified in section
2.15 using an RSA private key over a PKCS#1 padded hash (see
[RSA] and [PKCS1]).
RSA Digital Signature(1)--セクション2.15でPKCSの上でRSA秘密鍵を使用することで指定されるように計算されて、#1、はハッシュを水増ししました([RSA]と[PKCS1]を見てください)。
Shared Key Message Integrity Code (2) - Computed as specified in
section 2.15 using the shared key associated with the identity
in the ID payload and the negotiated prf function
共有されたKey Message Integrity Code(2)--セクション2.15で指定されるように計算されて、IDペイロードでアイデンティティに関連している共有されたキーを使用して、交渉されたprfは機能します。
DSS Digital Signature (3) - Computed as specified in section
2.15 using a DSS private key (see [DSS]) over a SHA-1 hash.
DSS Digital Signature(3)--計算されるのは、セクション2.15でSHA-1ハッシュの上でDSS秘密鍵([DSS]を見る)を使用することで指定しました。
Kaufman Standards Track [Page 63] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[63ページ]RFC4306IKEv2 December 2005
The values 0 and 4-200 are reserved to IANA. The values 201-255
are available for private use.
値0と4-200はIANAに予約されます。 値201-255は私的使用目的で利用可能です。
o Authentication Data (variable length) - see section 2.15.
o 認証Data(可変長)--セクション2.15を見てください。
The payload type for the Authentication Payload is thirty nine (39).
Authentication有効搭載量のためのペイロードタイプは39(39)です。
3.9. Nonce Payload
3.9. 一回だけの有効搭載量
The Nonce Payload, denoted Ni and Nr in this memo for the initiator's and responder's nonce respectively, contains random data used to guarantee liveness during an exchange and protect against replay attacks.
NiとNrは、創始者と応答者の一回だけのためのこのメモでNonce有効搭載量が交換の間、活性を保証して、反射攻撃から守るのに使用される無作為のデータを含むのをそれぞれ指示しました。
The Nonce Payload is defined as follows:
Nonce有効搭載量は以下の通り定義されます:
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Nonce Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 予約..ペイロード長..一回だけ..データ
Figure 15: Nonce Payload Format
図15: 一回だけの有効搭載量形式
o Nonce Data (variable length) - Contains the random data generated
by the transmitting entity.
o 一回だけのData(可変長)--伝える実体によって生成された無作為のデータを含んでいます。
The payload type for the Nonce Payload is forty (40).
Nonce有効搭載量のためのペイロードタイプは40(40)です。
The size of a Nonce MUST be between 16 and 256 octets inclusive. Nonce values MUST NOT be reused.
16〜256の八重奏が包括的であったなら、Nonceのサイズはそうしなければなりません。 一回だけの値を再利用してはいけません。
3.10. Notify Payload
3.10. 有効搭載量に通知してください。
The Notify Payload, denoted N in this document, is used to transmit informational data, such as error conditions and state transitions, to an IKE peer. A Notify Payload may appear in a response message (usually specifying why a request was rejected), in an INFORMATIONAL Exchange (to report an error not in an IKE request), or in any other message to indicate sender capabilities or to modify the meaning of the request.
Nは、Notify有効搭載量が情報のデータを送るのに使用されるのを本書では指示しました、エラー条件や状態遷移のように、IKE同輩に。 Notify有効搭載量は応答メッセージ(通常、要求がなぜ拒絶されたかを指定する)、INFORMATIONAL Exchange(IKE要求でないのにおける誤りを報告する)、または送付者能力を示すか、または要求の意味を変更するいかなる他のメッセージにも現れるかもしれません。
Kaufman Standards Track [Page 64] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[64ページ]RFC4306IKEv2 December 2005
The Notify Payload is defined as follows:
Notify有効搭載量は以下の通り定義されます:
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Notification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol ID ! SPI Size ! Notify Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Security Parameter Index (SPI) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Notification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Notify Payload Format
図16: 有効搭載量書式に通知してください。
o Protocol ID (1 octet) - If this notification concerns an existing
SA, this field indicates the type of that SA. For IKE_SA
notifications, this field MUST be one (1). For notifications
concerning IPsec SAs this field MUST contain either (2) to
indicate AH or (3) to indicate ESP. For notifications that do not
relate to an existing SA, this field MUST be sent as zero and MUST
be ignored on receipt. All other values for this field are
reserved to IANA for future assignment.
o プロトコルID(1つの八重奏)--この通知は既存のSAに関係があるなら、この分野がそのSAのタイプを示します。 IKE_SA通知のために、この分野はもの(1)でなければならない。 IPsec SAsに関する通知のために、この分野はAHを示す(2)か超能力を示す(3)のどちらかを含まなければなりません。 既存のSAに関連しない通知において、この野原をゼロとして送らなければならなくて、領収書の上で無視しなければなりません。 この分野への他のすべての値が将来の課題のためにIANAに予約されます。
o SPI Size (1 octet) - Length in octets of the SPI as defined by the
IPsec protocol ID or zero if no SPI is applicable. For a
notification concerning the IKE_SA, the SPI Size MUST be zero.
o SPI Size(1つの八重奏)--定義されるとしてのIPsecプロトコルIDかゼロもののSPIの八重奏における長さはSPIでないなら適切です。 IKE_SAに関する通知のために、SPI Sizeはゼロでなければなりません。
o Notify Message Type (2 octets) - Specifies the type of
notification message.
o Message Type(2つの八重奏)に通知してください。--通知メッセージのタイプを指定します。
o SPI (variable length) - Security Parameter Index.
o SPI(可変長)--セキュリティParameter Index。
o Notification Data (variable length) - Informational or error data
transmitted in addition to the Notify Message Type. Values for
this field are type specific (see below).
o 通知Data(可変長)--情報か誤りデータはNotify Message Typeに加えて送られました。 この分野への値はタイプ特有です(以下を見てください)。
The payload type for the Notify Payload is forty one (41).
Notify有効搭載量のためのペイロードタイプは41(41)です。
Kaufman Standards Track [Page 65] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[65ページ]RFC4306IKEv2 December 2005
3.10.1. Notify Message Types
3.10.1. メッセージタイプに通知してください。
Notification information 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. The table below lists the Notification messages and their corresponding values. The number of different error statuses was greatly reduced from IKEv1 both for simplification and to avoid giving configuration information to probers.
通知情報はなぜSAを設立できなかったかを指定するエラーメッセージであるかもしれません。 また、SAデータベースを管理するプロセスが同輩プロセスで交信したがっているのは、状態データであるかもしれません。 以下のテーブルはNotificationメッセージとそれらの換算値をリストアップします。 異なったエラー状況の数は、ともに、簡素化、設定情報を調査員に与えるのを避けるためにIKEv1から大いに減少しました。
Types in the range 0 - 16383 are intended for reporting errors. An implementation receiving a Notify payload with one of these types 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 except that they SHOULD be logged.
範囲0--16383のタイプは、誤りを報告するために意図します。 それが応答で見分けないこれらのタイプのひとりに従ったNotifyペイロードを受ける実装は、対応する要求が完全に失敗したと仮定しなければなりません。 認識されていない誤りが要求をタイプして、状態が要求をタイプしなければならないか、またはそれを除いて、応答を無視しなければならない、それら、SHOULD、登録されてください。
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.
状態タイプがどんなメッセージにも追加されるかもしれなくて、無視しなければならないか、または見分けられている状態で、ペイロードに通知してください。 それらは、能力を示すことを意図して、非暗号のパラメタを交渉するのにSA交渉の一部として使用されます。
NOTIFY MESSAGES - ERROR TYPES Value
----------------------------- -----
RESERVED 0
メッセージに通知してください--誤りは値をタイプします。----------------------------- ----- 予約された0
UNSUPPORTED_CRITICAL_PAYLOAD 1
サポートされない_重要な_ペイロード1
Sent if the payload has the "critical" bit set and the
payload type is not recognized. Notification Data contains
the one-octet payload type.
ペイロードで「重要な」ビットを設定して、ペイロードタイプが見分けられないなら、発信しました。 通知Dataは1八重奏のペイロードタイプを含んでいます。
INVALID_IKE_SPI 4
無効の_イケ_SPI4
Indicates an IKE message was received with an unrecognized
destination SPI. This usually indicates that the recipient
has rebooted and forgotten the existence of an IKE_SA.
IKEメッセージが認識されていない目的地SPIと共に受け取られたのを示します。 通常、これは、受取人がIKE_SAの存在をリブートして、忘れたのを示します。
INVALID_MAJOR_VERSION 5
無効の_主要な_バージョン5
Indicates the recipient cannot handle the version of IKE
specified in the header. The closest version number that
the recipient can support will be in the reply header.
受取人がヘッダーで指定されたIKEのバージョンを扱うことができないのを示します。 受取人がサポートすることができる中で最も近いバージョン番号が回答ヘッダーにあるでしょう。
INVALID_SYNTAX 7
無効の_構文7
Indicates the IKE message that was received was invalid
because some type, length, or value was out of range or
またはタイプ、長さ、または値が範囲から脱していたので受け取られたIKEメッセージが無効であったのを示す。
Kaufman Standards Track [Page 66] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[66ページ]RFC4306IKEv2 December 2005
because the request was rejected for policy reasons. To
avoid a denial of service attack using forged messages, this
status may only be returned for and in an encrypted packet
if the message ID and cryptographic checksum were valid. To
avoid leaking information to someone probing a node, this
status MUST be sent in response to any error not covered by
one of the other status types. To aid debugging, more
detailed error information SHOULD be written to a console or
log.
要求が方針理由で拒絶されたので。 偽造メッセージを使用することでサービス不能攻撃を避けるために、メッセージIDと暗号のチェックサムが有効であった場合にだけ、この状態はパケットと暗号化されたパケットで返されるかもしれません。 ノードを調べるだれかに情報を漏らすのを避けるために、他の状態タイプのひとりでカバーされなかった少しの誤りに対応してこの状態を送らなければなりません。 デバッグ、より詳細なエラー情報SHOULDを支援するには、コンソールかログに書かれてください。
INVALID_MESSAGE_ID 9
無効の_メッセージ_ID9
Sent when an IKE message ID outside the supported window is
received. This Notify MUST NOT be sent in a response; the
invalid request MUST NOT be acknowledged. Instead, inform
the other side by initiating an INFORMATIONAL exchange with
Notification data containing the four octet invalid message
ID. Sending this notification is optional, and
notifications of this type MUST be rate limited.
サポートしている窓の外のIKEメッセージIDが受け取られているとき、発信しました。 応答でこのNotifyを送ってはいけません。 無効の要求を承諾してはいけません。 代わりに、Notificationデータが4の八重奏の無効のメッセージIDを含んでいるINFORMATIONAL交換を起こすことによって、反対側を知らせてください。 この通知を送るのは任意です、そして、このタイプの通知は制限されたレートであるに違いありません。
INVALID_SPI 11
病人_SPI11
MAY be sent in an IKE INFORMATIONAL exchange when a node
receives an ESP or AH packet with an invalid SPI. The
Notification Data contains the SPI of the invalid packet.
This usually indicates a node has rebooted and forgotten an
SA. If this Informational Message is sent outside the
context of an IKE_SA, it should be used by the recipient
only as a "hint" that something might be wrong (because it
could easily be forged).
ノードが無効のSPIと共に超能力かAHパケットを受けるとき、IKE INFORMATIONAL交換で送るかもしれません。 Notification Dataは無効のパケットのSPIを含んでいます。 通常、これは、ノードがSAをリブートして、忘れたのを示します。 IKE_SAの文脈の外でこのInformational Messageを送るなら、受取人は単に何か問題があるかもしれないという(容易にそれを鍛造できたので)「ヒント」としてそれを使用するべきです。
NO_PROPOSAL_CHOSEN 14
選ばれた_提案がない_、14
None of the proposed crypto suites was acceptable.
提案された暗号スイートのいずれも許容できませんでした。
INVALID_KE_PAYLOAD 17
無効の_KE_ペイロード17
The D-H Group # field in the KE payload is not the group #
selected by the responder for this exchange. There are two
octets of data associated with this notification: the
accepted D-H Group # in big endian order.
KEペイロードのD-H Group#分野はこの交換のために応答者によって選択されたグループ#ではありません。 この通知に関連しているデータの2つの八重奏があります: ビッグエンディアンによる受け入れられたD-H Group#は注文します。
AUTHENTICATION_FAILED 24
認証_は24に失敗しました。
Sent in the response to an IKE_AUTH message when for some
reason the authentication failed. There is no associated
data.
ある理由で認証が失敗したとき、イケ_AUTHメッセージへの応答を送りました。 関連データが全くありません。
Kaufman Standards Track [Page 67] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[67ページ]RFC4306IKEv2 December 2005
SINGLE_PAIR_REQUIRED 34
シングル_組_は34を必要としました。
This error indicates that a CREATE_CHILD_SA request is
unacceptable because its sender is only willing to accept
traffic selectors specifying a single pair of addresses. The
requestor is expected to respond by requesting an SA for only
the specific traffic it is trying to forward.
この誤りは、送付者が、1組のアドレスを指定するトラフィックセレクタを受け入れても構わないと思っているだけであるのでSAが要求するCREATE_CHILD_が容認できないのを示します。 要請者がそれが進めようとしている特定のトラフィックだけのためにSAを要求することによって応じると予想されます。
NO_ADDITIONAL_SAS 35
_の追加_SASがありません35。
This error indicates that a CREATE_CHILD_SA request is
unacceptable because the responder is unwilling to accept any
more CHILD_SAs on this IKE_SA. Some minimal implementations may
only accept a single CHILD_SA setup in the context of an initial
IKE exchange and reject any subsequent attempts to add more.
この誤りは、応答者がこのIKE_SAの上のそれ以上のCHILD_SAsを受け入れたがっていないのでSAが要求するCREATE_CHILD_が容認できないのを示します。 いくつかの最小限の器具が、初期のIKE交換の文脈におけるただ一つのCHILD_SAセットアップを受け入れるだけであり、加えるどんなその後の試みもさらに拒絶するかもしれません。
INTERNAL_ADDRESS_FAILURE 36
内部の_のアドレス_故障36
Indicates an error assigning an internal address (i.e.,
INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the
processing of a Configuration Payload by a responder. If this
error is generated within an IKE_AUTH exchange, no CHILD_SA will
be created.
応答者によるConfiguration有効搭載量の処理の間に内部のアドレス(すなわち、INTERNAL_IP4_ADDRESSかINTERNAL_IP6_ADDRESS)を割り当てる誤りを示します。 この誤りがイケ_AUTH交換の中で発生すると、CHILD_SAは全く作成されないでしょう。
FAILED_CP_REQUIRED 37
失敗した_CP_は37を必要としました。
Sent by responder in the case where CP(CFG_REQUEST) was expected
but not received, and so is a conflict with locally configured
policy. There is no associated data.
CP(CFG_REQUEST)が予想されましたが、受け取られなかった場合で応答者によって送られて、局所的に構成された方針との闘争もそうです。 関連データが全くありません。
TS_UNACCEPTABLE 38
t_の容認できない38
Indicates that none of the addresses/protocols/ports in the
supplied traffic selectors is acceptable.
供給された交通セレクタのアドレス/プロトコル/ポートのいずれも許容できないのを示します。
INVALID_SELECTORS 39
無効の_セレクタ39
MAY be sent in an IKE INFORMATIONAL exchange when a node
receives an ESP or AH packet whose selectors do not match
those of the SA on which it was delivered (and that caused
the packet to be dropped). The Notification Data contains
the start of the offending packet (as in ICMP messages) and
the SPI field of the notification is set to match the SPI of
the IPsec SA.
ノードがセレクタがそれが届けられたSAのものに合っていない超能力かAHパケットを受けるとき(それはパケットを落とされました)、IKE INFORMATIONAL交換で送るかもしれません。 Notification Dataは怒っているパケットの始まりを含んでいます、そして、(ICMPメッセージのように)通知のSPI分野がIPsec SAのSPIに合うように設定されます。
RESERVED TO IANA - Error types 40 - 8191
RESERVED TO IANA--誤りは40--8191をタイプします。
Private Use - Errors 8192 - 16383
私用--誤り8192--16383
Kaufman Standards Track [Page 68] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[68ページ]RFC4306IKEv2 December 2005
NOTIFY MESSAGES - STATUS TYPES Value
------------------------------ -----
メッセージに通知してください--状態は値をタイプします。------------------------------ -----
INITIAL_CONTACT 16384
初期の_接触16384
This notification asserts that this IKE_SA is the only
IKE_SA currently active between the authenticated
identities. It MAY be sent when an IKE_SA is established
after a crash, and the recipient MAY use this information to
delete any other IKE_SAs it has to the same authenticated
identity without waiting for a timeout. This notification
MUST NOT be sent by an entity that may be replicated (e.g.,
a roaming user's credentials where the user is allowed to
connect to the corporate firewall from two remote systems at
the same time).
この通知は、このIKE_SAが現在認証されたアイデンティティの間でアクティブな唯一のIKE_SAであると断言します。 クラッシュの後にIKE_SAを設立するとき、それを送るかもしれません、そして、受取人はそれがタイムアウトを待たないで同じ認証されたアイデンティティに持っているいかなる他のIKE_SAsも削除するのにこの情報を使用するかもしれません。 模写されるかもしれない実体(例えば、ユーザが同時に2台のリモートシステムから法人のファイアウォールに接続できるローミングユーザの信任状)でこの通知を送ってはいけません。
SET_WINDOW_SIZE 16385
_窓_サイズ16385を設定してください。
This notification asserts that the sending endpoint is
capable of keeping state for multiple outstanding exchanges,
permitting the recipient to send multiple requests before
getting a response to the first. The data associated with a
SET_WINDOW_SIZE notification MUST be 4 octets long and
contain the big endian representation of the number of
messages the sender promises to keep. Window size is always
one until the initial exchanges complete.
この通知は、送付終点が複数の未決済為替のために状態を維持できると断言します、受取人が返事をもらう前の1日への複数の要求を送ることを許可して。 SET_WINDOW_SIZE通知に関連しているデータは、長い間の4つの八重奏であり、送付者が保つと約束するメッセージの数のビッグエンディアン表現を含まなければなりません。 交換が完成する初期までいつもウィンドウサイズは1です。
ADDITIONAL_TS_POSSIBLE 16386
追加_t_の可能な16386
This notification asserts that the sending endpoint narrowed
the proposed traffic selectors but that other traffic
selectors would also have been acceptable, though only in a
separate SA (see section 2.9). There is no data associated
with this Notify type. It may be sent only as an additional
payload in a message including accepted TSs.
この通知は、送付終点が提案された交通セレクタを狭くしましたが、また、他の交通セレクタが許容できていると断言します、別々のSAだけで(セクション2.9を見てください)。 このNotifyタイプに関連しているどんなデータもありません。 受け入れられたTSsを含んでいて、単に追加ペイロードとしてメッセージでそれを送るかもしれません。
IPCOMP_SUPPORTED 16387
IPCOMP_は16387を支持しました。
This notification may be included only in a message
containing an SA payload negotiating a CHILD_SA and
indicates a willingness by its sender to use IPComp on this
SA. The data associated with this notification includes a
two-octet IPComp CPI followed by a one-octet transform ID
optionally followed by attributes whose length and format
are defined by that transform ID. A message proposing an SA
may contain multiple IPCOMP_SUPPORTED notifications to
indicate multiple supported algorithms. A message accepting
an SA may contain at most one.
この通知は、CHILD_SAを交渉して、SAペイロードを含むメッセージだけに含まれるかもしれなくて、このSAの上のIPCompを使用するために送付者で意欲を示します。 この通知に関連しているデータは2八重奏のIPComp CPIを含んでいます、続いて1八重奏の変換IDを含んでいます、任意に、続いて、長さと書式がその変換IDによって定義される属性を含んでいます。 SAを提案するメッセージは複数の支持されたアルゴリズムSAを受け入れると最も1つに含むかもしれないメッセージを示す複数のIPCOMP_SUPPORTED通知を含むかもしれません。
Kaufman Standards Track [Page 69] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[69ページ]RFC4306IKEv2 December 2005
The transform IDs currently defined are:
現在定義されている変換IDは以下の通りです。
NAME NUMBER DEFINED IN
----------- ------ -----------
RESERVED 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2 RFC 2394
IPCOMP_LZS 3 RFC 2395
IPCOMP_LZJH 4 RFC 3051
名前番号はINを定義しました。----------- ------ ----------- 予約された0IPCOMP_OUI1IPCOMP_は2RFC2394IPCOMP_LZS3RFC2395IPCOMP_LZJH4RFC3051に空気を抜かせます。
values 5-240 are reserved to IANA. Values 241-255 are
for private use among mutually consenting parties.
値5-240はIANAに予約されます。 値241-255が私的使用目的で互いに同意しているパーティーにあります。
NAT_DETECTION_SOURCE_IP 16388
ナット_検出_ソース_IP16388
This notification is used by its recipient to determine
whether the source is behind a NAT box. The data associated
with this notification is a SHA-1 digest of the SPIs (in the
order they appear in the header), IP address, and port on
which this packet was sent. There MAY be multiple Notify
payloads of this type in a message if the sender does not
know which of several network attachments will be used to
send the packet. The recipient of this notification MAY
compare the supplied value to a SHA-1 hash of the SPIs,
source IP address, and port, and if they don't match it
SHOULD enable NAT traversal (see section 2.23).
Alternately, it MAY reject the connection attempt if NAT
traversal is not supported.
この通知は、NAT箱の後ろにソースがあるかを決定するのに受取人によって使用されます。 この通知に関連しているデータはこのパケットが送られたSPIs(彼らがヘッダーで見えるオーダーにおける)、IPアドレス、およびポートのSHA-1ダイジェストです。 送付者が、いくつかのネットワーク付属のどれがパケットを送るのに使用されるかを知らないなら、メッセージにはこのタイプの複数のNotifyペイロードがあるかもしれません。 この通知の受取人はSPIs、ソースIPアドレス、およびポートのSHA-1細切れ肉料理と供給値を比較するかもしれません、そして、彼らがそれに合っていないなら、SHOULDはNAT縦断を可能にします(セクション2.23を見てください)。 交互に、NAT縦断が支持されないなら、それは接続試みを拒絶するかもしれません。
NAT_DETECTION_DESTINATION_IP 16389
ナット_検出_目的地_IP16389
This notification is used by its recipient to determine
whether it is behind a NAT box. The data associated with
this notification is a SHA-1 digest of the SPIs (in the
order they appear in the header), IP address, and port to
which this packet was sent. The recipient of this
notification MAY compare the supplied value to a hash of the
SPIs, destination IP address, and port, and if they don't
match it SHOULD invoke NAT traversal (see section 2.23). If
they don't match, it means that this end is behind a NAT and
this end SHOULD start sending keepalive packets as defined
in [Hutt05]. Alternately, it MAY reject the connection
attempt if NAT traversal is not supported.
この通知は、NAT箱の後ろにそれがあるかを決定するのに受取人によって使用されます。 この通知に関連しているデータはこのパケットが送られたSPIs(彼らがヘッダーで見えるオーダーにおける)、IPアドレス、およびポートのSHA-1ダイジェストです。 この通知の受取人はSPIs、送付先IPアドレス、およびポートの細切れ肉料理と供給値を比較するかもしれません、そして、彼らがそれに合っていないなら、SHOULDはNAT縦断を呼び出します(セクション2.23を見てください)。 彼らが合っていないなら、それは、NATの後ろにこの終わりがあることを意味します、そして、この終わりのSHOULDは[Hutt05]で定義されるようにkeepaliveパケットを送り始めます。 交互に、NAT縦断が支持されないなら、それは接続試みを拒絶するかもしれません。
Kaufman Standards Track [Page 70] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[70ページ]RFC4306IKEv2 December 2005
COOKIE 16390
クッキー16390
This notification MAY be included in an IKE_SA_INIT
response. It indicates that the request should be retried
with a copy of this notification as the first payload. This
notification MUST be included in an IKE_SA_INIT request
retry if a COOKIE notification was included in the initial
response. The data associated with this notification MUST
be between 1 and 64 octets in length (inclusive).
この通知はイケ_SA_INIT応答に含まれるかもしれません。 それは、要求が最初のペイロードとしてこの通知のコピーで再試行されるべきであるのを示します。 COOKIE通知が初期の応答に含まれていたなら、イケ_SA_INIT要求再試行にこの通知を含まなければなりません。 この通知に関連しているデータは長さ(包括的な)が1〜64の八重奏であるに違いありません。
USE_TRANSPORT_MODE 16391
使用_輸送_モード16391
This notification MAY be included in a request message that
also includes an SA payload requesting a CHILD_SA. It
requests that the CHILD_SA use transport mode rather than
tunnel mode for the SA created. If the request is accepted,
the response MUST also include a notification of type
USE_TRANSPORT_MODE. If the responder declines the request,
the CHILD_SA will be established in tunnel mode. If this is
unacceptable to the initiator, the initiator MUST delete the
SA. Note: Except when using this option to negotiate
transport mode, all CHILD_SAs will use tunnel mode.
この通知はまた、CHILD_SAを要求するSAペイロードを含んでいる要求メッセージに含まれるかもしれません。 それは、CHILD_SAがSAのためのトンネルモードよりむしろモードが作成した輸送を使用するよう要求します。 また、要求を受け入れるなら、応答はタイプUSE_TRANSPORT_MODEの通知を含まなければなりません。 応答者が要求を断ると、CHILD_SAはトンネルモードに設立されるでしょう。 創始者にとって、これが容認できないなら、創始者はSAを削除しなければなりません。 以下に注意してください。 交通機関を交渉するのにこのオプションを使用する時を除いて、すべてのCHILD_SAsがトンネルモードを使用するでしょう。
Note: The ECN decapsulation modifications specified in
[RFC4301] MUST be performed for every tunnel mode SA created
by IKEv2.
以下に注意してください。 IKEv2によって作成されたあらゆるトンネルモードSAのために[RFC4301]で指定された電子証券取引ネットワークの被膜剥離術変更を実行しなければなりません。
HTTP_CERT_LOOKUP_SUPPORTED 16392
HTTP_本命_ルックアップ_は16392を支持しました。
This notification MAY be included in any message that can
include a CERTREQ payload and indicates that the sender is
capable of looking up certificates based on an HTTP-based
URL (and hence presumably would prefer to receive
certificate specifications in that format).
この通知はCERTREQペイロードを含むことができて、送付者ができるのを示すHTTPベースのURL(そして、したがって、おそらく、その形式で証明書仕様を受け取るのを好む)に基づく証明書を調べるどんなメッセージにも含まれるかもしれません。
REKEY_SA 16393
REKEY_SA16393
This notification MUST be included in a CREATE_CHILD_SA
exchange if the purpose of the exchange is to replace an
existing ESP or AH SA. The SPI field identifies the SA
being rekeyed. There is no data.
交換の目的が既存の超能力かAH SAを取り替えることであるならCREATE_CHILD_SA交換にこの通知を含まなければなりません。 SPI分野は「再-合わせ」られるSAを特定します。 データが全くありません。
ESP_TFC_PADDING_NOT_SUPPORTED 16394
_どんな_も水増ししない超能力_TFC_が16394を支持しました。
This notification asserts that the sending endpoint will NOT
accept packets that contain Flow Confidentiality (TFC)
padding.
この通知は、送付終点がFlow Confidentiality(TFC)詰め物を含むパケットを受け入れないと断言します。
Kaufman Standards Track [Page 71] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[71ページ]RFC4306IKEv2 December 2005
NON_FIRST_FRAGMENTS_ALSO 16395
_また、非_の最初の_は16395を断片化します。
Used for fragmentation control. See [RFC4301] for
explanation.
断片化コントロールにおいて、使用されています。 説明に関して[RFC4301]を見てください。
RESERVED TO IANA - STATUS TYPES 16396 - 40959
IANA--状態タイプ16396--40959まで予約されます。
Private Use - STATUS TYPES 40960 - 65535
私用--状態は40960--65535をタイプします。
3.11. Delete Payload
3.11. 有効搭載量を削除してください。
The Delete Payload, denoted D in this memo, contains a protocol- specific security association identifier that the sender has removed from its security association database and is, therefore, no longer valid. Figure 17 shows the format of the Delete Payload. It is possible to send multiple SPIs in a Delete payload; however, each SPI MUST be for the same protocol. Mixing of protocol identifiers MUST NOT be performed in a Delete payload. It is permitted, however, to include multiple Delete payloads in a single INFORMATIONAL exchange where each Delete payload lists SPIs for a different protocol.
Delete有効搭載量は、このメモでDを指示して、送付者がセキュリティ協会データベースから取り除いたプロトコルの特定のセキュリティ協会識別子を含んでいて、したがって、もう有効ではありません。 図17はDelete有効搭載量の書式を示しています。 Deleteペイロードで複数のSPIsを送るのは可能です。 しかしながら、各SPI MUSTは同じプロトコルのためのそうです。 Deleteペイロードでプロトコル識別子の混合を実行してはいけません。 しかしながら、それぞれのDeleteペイロードが異なったプロトコルのためにSPIsを記載するところでそれがただ一つのINFORMATIONAL交換に複数のDeleteペイロードを含んでいることが許可されています。
Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI is the SPI the sending endpoint would expect in inbound ESP or AH packets.
IKE_SAの削除は1(IKE)にもかかわらず、SPIsがないプロトコルIDによって示されます。 超能力かAHなどのCHILD_SAの削除はそのプロトコル(AH、超能力のための3のための2)のIPsecプロトコルIDを含むでしょう、そして、SPIは送付終点が本国行きの超能力かAHパケットで予想するSPIです。
The Delete Payload is defined as follows:
Delete有効搭載量は以下の通り定義されます:
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size ! # of SPIs !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index(es) (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 予約..ペイロード長..プロトコル..ID..サイズ..セキュリティ..パラメタ..インデックス
Figure 17: Delete Payload Format
図17: 有効搭載量書式を削除してください。
o Protocol ID (1 octet) - Must be 1 for an IKE_SA, 2 for AH, or 3
for ESP.
o _IKEのための1がSA、AHのための2、または超能力のための3でなければならなかったならID(1つの八重奏)について議定書の中で述べてください。
Kaufman Standards Track [Page 72] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[72ページ]RFC4306IKEv2 December 2005
o SPI Size (1 octet) - Length in octets of the SPI as defined by the
protocol ID. It MUST be zero for IKE (SPI is in message header)
or four for AH and ESP.
o SPI Size(1つの八重奏)--定義されるとしてのプロトコルIDによるSPIの八重奏における長さ。 それは、IKE(SPIがメッセージヘッダーにある)のためのゼロかAHと超能力のための4でなければなりません。
o # of SPIs (2 octets) - The number of SPIs contained in the Delete
payload. The size of each SPI is defined by the SPI Size field.
o # SPIs(2つの八重奏)--Deleteペイロードに含まれたSPIsの数。 それぞれのSPIのサイズはSPI Size分野によって定義されます。
o Security Parameter Index(es) (variable length) - Identifies the
specific security association(s) to delete. The length of this
field is determined by the SPI Size and # of SPIs fields.
o セキュリティParameter Index(es)(可変長)--削除する特定のセキュリティ協会を特定します。 この分野の長さはSPIs分野のSPI Sizeと#によって測定されます。
The payload type for the Delete Payload is forty two (42).
Delete有効搭載量のためのペイロードタイプは42(42)です。
3.12. Vendor ID Payload
3.12. 業者ID有効搭載量
The Vendor ID Payload, denoted V in this memo, contains a vendor defined constant. The constant is used by vendors to identify and recognize remote instances of their implementations. This mechanism allows a vendor to experiment with new features while maintaining backward compatibility.
Vendor ID有効搭載量(このメモによる指示されたV)は業者の定義された定数を含んでいます。 定数は、彼らの実現のリモート例を特定して、認識するのに業者によって使用されます。 このメカニズムで、業者は後方の互換性を維持している間、新機能を実験できます。
A Vendor ID payload MAY announce that the sender is capable to accepting certain extensions to the protocol, or it MAY simply identify the implementation as an aid in debugging. A Vendor ID payload MUST NOT change the interpretation of any information defined in this specification (i.e., the critical bit MUST be set to 0). Multiple Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to send any Vendor ID payload at all.
Vendor IDペイロードが、送付者が、ある拡大をプロトコルに受け入れるようにできると発表するかもしれませんか、またはそれは、実現がデバッグで援助であると単に認識するかもしれません。 Vendor IDペイロードはこの仕様に基づき定義されたどんな情報の解釈も変えてはいけません(すなわち、重要なビットを0に設定しなければなりません)。 複数のVendor IDペイロードを送るかもしれません。 実現は全くどんなVendor IDペイロードも送るNOT REQUIREDです。
A Vendor ID payload may be sent as part of any message. Reception of a familiar Vendor ID payload allows an implementation to make use of Private USE numbers described throughout this memo -- private payloads, private exchanges, private notifications, etc. Unfamiliar Vendor IDs MUST be ignored.
どんなメッセージの一部としてもVendor IDペイロードを送るかもしれません。 身近なVendor IDペイロードのレセプションで、実現はこのメモ中で説明された兵士のUSE番号を利用できます--個人的なペイロード、私設交換機、個人的な通知など なじみのないVendor IDを無視しなければなりません。
Writers of Internet-Drafts who wish to extend this protocol MUST define a Vendor ID payload to announce the ability to implement the extension in the Internet-Draft. It is expected that Internet-Drafts that gain acceptance and are standardized will be given "magic numbers" out of the Future Use range by IANA, and the requirement to use a Vendor ID will go away.
このプロトコルを広げたがっているインターネット草稿の作家は、インターネット草稿における拡大を実行する能力を発表するためにVendor IDペイロードを定義しなければなりません。 承認を獲得して、標準化されるインターネット草稿がIANAによるFuture Use範囲からの与えられた「マジックナンバー」であり、Vendor IDを使用するという要件が遠ざかると予想されます。
Kaufman Standards Track [Page 73] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[73ページ]RFC4306IKEv2 December 2005
The Vendor ID Payload fields are defined as follows:
Vendor ID有効搭載量分野は以下の通り定義されます:
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Vendor ID (VID) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 予約..ペイロード長..業者..ID
Figure 18: Vendor ID Payload Format
図18: 業者ID有効搭載量形式
o Vendor ID (variable length) - It is the responsibility of the
person choosing the Vendor ID to assure its uniqueness in spite of
the absence of any central registry for IDs. Good practice is to
include a company name, a person name, or some such. If you want
to show off, you might include the latitude and longitude and time
where you were when you chose the ID and some random input. A
message digest of a long unique string is preferable to the long
unique string itself.
o ベンダーID(可変長)--IDのためにどんな中央の登録も不在にもかかわらず、ユニークさに保証するのは、人がVendor IDを選ぶ責任です。 良い習慣は会社名、人の名、またはいくらかのそのようなものを含むことになっています。 IDと何らかの無作為の入力を選んだとき、目立とうとしたいなら、あなたは入れたところで緯度、経度、および時間を入れるかもしれません。 長いユニークなストリングのメッセージダイジェストは長いユニークなストリング自体より望ましいです。
The payload type for the Vendor ID Payload is forty three (43).
Vendor ID有効搭載量のためのペイロードタイプは43(43)です。
3.13. Traffic Selector Payload
3.13. トラフィックセレクタ有効搭載量
The Traffic Selector Payload, denoted TS in this memo, allows peers to identify packet flows for processing by IPsec security services. The Traffic Selector Payload consists of the IKE generic payload header followed by individual traffic selectors as follows:
TSは、このメモで同輩が処理のためにTraffic Selector有効搭載量でIPsecセキュリティー・サービスでパケット流れを特定できるのを指示しました。 Traffic Selector有効搭載量は以下の個々のトラフィックセレクタが支えたIKEジェネリックペイロードヘッダーから成ります:
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Number of TSs ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ <Traffic Selectors> ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 予約されました!
Figure 19: Traffic Selectors Payload Format
図19: トラフィックセレクタ有効搭載量形式
o Number of TSs (1 octet) - Number of traffic selectors being
provided.
o TSs(1つの八重奏)の数--提供されるトラフィックセレクタの数。
Kaufman Standards Track [Page 74] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[74ページ]RFC4306IKEv2 December 2005
o RESERVED - This field MUST be sent as zero and MUST be ignored on
receipt.
o RESERVED--この野原をゼロとして送らなければならなくて、領収書の上で無視しなければなりません。
o Traffic Selectors (variable length) - One or more individual
traffic selectors.
o トラフィックSelectors(可変長)--1個以上の個々のトラフィックセレクタ。
The length of the Traffic Selector payload includes the TS header and all the traffic selectors.
Traffic Selectorペイロードの長さはTSヘッダーとすべてのトラフィックセレクタを含んでいます。
The payload type for the Traffic Selector payload is forty four (44) for addresses at the initiator's end of the SA and forty five (45) for addresses at the responder's end.
Traffic Selectorペイロードのためのペイロードタイプは、創始者のSAの端のアドレスのための44(44)と応答者の方のアドレスのための45(45)です。
3.13.1. Traffic Selector
3.13.1. トラフィックセレクタ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! TS Type !IP Protocol ID*| Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Port* | End Port* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Starting Address* ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Ending Address* ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+++++++++++++++++++++++++++++++++! tタイプ!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 1IP Protocol ID*| セレクタの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ポート*を始動してください。| 端のポート*| 始める..アドレス..終わる..アドレス
Figure 20: Traffic Selector
図20: トラフィックセレクタ
* Note: All fields other than TS Type and Selector Length depend on the TS Type. The fields shown are for TS Types 7 and 8, the only two values currently defined.
* 以下に注意してください。 TS TypeとSelector Length以外のすべての分野がTS Typeに依存します。 示された分野はTS Types7のためのそうであり、8、唯一は現在定義されている2つの値です。
o TS Type (one octet) - Specifies the type of traffic selector.
o TS Type(1つの八重奏)--トラフィックセレクタのタイプを指定します。
o IP protocol ID (1 octet) - Value specifying an associated IP
protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the
protocol ID is not relevant to this traffic selector -- the SA can
carry all protocols.
o IPプロトコルID(1つの八重奏)--関連IPプロトコルID(例えば、UDP/TCP/ICMP)を指定する値。 ゼロの値は、プロトコルIDがこのトラフィックセレクタに関連していないことを意味します--SAはすべてのプロトコルを運ぶことができます。
o Selector Length - Specifies the length of this Traffic Selector
Substructure including the header.
o セレクタLength--ヘッダーを含むこのTraffic Selector Substructureの長さを指定します。
Kaufman Standards Track [Page 75] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[75ページ]RFC4306IKEv2 December 2005
o Start Port (2 octets) - Value specifying the smallest port number
allowed by this Traffic Selector. For protocols for which port is
undefined, or if all ports are allowed, this field MUST be zero.
For the ICMP protocol, the two one-octet fields Type and Code are
treated as a single 16-bit integer (with Type in the most
significant eight bits and Code in the least significant eight
bits) port number for the purposes of filtering based on this
field.
o Port(2つの八重奏)を始動してください--最もわずかなポートナンバーがこのTraffic Selectorで許した値の指定。 どのポートが未定義であるか、そして、またはすべてのポートが許容されているかどうかプロトコルのために、この分野はゼロでなければなりません。 ICMPプロトコルにおいて、2の1八重奏の分野のTypeとCodeはこの分野に基づくフィルタリングの目的のためにただ一つの16ビットの整数(Typeが最も重要な8ビットにあって、Codeが最も重要でない8ビットにある)ポートナンバーとして扱われます。
o End Port (2 octets) - Value specifying the largest port number
allowed by this Traffic Selector. For protocols for which port is
undefined, or if all ports are allowed, this field MUST be 65535.
For the ICMP protocol, the two one-octet fields Type and Code are
treated as a single 16-bit integer (with Type in the most
significant eight bits and Code in the least significant eight
bits) port number for the purposed of filtering based on this
field.
o 終わりのPort(2つの八重奏)--最も大きいポートナンバーがこのTraffic Selectorで許した指定を評価してください。 どのポートが未定義であるか、そして、またはすべてのポートが許容されているかどうかプロトコルのために、この分野は65535でなければなりません。 ICMPプロトコルにおいて、2の1八重奏の分野のTypeとCodeはこの分野に基づくフィルタリングの目的のためにただ一つの16ビットの整数(Typeが最も重要な8ビットにあって、Codeが最も重要でない8ビットにある)ポートナンバーとして扱われます。
o Starting Address - The smallest address included in this Traffic
Selector (length determined by TS type).
o 始めのAddress--このTraffic Selector(TSタイプによって決定している長さ)に最も小さいアドレスを含んでいます。
o Ending Address - The largest address included in this Traffic
Selector (length determined by TS type).
o 終わりのAddress--このTraffic Selector(TSタイプによって決定している長さ)に最も大きいアドレスを含んでいます。
Systems that are complying with [RFC4301] that wish to indicate "ANY" ports MUST set the start port to 0 and the end port to 65535; note that according to [RFC4301], "ANY" includes "OPAQUE". Systems working with [RFC4301] that wish to indicate "OPAQUE" ports, but not "ANY" ports, MUST set the start port to 65535 and the end port to 0.
「ANY」のポートを示したがっている[RFC4301]に従っているシステムは0へのスタートポートと65535への端のポートを設定しなければなりません。 [RFC4301]に従って「いずれも」が「不透明なもの」を含んでいることに注意してください。 「ANY」のポートではなく、「不透明な」ポートを示したがっている[RFC4301]と共に動作するシステムは65535へのスタートポートと0への端のポートを設定しなければなりません。
The following table lists the assigned values for the Traffic Selector Type field and the corresponding Address Selector Data.
以下のテーブルはTraffic Selector Type分野と対応するAddress Selector Dataのために割り当てられた値を記載します。
TS Type Value
------- -----
RESERVED 0-6
tは値をタイプします。------- ----- 0-6に予約されます。
TS_IPV4_ADDR_RANGE 7
t_IPV4_ADDR_範囲7
A range of IPv4 addresses, represented by two four-octet
values. The first value is the beginning IPv4 address
(inclusive) and the second value is the ending IPv4 address
(inclusive). All addresses falling between the two
specified addresses are considered to be within the list.
2つの4八重奏の値によって表されたさまざまなIPv4アドレス。 最初の値は始めのIPv4アドレス(包括的な)です、そして、2番目の値はIPv4が扱う(包括的な)結末です。 リストの中に2つの指定されたアドレスの間に下がるすべてのアドレスがあると考えられます。
Kaufman Standards Track [Page 76] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[76ページ]RFC4306IKEv2 December 2005
TS_IPV6_ADDR_RANGE 8
t_IPV6_ADDR_範囲8
A range of IPv6 addresses, represented by two sixteen-octet
values. The first value is the beginning IPv6 address
(inclusive) and the second value is the ending IPv6 address
(inclusive). All addresses falling between the two
specified addresses are considered to be within the list.
2つの16八重奏の値によって表されたさまざまなIPv6アドレス。 最初の値は始めのIPv6アドレス(包括的な)です、そして、2番目の値はIPv6が扱う(包括的な)結末です。 リストの中に2つの指定されたアドレスの間に下がるすべてのアドレスがあると考えられます。
RESERVED TO IANA 9-240
PRIVATE USE 241-255
IANA9-240私用241-255に予約されます。
3.14. Encrypted Payload
3.14. 暗号化された有効搭載量
The Encrypted Payload, denoted SK{...} or E in this memo, contains
other payloads in encrypted form. The Encrypted Payload, if present
in a message, MUST be the last payload in the message. Often, it is
the only payload in the message.
Encrypted有効搭載量、指示されたSK、… または、このメモによるE、暗号化されたフォームに他のペイロードを含んでいます。 メッセージに存在しているなら、Encrypted有効搭載量はメッセージで最後のペイロードであるに違いありません。 しばしば、それはメッセージで唯一のペイロードです。
The algorithms for encryption and integrity protection are negotiated during IKE_SA setup, and the keys are computed as specified in sections 2.14 and 2.18.
暗号化と保全保護のためのアルゴリズムはIKE_SAセットアップの間、交渉されます、そして、キーはセクション2.14と2.18で指定されるように計算されます。
The encryption and integrity protection algorithms are modeled after the ESP algorithms described in RFCs 2104 [KBC96], 4303 [RFC4303], and 2451 [ESPCBC]. This document completely specifies the cryptographic processing of IKE data, but those documents should be consulted for design rationale. We require a block cipher with a fixed block size and an integrity check algorithm that computes a fixed-length checksum over a variable size message.
暗号化と保全保護アルゴリズムはRFCs2104[KBC96]、4303年[RFC4303]、および2451年[ESPCBC]に説明された超能力アルゴリズムに倣われます。 このドキュメントはIKEデータの暗号の処理を完全に指定しますが、それらのドキュメントはデザイン原理のために参照されるべきです。 私たちは固定ブロック・サイズと保全チェックアルゴリズムがある可変サイズメッセージに関して固定長チェックサムを計算するブロック暗号を必要とします。
The payload type for an Encrypted payload is forty six (46). The Encrypted Payload consists of the IKE generic payload header followed by individual fields as follows:
Encryptedペイロードのためのペイロードタイプは46(46)です。 Encrypted有効搭載量は以下の個々の分野があとに続いたIKEジェネリックペイロードヘッダーから成ります:
Kaufman Standards Track [Page 77] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[77ページ]RFC4306IKEv2 December 2005
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initialization Vector !
! (length is block size for encryption algorithm) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encrypted IKE Payloads ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! Padding (0-255 octets) !
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
! ! Pad Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 有効搭載量..初期設定..長さ..ブロック・サイズ..暗号化..アルゴリズム..有効搭載量; 八重奏
Figure 21: Encrypted Payload Format
図21: 暗号化された有効搭載量形式
o Next Payload - The payload type of the first embedded payload.
Note that this is an exception in the standard header format,
since the Encrypted payload is the last payload in the message and
therefore the Next Payload field would normally be zero. But
because the content of this payload is embedded payloads and there
was no natural place to put the type of the first one, that type
is placed here.
o 次の有効搭載量--1番目のペイロードタイプはペイロードを埋め込みました。 これが標準のヘッダー形式の例外であることに注意してください、Encryptedペイロードはメッセージで最後のペイロードです、そして、したがって、したがって、通常、Next有効搭載量分野はゼロでしょう。 しかし、このペイロードの内容が埋め込まれたペイロードであり、最初のもののタイプを置くどんな自然な場所もなかったので、そのタイプはここに置かれます。
o Payload Length - Includes the lengths of the header, IV, Encrypted
IKE Payloads, Padding, Pad Length, and Integrity Checksum Data.
o 有効搭載量Length--ヘッダー、IV、Encrypted IKE有効搭載量、Padding、Pad Length、およびIntegrity Checksum Dataの長さを含んでいます。
o Initialization Vector - A randomly chosen value whose length is
equal to the block length of the underlying encryption algorithm.
Recipients MUST accept any value. Senders SHOULD either pick this
value pseudo-randomly and independently for each message or use
the final ciphertext block of the previous message sent. Senders
MUST NOT use the same value for each message, use a sequence of
values with low hamming distance (e.g., a sequence number), or use
ciphertext from a received message.
o 初期設定Vector--長さが基本的な暗号化アルゴリズムのブロック長と等しい手当たりしだいに選ばれた値。 受取人はどんな値も受け入れなければなりません。 そして、送付者SHOULDがこの値を選ぶ、疑似である、無作為である、独自に、各メッセージか使用のために、前のメッセージの最終的な暗号文ブロックは発信しました。 Sendersは、各メッセージに同じ値を使用してはいけませんし、低大根役者距離(例えば、一連番号)と共に値の系列を使用してはいけませんし、また受信されたメッセージから暗号文を使用してはいけません。
o IKE Payloads are as specified earlier in this section. This field
is encrypted with the negotiated cipher.
o このセクションで、より早く指定されるとしてIKE有効搭載量があります。 この分野は交渉された暗号で暗号化されます。
o Padding MAY contain any value chosen by the sender, and MUST have
a length that makes the combination of the Payloads, the Padding,
and the Pad Length to be a multiple of the encryption block size.
This field is encrypted with the negotiated cipher.
o 詰め物は、送付者によって選ばれたどんな値も含むかもしれなくて、暗号化ブロック・サイズの倍数になるように有効搭載量、Padding、およびPad Lengthの組み合わせをする長さを持たなければなりません。 この分野は交渉された暗号で暗号化されます。
Kaufman Standards Track [Page 78] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[78ページ]RFC4306IKEv2 December 2005
o Pad Length is the length of the Padding field. The sender SHOULD
set the Pad Length to the minimum value that makes the combination
of the Payloads, the Padding, and the Pad Length a multiple of the
block size, but the recipient MUST accept any length that results
in proper alignment. This field is encrypted with the negotiated
cipher.
o パッドLengthはPadding分野の長さです。 送付者SHOULDは有効搭載量、Padding、およびPad Lengthの組み合わせをブロック・サイズの倍数にする最小値にPad Lengthを設定しますが、受取人は適切な整列をもたらすどんな長さも受け入れなければなりません。 この分野は交渉された暗号で暗号化されます。
o Integrity Checksum Data is the cryptographic checksum of the
entire message starting with the Fixed IKE Header through the Pad
Length. The checksum MUST be computed over the encrypted message.
Its length is determined by the integrity algorithm negotiated.
o 保全Checksum DataはPad Lengthを通してFixed IKE Headerから始まる全体のメッセージの暗号のチェックサムです。 暗号化メッセージに関してチェックサムを計算しなければなりません。 長さは交渉された保全アルゴリズムで測定されます。
3.15. Configuration Payload
3.15. 構成有効搭載量
The Configuration payload, denoted CP in this document, is used to exchange configuration information between IKE peers. The exchange is for an IRAC to request an internal IP address from an IRAS and to exchange other information of the sort that one would acquire with Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly connected to a LAN.
CPは、ConfigurationペイロードがIKE同輩の間で設定情報を交換するのに使用されるのを本書では指示しました。 交換は、IRACが直接LANに接続されたなら、IRACがIRASから内部のIPアドレスを要求して、1つがDynamic Host Configuration Protocol(DHCP)で取得する種類の他の情報を交換することです。
Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE request. The IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK or a Notify payload with an error type indicating why the request could not be honored. An exception is that a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted as an indication that the request was not supported.
構成ペイロードはタイプCFG_REQUEST/CFG_REPLYかCFG_SET/CFG_ACKのもの(以下でのペイロード記述でCFG Typeを見る)です。 CFG_REQUESTとCFG_SETペイロードは任意にどんなIKE要求にも追加されるかもしれません。 IKE応答は対応するCFG_REPLYかCFG_ACKかなぜ要求を光栄に思うことができなかったかを示す誤りタイプがあるNotifyペイロードのどちらかを含まなければなりません。 例外は最小限の器具がすべてのCFG_REQUESTとCFG_SETペイロードを無視するかもしれないということであり、そうは対応するCFG_REPLYもCFG_ACK MUSTのない応答メッセージです。要求がサポートされなかったという指示として、認められます。
"CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information from its peer. If an attribute in the CFG_REQUEST Configuration Payload is not zero-length, it is taken as a suggestion for that attribute. The CFG_REPLY Configuration Payload MAY return that value, or a new one. It MAY also add new attributes and not include some requested ones. Requestors MUST ignore returned attributes that they do not recognize.
「CFG_REQUEST/CFG_REPLY」で、IKE終点は同輩から情報を要求できます。 CFG_REQUEST Configuration有効搭載量における属性がゼロ・レングスでないなら、それはその属性のための提案としてみなされます。 CFG_REPLY Configuration有効搭載量はその値、または新しいものを返すかもしれません。 それは、また、新しい属性を加えて、いくつかの要求されたものを含まないかもしれません。 要請者は彼らが認識しない返された属性を無視しなければなりません。
Some attributes MAY be multi-valued, in which case multiple attribute values of the same type are sent and/or returned. Generally, all values of an attribute are returned when the attribute is requested. For some attributes (in this version of the specification only internal addresses), multiple requests indicates a request that multiple values be assigned. For these attributes, the number of values returned SHOULD NOT exceed the number requested.
いくつかの属性がマルチ評価されているかもしれない、その場合、同じタイプの複数の属性値が、送る、そして/または、返されます。 属性を要求するとき、一般に、属性のすべての値を返します。 いくつかの属性(インターナルだけが扱う仕様のこのバージョンの)のために、複数の要求が複数の値が割り当てられるという要求を示します。 これらの属性、返された値の数のために、SHOULD NOTは要求された数を超えています。
Kaufman Standards Track [Page 79] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[79ページ]RFC4306IKEv2 December 2005
If the data type requested in a CFG_REQUEST is not recognized or not supported, the responder MUST NOT return an error type but rather MUST either send a CFG_REPLY that MAY be empty or a reply not containing a CFG_REPLY payload at all. Error returns are reserved for cases where the request is recognized but cannot be performed as requested or the request is badly formatted.
データ型が、CFGで_REQUESTが認識されないか、またはサポートされないよう要求したなら、応答者は、誤りタイプを返してはいけませんが、むしろ全く空であるかもしれないCFG_REPLYかCFG_REPLYペイロードを含まない回答を送らなければなりません。 誤りリターンは要求を認識されますが、要求された通り実行できないか、または要求がひどくフォーマットされるケースのために控えられます。
"CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data to its peer. In this case, the CFG_SET Configuration Payload contains attributes the initiator wants its peer to alter. The responder MUST return a Configuration Payload if it accepted any of the configuration data and it MUST contain the attributes that the responder accepted with zero-length data. Those attributes that it did not accept MUST NOT be in the CFG_ACK Configuration Payload. If no attributes were accepted, the responder MUST return either an empty CFG_ACK payload or a response message without a CFG_ACK payload. There are currently no defined uses for the CFG_SET/CFG_ACK exchange, though they may be used in connection with extensions based on Vendor IDs. An minimal implementation of this specification MAY ignore CFG_SET payloads.
「CFG_SET/CFG_ACK」で、IKE終点は同輩にコンフィギュレーション・データを押すことができます。 この場合、CFG_SET Configuration有効搭載量は創始者が、同輩に変更して欲しい属性を含みます。 コンフィギュレーション・データのどれかを受け入れたなら、応答者はConfiguration有効搭載量を返さなければなりません、そして、それは応答者がゼロ・レングスデータで受け入れた属性を含まなければなりません。 CFG_ACK Configuration有効搭載量にはそれが受け入れなかったそれらの属性があるはずがありません。 属性を全く受け入れなかったなら、応答者はCFG_ACKペイロードなしで空のCFG_ACKペイロードか応答メッセージのどちらかを返さなければなりません。 CFG_SET/CFG_ACK交換への現在定義されなかった用途があります、それらはVendor IDに基づく拡大に関して使用されるかもしれませんが。 この仕様の最小限の器具はCFG_SETペイロードを無視するかもしれません。
Extensions via the CP payload SHOULD NOT be used for general purpose management. Its main intent is to provide a bootstrap mechanism to exchange information within IPsec from IRAS to IRAC. While it MAY be useful to use such a method to exchange information between some Security Gateways (SGW) or small networks, existing management protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP, or LDAP [LDAP] should be preferred for enterprise management as well as subsequent information exchanges.
拡大、CPペイロードSHOULD NOTを通して、汎用の管理に使用されてください。 主な意図はaを提供するのがIPsecの中でIRASからIRACまで情報交換するためにメカニズムを独力で進むということです。 いくつかのSecurity Gateways(SGW)か小さいネットワークの間で情報交換するそのようなメソッドを使用するのが役に立つかもしれない間、DHCP[DHCP]、RADIUS[RADIUS]、SNMP、またはLDAP[LDAP]などの既存の管理プロトコルはその後の情報交換と同様に企業管理のために好まれるべきです。
The Configuration Payload is defined as follows:
Configuration有効搭載量は以下の通り定義されます:
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! CFG Type ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Configuration Attributes ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 予約されました!ペイロード長!+++++++++++++++++++++++++++++++++! CFGタイプ!は+++++++++++++++++++++++++++++++++を予約しました!~構成は~!+++++++++++++++++++++++++++++++++を結果と考えます。
Figure 22: Configuration Payload Format
図22: 構成有効搭載量形式
The payload type for the Configuration Payload is forty seven (47).
Configuration有効搭載量のためのペイロードタイプは47(47)です。
Kaufman Standards Track [Page 80] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[80ページ]RFC4306IKEv2 December 2005
o CFG Type (1 octet) - The type of exchange represented by the
Configuration Attributes.
o CFG Type(1つの八重奏)--Configuration Attributesによって表された交換のタイプ。
CFG Type Value
=========== =====
RESERVED 0
CFG_REQUEST 1
CFG_REPLY 2
CFG_SET 3
CFG_ACK 4
CFGは値をタイプします。=========== ===== 予約された0CFG_要求1CFG_回答2CFG_セット3CFG_ACK4
values 5-127 are reserved to IANA. Values 128-255 are for private
use among mutually consenting parties.
値5-127はIANAに予約されます。 値128-255が私的使用目的で互いに同意しているパーティーにあります。
o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on
receipt.
o RESERVED(3つの八重奏)--ゼロとして送らなければなりません。 領収書の上で無視しなければなりません。
o Configuration Attributes (variable length) - These are type length
values specific to the Configuration Payload and are defined
below. There may be zero or more Configuration Attributes in this
payload.
o 構成Attributes(可変長)--これらは、Configuration有効搭載量に特定のタイプ長さの値であり、以下で定義されます。 このペイロードにはゼロか、より多くのConfiguration Attributesがあるかもしれません。
3.15.1. Configuration Attributes
3.15.1. 構成属性
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!R| Attribute Type ! Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! R| 属性タイプ!の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 値~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Configuration Attribute Format
図23: 構成属性形式
o Reserved (1 bit) - This bit MUST be set to zero and MUST be
ignored on receipt.
o 予約されました(1ビット)--このビットをゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
o Attribute Type (15 bits) - A unique identifier for each of the
Configuration Attribute Types.
o Type(15ビット)を結果と考えてください--それぞれのConfiguration Attribute Typesに、ユニークな識別子。
o Length (2 octets) - Length in octets of Value.
o 長さ(2つの八重奏)--Valueの八重奏における長さ。
o Value (0 or more octets) - The variable-length value of this
Configuration Attribute.
o (0つ以上の八重奏)を評価してください--このConfiguration Attributeの可変長の値。
Kaufman Standards Track [Page 81] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[81ページ]RFC4306IKEv2 December 2005
The following attribute types have been defined:
以下の属性タイプは定義されました:
Multi-
Attribute Type Value Valued Length
======================= ===== ====== ==================
RESERVED 0
INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets
INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
INTERNAL_IP4_DNS 3 YES 0 or 4 octets
INTERNAL_IP4_NBNS 4 YES 0 or 4 octets
INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets
INTERNAL_IP4_DHCP 6 YES 0 or 4 octets
APPLICATION_VERSION 7 NO 0 or more
INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
RESERVED 9
INTERNAL_IP6_DNS 10 YES 0 or 16 octets
INTERNAL_IP6_NBNS 11 YES 0 or 16 octets
INTERNAL_IP6_DHCP 12 YES 0 or 16 octets
INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets
SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
INTERNAL_IP6_SUBNET 15 YES 17 octets
マルチ属性タイプの値の評価された長さ======================= ===== ====== ================== RESERVED0INTERNAL_IP4_ADDRESS1はい*の0か4つの八重奏、INTERNAL_IP4_NETMASK2ノー0か4八重奏INTERNAL_IP4_DNS3はい0か4八重奏INTERNAL_IP4_NBNS4はい0か4つの八重奏INTERNAL_ADDRESS_EXPIRY5ノー0か4八重奏INTERNAL_IP4_DHCP、6はい0か4の八重奏APPLICATION_バージョン、 より7より多くのノー0; INTERNAL_IP6はい*0か17の_ADDRESS8八重奏RESERVED9INTERNAL_IP6_DNS10はい0か16八重奏INTERNAL_IP6_NBNS11はい0か16の八重奏INTERNAL_IP6_DHCP、2INTERNAL_IP6_SUBNET15はい17の八重奏の12はい0か16の八重奏INTERNAL_IP4_SUBNET13はい0か8の八重奏SUPPORTED_ATTRIBUTES14ノーMultiple
* These attributes may be multi-valued on return only if multiple
values were requested.
* 複数の値が要求された場合にだけ、これらの属性はリターンのときにマルチ評価されているかもしれません。
Types 16-16383 are reserved to IANA. Values 16384-32767 are for
private use among mutually consenting parties.
タイプ16-16383はIANAに予約されます。 値16384-32767が私的使用目的で互いに同意しているパーティーにあります。
o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
internal network, sometimes called a red node address or
private address and MAY be a private address on the Internet.
In a request message, the address specified is a requested
address (or zero if no specific address is requested). If a
specific address is requested, it likely indicates that a
previous connection existed with this address and the requestor
would like to reuse that address. With IPv6, a requestor MAY
supply the low-order address bytes it wants to use. Multiple
internal addresses MAY be requested by requesting multiple
internal address attributes. The responder MAY only send up to
the number of addresses requested. The INTERNAL_IP6_ADDRESS is
made up of two fields: the first is a sixteen-octet IPv6
address and the second is a one-octet prefix-length as defined
in [ADDRIPV6].
o INTERNAL_IP4_ADDRESS、INTERNAL_IP6_ADDRESS--内部のネットワークに関するアドレス、赤を時々ノードアドレスか個人的なアドレスと呼んで、インターネットに関するプライベート・アドレスであるかもしれません。 または、指定されたアドレスが要求メッセージでは、要求されたアドレスである、(どんな特定のアドレスも要求されないならゼロに合わせる、) 特定のアドレスが要求されるなら、前の接続がこのアドレスで存在したのをおそらく示します、そして、要請者はそのアドレスを再利用したがっています。 IPv6と共に、要請者はそれが使用したがっている下位のアドレスバイトを供給するかもしれません。 複数の内部のアドレスが、複数の内部のアドレス属性を要求することによって、要求されているかもしれません。 応答者は要求されたアドレスの数まで発信するだけであるかもしれません。 INTERNAL_IP6_ADDRESSは2つの分野で作られます: 1番目は16八重奏のIPv6アドレスです、そして、2番目は[ADDRIPV6]で定義されるように1八重奏の接頭語長さです。
The requested address is valid until the expiry time defined
with the INTERNAL_ADDRESS EXPIRY attribute or there are no
IKE_SAs between the peers.
満期時間がINTERNALと共にADDRESS EXPIRYが結果と考える_を定義するまで、要求されたアドレスが有効であるか、または同輩の間には、IKE_SAsが全くありません。
Kaufman Standards Track [Page 82] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[82ページ]RFC4306IKEv2 December 2005
o INTERNAL_IP4_NETMASK - The internal network's netmask. Only
one netmask is allowed in the request and reply messages (e.g.,
255.255.255.0), and it MUST be used only with an
INTERNAL_IP4_ADDRESS attribute.
o INTERNAL_IP4_NETMASK--内部のネットワークのネットマスク。 .0、)およびそれは使用しなければなりません。1つのネットマスクだけが要求と応答メッセージに許容されている、(例えば、255.255、.255、INTERNAL_IP4_ADDRESS属性だけと共に使用されてください。
o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a
DNS server within the network. Multiple DNS servers MAY be
requested. The responder MAY respond with zero or more DNS
server attributes.
o INTERNAL_IP4_DNS、INTERNAL_IP6_DNS--ネットワークの中でDNSサーバのアドレスを指定します。 複数のDNSサーバが要求されているかもしれません。 応答者はゼロか、より多くのDNSサーバ属性で応じるかもしれません。
o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of
a NetBios Name Server (WINS) within the network. Multiple NBNS
servers MAY be requested. The responder MAY respond with zero
or more NBNS server attributes.
o INTERNAL_IP4_NBNS、INTERNAL_IP6_NBNS--ネットワークの中でNetBios Name Server(WINS)のアドレスを指定します。 複数のNBNSサーバが要求されているかもしれません。 応答者はゼロか、より多くのNBNSサーバ属性で応じるかもしれません。
o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that
the host can use the internal IP address. The host MUST renew
the IP address before this expiry time. Only one of these
attributes MAY be present in the reply.
o INTERNAL_ADDRESS_EXPIRY--ホストが内部のIPアドレスを使用できる秒の数を指定します。 ホストはこの満期時の前にIPアドレスを更新しなければなりません。 これらの属性の1つだけが回答で存在しているかもしれません。
o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to
send any internal DHCP requests to the address contained within
the attribute. Multiple DHCP servers MAY be requested. The
responder MAY respond with zero or more DHCP server attributes.
o INTERNAL_IP4_DHCP、INTERNAL_IP6_DHCP--あらゆる内部のDHCP要求を属性の中に含まれたアドレスに送るようホストに命令します。 複数のDHCPサーバが要求されているかもしれません。 応答者はゼロか、より多くのDHCPサーバ属性で応じるかもしれません。
o APPLICATION_VERSION - The version or application information of
the IPsec host. This is a string of printable ASCII characters
that is NOT null terminated.
o APPLICATION_バージョン--IPsecホストのバージョンかアプリケーション情報。 これは一連の印刷可能なASCII文字です、すなわち、どんなヌルも終わりませんでした。
o INTERNAL_IP4_SUBNET - The protected sub-networks that this
edge-device protects. This attribute is made up of two fields:
the first is an IP address and the second is a netmask.
Multiple sub-networks MAY be requested. The responder MAY
respond with zero or more sub-network attributes.
o INTERNAL_IP4_SUBNET--このエッジデバイスが保護する保護されたサブネットワーク。 この属性は2つの分野で作られます: 1番目はIPアドレスです、そして、2番目はネットマスクです。 複数のサブネットワークが要求されているかもしれません。 応答者はゼロか、より多くのサブネットワーク属性で応じるかもしれません。
o SUPPORTED_ATTRIBUTES - When used within a Request, this
attribute MUST be zero-length and specifies a query to the
responder to reply back with all of the attributes that it
supports. The response contains an attribute that contains a
set of attribute identifiers each in 2 octets. The length
divided by 2 (octets) would state the number of supported
attributes contained in the response.
o SUPPORTED_ATTRIBUTES--Requestの中で使用されると、この属性は、それがサポートする属性のすべてで返答し返すためにゼロ・レングスでなければならなく、応答者に質問を指定します。 応答はそれぞれ2つの八重奏における、1セットの属性識別子を含む属性を含んでいます。 2(八重奏)によって分割された長さは応答に含まれたサポートしている属性の数を述べるでしょう。
Kaufman Standards Track [Page 83] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[83ページ]RFC4306IKEv2 December 2005
o INTERNAL_IP6_SUBNET - The protected sub-networks that this
edge-device protects. This attribute is made up of two fields:
the first is a sixteen-octet IPv6 address and the second is a
one-octet prefix-length as defined in [ADDRIPV6]. Multiple
sub-networks MAY be requested. The responder MAY respond with
zero or more sub-network attributes.
o INTERNAL_IP6_SUBNET--このエッジデバイスが保護する保護されたサブネットワーク。 この属性は2つの分野で作られます: 1番目は16八重奏のIPv6アドレスです、そして、2番目は[ADDRIPV6]で定義されるように1八重奏の接頭語長さです。 複数のサブネットワークが要求されているかもしれません。 応答者はゼロか、より多くのサブネットワーク属性で応じるかもしれません。
Note that no recommendations are made in this document as to how
an implementation actually figures out what information to send in
a reply. That is, we do not recommend any specific method of an
IRAS determining which DNS server should be returned to a
requesting IRAC.
実装が、実際に回答でどんな情報を送ったらよいかを本書ではどう理解するかに関して推薦状を全くしないことに注意してください。 すなわち、私たちはIRASが、どのDNSサーバが要求IRACに返されるべきであるかを決定する少しの特定のメソッドも推薦しません。
3.16. Extensible Authentication Protocol (EAP) Payload
3.16. 拡張認証プロトコル(EAP)有効搭載量
The Extensible Authentication Protocol Payload, denoted EAP in this memo, allows IKE_SAs to be authenticated using the protocol defined in RFC 3748 [EAP] and subsequent extensions to that protocol. The full set of acceptable values for the payload is defined elsewhere, but a short summary of RFC 3748 is included here to make this document stand alone in the common cases.
EAPは、このメモで拡張認証プロトコル有効搭載量が、IKE_SAsが認証されるのをRFC3748[EAP]とその後の拡大でそのプロトコルと定義されたプロトコルを使用することで許容するのを指示しました。 ペイロードのための許容値のフルセットはほかの場所で定義されますが、RFC3748に関する要約は、このドキュメントをよくある例で単独で立たせるためにここに含まれています。
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ EAP Message ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 予約されました!
Figure 24: EAP Payload Format
図24: EAP有効搭載量形式
The payload type for an EAP Payload is forty eight (48).
EAP有効搭載量のためのペイロードタイプは48(48)です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Code ! Identifier ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Type_Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
タイプしてください!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 25: EAP Message Format
図25: EAPメッセージ・フォーマット
o Code (1 octet) indicates whether this message is a Request (1),
Response (2), Success (3), or Failure (4).
o コード(1つの八重奏)は、このメッセージがRequest(1)、Response(2)、Success(3)、またはFailure(4)であるかを示します。
Kaufman Standards Track [Page 84] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[84ページ]RFC4306IKEv2 December 2005
o Identifier (1 octet) is used in PPP to distinguish replayed
messages from repeated ones. Since in IKE, EAP runs over a
reliable protocol, it serves no function here. In a response
message, this octet MUST be set to match the identifier in the
corresponding request. In other messages, this field MAY be set
to any value.
o 識別子(1つの八重奏)は、繰り返されたものと再演されたメッセージを区別するのにPPPで使用されます。 EAPがIKEで信頼できるプロトコルをひくので、それはここで機能を全く果たしません。 応答メッセージでは、対応する要求における識別子を合わせるようにこの八重奏を設定しなければなりません。 他のメッセージでは、この分野はどんな値にも設定されるかもしれません。
o Length (2 octets) is the length of the EAP message and MUST be
four less than the Payload Length of the encapsulating payload.
o 長さ(2つの八重奏)は、EAPメッセージの長さであり、要約ペイロードの有効搭載量Lengthよりそれほど4であるに違いありません。
o Type (1 octet) is present only if the Code field is Request (1) or
Response (2). For other codes, the EAP message length MUST be
four octets and the Type and Type_Data fields MUST NOT be present.
In a Request (1) message, Type indicates the data being requested.
In a Response (2) message, Type MUST either be Nak or match the
type of the data requested. The following types are defined in
RFC 3748:
o タイプ(1つの八重奏)はCode分野がRequest(1)かResponse(2)である場合にだけ出席しています。 他のコードのために、EAPメッセージ長は、4つの八重奏とTypeでなければなりません、そして、Type_Data分野は存在しているはずがありません。 Request(1)メッセージでは、Typeは要求されているデータを示します。 Response(2)メッセージでは、Typeはデータのタイプが要求したNakかマッチのどちらかであるに違いありません。 以下のタイプはRFC3748で定義されます:
1 Identity
2 Notification
3 Nak (Response Only)
4 MD5-Challenge
5 One-Time Password (OTP)
6 Generic Token Card
1 アイデンティティ2通知3Nak(応答専用)4MD5-挑戦5ワンタイムパスワード(OTP)6ジェネリックトークン・カード
o Type_Data (Variable Length) varies with the Type of Request and
the associated Response. For the documentation of the EAP
methods, see [EAP].
o Data(可変Length)がRequestのTypeと関連Responseと共に変える_をタイプしてください。 EAPメソッドのドキュメンテーションに関しては、[EAP]を見てください。
Note that since IKE passes an indication of initiator identity in message 3 of the protocol, the responder SHOULD NOT send EAP Identity requests. The initiator SHOULD, however, respond to such requests if it receives them.
IKEがプロトコルに関するメッセージ3における、創始者のアイデンティティのしるしを通過するので応答者SHOULD NOTが要求をEAP Identityに送ることに注意してください。 しかしながら、それらを受けるなら、創始者SHOULDはそのような要求に応じます。
4. Conformance Requirements
4. 順応要件
In order to assure that all implementations of IKEv2 can interoperate, there are "MUST support" requirements in addition to those listed elsewhere. Of course, IKEv2 is a security protocol, and one of its major functions is to allow only authorized parties to successfully complete establishment of SAs. So a particular implementation may be configured with any of a number of restrictions concerning algorithms and trusted authorities that will prevent universal interoperability.
IKEv2の実装がそこに共同利用できるのが、「サポートしなければならない」ことであることを保証するために、それらに加えた要件はほかの場所にリストアップされました。 もちろん、IKEv2はセキュリティプロトコルです、そして、主要な機能の1つはSAsの首尾よく完全な設立に認可されたパーティーだけを許容することです。 それで、特定の実装は多くの制限のいずれによっても普遍的な相互運用性を防ぐアルゴリズムと信じられた当局に関して構成されるかもしれません。
Kaufman Standards Track [Page 85] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[85ページ]RFC4306IKEv2 December 2005
IKEv2 is designed to permit minimal implementations that can interoperate with all compliant implementations. There are a series of optional features that can easily be ignored by a particular implementation if it does not support that feature. Those features include:
IKEv2は、すべての対応する実装で共同利用できる最小限の器具を可能にするように設計されています。 その特徴をサポートしないなら特定の実装で容易に無視できる一連のオプション機能があります。 それらの特徴は:
Ability to negotiate SAs through a NAT and tunnel the resulting
ESP SA over UDP.
NATを通してSAsを交渉して、UDPの上で結果として起こるESP SAにトンネルを堀る能力。
Ability to request (and respond to a request for) a temporary IP
address on the remote end of a tunnel.
そして、要求する能力、(要求に応じる、)、トンネルのリモートエンドに関する一時的なIPアドレス。
Ability to support various types of legacy authentication.
レガシー認証の様々なタイプをサポートする能力。
Ability to support window sizes greater than one.
ウィンドウサイズに1つ以上をサポートする能力。
Ability to establish multiple ESP and/or AH SAs within a single
IKE_SA.
独身のIKE_SAの中に複数の超能力、そして/または、AH SAsを設立する能力。
Ability to rekey SAs.
rekey SAsへの能力。
To assure interoperability, all implementations MUST be capable of parsing all payload types (if only to skip over them) and to ignore payload types that it does not support unless the critical bit is set in the payload header. If the critical bit is set in an unsupported payload header, all implementations MUST reject the messages containing those payloads.
相互運用性を保証するために、すべての実装がすべてのペイロードタイプを分析できなければなりません、そして、(彼らを飛ばすために唯一なら)重要なビットがサポートしない場合それがサポートしないペイロードタイプを無視するのはペイロードヘッダーにセットしました。 重要なビットがサポートされないペイロードヘッダーに設定されるなら、すべての実装がそれらのペイロードを含むメッセージを拒絶しなければなりません。
Every implementation MUST be capable of doing four-message IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, one for ESP and/or AH). Implementations MAY be initiate-only or respond-only if appropriate for their platform. Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply (note that within the context of an IKE_SA, an "empty" message consists of an IKE header followed by an Encrypted payload with no payloads contained in it). A minimal implementation MAY support the CREATE_CHILD_SA exchange only in so far as to recognize requests and reject them with a Notify payload of type NO_ADDITIONAL_SAS. A minimal implementation need not be able to initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA expires (based on locally configured values of either lifetime or octets passed), and implementation MAY either try to renew it with a CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and create a new one. If the responder rejects the CREATE_CHILD_SA request with a NO_ADDITIONAL_SAS notification, the implementation MUST be capable of instead closing the old SA and creating a new one.
あらゆる実装が_2SAs(IKEのためのもの、超能力のためのもの、そして/または、AH)を設立するSA_INITとイケ_AUTH交換が4メッセージのイケにできなければなりません。 または、実装が開始専用であるかもしれない、応じる、-単に、それらのプラットホームにおいて、適切です。 あらゆる実装がINFORMATIONAL交換に応じることができなければなりませんが、最小限の器具は空のINFORMATIONAL回答でどんなINFORMATIONALメッセージにも応じるかもしれません(IKE_SAの文脈の中では、「空」のメッセージがEncryptedペイロードがそれに含まれたペイロードなしで支えたIKEヘッダーから成ることに注意してください)。 最小限の器具はSAが今までのところだけタイプいいえ_ADDITIONALのNotifyペイロードで要求を認識して、それらを拒絶するほど交換するCREATE_CHILD_に_SASをサポートするかもしれません。 最小限の器具はSAかINFORMATIONALが交換するCREATE_CHILD_を開始する必要はないことができます。 いつ、SAが期限が切れて(どちらかの局所的に構成された値に基づいて、生涯か八重奏が経過しました)、実装がCREATE_CHILD_SA交換でそれを更新しようとするかもしれないか、そして、それが、(近いところで)古いSAを削除して、新しいものを作成するかもしれません。 応答者がSAがいいえ_ADDITIONAL_SASの通知で要求するCREATE_CHILD_を拒絶するなら、実装は、代わりに古いSAを閉じて、新しいものを作成できなければなりません。
Kaufman Standards Track [Page 86] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[86ページ]RFC4306IKEv2 December 2005
Implementations are not required to support requesting temporary IP addresses or responding to such requests. If an implementation does support issuing such requests, it MUST include a CP payload in message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All other fields are optional. If an implementation supports responding to such requests, it MUST parse the CP payload of type CFG_REQUEST in message 3 and recognize a field of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing an address of the appropriate type, it MUST return a CP payload of type CFG_REPLY containing an address of the requested type. The responder SHOULD include all of the other related attributes if it has them.
実装は、そのような要求への一時的なIPアドレスを要求するか、応じることをサポートするのに必要ではありません。 実装が、発行がそのような要求であるとサポートするなら、それは少なくともaがさばくタイプINTERNAL_IP4_ADDRESSかINTERNAL_IP6_ADDRESSのメッセージ3含有にCPペイロードを含まなければなりません。 他のすべての分野が任意です。 実装がそのような要求への応じることをサポートするなら、それは、メッセージ3のタイプCFG_REQUESTのCPペイロードを分析して、タイプINTERNAL_IP4_ADDRESSかINTERNAL_IP6_ADDRESSの分野を認識しなければなりません。 賃貸借契約が適切なタイプのアドレスであるとサポートするなら、それは要求されたタイプのアドレスを含むタイプCFG_REPLYのCPペイロードを返さなければなりません。 それらを持っているなら、応答者SHOULDは他の関連する属性のすべてを含んでいます。
A minimal IPv4 responder implementation will ignore the contents of the CP payload except to determine that it includes an INTERNAL_IP4_ADDRESS attribute and will respond with the address and other related attributes regardless of whether the initiator requested them.
最小量のIPv4応答者実装は、INTERNAL_IP4_ADDRESS属性を含んでいることを決定するのを除いて、CPペイロードのコンテンツを無視して、創始者がそれらを要求したかどうかにかかわらずアドレスと他の関連する属性で応じるでしょう。
A minimal IPv4 initiator will generate a CP payload containing only an INTERNAL_IP4_ADDRESS attribute and will parse the response ignoring attributes it does not know how to use. The only attribute it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must use to bound the lifetime of the SA unless it successfully renews the lease before it expires. Minimal initiators need not be able to request lease renewals and minimal responders need not respond to them.
最小量のIPv4創始者は、INTERNAL_IP4_ADDRESS属性だけを含むCPペイロードを生成して、それが、どのようにが使用するかを知らない応答無視属性を分析するでしょう。 それが処理できなければならない唯一の属性はINTERNAL_ADDRESS_EXPIRY、期限が切れる前に首尾よくリースを更新しない場合どれに使用しなければならないかがSAの生涯を縛ったということです。 最小量の創始者は、リース更新と最小量の応答者が彼らに応じる必要はないよう要求する必要はないことができます。
For an implementation to be called conforming to this specification, it MUST be possible to configure it to accept the following:
実装がこの仕様に従うと呼ばれるために、以下を受け入れるためにそれを構成するのは可能でなければなりません:
PKIX Certificates containing and signed by RSA keys of size 1024 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or ID_DER_ASN1_DN.
1024ビットかIDが通り過ぎた2048ビットのサイズのRSAキーで含んでいて、署名するPKIX CertificatesはIDの___KEY_ID、ID FQDN、ID RFC822_ADDRかID_DER_ASN1_DNのいずれでもあります。
Shared key authentication where the ID passes is any of ID_KEY_ID, ID_FQDN, or ID_RFC822_ADDR.
共有された主要な認証はIDが通り過ぎるところの_ID KEY_ID、ID_FQDN、または_ID RFC822_ADDRのいずれでもあります。
Authentication where the responder is authenticated using PKIX Certificates and the initiator is authenticated using shared key authentication.
応答者がPKIX Certificatesと創始者を使用することで認証されるところで認証は、共有された主要な認証を使用することで認証されます。
Kaufman Standards Track [Page 87] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[87ページ]RFC4306IKEv2 December 2005
5. Security Considerations
5. セキュリティ問題
While this protocol is designed to minimize disclosure of configuration information to unauthenticated peers, some such disclosure is unavoidable. One peer or the other must identify itself first and prove its identity first. To avoid probing, the initiator of an exchange is required to identify itself first, and usually is required to authenticate itself first. The initiator can, however, learn that the responder supports IKE and what cryptographic protocols it supports. The responder (or someone impersonating the responder) can probe the initiator not only for its identity, but using CERTREQ payloads may be able to determine what certificates the initiator is willing to use.
このプロトコルは設定情報の公開を非認証された同輩に最小にするように設計されていますが、そのような何らかの公開が避けられません。 1人の同輩かもう片方が、最初に、それ自体を特定して、最初に、アイデンティティを立証しなければなりません。 交換の創始者は、調べるのを避けるために、最初にそれ自体を特定するのが必要であり、通常、最初に、それ自体を認証しなければなりません。 しかしながら、創始者は、応答者がIKEとそれがサポートするすべての暗号のプロトコルをサポートすることを学ぶことができます。 アイデンティティのためだけに創始者を調べることができるのではなく、CERTREQペイロードを使用している応答者(または、応答者をまねるだれか)は、どんな証明書を使用するかを構わない創始者が、思っている決定できるかもしれません。
Use of EAP authentication changes the probing possibilities somewhat. When EAP authentication is used, the responder proves its identity before the initiator does, so an initiator that knew the name of a valid initiator could probe the responder for both its name and certificates.
EAP認証の使用は調べの可能性をいくらか変えます。 EAP認証が使用されているとき、応答者が、創始者の前のアイデンティティがすると立証するので、有効な創始者の名前を知っていた創始者は名前と証明書の両方のために応答者を調べることができました。
Repeated rekeying using CREATE_CHILD_SA without additional Diffie- Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a single key or overrun of either endpoint. Implementers should take note of this fact and set a limit on CREATE_CHILD_SA exchanges between exponentiations. This memo does not prescribe such a limit.
追加ディフィーのヘルマンの交換なしでCREATE_CHILD_SAを使用する繰り返された「再-合わせ」るのが単一のキーの暗号文解読術かどちらかの終点の超過に被害を受け易いSAsにすべてを残します。 Implementersは羃法の間のCREATE_CHILD_SA交換にこの事実に注目して、限界を設定するはずです。 このメモはそのような限界を定めません。
The strength of a key derived from a Diffie-Hellman exchange using any of the groups defined here depends on the inherent strength of the group, the size of the exponent used, and the entropy provided by the random number generator used. Due to these inputs, it is difficult to determine the strength of a key for any of the defined groups. Diffie-Hellman group number two, when used with a strong random number generator and an exponent no less than 200 bits, is common for use with 3DES. Group five provides greater security than group two. Group one is for historic purposes only and does not provide sufficient strength except for use with DES, which is also for historic use only. Implementations should make note of these estimates when establishing policy and negotiating security parameters.
ディフィー-ヘルマンの交換からここで定義されたグループのどれかを使用することで得られたキーの強さをグループの固有の勢力に依存します、と解説者のサイズは使用して、エントロピーは使用される乱数発生器で前提としました。 これらの入力のために、定義されたグループのどれかのためにキーの強さを測定するのは難しいです。 強い乱数発生器と解説者と共に少なくとも200ビット使用されると、3DESとの使用に、ディフィー-ヘルマングループ番号twoは一般的です。 グループfiveはグループtwoよりすばらしいセキュリティを提供します。 グループ1は、歴史的な目的だけのためにあって、使用以外の十分な力にDESを提供しません。(DESは歴史的な使用だけのためにもものです)。 方針を確立して、セキュリティパラメタを交渉するとき、実装はこれらのメモを見積りにするべきです。
Note that these limitations are on the Diffie-Hellman groups themselves. There is nothing in IKE that prohibits using stronger groups nor is there anything that will dilute the strength obtained from stronger groups (limited by the strength of the other algorithms negotiated including the prf function). In fact, the extensible framework of IKE encourages the definition of more groups; use of elliptical curve groups may greatly increase strength using much smaller numbers.
これらの制限がディフィー-ヘルマングループ自体にあることに注意してください。 何もより強いグループを使用するのを禁止するIKEにありません、そして、何もより強いグループ(prf機能を含んでいて、交渉された他のアルゴリズムの強さで、制限される)から得られた強さを希釈するものがありません。 事実上、IKEの広げることができるフレームワークは、より多くのグループの定義を奨励します。 楕円のカーブグループの使用は、はるかに少ない数を使用することで強さを大いに増強するかもしれません。
Kaufman Standards Track [Page 88] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[88ページ]RFC4306IKEv2 December 2005
It is assumed that all Diffie-Hellman exponents are erased from memory after use. In particular, these exponents MUST NOT be derived from long-lived secrets like the seed to a pseudo-random generator that is not erased after use.
すべてのディフィー-ヘルマン解説者が使用の後にメモリから消されると思われます。 特に、これらの解説者を種子のような長命の秘密から使用の後に消されない擬似ランダムジェネレータまで引き出してはいけません。
The strength of all keys is limited by the size of the output of the negotiated prf function. For this reason, a prf function whose output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with this protocol.
すべてのキーの強さは交渉されたprf機能の出力のサイズによって制限されます。 この理由のために、このプロトコルと共に出力が128ビット(例えば、3DES-CBC)未満であるprf機能を使用してはいけません。
The security of this protocol is critically dependent on the randomness of the randomly chosen parameters. These should be generated by a strong random or properly seeded pseudo-random source (see [RFC4086]). Implementers should take care to ensure that use of random numbers for both keys and nonces is engineered in a fashion that does not undermine the security of the keys.
このプロトコルのセキュリティは批判的に手当たりしだいに選ばれたパラメタの偶発性に依存しています。 これらは無作為の、または、適切に種を蒔かれた強い擬似ランダムソースによって生成されるべきです([RFC4086]を見てください)。 Implementersは、乱数のキーと一回だけの両方の使用がキーのセキュリティを弱体化させないファッションで設計されるのを保証するために注意するはずです。
For information on the rationale of many of the cryptographic design choices in this protocol, see [SIGMA] and [SKEME]. Though the security of negotiated CHILD_SAs does not depend on the strength of the encryption and integrity protection negotiated in the IKE_SA, implementations MUST NOT negotiate NONE as the IKE integrity protection algorithm or ENCR_NULL as the IKE encryption algorithm.
このプロトコルにおける暗号のデザイン選択の多くの原理の情報に関しては、[SIGMA]と[SKEME]を見てください。 交渉されたCHILD_SAsのセキュリティはIKE_SAで交渉された暗号化と保全保護の強さによりませんが、実装はIKE保全保護アルゴリズムとしてのNONEかIKE暗号化アルゴリズムとしてのENCR_NULLを交渉してはいけません。
When using pre-shared keys, a critical consideration is how to assure the randomness of these secrets. The strongest practice is to ensure that any pre-shared key contain as much randomness as the strongest key being negotiated. Deriving a shared secret from a password, name, or other low-entropy source is not secure. These sources are subject to dictionary and social engineering attacks, among others.
あらかじめ共有されたキーを使用するとき、重要な考慮はどうこれらの秘密を偶発性に保証するかということです。 最も強い習慣は、どんなあらかじめ共有されたキーも交渉される中で最も強いキーと同じくらい多くの偶発性を含むのを保証することになっています。 パスワード、名前、または他の低エントロピーソースから共有秘密キーを得るのは安全ではありません。 これらのソースは辞書と特にソーシャルエンジニアリング攻撃を受けることがあります。
The NAT_DETECTION_*_IP notifications contain a hash of the addresses and ports in an attempt to hide internal IP addresses behind a NAT. Since the IPv4 address space is only 32 bits, and it is usually very sparse, it would be possible for an attacker to find out the internal address used behind the NAT box by trying all possible IP addresses and trying to find the matching hash. The port numbers are normally fixed to 500, and the SPIs can be extracted from the packet. This reduces the number of hash calculations to 2^32. With an educated guess of the use of private address space, the number of hash calculations is much smaller. Designers should therefore not assume that use of IKE will not leak internal address information.
NAT_DETECTION_*_IP通知はNATの後ろに内部のIPアドレスを隠す試みでアドレスとポートのハッシュを含んでいます。 IPv4アドレス空間が32ビットであるにすぎなく、それが通常非常にまばらであるので、攻撃者がNAT箱の後ろですべての可能なIPアドレスを試みて、合っているハッシュを見つけようとすることによって使用される内部のアドレスを見つけるのは、可能でしょう。 通常、500にポートナンバーを固定しています、そして、パケットからSPIsを抽出できます。 これはハッシュ計算の数を2^32まで減少させます。 プライベート・アドレススペースの使用の経験に基づいた推測で、ハッシュ計算の数ははるかに少ないです。 したがって、デザイナーは、IKEの使用が内部のアドレス情報を漏らさないと仮定するべきではありません。
When using an EAP authentication method that does not generate a shared key for protecting a subsequent AUTH payload, certain man-in- the-middle and server impersonation attacks are possible [EAPMITM]. These vulnerabilities occur when EAP is also used in protocols that are not protected with a secure tunnel. Since EAP is a general-
そして、EAP認証方法を使用するとき、それはその後のAUTHペイロードを保護するための共有されたキーを生成しません、中の確信している男性、-、-、中央、サーバものまね攻撃が可能です[EAPMITM]。 また、EAPが安全なトンネルで保護されないプロトコルに使用されるとき、これらの脆弱性は起こります。 EAPが司令官であるので
Kaufman Standards Track [Page 89] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[89ページ]RFC4306IKEv2 December 2005
purpose authentication protocol, which is often used to provide single-signon facilities, a deployed IPsec solution that relies on an EAP authentication method that does not generate a shared key (also known as a non-key-generating EAP method) can become compromised due to the deployment of an entirely unrelated application that also happens to use the same non-key-generating EAP method, but in an unprotected fashion. Note that this vulnerability is not limited to just EAP, but can occur in other scenarios where an authentication infrastructure is reused. For example, if the EAP mechanism used by IKEv2 utilizes a token authenticator, a man-in-the-middle attacker could impersonate the web server, intercept the token authentication exchange, and use it to initiate an IKEv2 connection. For this reason, use of non-key-generating EAP methods SHOULD be avoided where possible. Where they are used, it is extremely important that all usages of these EAP methods SHOULD utilize a protected tunnel, where the initiator validates the responder's certificate before initiating the EAP exchange. Implementers SHOULD describe the vulnerabilities of using non-key-generating EAP methods in the documentation of their implementations so that the administrators deploying IPsec solutions are aware of these dangers.
目的認証プロトコル、共有されたキー(また、キーを生成しないEAPメソッドとして、知られている)を生成しないEAP認証方法を当てにする配布しているIPsecソリューションは、また、たまたま同じであるキーを生成しないEAPメソッドのを使用する完全に関係ないアプリケーションの展開のため感染されるようになりますが、保護のないファッションでなることができます。(それは、単一のsignon施設を提供するのにしばしば使用されます)。 この脆弱性がまさしくEAPに制限されませんが、認証インフラストラクチャが再利用される他のシナリオに起こることができることに注意してください。 例えば、IKEv2によって使用されたEAPメカニズムがトークン固有識別文字を利用するなら、中央の男性攻撃者は、ウェブサーバーをまねて、トークン認証交換を妨害して、IKEv2接続を開始するのにそれを使用するかもしれません。 これは推論して、キーを生成しないEAPの使用はメソッドSHOULDです。可能であるところで避けられます。 それらが使用されているところでは、これらのEAPメソッドSHOULDのすべての使用法が保護されたトンネルを利用するのは、非常に重要です。(そこでは、EAP交換を起こす前に、創始者が応答者の証明書を有効にします)。 Implementers SHOULDがそれらの実装のドキュメンテーションのキーを生成しないEAPメソッドを使用する脆弱性について説明するので、IPsecにソリューションを配布する管理者はこれらの危険を意識しています。
An implementation using EAP MUST also use a public-key-based authentication of the server to the client before the EAP exchange begins, even if the EAP method offers mutual authentication. This avoids having additional IKEv2 protocol variations and protects the EAP data from active attackers.
また、EAP交換が始まる前にEAP MUSTを使用する実装はサーバの公開鍵ベースの認証をクライアントに使用します、EAPメソッドが互いの認証を提供しても。 これは、追加IKEv2プロトコル変化を持っているのを避けて、活発な攻撃者からEAPデータを保護します。
If the messages of IKEv2 are long enough that IP-level fragmentation is necessary, it is possible that attackers could prevent the exchange from completing by exhausting the reassembly buffers. The chances of this can be minimized by using the Hash and URL encodings instead of sending certificates (see section 3.6). Additional mitigations are discussed in [KPS03].
IKEv2のメッセージがIP-レベル断片化が必要であるほど長いなら、攻撃者が再アセンブリバッファを消耗させることによって完成からの交換を防ぐことができるだろうというのは、可能です。 証明書を送ることの代わりにHashとURL encodingsを使用することによって、この機会を最小にすることができます(セクション3.6を見てください)。 [KPS03]で追加緩和について議論します。
6. IANA Considerations
6. IANA問題
This document defines a number of new field types and values where future assignments will be managed by the IANA.
このドキュメントは将来の課題がIANAによって管理される多くの新しいフィールド・タイプと値を定義します。
The following registries have been created by the IANA:
以下の登録はIANAによって作成されました:
IKEv2 Exchange Types (section 3.1)
IKEv2 Payload Types (section 3.2)
IKEv2 Transform Types (section 3.3.2)
IKEv2 Transform Attribute Types (section 3.3.2)
IKEv2 Encryption Transform IDs (section 3.3.2)
IKEv2 Pseudo-random Function Transform IDs (section 3.3.2)
IKEv2 Integrity Algorithm Transform IDs (section 3.3.2)
IKEv2交換タイプ(セクション3.1)IKEv2有効搭載量はIKEv2変換タイプ(セクション3.3.2)のためにIKEv2変換属性タイプ(セクション3.3.2)IKEv2暗号化変換ID(セクション3.3.2)IKEv2擬似ランダム機能変換ID(セクション3.3.2)IKEv2保全アルゴリズム変換IDをタイプします(セクション3.2)。(セクション3.3.2)
Kaufman Standards Track [Page 90] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[90ページ]RFC4306IKEv2 December 2005
IKEv2 Diffie-Hellman Transform IDs (section 3.3.2)
IKEv2 Identification Payload ID Types (section 3.5)
IKEv2 Certificate Encodings (section 3.6)
IKEv2 Authentication Method (section 3.8)
IKEv2 Notify Message Types (section 3.10.1)
IKEv2 Notification IPCOMP Transform IDs (section 3.10.1)
IKEv2 Security Protocol Identifiers (section 3.3.1)
IKEv2 Traffic Selector Types (section 3.13.1)
IKEv2 Configuration Payload CFG Types (section 3.15)
IKEv2 Configuration Payload Attribute Types (section 3.15.1)
タイプする(セクション3.10.1)IKEv2認証方法(セクション3.8)IKEv2がIPCOMP変換ID(セクション3.10.1)IKEv2セキュリティプロトコル識別子(セクション3.3.1)IKEv2トラフィックセレクタがIKEv2構成有効搭載量CFGをタイプするという(セクション3.13.1)IKEv2通知にメッセージに通知するIKEv2ディフィー-ヘルマン変換ID(セクション3.3.2)IKEv2識別有効搭載量IDタイプ(セクション3.5)IKEv2証明書Encodings(セクション3.6)がIKEv2構成有効搭載量属性タイプをタイプします(セクション3.15)。(セクション3.15.1)
Note: When creating a new Transform Type, a new registry for it must be created.
以下に注意してください。 新しいTransform Typeを作成するとき、それのための新しい登録を作成しなければなりません。
Changes and additions to any of those registries are by expert review.
それらの登録のどれかへの変化と追加が専門のレビューであります。
7. Acknowledgements
7. 承認
This document is a collaborative effort of the entire IPsec WG. If there were no limit to the number of authors that could appear on an RFC, the following, in alphabetical order, would have been listed: Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer Reingold, and Michael Richardson. Many other people contributed to the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, each of which has its own list of authors. Hugh Daniel suggested the feature of having the initiator, in message 3, specify a name for the responder, and gave the feature the cute name "You Tarzan, Me Jane". David Faucher and Valery Smyzlov helped refine the design of the traffic selector negotiation.
このドキュメントは全体のIPsec WGの共同努力です。 RFCに現れることができた作者の数への限界が全くないなら、以下はアルファベット順に記載されるでしょうに: ビル・アイエロ、ステファーヌBeaulieu、スティーブBellovin、サラBitan(マットBlaze)はカネッティ、ダーレンDukes、ダン・ハーキン、ポール・ホフマン、ジョンIoannidis、チャーリー・カウフマン、スティーブ・ケント、Angelos Keromytis、Tero Kivinen、ユーゴーKrawczyk、アンドリューKrywaniuk、Radiaパールマン、オメル・レインゴールド、およびマイケル・リチャードソンを車で送りました。 多くの他の人々がデザインに貢献しました。 それはIKEv1、ISAKMP、およびIPsec DOIの発展です。それのそれぞれには、それ自身の作者のリストがあります。 ヒュー・ダニエルが、創始者がメッセージ3にいる特徴が応答者に名前を指定して、かわいい名前を特徴に与えたと示唆した、「このターザン、私、ジェーン、」 デヴィッド・ファウチャーとヴァレリSmyzlovは、トラフィックセレクタ交渉のデザインを洗練するのを助けました。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[ADDGROUP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[ADDGROUP] Kivinen、T.、およびM.Kojo、「より多くのModular Exponential(MODP)ディフィー-ヘルマンはインターネット・キー・エクスチェンジ(IKE)のために分類します」、RFC3526、2003年5月。
[ADDRIPV6] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[ADDRIPV6]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[Bra97] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bra97]ブラドナー、S.、「RFCsにおける使用がRequirement Levelsを示す主要なワーズ」、BCP14、RFC2119、3月1997日
Kaufman Standards Track [Page 91] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[91ページ]RFC4306IKEv2 December 2005
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[EAP]Aboba、B.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[ESPCBC] ペレイラとR.とR.アダムス、「超能力CBC-モード暗号アルゴリズム」、RFC2451、1998年11月。
[Hutt05] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
3948, January 2005.
[Hutt05]HuttunenとA.とSwanderとB.とボルペとV.とDiBurro、L.とM.Stenberg、「IPsec超能力パケットのUDPカプセル化」RFC3948(2005年1月)。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3168] Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知のIPへの追加(電子証券取引ネットワーク)」、RFC3168(2001年9月)。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3280] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
8.2. Informative References
8.2. 有益な参照
[DES] ANSI X3.106, "American National Standard for Information
Systems-Data Link Encryption", American National Standards
Institute, 1983.
[デス]ANSI X3.106、「情報システムデータ・リンク暗号化のための米国標準規格」、American National Standards Institut、1983。
[DH] Diffie, W., and Hellman M., "New Directions in
Cryptography", IEEE Transactions on Information Theory, V.
IT-22, n. 6, June 1977.
情報Theory、V.IT-22、nの[DH]ディフィー、W.とヘルマンM.、「暗号に関する新傾向」IEEE Transactions。 6 1977年6月。
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[DHCP] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[DSS] NIST, "Digital Signature Standard", FIPS 186, National
Institute of Standards and Technology, U.S. Department of
Commerce, May, 1994.
[DSS]NIST、「デジタル署名基準」、FIPS186、米国商務省標準技術局、米国商務省、1994年5月。
[EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle
in Tunneled Authentication Protocols",
http://eprint.iacr.org/2002/163, November 2002.
2002年11月の[EAPMITM]AsokanとN.とNierni、V.とニーベルグ、K.、「トンネルを堀られた認証プロトコルの中央の男性」 http://eprint.iacr.org/2002/163 。
Kaufman Standards Track [Page 92] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[92ページ]RFC4306IKEv2 December 2005
[HC98] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[HC98]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[IDEA] Lai, X., "On the Design and Security of Block Ciphers,"
ETH Series in Information Processing, v. 1, Konstanz:
Hartung-Gorre Verlag, 1992.
[IDEA]レイ、情報Processing、vの「ブロック暗号のデザインとセキュリティ」のX.ETH Series。 1、コンスタンツ: ハルトゥング-Gorre Verlag、1992。
[IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173,
September 2001.
[IPCOMP]Shacham、A.、Monsour、B.、ペレイラ、R.、およびM.トーマス、「IP有効搭載量圧縮プロトコル(IPComp)」、RFC3173 2001年9月。
[KPS03] Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS
protection for UDP-based protocols", ACM Conference on
Computer and Communications Security, October 2003.
コンピュータとCommunications Security(2003年10月)の上の[KPS03]コーフマンとC.とパールマン、R.とゾンマーフェルト、B.、「UDPベースのプロトコルのためのDoS保護」ACMコンファレンス。
[KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[KBC96] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[LDAP] Wahl, M., Howes, T., and S Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[LDAP]ウォール、M.、ハウズ、T.、およびS Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[MD5] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[MSST98] Maughan、D.、Schertler、M.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べます」、RFC2408、1998年11月。
[Orm96] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[Orm96] Orman、H.、「オークリーの主要な決断プロトコル」、RFC2412、1998年11月。
[PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998.
[PFKEY] マクドナルドとD.とメス、C.とB.Phan、「pfの_の主要なKey Management API、バージョン2インチ、RFC2367、1998年7月。」
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[PKCS1] イェンソン、J.、およびB.Kaliski、「公開鍵暗号化標準(PKCS)#1:」 RSA暗号仕様バージョン2.1インチ、RFC3447、2月2003日
[PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key
exchange Standard", WET-ICE Security Conference, MIT,2001,
http://sec.femto.org/wetice-2001/papers/radia-paper.pdf.
[PK01]パールマン、R.とコーフマン、C.、「IPsecの主要な交換Standardの分析」WET-ICE Securityコンファレンス、MIT、2001、 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf 。
[Pip98] Piper, D., "The Internet IP Security Domain Of
Interpretation for ISAKMP", RFC 2407, November 1998.
[Pip98]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
Kaufman Standards Track [Page 93] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[93ページ]RFC4306IKEv2 December 2005
[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[半径]Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RFC4086]イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC1958] 1996年6月の大工、B.、「インターネットの建築プリンシプルズ」RFC1958。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2474] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC2475] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「差別化されたサービスのためのアーキテクチャ」RFC2475、1998年12月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P.、およびW.シンプソン、「Photuris:」 「セッションKey Managementプロトコル」、RFC2522、1999年3月。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February
2000.
[RFC2775] 大工、B.、「インターネット透明」、RFC2775、2000年2月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC2983]黒(D.)が「サービスとトンネルを差別化した」、RFC2983、10月2000日
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, December 2002.
[RFC3439]ブッシュと、R. and D.マイヤーと、「何らかのインターネットの建築ガイドラインと哲学」、RFC3439、12月2002日
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] AbobaとB.とW.ディクソン、「IPsec-ネットワーク・アドレス翻訳(NAT)互換性要件」、RFC3715、2004年3月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM, v. 21, n. 2,
February 1978.
ACM(v)の[RSA]RivestとR.とシャミル、A.とAdleman、L.、「デジタル署名と公開鍵暗号系を得るためのメソッド」Communications。 21、n。 2 1978年2月。
Kaufman Standards Track [Page 94] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[94ページ]RFC4306IKEv2 December 2005
[SHA] NIST, "Secure Hash Standard", FIPS 180-1, National
Institute of Standards and Technology, U.S. Department of
Commerce, May 1994.
[SHA]NIST、「安全なハッシュ規格」、FIPS180-1、米国商務省標準技術局、米国商務省は1994がそうするかもしれません。
[SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and its Use in the IKE
Protocols", in Advances in Cryptography - CRYPTO 2003
Proceedings, LNCS 2729, Springer, 2003. Available at:
http://www.informatik.uni-trier.de/~ley/db/conf/
crypto/crypto2003.html.
[σ]Krawczyk、H.、「σ:」 CRYPTO2003Proceedings、LNCS2729、Springer、CryptographyのAdvancesの「Authenticatedディフィー-ヘルマンとIKEプロトコルのそのUseへの'SIGnとMAc'Approach」--2003。 利用可能: http://www.informatik.uni-trier.de/~ley/db/conf/ 暗号/crypto2003.html。
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", from IEEE Proceedings of the 1996
Symposium on Network and Distributed Systems Security.
[SKEME]Krawczyk、H.、「SKEME:」 ネットワークと分散システムセキュリティにおける1996年のシンポジウムのIEEE議事からの「インターネットへの多能な安全な主要な交換メカニズム。」
[X.501] ITU-T Recommendation X.501: Information Technology - Open
Systems Interconnection - The Directory: Models, 1993.
[X.501]ITU-T推薦X.501: 情報技術--オープン・システム・インターコネクション--ディレクトリ: モデル、1993。
[X.509] ITU-T Recommendation X.509 (1997 E): Information
Technology - Open Systems Interconnection - The Directory:
Authentication Framework, June 1997.
[X.509]ITU-T推薦X.509(1997E): 情報技術--オープン・システム・インターコネクション--ディレクトリ: 1997年6月の認証フレームワーク。
Kaufman Standards Track [Page 95] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[95ページ]RFC4306IKEv2 December 2005
Appendix A: Summary of changes from IKEv1
付録A: IKEv1からの変化の概要
The goals of this revision to IKE are:
IKEへのこの改正の目標は以下の通りです。
1) To define the entire IKE protocol in a single document, replacing RFCs 2407, 2408, and 2409 and incorporating subsequent changes to support NAT Traversal, Extensible Authentication, and Remote Address acquisition;
1) 全体のIKEを定義するために、ただ一つのドキュメントで議定書を作ってください、RFCs2407、2408、および2409を取り替えて、NATがTraversalと、Extensible Authenticationと、Remote Address獲得であるとサポートするためにその後の変化を取り入れて。
2) To simplify IKE by replacing the eight different initial exchanges with a single four-message exchange (with changes in authentication mechanisms affecting only a single AUTH payload rather than restructuring the entire exchange) see [PK01];
2) 8回の異なった初期の交換をただ一つの4交換処理(認証機構における変化がただ一つのAUTHペイロードだけに再構築するよりむしろ全体の交換に影響する)に取り替えることによってIKEを簡素化するには、[PK01]を見てください。
3) To remove the Domain of Interpretation (DOI), Situation (SIT), and Labeled Domain Identifier fields, and the Commit and Authentication only bits;
3) Interpretation(DOI)、Situation(SIT)、およびLabeled Domain Identifier分野のDomain、Commit、およびAuthenticationを唯一のビット取り外すために。
4) To decrease IKE's latency in the common case by making the initial exchange be 2 round trips (4 messages), and allowing the ability to piggyback setup of a CHILD_SA on that exchange;
4) 初期の交換をするのによるよくある例は、IKEの潜在に縮小するために、2つの周遊旅行(4つのメッセージ)であり、その交換のCHILD_SAのセットアップを背負う能力を許容しています。
5) To replace the cryptographic syntax for protecting the IKE messages themselves with one based closely on ESP to simplify implementation and security analysis;
5) 実装と証券分析を簡素化するために超能力に1があるメッセージ自体が密接に基礎づけたIKEを保護するための暗号の構文を置き換えるために。
6) To reduce the number of possible error states by making the protocol reliable (all messages are acknowledged) and sequenced. This allows shortening CREATE_CHILD_SA exchanges from 3 messages to 2;
6) プロトコルを信頼でき(すべてのメッセージが承認される)て配列されるようにすることによって可能な誤り州の数を減少させるために。 これで、3つのメッセージから2までのCREATE_CHILD_SA交換を短くします。
7) To increase robustness by allowing the responder to not do significant processing until it receives a message proving that the initiator can receive messages at its claimed IP address, and not commit any state to an exchange until the initiator can be cryptographically authenticated;
7) 創始者は、それを立証するメッセージを受け取るまで応答者が重要な処理をしないのを許容することによって丈夫さを増強するために、要求されたIPアドレスにメッセージを受け取って、暗号で創始者を認証できるまで少しの状態も交換に遂行できません。
8) To fix cryptographic weaknesses such as the problem with symmetries in hashes used for authentication documented by Tero Kivinen;
8) Tero Kivinenによって記録された認証に使用されるハッシュにおける左右対称に関する問題などの暗号の弱点を修理するために。
9) To specify Traffic Selectors in their own payloads type rather than overloading ID payloads, and making more flexible the Traffic Selectors that may be specified;
9) それら自身のでTraffic Selectorsを指定するために、ペイロードはIDペイロードを積みすぎて、指定されるかもしれないTraffic Selectorsをよりフレキシブルにするよりむしろタイプされます。
10) To specify required behavior under certain error conditions or when data that is not understood is received, to make it easier to make future revisions that do not break backward compatibility;
10) あるエラー条件かそれともいつ後方に壊れない今後の改正を互換性にするのをより簡単にするように理解されていないデータを受け取るかの下で指定するのは振舞いを必要としました。
Kaufman Standards Track [Page 96] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[96ページ]RFC4306IKEv2 December 2005
11) To simplify and clarify how shared state is maintained in the presence of network failures and Denial of Service attacks; and
11) 共有された状態がネットワーク失敗とサービス妨害があるときどう維持されるかを簡素化して、はっきりさせるのは攻撃されます。 そして
12) To maintain existing syntax and magic numbers to the extent possible to make it likely that implementations of IKEv1 can be enhanced to support IKEv2 with minimum effort.
12) 最小努力でIKEv2をサポートするためにIKEv1の実装を高めることができるのをありそうにするように可能な範囲内で既存の構文とマジックナンバーを維持するために。
Appendix B: Diffie-Hellman Groups
付録B: ディフィー-ヘルマングループ
There are two Diffie-Hellman groups defined here for use in IKE. These groups were generated by Richard Schroeppel at the University of Arizona. Properties of these primes are described in [Orm96].
IKEにおける使用のためにここで定義された2つのディフィー-ヘルマングループがあります。 これらのグループはアリゾナ大学のリチャードSchroeppelによって作られました。 これらの盛りの特性は[Orm96]で説明されます。
The strength supplied by group one may not be sufficient for the mandatory-to-implement encryption algorithm and is here for historic reasons.
グループ1によって供給された強さは、実装するために義務的な暗号化アルゴリズムに十分でないかもしれなく、歴史的な理由でここにあります。
Additional Diffie-Hellman groups have been defined in [ADDGROUP].
追加ディフィー-ヘルマングループは[ADDGROUP]で定義されました。
B.1. Group 1 - 768 Bit MODP
B.1。 グループの1--768ビットのMODP
This group is assigned id 1 (one).
イド1(1)はこのグループに配属されます。
The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } Its
hexadecimal value is:
第1は以下の通りです。 2^768--16進が評価する2^64 2^704--1+*[2^638パイ]+149686は以下の通りです。
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
A63A3620 FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024 08Eの8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
The generator is 2.
ジェネレータは2です。
B.2. Group 2 - 1024 Bit MODP
B.2。 グループの1024年の2--ビットのMODP
This group is assigned id 2 (two).
イド2(2)はこのグループに配属されます。
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its hexadecimal value is:
第1は2^1024です--2^960--1+2^64*。+ [2^894パイ]129093。 16進値は以下の通りです。
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
49286651 ECE65381 FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024 08Eの8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651ECE65381 FFFFFFFF FFFFFFFF
The generator is 2.
ジェネレータは2です。
Kaufman Standards Track [Page 97] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[97ページ]RFC4306IKEv2 December 2005
Editor's Address
エディタのアドレス
Charlie Kaufman Microsoft Corporation 1 Microsoft Way Redmond, WA 98052
チャーリー・カウフマンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: 1-425-707-3335 EMail: charliek@microsoft.com
以下に電話をしてください。 1-425-707-3335 メールしてください: charliek@microsoft.com
Kaufman Standards Track [Page 98] RFC 4306 IKEv2 December 2005
コーフマン標準化過程[98ページ]RFC4306IKEv2 December 2005
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Kaufman Standards Track [Page 99]
コーフマン標準化過程[99ページ]
一覧
スポンサーリンク
