RFC2408 日本語訳
2408 Internet Security Association and Key Management Protocol(ISAKMP). D. Maughan, M. Schertler, M. Schneider, J. Turner. November 1998. (Format: TXT=209175 bytes) (Obsoleted by RFC4306) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Maughan
Request for Comments: 2408 National Security Agency
Category: Standards Track M. Schertler
Securify, Inc.
M. Schneider
National Security Agency
J. Turner
RABA Technologies, Inc.
November 1998
Maughanがコメントのために要求するワーキンググループD.をネットワークでつないでください: 2408年の国家安全保障局カテゴリ: 標準化過程M.Schertler Securify Inc.M.シュナイダー国家安全保障局J.ターナーラバ川技術Inc.1998年11月
Internet Security Association and Key Management Protocol (ISAKMP)
インターネットセキュリティ協会とKey Managementプロトコル(ISAKMP)
Status of this Memo
この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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment.
このメモはSecurity Associations(SA)と暗号化キーをインターネット環境に設立するのに必要なセキュリティ概念を利用するプロトコルについて説明します。 Security Associationsと彼らの属性を交渉して、確立して、変更して、削除するSecurity Associationプロトコルが発展インターネットに必要です。そこに、各セキュリティー対策のための多数のセキュリティー対策といくつかのオプションがあるでしょう。 かぎ管理プロトコルは、その要件で全体のインターネットコミュニティのための公開鍵世代とそれらの私設のネットワークのための秘密鍵要件を扱うために強健でなければなりません。 インターネットSecurity AssociationとKey Managementプロトコル(ISAKMP)は交信している同輩を認証するための手順、Security Associationsの作成と管理、キー生成のテクニック、および脅威緩和(例えば、サービスと反射攻撃の否定)を定義します。 これらのすべてが、インターネット環境で安全なコミュニケーションを確立して、維持すること(IP Security Serviceかいかなる他のセキュリティプロトコルでも)に必要です。
Maughan, et. al. Standards Track [Page 1] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[1ページ]。
Table of Contents
目次
1 Introduction 4
1.1 Requirements Terminology . . . . . . . . . . . . . . . . . 5
1.2 The Need for Negotiation . . . . . . . . . . . . . . . . . 5
1.3 What can be Negotiated? . . . . . . . . . . . . . . . . . 6
1.4 Security Associations and Management . . . . . . . . . . . 7
1.4.1 Security Associations and Registration . . . . . . . . 7
1.4.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 8
1.5 Authentication . . . . . . . . . . . . . . . . . . . . . . 8
1.5.1 Certificate Authorities . . . . . . . . . . . . . . . 9
1.5.2 Entity Naming . . . . . . . . . . . . . . . . . . . . 9
1.5.3 ISAKMP Requirements . . . . . . . . . . . . . . . . . 10
1.6 Public Key Cryptography . . . . . . . . . . . . . . . . . . 10
1.6.1 Key Exchange Properties . . . . . . . . . . . . . . . 11
1.6.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 12
1.7 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . 12
1.7.1 Anti-Clogging (Denial of Service) . . . . . . . . . . 12
1.7.2 Connection Hijacking . . . . . . . . . . . . . . . . . 13
1.7.3 Man-in-the-Middle Attacks . . . . . . . . . . . . . . 13
1.8 Multicast Communications . . . . . . . . . . . . . . . . . 13
2 Terminology and Concepts 14
2.1 ISAKMP Terminology . . . . . . . . . . . . . . . . . . . . 14
2.2 ISAKMP Placement . . . . . . . . . . . . . . . . . . . . . 16
2.3 Negotiation Phases . . . . . . . . . . . . . . . . . . . . 16
2.4 Identifying Security Associations . . . . . . . . . . . . . 17
2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.1 Transport Protocol . . . . . . . . . . . . . . . . . . 20
2.5.2 RESERVED Fields . . . . . . . . . . . . . . . . . . . 20
2.5.3 Anti-Clogging Token ("Cookie") Creation . . . . . . . 20
3 ISAKMP Payloads 21
3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 21
3.2 Generic Payload Header . . . . . . . . . . . . . . . . . . 25
3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Security Association Payload . . . . . . . . . . . . . . . 27
3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . 28
3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . 29
3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . 31
3.8 Identification Payload . . . . . . . . . . . . . . . . . . 32
3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . 33
3.10 Certificate Request Payload . . . . . . . . . . . . . . . 34
3.11 Hash Payload . . . . . . . . . . . . . . . . . . . . . . 36
3.12 Signature Payload . . . . . . . . . . . . . . . . . . . . 37
3.13 Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 37
3.14 Notification Payload . . . . . . . . . . . . . . . . . . 38
3.14.1 Notify Message Types . . . . . . . . . . . . . . . . 40
3.15 Delete Payload . . . . . . . . . . . . . . . . . . . . . 41
3.16 Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 43
1つの序論4 1.1Requirements Terminology. . . . . . . . . . . . . . . . . 5 1.2、Negotiation. . . . . . . . . . . . . . . . . 5 1.3WhatがNegotiatedであるかもしれないかので、そうしなければなりません。 . . . . . . . . . . . . . . . . . 6 1.4 セキュリティ協会、管理. . . . . . . . . . . 7 1.4.1のセキュリティ協会、および登録. . . . . . . . 7 1.4.2のISAKMP要件. . . . . . . . . . . . . . . . . 8 1.5認証. . . . . . . . . . . . . . . . . . . . . . 8 1; 5.1は当局. . . . . . . . . . . . . . . 9 1.5.2実体命名. . . . . . . . . . . . . . . . . . . . 9 1.5.3のISAKMP要件. . . . . . . . . . . . . . . . . 10 1.6公開鍵暗号. . . . . . . . . . . . . . . . . . 10 1を証明します; 6.1 中央の主要な交換の特性. . . . . . . . . . . . . . . 11 1.6の.2のISAKMP要件. . . . . . . . . . . . . . . . . 12 1.7ISAKMP保護. . . . . . . . . . . . . . . . . . . . . 12 1.7.1反目詰まり(サービス妨害). . . . . . . . . . 12 1.7.2接続ハイジャック. . . . . . . . . . . . . . . . . 13 1.7.3男性は.131.8のマルチキャストコミュニケーション. . . . . . . . . . . . . . . . . 13 2用語と概念14 2.1ISAKMP用語を攻撃します… . . . . . . . . . . . . . . 14 2.2 セキュリティ協会. . . . . . . . . . . . . 17 2.5その他. . . . . . . . . . . . . . . . . . . . . . . 20 2.5の.1トランスポート・プロトコル. . . . . . . . . . . . . . . . . . 20 2.5.2を特定するISAKMPプレースメント. . . . . . . . . . . . . . . . . . . . . 16 2.3交渉フェーズ. . . . . . . . . . . . . . . . . . . . 16 2.4が分野. . . . . . . . . . . . . . . . . . . 20 2.5.3反目詰まりトークン(「クッキー」)作成. . . . . . . 20 3ISAKMP有効搭載量21 3.1ISAKMPヘッダー形式を予約しました…; .213.2 ヘッダー.253.3のジェネリック有効搭載量データ属性. . . . . . . . . . . . . . . . . . . . . . 25 3.4セキュリティ協会有効搭載量. . . . . . . . . . . . . . . 27 3.5提案有効搭載量. . . . . . . . . . . . . . . . . . . . . 28 3.6は有効搭載量. . . . . . . . . . . . . . . . . . . . . 29 3.7の主要な交換有効搭載量. . . . . . . . . . . . . . . . . . . 31 3.8識別有効搭載量. . . . . . . . . . . . . . . . . . 32 3.9Certificatを変えます。e有効搭載量. . . . . . . . . . . . . . . . . . . . 33 3.10は要求有効搭載量. . . . . . . . . . . . . . . 34 3.11ハッシュ有効搭載量. . . . . . . . . . . . . . . . . . . . . . 36 3.12署名有効搭載量. . . . . . . . . . . . . . . . . . . . 37 3.13の一回だけの有効搭載量を証明します…; .37 3.14 .1が有効搭載量. . . . . . . . . . . . . . . . . . . . . 41 3.16ベンダーID有効搭載量. . . . . . . . . . . . . . . . . . . . 43を削除するようにメッセージタイプ. . . . . . . . . . . . . . . . 40 3.15に通知する通知有効搭載量. . . . . . . . . . . . . . . . . . 38 3.14
Maughan, et. al. Standards Track [Page 2] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[2ページ]。
4 ISAKMP Exchanges 44
4.1 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . 45
4.1.1 Notation . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Security Association Establishment . . . . . . . . . . . . 46
4.2.1 Security Association Establishment Examples . . . . . 48
4.3 Security Association Modification . . . . . . . . . . . . . 50
4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . 51
4.5 Identity Protection Exchange . . . . . . . . . . . . . . . 52
4.6 Authentication Only Exchange . . . . . . . . . . . . . . . 54
4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . 55
4.8 Informational Exchange . . . . . . . . . . . . . . . . . . 57
5 ISAKMP Payload Processing 58
5.1 General Message Processing . . . . . . . . . . . . . . . . 58
5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . 59
5.3 Generic Payload Header Processing . . . . . . . . . . . . . 61
5.4 Security Association Payload Processing . . . . . . . . . . 62
5.5 Proposal Payload Processing . . . . . . . . . . . . . . . . 63
5.6 Transform Payload Processing . . . . . . . . . . . . . . . 64
5.7 Key Exchange Payload Processing . . . . . . . . . . . . . . 65
5.8 Identification Payload Processing . . . . . . . . . . . . . 66
5.9 Certificate Payload Processing . . . . . . . . . . . . . . 66
5.10 Certificate Request Payload Processing . . . . . . . . . 67
5.11 Hash Payload Processing . . . . . . . . . . . . . . . . . 69
5.12 Signature Payload Processing . . . . . . . . . . . . . . 69
5.13 Nonce Payload Processing . . . . . . . . . . . . . . . . 70
5.14 Notification Payload Processing . . . . . . . . . . . . . 71
5.15 Delete Payload Processing . . . . . . . . . . . . . . . . 73
6 Conclusions 75
A ISAKMP Security Association Attributes 77
A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . 77
A.2 Internet IP Security DOI Assigned Value . . . . . . . . . . 77
A.3 Supported Security Protocols . . . . . . . . . . . . . . . 77
A.4 ISAKMP Identification Type Values . . . . . . . . . . . . . 78
A.4.1 ID_IPV4_ADDR . . . . . . . . . . . . . . . . . . . . . 78
A.4.2 ID_IPV4_ADDR_SUBNET . . . . . . . . . . . . . . . . . . 78
A.4.3 ID_IPV6_ADDR . . . . . . . . . . . . . . . . . . . . . 78
A.4.4 ID_IPV6_ADDR_SUBNET . . . . . . . . . . . . . . . . . 78
B Defining a new Domain of Interpretation 79
B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . 80
B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . 80
B.4 Syntax for Specifying Security Services . . . . . . . . . . 80
B.5 Payload Specification . . . . . . . . . . . . . . . . . . . 80
B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . 80
Security Considerations 81
IANA Considerations 81
Domain of Interpretation 81
Supported Security Protocols 82
4回のISAKMP交換44 4.1のISAKMP交換タイプ.454.1.1記法. . . . . . . . . . . . . . . . . . . . . . . 46 4.2セキュリティ協会特権階級、.464.2、.1のセキュリティ協会設立の例; .484.3 セキュリティ協会変更. . . . . . . . . . . . . 50 4.4はアイデンティティ保護交換. . . . . . . . . . . . . . . 52 4.6認証が交換するだけである交換. . . . . . . . . . . . . . . . . . . . . . . 51 4.5を基礎づけます; .544.7 攻撃的な交換. . . . . . . . . . . . . . . . . . . . 55 4.8の情報の交換. . . . . . . . . . . . . . . . . . 57 5ISAKMP有効搭載量処理58 5.1一般教書処理. . . . . . . . . . . . . . . . 58 5.2ISAKMPヘッダー処理. . . . . . . . . . . . . . . . . 59 5.3ジェネリック有効搭載量ヘッダー処理. . . . . . . . . . . . . 61 5.4セキュリティ協会有効搭載量処理. . . . . . . . . . 62 5.5提案有効搭載量処理…. . . . . . . . . . . 63 5.6 .69 5.13の一回だけの有効搭載量処理を処理する有効搭載量処理. . . . . . . . . . . . . . . 64 5.7主要な交換有効搭載量処理. . . . . . . . . . . . . . 65 5.8識別有効搭載量処理. . . . . . . . . . . . . 66 5.9証明書有効搭載量処理. . . . . . . . . . . . . . 66 5.10証明書要求有効搭載量処理. . . . . . . . . 67 5.11ハッシュ有効搭載量処理. . . . . . . . . . . . . . . . . 69 5.12署名有効搭載量を変えてください…; .70 5.14 通知有効搭載量処理. . . . . . . . . . . . . 71 5.15は.736の結論75を処理する属性77A.1バックグラウンド/原理. . . . . . . . . . . . . . . . . . . 77A.2インターネットIPセキュリティDOIがセキュリティプロトコル. . . . . . . . . . . . . . . 77A.4 ISAKMP識別であるとサポートされた値. . . . . . . . . . 77のA.3を配属したISAKMPセキュリティ協会が.78A.4.1ID_IPV4_ADDRを評価するのをタイプする有効搭載量を削除します…. . . . . . . . . . . . . Interpretation79B.1 Situation. . . . . . . . . . . . . . . . . . . . . . . . . 79B.2 Security Policiesの78A.4.2 ID_IPV4_ADDR_SUBNET. . . . . . . . . . . . . . . . . . 78A.4.3 ID_IPV6_ADDR. . . . . . . . . . . . . . . . . . . . . 78A.4.4 ID_IPV6_ADDR_SUBNET. . . . . . . . . . . . . . . . . 78B Definingのa新しいDomain、.80、B; 3 Interpretation81Supported Securityプロトコル82のSpecifying Security Services. . . . . . . . . . 80B.5有効搭載量Specification. . . . . . . . . . . . . . . . . . . 80のB.6 Definingの新しいExchange Types. . . . . . . . . . . . . . . . 80Security Considerations81IANA Considerations81Domainにちなんで.80B.4 SyntaxとSchemesを命名すること。
Maughan, et. al. Standards Track [Page 3] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[3ページ]。
Acknowledgements 82 References 82 Authors' Addresses 85 Full Copyright Statement 86
承認82参照82作者のアドレス85の完全な著作権宣言文86
List of Figures
数字のリスト
1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . 16 2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 22 3 Generic Payload Header . . . . . . . . . . . . . . . . . . 25 4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 26 5 Security Association Payload . . . . . . . . . . . . . . . 27 6 Proposal Payload Format . . . . . . . . . . . . . . . . . . 28 7 Transform Payload Format . . . . . . . . . . . . . . . . . 30 8 Key Exchange Payload Format . . . . . . . . . . . . . . . . 31 9 Identification Payload Format . . . . . . . . . . . . . . . 32 10 Certificate Payload Format . . . . . . . . . . . . . . . . 33 11 Certificate Request Payload Format . . . . . . . . . . . . 34 12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . 36 13 Signature Payload Format . . . . . . . . . . . . . . . . . 37 14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . 38 15 Notification Payload Format . . . . . . . . . . . . . . . . 39 16 Delete Payload Format . . . . . . . . . . . . . . . . . . . 42 17 Vendor ID Payload Format . . . . . . . . . . . . . . . . . 44
1 ヘッダー.254のISAKMP関係. . . . . . . . . . . . . . . . . . . 16 2ISAKMPヘッダー形式. . . . . . . . . . . . . . . . . . . 22 3ジェネリック有効搭載量データ属性. . . . . . . . . . . . . . . . . . . . . . 26 5セキュリティ協会有効搭載量. . . . . . . . . . . . . . . 27 6提案有効搭載量形式. . . . . . . . . . . . . . . . . . 28 7は有効搭載量形式. . . . . . . . . . . . . . . . . 30 8キー交換有効搭載量形式を変えます…; 31 9 識別有効搭載量形式. . . . . . . . . . . . . . . 32 10証明書有効搭載量形式. . . . . . . . . . . . . . . . 33 11証明書要求有効搭載量形式. . . . . . . . . . . . 34 12ハッシュ有効搭載量形式. . . . . . . . . . . . . . . . . . . . 36 13署名有効搭載量形式. . . . . . . . . . . . . . . . . 37 14一回だけの有効搭載量形式. . . . . . . . . . . . . . . . . . . 38 15通知有効搭載量形式. . . . . . . . . . . . . . . . 39 16は有効搭載量書式を削除します… . . . . . . 42 17ベンダーID有効搭載量形式. . . . . . . . . . . . . . . . . 44
1 Introduction
1つの序論
This document describes an Internet Security Association and Key Management Protocol (ISAKMP). ISAKMP combines the security concepts of authentication, key management, and security associations to establish the required security for government, commercial, and private communications on the Internet.
このドキュメントはインターネットSecurity AssociationとKey Managementプロトコル(ISAKMP)について説明します。 ISAKMPは認証、かぎ管理、および政府のために必要なセキュリティを確立するセキュリティ協会のセキュリティ概念を結合します、インターネットに関する商業的、そして、個人的なコミュニケーション。
The Internet Security Association and Key Management Protocol (ISAKMP) defines procedures and packet formats to establish, negotiate, modify and delete Security Associations (SA). SAs contain all the information required for execution of various network security services, such as the IP layer services (such as header authentication and payload encapsulation), transport or application layer services, or self-protection of negotiation traffic. ISAKMP defines payloads for exchanging key generation and authentication data. These formats provide a consistent framework for transferring key and authentication data which is independent of the key generation technique, encryption algorithm and authentication mechanism.
インターネットSecurity AssociationとKey Managementプロトコル(ISAKMP)は、Security Associations(SA)を設立して、交渉して、変更して、削除するために手順とパケット・フォーマットを定義します。 SAsは様々なネットワークセキュリティー・サービスの実行に必要であるすべての情報を含んでいます、交渉トラフィックのIP層のサービス(ヘッダー認証やペイロードカプセル化などの)、輸送、応用層サービス、または自己保護などのように。 ISAKMPは、キー生成と認証データを交換するためにペイロードを定義します。 これらの形式はキー生成のテクニック、暗号化アルゴリズム、および認証機構から独立しているキーと認証データを移すのに一貫したフレームワークを提供します。
Maughan, et. al. Standards Track [Page 4] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[4ページ]。
ISAKMP is distinct from key exchange protocols in order to cleanly separate the details of security association management (and key management) from the details of key exchange. There may be many different key exchange protocols, each with different security properties. However, a common framework is required for agreeing to the format of SA attributes, and for negotiating, modifying, and deleting SAs. ISAKMP serves as this common framework.
ISAKMPは、主要な交換の詳細とセキュリティ協会管理(そして、かぎ管理)の細部を清潔に切り離すために主要な交換プロトコルと異なっています。 それぞれ異なったセキュリティの特性がある多くの異なった主要な交換プロトコルがあるかもしれません。 しかしながら、一般的なフレームワークがSA属性の書式に同意して、交渉するのに必要です、SAsを変更して、削除して。 ISAKMPはこの一般的なフレームワークとして機能します。
Separating the functionality into three parts adds complexity to the security analysis of a complete ISAKMP implementation. However, the separation is critical for interoperability between systems with differing security requirements, and should also simplify the analysis of further evolution of a ISAKMP server.
3つの部分に機能性を切り離すと、複雑さは完全なISAKMP実装の証券分析に追加されます。 しかしながら、分離は、異なったセキュリティ要件でシステムの間の相互運用性に重要であり、また、ISAKMPサーバの一層の発展の分析を簡素化するべきです。
ISAKMP is intended to support the negotiation of SAs for security protocols at all layers of the network stack (e.g., IPSEC, TLS, TLSP, OSPF, etc.). By centralizing the management of the security associations, ISAKMP reduces the amount of duplicated functionality within each security protocol. ISAKMP can also reduce connection setup time, by negotiating a whole stack of services at once.
ISAKMPがネットワークスタック(例えば、IPSEC、TLS、TLSP、OSPFなど)のすべての層のセキュリティプロトコルのためにSAsの交渉をサポートすることを意図します。 セキュリティ協会の経営を集結することによって、ISAKMPはそれぞれのセキュリティプロトコルの中でコピーされた機能性の量を減少させます。 また、ISAKMPは、すぐに全体のサービスのスタックを交渉することによって、接続準備時間を短縮できます。
The remainder of section 1 establishes the motivation for security negotiation and outlines the major components of ISAKMP, i.e. Security Associations and Management, Authentication, Public Key Cryptography, and Miscellaneous items. Section 2 presents the terminology and concepts associated with ISAKMP. Section 3 describes the different ISAKMP payload formats. Section 4 describes how the payloads of ISAKMP are composed together as exchange types to establish security associations and perform key exchanges in an authenticated manner. Additionally, security association modification, deletion, and error notification are discussed. Section 5 describes the processing of each payload within the context of ISAKMP exchanges, including error handling and associated actions. The appendices provide the attribute values necessary for ISAKMP and requirement for defining a new Domain of Interpretation (DOI) within ISAKMP.
セクション1の残りは、セキュリティ交渉に関する動機を確立して、ISAKMP、すなわち、Security Associations、Management、Authentication、Public Key Cryptography、およびMiscellaneousの品目の主要コンポーネントについて概説します。セクション2はISAKMPに関連している用語と概念を提示します。 セクション3は異なったISAKMPペイロード形式について説明します。 セクション4はISAKMPのペイロードが認証された方法でセキュリティ協会を設立して、主要な交換を実行するために交換タイプとしてどう一緒に構成されるかを説明します。 さらに、セキュリティ協会変更、削除、およびエラー通知について議論します。 セクション5はエラー処理と関連動作を含むISAKMP交換の文脈の中のそれぞれのペイロードの処理について説明します。 付録はISAKMPの中でInterpretation(DOI)の新しいDomainを定義するためのISAKMPと要件に必要な属性値を提供します。
1.1 Requirements Terminology
1.1 要件用語
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC-2119].
キーワードが解釈しなければならない、本書では現れるとき、[RFC-2119]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
1.2 The Need for Negotiation
1.2 交渉の必要性
ISAKMP extends the assertion in [DOW92] that authentication and key exchanges must be combined for better security to include security association exchanges. The security services required for
ISAKMPは、セキュリティ協会交換を含むように、より良いセキュリティのために認証と主要な交換を結合しなければならないという[DOW92]での主張を広げています。 セキュリティー・サービスが必要です。
Maughan, et. al. Standards Track [Page 5] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[5ページ]。
communications depends on the individual network configurations and environments. Organizations are setting up Virtual Private Networks (VPN), also known as Intranets, that will require one set of security functions for communications within the VPN and possibly many different security functions for communications outside the VPN to support geographically separate organizational components, customers, suppliers, sub-contractors (with their own VPNs), government, and others. Departments within large organizations may require a number of security associations to separate and protect data (e.g. personnel data, company proprietary data, medical) on internal networks and other security associations to communicate within the same department. Nomadic users wanting to "phone home" represent another set of security requirements. These requirements must be tempered with bandwidth challenges. Smaller groups of people may meet their security requirements by setting up "Webs of Trust". ISAKMP exchanges provide these assorted networking communities the ability to present peers with the security functionality that the user supports in an authenticated and protected manner for agreement upon a common set of security attributes, i.e. an interoperable security association.
コミュニケーションは個々のネットワーク・コンフィギュレーションと環境に依存します。 VPNの外のコミュニケーションが地理的に別々の組織的なコンポーネント、顧客、供給者、下請契約者(それら自身のVPNsと)、政府、および他のものをサポートするように、組織はVPNとことによると多くの異なったセキュリティ機能の中でコミュニケーションのために1セットにセキュリティ機能を要求するまた、イントラネットとして知られているVirtual兵士のNetworks(VPN)をセットアップしています。 大きな組織の中の部は内部のネットワークに関するデータ(例えば、会社の独占データの、そして、医学の人員データ)を切り離して、保護する多くのセキュリティ協会と同じ部の中で交信する他のセキュリティ協会を必要とするかもしれません。 「家に電話をしたがっている」遊牧民的なユーザがもう1セットのセキュリティ要件を表します。 帯域幅挑戦でこれらの要件を緩和しなければなりません。 人々の、より小さいグループは、「信頼のウェブ」をセットアップすることによって、彼らのセキュリティ必要条件を満たすかもしれません。 ISAKMP交換はユーザが一般的なセキュリティー属性の協定のための認証されて保護された方法でサポートするセキュリティの機能性を同輩に与える能力をこれらのさまざまなネットワーク共同体に提供します、すなわち、共同利用できるセキュリティ協会。
1.3 What can be Negotiated?
1.3 Negotiatedは何であるかもしれませんか?
Security associations must support different encryption algorithms, authentication mechanisms, and key establishment algorithms for other security protocols, as well as IP Security. Security associations must also support host-oriented certificates for lower layer protocols and user- oriented certificates for higher level protocols. Algorithm and mechanism independence is required in applications such as e-mail, remote login, and file transfer, as well as in session oriented protocols, routing protocols, and link layer protocols. ISAKMP provides a common security association and key establishment protocol for this wide range of security protocols, applications, security requirements, and network environments.
セキュリティ協会は他のセキュリティプロトコルのために異なった暗号化アルゴリズム、認証機構、および主要な設立アルゴリズムをサポートしなければなりません、IP Securityと同様に。 また、セキュリティ協会は下層プロトコルとユーザのためのホスト指向の証明書により高い平らなプロトコルのための指向の証明書を支えなければなりません。 アルゴリズムとメカニズム独立がメールや、リモート・ログインや、ファイル転送などの応用、セッション指向のプロトコル、ルーティング・プロトコル、およびリンクレイヤプロトコルで必要です。 ISAKMPはこの広範囲のセキュリティプロトコル、アプリケーション、セキュリティ要件、およびネットワーク環境に共通の安全保障協会と主要な設立プロトコルを提供します。
ISAKMP is not bound to any specific cryptographic algorithm, key generation technique, or security mechanism. This flexibility is beneficial for a number of reasons. First, it supports the dynamic communications environment described above. Second, the independence from specific security mechanisms and algorithms provides a forward migration path to better mechanisms and algorithms. When improved security mechanisms are developed or new attacks against current encryption algorithms, authentication mechanisms and key exchanges are discovered, ISAKMP will allow the updating of the algorithms and mechanisms without having to develop a completely new KMP or patch the current one.
ISAKMPはどんな特定の暗号アルゴリズム、キー生成のテクニック、またはセキュリティメカニズムにも縛られません。 この柔軟性は様々な意味で有利です。 まず最初に、それは、ダイナミックなコミュニケーションが上で説明された環境であるとサポートします。 2番目に、特定のセキュリティー対策とアルゴリズムからの独立は、より良いメカニズムとアルゴリズムに前進の移行パスを供給します。改良されたセキュリティー対策が開発されているか、または現在の暗号化アルゴリズム、認証機構、および主要な交換に対する新しい攻撃が発見されるとき、ISAKMPはアルゴリズムとメカニズムの完全に新しいKMPかパッチを開発する必要はなくてアップデートに現在のものを許容するでしょう。
Maughan, et. al. Standards Track [Page 6] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[6ページ]。
ISAKMP has basic requirements for its authentication and key exchange components. These requirements guard against denial of service, replay / reflection, man-in-the-middle, and connection hijacking attacks. This is important because these are the types of attacks that are targeted against protocols. Complete Security Association (SA) support, which provides mechanism and algorithm independence, and protection from protocol threats are the strengths of ISAKMP.
ISAKMPには、認証と主要な交換コンポーネントのための基本的な要件があります。 これらの要件はサービスの否定、再生/反射、中央の人、および攻撃をハイジャックしている接続に用心します。 これらがプロトコルに対して狙う攻撃のタイプであるので、これは重要です。 プロトコルの脅威からの完全なSecurity Association(SA)サポートと保護はISAKMPの強さです。(サポートはメカニズムとアルゴリズム独立を提供します)。
1.4 Security Associations and Management
1.4 セキュリティ協会と管理
A Security Association (SA) is a relationship between two or more entities that describes how the entities will utilize security services to communicate securely. This relationship is represented by a set of information that can be considered a contract between the entities. The information must be agreed upon and shared between all the entities. Sometimes the information alone is referred to as an SA, but this is just a physical instantiation of the existing relationship. The existence of this relationship, represented by the information, is what provides the agreed upon security information needed by entities to securely interoperate. All entities must adhere to the SA for secure communications to be possible. When accessing SA attributes, entities use a pointer or identifier refered to as the Security Parameter Index (SPI). [SEC-ARCH] provides details on IP Security Associations (SA) and Security Parameter Index (SPI) definitions.
Security Association(SA)は2つ以上の実体の間の実体がしっかりと交信するのにどうセキュリティー・サービスを利用するかを説明する関係です。 この関係は実体の契約であると考えることができる1セットの情報によって表されます。 すべての実体の間で情報に同意されて、共有しなければなりません。 時々、情報だけがSAと呼ばれますが、これはただ既存の関係の物理的な具体化です。 情報によって表されたこの関係の存在はセキュリティ情報がしっかりと共同利用する実体で必要とした同意を提供することです。 すべての実体が、安全なコミュニケーションが可能であるようにSAを固く守らなければなりません。 SA属性にアクセスするとき、実体はSecurity Parameter Index(SPI)としてreferedされた指針か識別子を使用します。 [SEC-ARCH]はIP Security Associations(SA)とSecurity Parameter Index(SPI)定義に関する詳細を明らかにします。
1.4.1 Security Associations and Registration
1.4.1 セキュリティ協会と登録
The SA attributes required and recommended for the IP Security (AH, ESP) are defined in [SEC-ARCH]. The attributes specified for an IP Security SA include, but are not limited to, authentication mechanism, cryptographic algorithm, algorithm mode, key length, and Initialization Vector (IV). Other protocols that provide algorithm and mechanism independent security MUST define their requirements for SA attributes. The separation of ISAKMP from a specific SA definition is important to ensure ISAKMP can es tablish SAs for all possible security protocols and applications.
IP Security(AH、超能力)のために必要であり、推薦されたSA属性は[SEC-ARCH]で定義されます。 IP Security SAインクルードに指定しますが、属性が制限されない、認証機構、暗号アルゴリズム、アルゴリズムモード、キー長、および初期設定Vector(IV)。 アルゴリズムを提供する他のプロトコルとメカニズムの独立しているセキュリティはSA属性のためのそれらの要件を定義しなければなりません。 特定のSA定義からのISAKMPの分離は、ISAKMPはすべての可能なセキュリティプロトコルとアプリケーションのためのes tablish SAsをそうすることができるのを保証するために重要です。
NOTE: See [IPDOI] for a discussion of SA attributes that should be considered when defining a security protocol or application.
以下に注意してください。 セキュリティプロトコルかアプリケーションを定義するとき考えられるべきであるSA属性の議論に関して[IPDOI]を見てください。
In order to facilitate easy identification of specific attributes (e.g. a specific encryption algorithm) among different network entites the attributes must be assigned identifiers and these identifiers must be registered by a central authority. The Internet Assigned Numbers Authority (IANA) provides this function for the Internet.
異なったネットワークentitesの中で特定の属性(例えば、特定の暗号化アルゴリズム)の簡単な識別を容易にするために、識別子を属性に割り当てなければなりません、そして、主要な権威でこれらの識別子を登録しなければなりません。 インターネットAssigned民数記Authority(IANA)はこの機能をインターネットに提供します。
Maughan, et. al. Standards Track [Page 7] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[7ページ]。
1.4.2 ISAKMP Requirements
1.4.2 ISAKMP要件
Security Association (SA) establishment MUST be part of the key management protocol defined for IP based networks. The SA concept is required to support security protocols in a diverse and dynamic networking environment. Just as authentication and key exchange must be linked to provide assurance that the key is established with the authenticated party [DOW92], SA establishment must be linked with the authentication and the key exchange protocol.
セキュリティAssociation(SA)設立はIPのベースのネットワークのために定義されたかぎ管理プロトコルの一部であるに違いありません。 SA概念が、セキュリティがさまざまの、そして、ダイナミックなネットワーク環境でプロトコルであるとサポートするのに必要です。 ちょうど認証されたパーティー[DOW92]をキーが設立されるという保証に提供するために認証と主要な交換をリンクしなければならないように、認証と主要な交換プロトコルにSA設立をリンクしなければなりません。
ISAKMP provides the protocol exchanges to establish a security association between negotiating entities followed by the establishment of a security association by these negotiating entities in behalf of some protocol (e.g. ESP/AH). First, an initial protocol exchange allows a basic set of security attributes to be agreed upon. This basic set provides protection for subsequent ISAKMP exchanges. It also indicates the authentication method and key exchange that will be performed as part of the ISAKMP protocol. If a basic set of security attributes is already in place between the negotiating server entities, the initial ISAKMP exchange may be skipped and the establishment of a security association can be done directly. After the basic set of security attributes has been agreed upon, initial identity authenticated, and required keys generated, the established SA can be used for subsequent communications by the entity that invoked ISAKMP. The basic set of SA attributes that MUST be implemented to provide ISAKMP interoperability are defined in Appendix A.
ISAKMPは、セキュリティ協会の設立が何らかのプロトコル(例えば、超能力/AH)のために実体を交渉しながらこれらがあとに続いた実体を交渉することの間のセキュリティ協会を証明するためにプロトコル交換を供給します。 まず最初に、初期のプロトコル交換は、基本的なセキュリティー属性が同意されるのを許容します。 この基本的なセットはその後のISAKMP交換のための保護を提供します。 また、それはISAKMPプロトコルの一部として実行される認証方法と主要な交換を示します。 交渉しているサーバ実体の間には、基本的なセキュリティー属性が既に適所にあるなら、初期のISAKMP交換をサボるかもしれません、そして、直接セキュリティ協会の設立ができます。 基本的なセキュリティー属性が同意された後に、認証されたアイデンティティに頭文字をつけてください。そうすれば、必要なキーが生成されて、その後のコミュニケーションにISAKMPを呼び出した実体で確立したSAは使用できます。 ISAKMP相互運用性を提供するために実装しなければならない基本的なセットのSA属性はAppendix Aで定義されます。
1.5 Authentication
1.5 認証
A very important step in establishing secure network communications is authentication of the entity at the other end of the communication. Many authentication mechanisms are available. Authentication mechanisms fall into two catagories of strength - weak and strong. Sending cleartext keys or other unprotected authenticating information over a network is weak, due to the threat of reading them with a network sniffer. Additionally, sending one- way hashed poorly-chosen keys with low entropy is also weak, due to the threat of brute-force guessing attacks on the sniffed messages. While passwords can be used for establishing identity, they are not considered in this context because of recent statements from the Internet Architecture Board [IAB]. Digital signatures, such as the Digital Signature Standard (DSS) and the Rivest-Shamir-Adleman (RSA) signature, are public key based strong authentication mechanisms. When using public key digital signatures each entity requires a public key and a private key. Certificates are an essential part of a digital signature authentication mechanism. Certificates bind a specific entity's identity (be it host, network, user, or
安全なネットワークコミュニケーションを確立することにおける非常に重要なステップはコミュニケーションのもう一方の端の実体の認証です。 多くの認証機構が利用可能です。 認証機構は強さの2catagoriesになります--弱くて、強いです。 ネットワークの上でcleartextキーか他の保護のない認証に情報を送るのは弱いです、ネットワーク障害解析ソフトウェアでそれらを読む脅威のため。 また、さらに、低エントロピーと共に論じ尽くされた不十分に選ばれたキーを1つの方法に送るのも弱い、ブルートフォースの脅威のため、推測はかがれたメッセージで攻撃されます。 アイデンティティを確立するのにパスワードを使用できますが、それらはこのような関係においてはインターネット・アーキテクチャ委員会[IAB]からの最近の声明のために考えられません。 デジタル署名基準(DSS)やRivestシャミルAdleman(RSA)署名などのデジタル署名は公開鍵に基づいている強い認証機構です。公開鍵デジタル署名を使用するとき、各実体は公開鍵と秘密鍵を必要とします。 証明書はデジタル署名認証機構の不可欠の部分です。 または証明書が特定の実体のアイデンティティを縛る、(それがホスト、ネットワーク、ユーザであった。
Maughan, et. al. Standards Track [Page 8] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[8ページ]。
application) to its public keys and possibly other security-related information such as privileges, clearances, and compartments. Authentication based on digital signatures requires a trusted third party or certificate authority to create, sign and properly distribute certificates. For more detailed information on digital signatures, such as DSS and RSA, and certificates see [Schneier].
アプリケーション) 特権や、クリアランスや、コンパートメントなどのその公開鍵とことによると他のセキュリティ関連の情報に。 デジタル署名に基づく認証は信頼できる第三者機関か証明書に作成して、署名して、適切に配布する認証局を必要とします。 DSSや、RSAや、証明書などのデジタル署名の、より詳細な情報に関しては、[シュナイアー]を見てください。
1.5.1 Certificate Authorities
1.5.1 認証局
Certificates require an infrastructure for generation, verification, revocation, management and distribution. The Internet Policy Registration Authority (IPRA) [RFC-1422] has been established to direct this infrastructure for the IETF. The IPRA certifies Policy Certification Authorities (PCA). PCAs control Certificate Authorities (CA) which certify users and subordinate entities. Current certificate related work includes the Domain Name System (DNS) Security Extensions [DNSSEC] which will provide signed entity keys in the DNS. The Public Key Infrastucture (PKIX) working group is specifying an Internet profile for X.509 certificates. There is also work going on in industry to develop X.500 Directory Services which would provide X.509 certificates to users. The U.S. Post Office is developing a (CA) hierarchy. The NIST Public Key Infrastructure Working Group has also been doing work in this area. The DOD Multi Level Information System Security Initiative (MISSI) program has begun deploying a certificate infrastructure for the U.S. Government. Alternatively, if no infrastructure exists, the PGP Web of Trust certificates can be used to provide user authentication and privacy in a community of users who know and trust each other.
証明書は生成、検証、取消し、管理、および分配のためにインフラストラクチャを必要とします。 インターネットPolicy Registration Authority(IPRA)[RFC-1422]は、IETFのためにこのインフラストラクチャを指示するために設立されました。 IPRAはPolicy Certification Authorities(PCA)を公認します。 PCAsはユーザと下位の実体を公認するCertificate Authorities(カリフォルニア)を制御します。 現在の証明書関連する仕事は署名している実体キーをDNSに供給するドメインネームシステム(DNS)セキュリティExtensions[DNSSEC]を含んでいます。 Public Key Infrastucture(PKIX)ワーキンググループはX.509証明書のためのインターネットプロフィールを指定しています。 また、産業で証明書をX.509に供給するX.500ディレクトリサービスをユーザに開発し続ける仕事があります。 米国のポストオフィスは(カリフォルニア)階層構造を発生しています。 また公開鍵基盤作業部会がしているNISTはこの領域で働いています。 DOD Multi Level情報システムSecurity Initiative(MISSI)プログラムは米国政府のために証明書インフラストラクチャを配布し始めました。 あるいはまた、インフラストラクチャが全く存在していないなら、互いを知って、信じるユーザの共同体にユーザー認証とプライバシーを提供するのにTrust証明書のPGPウェブを使用できます。
1.5.2 Entity Naming
1.5.2 実体命名
An entity's name is its identity and is bound to its public keys in certificates. The CA MUST define the naming semantics for the certificates it issues. See the UNINETT PCA Policy Statements [Berge] for an example of how a CA defines its naming policy. When the certificate is verified, the name is verified and that name will have meaning within the realm of that CA. An example is the DNS security extensions which make DNS servers CAs for the zones and nodes they serve. Resource records are provided for public keys and signatures on those keys. The names associated with the keys are IP addresses and domain names which have meaning to entities accessing the DNS for this information. A Web of Trust is another example. When webs of trust are set up, names are bound with the public keys. In PGP the name is usually the entity's e-mail address which has meaning to those, and only those, who understand e-mail. Another web of trust could use an entirely different naming scheme.
実体の名前は、アイデンティティであり、証明書の公開鍵に縛られます。 カリフォルニアはそれが発行する証明書のために命名意味論を定義しなければなりません。 カリフォルニアがどう命名方針を定義するかに関する例に関してUNINETT PCA Policy Statements[Berge]を見てください。 証明書が確かめられるとき、名前は確かめられます、そして、その名前はそのカリフォルニアの分野の中に意味を持つでしょう。 例はそれらが役立つゾーンとノードのためにDNSをサーバCAsにするDNSセキュリティ拡張子です。 それらのキーの上にリソース記録を公開鍵と署名に提供します。 キーに関連している名前は、この情報のためにDNSにアクセスする実体に意味を持っているIPアドレスとドメイン名です。 Trustのウェブは別の例です。 信頼のウェブがセットアップされるとき、名前は公開鍵で制限されています。 PGPでは、名前はメールするように分かるそれら、および唯一のものに意味するそうした通常実体のEメールアドレスです。 信頼の別のウェブは完全に異なった命名体系を使用するかもしれません。
Maughan, et. al. Standards Track [Page 9] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[9ページ]。
1.5.3 ISAKMP Requirements
1.5.3 ISAKMP要件
Strong authentication MUST be provided on ISAKMP exchanges. Without being able to authenticate the entity at the other end, the Security Association (SA) and session key established are suspect. Without authentication you are unable to trust an entity's identification, which makes access control questionable. While encryption (e.g. ESP) and integrity (e.g. AH) will protect subsequent communications from passive eavesdroppers, without authentication it is possible that the SA and key may have been established with an adversary who performed an active man-in-the-middle attack and is now stealing all your personal data.
ISAKMP交換のときに強い認証を提供しなければなりません。 もう一方の端のときに実体を認証できないで、(SA)とセッションキーが設立したSecurity Associationは疑わしいです。 認証がなければ、あなたは実体の識別を信じることができません。(それは、アクセスコントロールを疑わしくします)。 暗号化(例えば、超能力)と保全(例えば、AH)は受け身の立ち聞きする者からその後のコミュニケーションを保護するでしょうが、認証がなければ、SAとキーが中央の活発な男性攻撃を実行して、現在あなたのすべての個人的なデータを横取りしている敵と共に設立されたのは、可能です。
A digital signature algorithm MUST be used within ISAKMP's authentication component. However, ISAKMP does not mandate a specific signature algorithm or certificate authority (CA). ISAKMP allows an entity initiating communications to indicate which CAs it supports. After selection of a CA, the protocol provides the messages required to support the actual authentication exchange. The protocol provides a facility for identification of different certificate authorities, certificate types (e.g. X.509, PKCS #7, PGP, DNS SIG and KEY records), and the exchange of the certificates identified.
ISAKMPの認証コンポーネントの中でデジタル署名アルゴリズムを使用しなければなりません。 しかしながら、ISAKMPは特定の署名アルゴリズムか認証局(カリフォルニア)を強制しません。 ISAKMPはそれがどのCAsをサポートするかをコミュニケーションを開始する実体を示させます。 カリフォルニアの選択の後に、プロトコルは実際の認証が交換であるとサポートするのに必要であるメッセージを提供します。 プロトコルは異なった認証局の識別に施設を提供します、と証明書がタイプして(例えば、X.509、PKCS#7、PGP、DNS SIG、およびKEY記録)、証明書の交換は特定しました。
ISAKMP utilizes digital signatures, based on public key cryptography, for authentication. There are other strong authentication systems available, which could be specified as additional optional authentication mechanisms for ISAKMP. Some of these authentication systems rely on a trusted third party called a key distribution center (KDC) to distribute secret session keys. An example is Kerberos, where the trusted third party is the Kerberos server, which holds secret keys for all clients and servers within its network domain. A client's proof that it holds its secret key provides authenticaton to a server.
ISAKMPは公開鍵暗号に基づくデジタル署名を認証に利用します。 利用可能な他の強い認証システムがあります。(追加ISAKMPに、任意の認証機構としてシステムを指定できました)。 これらのいくつかの認証システムが非公開会議キーを分配するために主要な配送センター(KDC)と呼ばれる信頼できる第三者機関に頼ります。 例はケルベロスです。(そこでは、信頼できる第三者機関がケルベロスサーバです)。(そのサーバはネットワークドメインの中ですべてのクライアントとサーバのための秘密鍵を支えます)。 秘密鍵を持っているというクライアントの証拠はauthenticatonをサーバに提供します。
The ISAKMP specification does not specify the protocol for communicating with the trusted third parties (TTP) or certificate directory services. These protocols are defined by the TTP and directory service themselves and are outside the scope of this specification. The use of these additional services and protocols will be described in a Key Exchange specific document.
ISAKMP仕様は信頼できる第三者機関とコミュニケートするためのプロトコル(TTP)か証明書ディレクトリサービスを指定しません。 これらのプロトコルは、TTPとディレクトリサービスによって自分たちで定義されて、この仕様の範囲の外にあります。 これらの追加サービスとプロトコルの使用はKey Exchangeの特定のドキュメントで説明されるでしょう。
1.6 Public Key Cryptography
1.6 公開鍵暗号
Public key cryptography is the most flexible, scalable, and efficient way for users to obtain the shared secrets and session keys needed to support the large number of ways Internet users will interoperate. Many key generation algorithms, that have different properties, are
公開鍵暗号はユーザが共有秘密キーを得る最もフレキシブルで、スケーラブルで、効率的な方法です、そして、セッションキーはインターネットユーザが共同利用する多くの方法をサポートする必要がありました。 多くのキー生成アルゴリズムであり、それは、異なった特性を持って、います。
Maughan, et. al. Standards Track [Page 10] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[10ページ]。
available to users (see [DOW92], [ANSI], and [Oakley]). Properties of key exchange protocols include the key establishment method, authentication, symmetry, perfect forward secrecy, and back traffic protection.
ユーザ([DOW92]、[ANSI]、および[オークリー]を見ます)にとって、利用可能です。 主要な交換プロトコルの特性は主要な設立メソッド、認証、対称、完全な前進の秘密保持、および逆トラフィック保護を含んでいます。
NOTE: Cryptographic keys can protect information for a considerable length of time. However, this is based on the assumption that keys used for protection of communications are destroyed after use and not kept for any reason.
以下に注意してください。 暗号化キーはかなりの長さの時間の情報を保護できます。 しかしながら、これはコミュニケーションの保護に使用されるキーが使用の後に破壊されて、どんな理由でも保たれないという仮定に基づいています。
1.6.1 Key Exchange Properties
1.6.1 主要な交換の特性
Key Establishment (Key Generation / Key Transport): The two common methods of using public key cryptography for key establishment are key transport and key generation. An example of key transport is the use of the RSA algorithm to encrypt a randomly generated session key (for encrypting subsequent communications) with the recipient's public key. The encrypted random key is then sent to the recipient, who decrypts it using his private key. At this point both sides have the same session key, however it was created based on input from only one side of the communications. The benefit of the key transport method is that it has less computational overhead than the following method. The Diffie-Hellman (D-H) algorithm illustrates key generation using public key cryptography. The D-H algorithm is begun by two users exchanging public information. Each user then mathematically combines the other's public information along with their own secret information to compute a shared secret value. This secret value can be used as a session key or as a key encryption key for encrypting a randomly generated session key. This method generates a session key based on public and secret information held by both users. The benefit of the D-H algorithm is that the key used for encrypting messages is based on information held by both users and the independence of keys from one key exchange to another provides perfect forward secrecy. Detailed descriptions of these algorithms can be found in [Schneier]. There are a number of variations on these two key generation schemes and these variations do not necessarily interoperate.
主要な設立(キー生成/キー輸送): 主要な設立に公開鍵暗号を使用する2つの一般的なメソッドが、主要な輸送とキー生成です。 主要な輸送に関する例は受取人の公開鍵で手当たりしだいに発生しているセッションキー(その後のコミュニケーションを暗号化するための)を暗号化するRSAアルゴリズムの使用です。 そして、暗号化されたランダムキーを受取人に送ります。(その受取人は、彼の秘密鍵を使用することでそれを解読します)。 ここに、両側には同じセッションキーがあって、しかしながら、それはコミュニケーションの唯一の半面からの入力に基づいて作成されました。 主要な輸送メソッドの利益はそれにはコンピュータのオーバーヘッドより以下のメソッドがあるということです。 ディフィー-ヘルマン(D-H)アルゴリズムは、公開鍵暗号を使用することでキー生成を例証します。 D-Hアルゴリズムは公開情報を交換する2人のユーザによって始められます。 そして、各ユーザは、共有秘密キー値を計算するためにそれら自身の秘密の情報に伴うもう片方の公開情報を数学的に結合します。 セッションキーとして、または、手当たりしだいに発生しているセッションキーを暗号化するのに、主要な主要な暗号化としてこの秘密の値を使用できます。 このメソッドは両方のユーザによって保持された公共の、そして、秘密の情報に基づいて主要なセッションを生成します。 D-Hアルゴリズムの利益はメッセージを暗号化するのに使用されるキーが両方のユーザによって保持された情報に基づいているということです、そして、1回の主要な交換から別の交換までのキーからの独立は完全な前進の秘密保持を提供します。 [シュナイアー]でこれらのアルゴリズムの詳述を見つけることができます。 これらの2つのキー生成の体系の多くの変化があります、そして、これらの変化は必ず共同利用するというわけではありません。
Key Exchange Authentication: Key exchanges may be authenticated during the protocol or after protocol completion. Authentication of the key exchange during the protocol is provided when each party provides proof it has the secret session key before the end of the protocol. Proof can be provided by encrypting known data in the secret session key during the protocol echange. Authentication after the protocol must occur in subsequent commu nications. Authentication during the protocol is preferred so subsequent communications are not initiated if the secret session key is not established with the desired party.
主要な交換認証: 主要な交換はプロトコルかプロトコル完成の後に認証されるかもしれません。 各当事者がそれにはプロトコルの終わりまでに主要な非公開会議があるという証拠を提供するとき、プロトコルの間の主要な交換の認証を提供します。 知られているデータを暗号化することによって、プロトコルechangeの間、主要な非公開会議に証拠を提供できます。 プロトコルの後の認証はその後のcommu nicationsに起こらなければなりません。 プロトコルの間の認証が好まれるので、非公開会議キーが必要なパーティーと共に設立されないなら、その後のコミュニケーションは開始されません。
Maughan, et. al. Standards Track [Page 11] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[11ページ]。
Key Exchange Symmetry: A key exchange provides symmetry if either party can initiate the exchange and exchanged messages can cross in transit without affecting the key that is generated. This is desirable so that computation of the keys does not require either party to know who initated the exchange. While key exchange symmetry is desirable, symmetry in the entire key management protocol may provide a vulnerablity to reflection attacks.
主要な交換対称: 何れの当事者が交換を起こすことができるなら、主要な交換は対称を供給します、そして、発生しているキーに影響しないで、交換されたメッセージはトランジットで交差できます。 これはしたがって、キーのその計算が、何れの当事者が、だれが交換をinitatedしたかを知っているのを必要としないのが望ましいです。 主要な交換対称が望ましい間、全体のかぎ管理プロトコルにおける対称は反射攻撃にvulnerablityを提供するかもしれません。
Perfect Forward Secrecy: As described in [DOW92], an authenticated key exchange protocol provides perfect forward secrecy if disclosure of longterm secret keying material does not compromise the secrecy of the exchanged keys from previous communications. The property of perfect forward secrecy does not apply to key exchange without authentication.
前進の秘密保持を完成させてください: [DOW92]で説明されるように、材料を合わせる長期秘密の公開が前のコミュニケーションから交換されたキーの秘密保持に感染しないなら、認証された主要な交換プロトコルは完全な前進の秘密保持を提供します。 完全な前進の秘密保持の特性は認証なしで主要な交換に適用されません。
1.6.2 ISAKMP Requirements
1.6.2 ISAKMP要件
An authenticated key exchange MUST be supported by ISAKMP. Users SHOULD choose additional key establishment algorithms based on their requirements. ISAKMP does not specify a specific key exchange. However, [IKE] describes a proposal for using the Oakley key exchange [Oakley] in conjunction with ISAKMP. Requirements that should be evaluated when choosing a key establishment algorithm include establishment method (generation vs. transport), perfect forward secrecy, computational overhead, key escrow, and key strength. Based on user requirements, ISAKMP allows an entity initiating communications to indicate which key exchanges it supports. After selection of a key exchange, the protocol provides the messages required to support the actual key establishment.
ISAKMPは認証された主要な交換をサポートしなければなりません。 ユーザSHOULDはそれらの要件に基づく追加主要な設立アルゴリズムを選びます。 ISAKMPは特定の主要な交換を指定しません。 しかしながら、[IKE]はISAKMPに関連してオークリーの主要な交換[オークリー]を使用するための提案について説明します。 主要な設立アルゴリズムを選ぶとき評価されるべきである要件は設立メソッド(世代対輸送)、完全な前進の秘密保持、コンピュータのオーバーヘッド、キーエスクロー、および主要な強さを含んでいます。 ユーザ要件に基づいて、ISAKMPはそれがどの主要な交換をサポートするかをコミュニケーションを開始する実体を示させます。 主要な交換の選択の後に、プロトコルは実際のキーが設立であるとサポートするのに必要であるメッセージを提供します。
1.7 ISAKMP Protection
1.7 ISAKMP保護
1.7.1 Anti-Clogging (Denial of Service)
1.7.1 反目詰まり(サービス妨害)
Of the numerous security services available, protection against denial of service always seems to be one of the most difficult to address. A "cookie" or anti-clogging token (ACT) is aimed at protecting the computing resources from attack without spending excessive CPU resources to determine its authenticity. An exchange prior to CPU-intensive public key operations can thwart some denial of service attempts (e.g. simple flooding with bogus IP source addresses). Absolute protection against denial of service is impossible, but this anti-clogging token provides a technique for making it easier to handle. The use of an anti-clogging token was introduced by Karn and Simpson in [Karn].
利用可能な頻繁なセキュリティー・サービスでは、サービスの否定に対する保護は扱う最も難しいものの1つであるようにいつも思えます。 「クッキー」か反目詰まりトークン(大学入学能力テスト)は攻撃から信憑性を決定するために過度のCPUリソースを費やさないでコンピューティング資源を保護するのを目的とされます。 CPU徹底的な公開鍵操作の前の交換はサービス試み(例えば、にせのIPソースアドレスがある簡単な氾濫)の何らかの否定を阻むことができます。 サービスの否定に対する絶対保護は不可能ですが、この反目詰まりトークンはそれを扱うのが、より簡単にするためのテクニックを提供します。 反目詰まりトークンの使用は[Karn]でKarnとシンプソンによって導入されました。
Maughan, et. al. Standards Track [Page 12] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[12ページ]。
It should be noted that in the exchanges shown in section 4, the anticlogging mechanism should be used in conjuction with a garbage- state collection mechanism; an attacker can still flood a server using packets with bogus IP addresses and cause state to be created. Such aggressive memory management techniques SHOULD be employed by protocols using ISAKMP that do not go through an initial, anti- clogging only phase, as was done in [Karn].
セクション4で示された交換に「反-障害物」メカニズムがconjuctionでゴミ州の収集メカニズムで使用されるべきであることに注意されるべきです。 攻撃者は、作成されるのににせのIPアドレスと原因状態があるパケットを使用することでサーバをまだあふれさせることができます。 そのような攻撃的なメモリ管理テクニックSHOULDがプロトコルによってイニシャルに直面していないISAKMPを使用することで使われて、反目詰まりはされたコネのように[Karn]の位相を合わせるだけです。
1.7.2 Connection Hijacking
1.7.2 接続ハイジャック
ISAKMP prevents connection hijacking by linking the authentication, key exchange and security association exchanges. This linking prevents an attacker from allowing the authentication to complete and then jumping in and impersonating one entity to the other during the key and security association exchanges.
ISAKMPは、接続が認証、主要な交換、およびセキュリティ協会交換をリンクすることによってハイジャックするのを防ぎます。 このリンクは、キーとセキュリティ協会交換の間、もう片方に攻撃者は終了する認証を許して、次に、ジャンプを許すのを防いで、1つの実体をまねます。
1.7.3 Man-in-the-Middle Attacks
1.7.3 介入者攻撃
Man-in-the-Middle attacks include interception, insertion, deletion, and modification of messages, reflecting messages back at the sender, replaying old messages and redirecting messages. ISAKMP features prevent these types of attacks from being successful. The linking of the ISAKMP exchanges prevents the insertion of messages in the protocol exchange. The ISAKMP protocol state machine is defined so deleted messages will not cause a partial SA to be created, the state machine will clear all state and return to idle. The state machine also prevents reflection of a message from causing harm. The requirement for a new cookie with time variant material for each new SA establishment prevents attacks that involve replaying old messages. The ISAKMP strong authentication requirement prevents an SA from being established with anyone other than the intended party. Messages may be redirected to a different destination or modified but this will be detected and an SA will not be established. The ISAKMP specification defines where abnormal processing has occurred and recommends notifying the appropriate party of this abnormality.
中央の男性攻撃はメッセージの妨害、挿入、削除、および変更を含んでいます、送付者でメッセージを映し出して、古いメッセージを再演して、メッセージを向け直して。 ISAKMPの特徴は、これらのタイプの攻撃がうまくいっているのを防ぎます。 ISAKMP交換のリンクはプロトコル交換へのメッセージの挿入を防ぎます。 ISAKMPプロトコル州のマシンがメッセージで部分的なSAを作成しないように削除されていた状態で定義されて、州のマシンはすべての状態をきれいにして、戻って、怠けるでしょう。 また、州のマシンは、メッセージの反映が害を引き起こすのを防ぎます。 それぞれの新しいSA設立のための時間異形の材料がある新しいクッキーのための要件は古いメッセージを再演することを伴う攻撃を防ぎます。 ISAKMPの強い認証要件は、SAが通話相手以外のだれと共にも設立されるのを防ぎます。 これは検出されるでしょう、そして、メッセージは、異なった目的地に向け直されるか、または変更されるかもしれませんが、SAは設立されないでしょう。 ISAKMP仕様は、異常な処理がどこに起こったかを定義して、この異常について適切なパーティーに通知することを勧めます。
1.8 Multicast Communications
1.8 マルチキャストコミュニケーション
It is expected that multicast communications will require the same security services as unicast communications and may introduce the need for additional security services. The issues of distributing SPIs for multicast traffic are presented in [SEC-ARCH]. Multicast security issues are also discussed in [RFC-1949] and [BC]. A future extension to ISAKMP will support multicast key distribution. For an introduction to the issues related to multicast security, consult the Internet Drafts, [RFC-2094] and [RFC-2093], describing Sparta's research in this area.
マルチキャストコミュニケーションがユニキャストコミュニケーションと同じセキュリティー・サービスを必要として、追加担保サービスの必要性を導入するかもしれないと予想されます。 マルチキャストトラフィックのためにSPIsを分配する問題は[SEC-ARCH]に提示されます。 また、[RFC-1949]と[紀元前]のときにマルチキャスト安全保障問題について議論します。 ISAKMPへの今後の拡大はマルチキャストの主要な分配をサポートするでしょう。 マルチキャストセキュリティに関連する問題への序論には、インターネットDrafts、[RFC-2094]、および[RFC-2093]に相談してください、この領域でスパルタの研究について説明して。
Maughan, et. al. Standards Track [Page 13] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[13ページ]。
2 Terminology and Concepts
2 用語と概念
2.1 ISAKMP Terminology
2.1 ISAKMP用語
Security Protocol: A Security Protocol consists of an entity at a single point in the network stack, performing a security service for network communication. For example, IPSEC ESP and IPSEC AH are two different security protocols. TLS is another example. Security Protocols may perform more than one service, for example providing integrity and confidentiality in one module.
セキュリティは議定書を作ります: Securityプロトコルはネットワークスタックで1ポイントで実体から成ります、ネットワークコミュニケーションのためのセキュリティー・サービスを実行して。 例えば、IPSEC ESPとIPSEC AHは2つの異なったセキュリティプロトコルです。 TLSは別の例です。 例えば、保全と秘密性を1つのモジュールに提供して、セキュリティプロトコルは1つ以上のサービスを実行するかもしれません。
Protection Suite: A protection suite is a list of the security services that must be applied by various security protocols. For example, a protection suite may consist of DES encryption in IP ESP, and keyed MD5 in IP AH. All of the protections in a suite must be treated as a single unit. This is necessary because security services in different security protocols can have subtle interactions, and the effects of a suite must be analyzed and verified as a whole.
保護スイート: 保護スイートは様々なセキュリティプロトコルで適用しなければならないセキュリティー・サービスのリストです。 例えば、保護スイートはIPの超能力、およびIP AHの合わせられたMD5でDES暗号化から成るかもしれません。 スイートでの保護のすべてを単一の単位として扱わなければなりません。 異なったセキュリティプロトコルにおけるセキュリティー・サービスが微妙な相互作用を持つことができるのでこれが必要であり、全体でスイートの効果を分析されて、確かめなければなりません。
Security Association (SA): A Security Association is a security- protocol- specific set of parameters that completely defines the services and mechanisms necessary to protect traffic at that security protocol location. These parameters can include algorithm identifiers, modes, cryptographic keys, etc. The SA is referred to by its associated security protocol (for example, "ISAKMP SA", "ESP SA", "TLS SA").
セキュリティ協会(SA): Security Associationはそのセキュリティプロトコル位置にトラフィックを保護するのに必要なサービスとメカニズムを完全に定義するセキュリティプロトコルの特定のセットのパラメタです。 これらのパラメタはアルゴリズム識別子、モード、暗号化キーなどを含むことができます。 関連セキュリティプロトコル(例えば、"ISAKMP SA"、「超能力SA」"TLS SA")によってSAは言及されます。
ISAKMP SA: An SA used by the ISAKMP servers to protect their own traffic. Sections 2.3 and 2.4 provide more details about ISAKMP SAs.
ISAKMP SA: ISAKMPサーバによって使用される、それら自身のトラフィックを保護するSA。 セクション2.3と2.4はISAKMP SAsに関するその他の詳細を提供します。
Security Parameter Index (SPI): An identifier for a Security Assocation, relative to some security protocol. Each security protocol has its own "SPI-space". A (security protocol, SPI) pair may uniquely identify an SA. The uniqueness of the SPI is implementation dependent, but could be based per system, per protocol, or other options. Depending on the DOI, additional information (e.g. host address) may be necessary to identify an SA. The DOI will also determine which SPIs (i.e. initiator's or responder's) are sent during communication.
セキュリティパラメタインデックス(SPI): 何らかのセキュリティプロトコルに比例したSecurity Assocationのための識別子。 それぞれのセキュリティプロトコルには、それ自身の「SPI-スペース」があります。 (SPI、セキュリティは議定書を作ります)組は唯一SAを特定するかもしれません。 SPIのユニークさは、実装に依存していますが、1プロトコルあたりのシステムあたりのベース、または他のオプションであるかもしれません。 DOIによって、追加情報(例えば、ホスト・アドレス)が、SAを特定するのに必要であるかもしれません。 また、DOIは、どのSPIs(すなわち、創始者か応答者のもの)がコミュニケーションの間、送られるかを決定するでしょう。
Domain of Interpretation: A Domain of Interpretation (DOI) defines payload formats, exchange types, and conventions for naming security-relevant information such as security policies or cryptographic algorithms and modes. A Domain of Interpretation (DOI) identifier is used to interpret the payloads of ISAKMP payloads. A system SHOULD support multiple Domains of Interpretation simultaneously. The concept of a DOI is based on previous work by
解釈のドメイン: Interpretation(DOI)のDomainはセキュリティ関連している情報を命名するための安全保障政策か暗号アルゴリズムやモードなどのペイロード書式、交換タイプ、およびコンベンションを定義します。 Interpretation(DOI)識別子のDomainは、ISAKMPペイロードのペイロードを解釈するのに使用されます。 SHOULDが同時にInterpretationの複数のDomainsをサポートするシステム。 DOIの概念は前の仕事に基づいています。
Maughan, et. al. Standards Track [Page 14] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[14ページ]。
the TSIG CIPSO Working Group, but extends beyond security label interpretation to include naming and interpretation of security services. A DOI defines:
TSIG CIPSO作業部会、セキュリティー・サービスの命名と解釈を含むように機密保護ラベル解釈を超えて広がっています。 DOIは以下を定義します。
o A "situation": the set of information that will be used to
determine the required security services.
o 「状況」: 必要なセキュリティー・サービスを決定するのに使用される情報のセット。
o The set of security policies that must, and may, be supported.
o サポートされなければならなくて、サポートされるかもしれない安全保障政策のセット。
o A syntax for the specification of proposed security services.
o 提案されたセキュリティー・サービスの仕様のための構文。
o A scheme for naming security-relevant information, including
encryption algorithms, key exchange algorithms, security policy
attributes, and certificate authorities.
o 暗号化アルゴリズム、主要な交換アルゴリズム、安全保障政策属性、および認証局を含むセキュリティ関連している情報を命名することの体系。
o The specific formats of the various payload contents.
o 様々なペイロード内容の特定の形式。
o Additional exchange types, if required.
o 必要なら追加交換タイプ。
The rules for the IETF IP Security DOI are presented in [IPDOI]. Specifications of the rules for customized DOIs will be presented in separate documents.
IETF IP Security DOIのための規則は[IPDOI]に提示されます。 カスタム設計されたDOIsのための規則の仕様は別々のドキュメントに提示されるでしょう。
Situation: A situation contains all of the security-relevant information that a system considers necessary to decide the security services required to protect the session being negotiated. The situation may include addresses, security classifications, modes of operation (normal vs. emergency), etc.
状況: 状況はシステムがセキュリティー・サービスが交渉されるセッションを保護するのが必要であると決めるのに必要であると考えるセキュリティ関連している情報のすべてを含んでいます。 状況はアドレス、セキュリティ分類、運転モード(非常時に対して正常な)などを含むかもしれません。
Proposal: A proposal is a list, in decreasing order of preference, of the protection suites that a system considers acceptable to protect traffic under a given situation.
提案: 提案は多いほうから少ないほうへ順に並べると好み、システムが与えられた状況の下でトラフィックを保護するのにおいて許容できると考える保護スイートのリストです。
Payload: ISAKMP defines several types of payloads, which are used to transfer information such as security association data, or key exchange data, in DOI-defined formats. A payload consists of a generic payload header and a string of octects that is opaque to ISAKMP. ISAKMP uses DOI- specific functionality to synthesize and interpret these payloads. Multiple payloads can be sent in a single ISAKMP message. See section 3 for more details on the payload types, and [IPDOI] for the formats of the IETF IP Security DOI payloads.
有効搭載量: ISAKMPはいくつかのタイプのセキュリティ協会データなどの情報を移すのに使用されるペイロードか主要な交換データを定義します、DOIによって定義された形式で。 ペイロードはISAKMPに分っているジェネリックペイロードヘッダーと一連のoctectsから成ります。 ISAKMPは、これらのペイロードを統合して、解釈するのにDOIの特定の機能性を使用します。 ただ一つのISAKMPメッセージで複数のペイロードを送ることができます。 ペイロードタイプ、および[IPDOI]に関するその他の詳細に関してIETF IP Security DOIペイロードの形式に関してセクション3を見てください。
Exchange Type: An exchange type is a specification of the number of messages in an ISAKMP exchange, and the payload types that are contained in each of those messages. Each exchange type is designed to provide a particular set of security services, such as anonymity of the participants, perfect forward secrecy of the keying material, authentication of the participants, etc. Section 4.1 defines the
タイプを交換してください: 交換タイプは、ISAKMP交換における、メッセージの数の仕様と、それぞれに関するそれらのメッセージに含まれているペイロードタイプです。 それぞれの交換タイプは特定のセキュリティー・サービスを提供するように設計されています、関係者の匿名、合わせることの材料の完全な前進の秘密保持、関係者の認証などのように セクション4.1は定義します。
Maughan, et. al. Standards Track [Page 15] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[15ページ]。
default set of ISAKMP exchange types. Other exchange types can be added to support additional key exchanges, if required.
ISAKMP交換のデフォルトセットはタイプされます。 必要なら、追加キーが交換するサポートに他の交換タイプを加えることができます。
2.2 ISAKMP Placement
2.2 ISAKMPプレースメント
Figure 1 is a high level view of the placement of ISAKMP within a system context in a network architecture. An important part of negotiating security services is to consider the entire "stack" of individual SAs as a unit. This is referred to as a "protection suite".
図1はネットワークアーキテクチャのシステムの背景の中のISAKMPのプレースメントの高い平らな視点です。 交渉セキュリティー・サービスの重要な部分は個々のSAsの全体の「スタック」を一体にして考えることです。 これは「保護スイート」と呼ばれます。
+------------+ +--------+ +--------------+
! DOI ! ! ! ! Application !
! Definition ! <----> ! ISAKMP ! ! Process !
+------------+ --> ! ! !--------------!
+--------------+ ! +--------+ ! Appl Protocol!
! Key Exchange ! ! ^ ^ +--------------+
! Definition !<-- ! ! ^
+--------------+ ! ! !
! ! !
!----------------! ! !
v ! !
+-------+ v v
! API ! +---------------------------------------------+
+-------+ ! Socket Layer !
! !---------------------------------------------!
v ! Transport Protocol (TCP / UDP) !
+----------+ !---------------------------------------------!
! Security ! <----> ! IP !
! Protocol ! !---------------------------------------------!
+----------+ ! Link Layer Protocol !
+---------------------------------------------+
+------------+ +--------+ +--------------+ DOI!アプリケーション!定義!<。---->!ISAKMP!プロセス!+------------+-->!--------------! +--------------+ ! +--------+ Applは議定書を作ります! ! 主要な交換!^ ^ +--------------+ 定義!<--、^ +--------------+ ! ! ! ! ! ! !----------------! ! ! v!+-------+ v!API!+に対して---------------------------------------------+ +-------+ ソケットレイヤー!---------------------------------------------! v!Transportプロトコル(TCP / UDP)!+----------+ !---------------------------------------------! ! セキュリティ!<。---->!IP!議定書を作ってください!---------------------------------------------! +----------+ リンクレイヤプロトコル!+---------------------------------------------+
Figure 1: ISAKMP Relationships
図1: ISAKMP関係
2.3 Negotiation Phases
2.3 交渉フェーズ
ISAKMP offers two "phases" of negotiation. In the first phase, two entities (e.g. ISAKMP servers) agree on how to protect further negotiation traffic between themselves, establishing an ISAKMP SA. This ISAKMP SA is then used to protect the negotiations for the Protocol SA being requested. Two entities (e.g. ISAKMP servers) can negotiate (and have active) multiple ISAKMP SAs.
ISAKMPは交渉の2「フェーズ」を提供します。 第1段階では、2つの実体(例えば、ISAKMPサーバ)が自分たちの間のさらなる交渉トラフィックを保護する方法に同意します、ISAKMP SAを設立して。 そして、このISAKMP SAは、要求されているプロトコルSAのために交渉を保護するのに使用されます。 2つの実体(例えば、ISAKMPサーバ)が複数のISAKMP SAsを交渉できます(能動態を持ってください)。
Maughan, et. al. Standards Track [Page 16] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[16ページ]。
The second phase of negotiation is used to establish security associations for other security protocols. This second phase can be used to establish many security associations. The security associations established by ISAKMP during this phase can be used by a security protocol to protect many message/data exchanges.
交渉の2番目のフェーズは、他のセキュリティプロトコルのためにセキュリティ協会を証明するのに使用されます。 多くのセキュリティ協会を証明するのにこの2番目のフェーズを使用できます。 この段階の間にISAKMPによって設立されたセキュリティ協会はセキュリティプロトコルによって使用されて、多くのメッセージ/データ交換を保護できます。
While the two-phased approach has a higher start-up cost for most simple scenarios, there are several reasons that it is beneficial for most cases.
2段階のアプローチには、ほとんどの簡単なシナリオのための、より高い始動費用がありますが、ほとんどのケースに、それが有益であるいくつかの理由があります。
First, entities (e.g. ISAKMP servers) can amortize the cost of the first phase across several second phase negotiations. This allows multiple SAs to be established between peers over time without having to start over for each communication.
まず最初に、実体(例えば、ISAKMPサーバ)は数個の2番目のフェーズ交渉の向こう側に第1段階の費用を清算できます。 これで、各コミュニケーションのためにやり直す必要はなくて、複数のSAsが時間がたつにつれて、同輩の間で創業します。
Second, security services negotiated during the first phase provide security properties for the second phase. For example, after the first phase of negotiation, the encryption provided by the ISAKMP SA can provide identity protection, potentially allowing the use of simpler second-phase exchanges. On the other hand, if the channel established during the first phase is not adequate to protect identities, then the second phase must negotiate adequate security mechanisms.
2番目に、第1段階の間に交渉されたセキュリティー・サービスは2番目のフェーズにセキュリティ資産を提供します。 例えば、交渉の第1段階の後にISAKMP SAによって提供された暗号化はアイデンティティ保護を提供できます、潜在的により簡単な2番目のフェーズ交換の使用を許して。 他方では、第1段階の間に確立されたチャンネルがアイデンティティを保護するために適切でないなら、2番目のフェーズは十分な安全性メカニズムを交渉しなければなりません。
Third, having an ISAKMP SA in place considerably reduces the cost of ISAKMP management activity - without the "trusted path" that an ISAKMP SA gives you, the entities (e.g. ISAKMP servers) would have to go through a complete re-authentication for each error notification or deletion of an SA.
3番目に、適所にISAKMP SAを持っていると、ISAKMP管理活動のコストはISAKMP SAがあなたに与える「信じられた経路」なしでかなり削減されます、SAの各エラー通知か削除のための完全な再認証に直面するために(例えば、ISAKMPサーバ)にはある実体。
Negotiation during each phase is accomplished using ISAKMP-defined exchanges (see section 4) or exchanges defined for a key exchange within a DOI.
各段階の間の交渉はDOIの中でISAKMPによって定義された交換(セクション4を見る)か主要な交換のために定義された交換を使用するのに優れています。
Note that security services may be applied differently in each negotiation phase. For example, different parties are being authenticated during each of the phases of negotiation. During the first phase, the parties being authenticated may be the ISAKMP servers/hosts, while during the second phase, users or application level programs are being authenticated.
セキュリティー・サービスがそれぞれの交渉フェーズで異なって適用されるかもしれないことに注意してください。 例えば、異なったパーティーはそれぞれの交渉の段階の間、認証されています。 第1段階の間、認証されるパーティーはISAKMPサーバ/ホストであるかもしれません、ユーザかアプリケーションレベルプログラムが2番目の段階の間、認証されている間。
2.4 Identifying Security Associations
2.4 セキュリティ協会を特定すること。
While bootstrapping secure channels between systems, ISAKMP cannot assume the existence of security services, and must provide some protections for itself. Therefore, ISAKMP considers an ISAKMP Security Association to be different than other types, and manages ISAKMP SAs itself, in their own name space. ISAKMP uses the two
システムの間の安全なチャンネルを独力で進んでいる間、ISAKMPはセキュリティー・サービスの存在を仮定できないで、それ自体のためのいくつかの保護を提供しなければなりません。 したがって、ISAKMPはISAKMP Security Associationが他のタイプと異なっていると考えて、ISAKMP SAs自身を管理します、それら自身の名前スペースで。 ISAKMPは2を使用します。
Maughan, et. al. Standards Track [Page 17] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[17ページ]。
cookie fields in the ISAKMP header to identify ISAKMP SAs. The Message ID in the ISAKMP Header and the SPI field in the Proposal payload are used during SA establishment to identify the SA for other security protocols. The interpretation of these four fields is dependent on the operation taking place.
ISAKMP SAsを特定するISAKMPヘッダーのクッキー分野。 ISAKMP HeaderのMessage IDとProposalペイロードのSPI分野は、他のセキュリティプロトコルのためにSAを特定するのにSA設立の間、使用されます。 これらの4つの分野の解釈は行われる操作に依存しています。
The following table shows the presence or absence of several fields during SA establishment. The following fields are necessary for various operations associated with SA establishment: cookies in the ISAKMP header, the ISAKMP Header Message ID field, and the SPI field in the Proposal payload. An 'X' in the column means the value MUST be present. An 'NA' in the column means a value in the column is Not Applicable to the operation.
以下のテーブルはSA設立の間、いくつかの分野の存在か欠如を見せています。 以下の分野がSA設立に関連している様々な操作に必要です: ISAKMPヘッダー、ISAKMP Header Message ID分野、およびProposalペイロードのSPI分野のクッキー。 コラムの'X'は、値が存在していなければならないことを意味します。 コラムの'NA'は、コラムの値が操作へのNot Applicableであることを意味します。
# Operation I-Cookie R-Cookie Message ID SPI (1) Start ISAKMP SA negotiation X 0 0 0 (2) Respond ISAKMP SA negotiation X X 0 0 (3) Init other SA negotiation X X X X (4) Respond other SA negotiation X X X X (5) Other (KE, ID, etc.) X X X/0 NA (6) Security Protocol (ESP, AH) NA NA NA X
# 操作I-クッキーR-クッキーMessage ID SPI(1)スタートISAKMP SA交渉X0 0 0(2)は他のSA交渉X X X X(5)他で(KE、IDなど)X0 0(3)イニットもう一方SA交渉X X X X(4)が反応させるISAKMP SA交渉Xを反応させます。 X X X/0Na(6)セキュリティプロトコル(超能力、ああ)Na Na Na X
In the first line (1) of the table, the initiator includes the Initiator Cookie field in the ISAKMP Header, using the procedures outlined in sections 2.5.3 and 3.1.
テーブルの最初の系列(1)では、創始者はISAKMP HeaderのInitiator Cookie分野を入れます、セクション2.5.3と3.1に概説された手順を用いて。
In the second line (2) of the table, the responder includes the Initiator and Responder Cookie fields in the ISAKMP Header, using the procedures outlined in sections 2.5.3 and 3.1. Additional messages may be exchanged between ISAKMP peers, depending on the ISAKMP exchange type used during the phase 1 negotiation. Once the phase 1 exchange is completed, the Initiator and Responder cookies are included in the ISAKMP Header of all subsequent communications between the ISAKMP peers.
テーブルのセカンドライン(2)では、応答者がISAKMP HeaderのInitiatorとResponder Cookie分野を入れます、セクション2.5.3と3.1に概説された手順を用いて。 ISAKMP同輩の間で追加メッセージを交換したかもしれなくて、ISAKMP交換タイプに頼るのは段階の間、1つの交渉を使用しました。 フェーズ1交換がいったん終了されていると、InitiatorとResponderクッキーはISAKMP同輩のすべてのその後のコミュニケーションのISAKMP Headerに含まれています。
During phase 1 negotiations, the initiator and responder cookies determine the ISAKMP SA. Therefore, the SPI field in the Proposal payload is redundant and MAY be set to 0 or it MAY contain the transmitting entity's cookie.
フェーズ1交渉の間、創始者と応答者クッキーはISAKMP SAを決定します。 したがって、ProposalペイロードのSPI分野が、余分であり、0に設定されるかもしれませんか、またはそれは伝える実体のクッキーを含むかもしれません。
In the third line (3) of the table, the initiator associates a Message ID with the Protocols contained in the SA Proposal. This Message ID and the initiator's SPI(s) to be associated with each protocol in the Proposal are sent to the responder. The SPI(s) will be used by the security protocols once the phase 2 negotiation is completed.
テーブルの3番目の系列(3)では、創始者はSA Proposalに含まれているプロトコルにMessage IDを関連づけます。 Proposalの各プロトコルに関連しているこのMessage IDと創始者のSPI(s)を応答者に送ります。 フェーズ2交渉がいったん終了されていると、SPI(s)はセキュリティプロトコルによって使用されるでしょう。
Maughan, et. al. Standards Track [Page 18] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[18ページ]。
In the fourth line (4) of the table, the responder includes the same Message ID and the responder's SPI(s) to be associated with each protocol in the accepted Proposal. This information is returned to the initiator.
テーブルの4番目の系列(4)では、応答者は、受け入れられたProposalの各プロトコルに関連しているように同じMessage IDと応答者のSPI(s)を入れます。 この情報を創始者に返します。
In the fifth line (5) of the table, the initiator and responder use the Message ID field in the ISAKMP Header to keep track of the in- progress protocol negotiation. This is only applicable for a phase 2 exchange and the value MUST be 0 for a phase 1 exchange because the combined cookies identify the ISAKMP SA. The SPI field in the Proposal payload is not applicable because the Proposal payload is only used during the SA negotiation message exchange (steps 3 and 4).
テーブルの5番目の系列(5)では、創始者と応答者は、コネ進歩議定書交渉の動向をおさえるのにISAKMP HeaderのMessage ID分野を使用します。 フェーズ2交換だけに、これは適切です、そして、結合したクッキーがISAKMP SAを特定するので、値はフェーズ1交換のための0でなければなりません。 ProposalペイロードがSA交渉交換処理(ステップ3と4)の間、使用されるだけであるので、ProposalペイロードのSPI分野は適切ではありません。
In the sixth line (6) of the table, the phase 2 negotiation is complete. The security protocols use the SPI(s) to determine which security services and mechanisms to apply to the communication between them. The SPI value shown in the sixth line (6) is not the SPI field in the Proposal payload, but the SPI field contained within the security protocol header.
テーブルの6番目の系列(6)では、フェーズ2交渉は完全です。 セキュリティプロトコルは、どのセキュリティー・サービスとメカニズムをそれらのコミュニケーションに適用したらよいかを決定するのにSPI(s)を使用します。 6番目の系列(6)に示されたSPI値はProposalペイロードのSPI分野ではなく、セキュリティプロトコルヘッダーの中に含まれたSPI分野です。
During the SA establishment, a SPI MUST be generated. ISAKMP is designed to handle variable sized SPIs. This is accomplished by using the SPI Size field within the Proposal payload during SA establishment. Handling of SPIs will be outlined by the DOI specification (e.g. [IPDOI]).
SA設立、SPI MUST、生成されてください。 ISAKMPは、可変大きさで分けられたSPIsを扱うように設計されています。 これは、SA設立の間、Proposalペイロードの中にSPI Size分野を使用することによって、達成されます。 DOI仕様(例えば、[IPDOI])でSPIsの取り扱いは概説されるでしょう。
When a security association (SA) is initially established, one side assumes the role of initiator and the other the role of responder. Once the SA is established, both the original initiator and responder can initiate a phase 2 negotiation with the peer entity. Thus, ISAKMP SAs are bidirectional in nature.
セキュリティ協会(SA)が初めは設立されるとき、半面は、創始者ともう片方の役割が応答者の役割であると仮定します。 SAがいったん設立されると、オリジナルの創始者と応答者の両方が同輩実体とのフェーズ2交渉を開始できます。 したがって、ISAKMP SAsは現実に双方向です。
Additionally, ISAKMP allows both initiator and responder to have some control during the negotiation process. While ISAKMP is designed to allow an SA negotiation that includes multiple proposals, the initiator can maintain some control by only making one proposal in accordance with the initiator's local security policy. Once the initiator sends a proposal containing more than one proposal (which are sent in decreasing preference order), the initiator relinquishes control to the responder. Once the responder is controlling the SA establishment, the responder can make its policy take precedence over the initiator within the context of the multiple options offered by the initiator. This is accomplished by selecting the proposal best suited for the responder's local security policy and returning this selection to the initiator.
さらに、ISAKMPは創始者と応答者の両方に交渉プロセスの間、何らかのコントロールを持たせます。 ISAKMPが複数の提案を含んでいるSA交渉を許すように設計されている間、創始者は、創始者のローカルの安全保障政策によると、1つの提案しかしないことによって、何らかのコントロールを維持できます。 創始者がいったん1つ以上の提案を含む提案を送ると(好みの命令を減少させるのが送られます)、創始者はコントロールを応答者に放棄します。 応答者がいったんSA設立を制御していると、応答者は創始者によって提供された複数のオプションの文脈の中で創始者の上で方針を優先させることができます。 これは、応答者のローカルの安全保障政策に合っていて、この選択を創始者に返しながら、提案を最もよく選択することによって、達成されます。
Maughan, et. al. Standards Track [Page 19] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[19ページ]。
2.5 Miscellaneous
2.5 その他
2.5.1 Transport Protocol
2.5.1 トランスポート・プロトコル
ISAKMP can be implemented over any transport protocol or over IP itself. Implementations MUST include send and receive capability for ISAKMP using the User Datagram Protocol (UDP) on port 500. UDP Port 500 has been assigned to ISAKMP by the Internet Assigned Numbers Authority (IANA). Implementations MAY additionally support ISAKMP over other transport protocols or over IP itself.
どんなトランスポート・プロトコルの上、または、IP自身の上でISAKMPを実装することができます。 実装を含まなければなりません。ISAKMPのためにポート500の上でユーザー・データグラム・プロトコル(UDP)を使用することで能力を送って、受けてください。 UDP Port500はインターネットAssigned民数記Authority(IANA)によってISAKMPに割り当てられました。 実装は他のトランスポート・プロトコルの上、または、IP自身の上でさらに、ISAKMPをサポートするかもしれません。
2.5.2 RESERVED Fields
2.5.2 予約された分野
The existence of RESERVED fields within ISAKMP payloads are used strictly to preserve byte alignment. All RESERVED fields in the ISAKMP protocol MUST be set to zero (0) when a packet is issued. The receiver SHOULD check the RESERVED fields for a zero (0) value and discard the packet if other values are found.
ISAKMPペイロードの中のRESERVED分野の存在は、バイト整列を保存するのに厳密に使用されます。 パケットが発行されたら(0)のゼロを合わせるようにISAKMPプロトコルのすべてのRESERVED分野を設定しなければなりません。 受信機SHOULDはゼロ(0)値がないかどうかRESERVED分野をチェックして、他の値が見つけられるなら、パケットを捨てます。
2.5.3 Anti-Clogging Token ("Cookie") Creation
2.5.3 反目詰まりトークン(「クッキー」)作成
The details of cookie generation are implementation dependent, but MUST satisfy these basic requirements (originally stated by Phil Karn in [Karn]):
クッキー世代の細部は、実装に依存していますが、これらの基本的な要件を満たさなければなりません(元々、[Karn]にフィルKarnによって述べられます):
1. The cookie must depend on the specific parties. This
prevents an attacker from obtaining a cookie using a real IP
address and UDP port, and then using it to swamp the victim
with Diffie-Hellman requests from randomly chosen IP
addresses or ports.
1. クッキーは特定のパーティーに頼らなければなりません。 これによって、攻撃者は、本当のIPアドレスとUDPポートを使用することでクッキーを入手して、次に、手当たりしだいに選ばれたIPアドレスかポートからのディフィー-ヘルマンの要求で犠牲者を圧倒するのにそれを使用できません。
2. It must not be possible for anyone other than the issuing
entity to generate cookies that will be accepted by that
entity. This implies that the issuing entity must use local
secret information in the generation and subsequent
verification of a cookie. It must not be possible to deduce
this secret information from any particular cookie.
2. 発行実体以外のだれでもその実体によって受け入れられるクッキーを生成するのは、可能であるはずがありません。 これは、発行実体がクッキーの世代とその後の検証にローカルの秘密の情報を使用しなければならないのを含意します。 どんな特定のクッキーからのこの秘密の情報も推論するのは可能であるはずがありません。
3. The cookie generation function must be fast to thwart
attacks intended to sabotage CPU resources.
3. クッキー世代機能はCPUリソースを故意に妨害することを意図する攻撃を阻むのにおいて速いに違いありません。
Karn's suggested method for creating the cookie is to perform a fast hash (e.g. MD5) over the IP Source and Destination Address, the UDP Source and Destination Ports and a locally generated secret random value. ISAKMP requires that the cookie be unique for each SA establishment to help prevent replay attacks, therefore, the date and time MUST be added to the information hashed. The generated cookies are placed in the ISAKMP Header (described in section 3.1) Initiator
Karnは、クッキーを作成するためのメソッドがIP Source、Destination Address、UDP Source、Destination Ports、および局所的に生成している秘密の無作為の値の上で速いハッシュ(例えば、MD5)を実行することであることを示しました。 ISAKMPは、それぞれのSA設立が、反射攻撃を防ぐのを助けるようにクッキーがユニークであることを必要とします、したがって、論じ尽くされた情報に日時を追加しなければなりません。 発生しているクッキーはISAKMP Header(セクション3.1で、説明される)創始者に置かれます。
Maughan, et. al. Standards Track [Page 20] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[20ページ]。
and Responder cookie fields. These fields are 8 octets in length, thus, requiring a generated cookie to be 8 octets. Notify and Delete messages (see sections 3.14, 3.15, and 4.8) are uni-directional transmissions and are done under the protection of an existing ISAKMP SA, thus, not requiring the generation of a new cookie. One exception to this is the transmission of a Notify message during a Phase 1 exchange, prior to completing the establishment of an SA. Sections 3.14 and 4.8 provide additional details.
そして、Responderクッキー分野。 これらの分野は長さが8つの八重奏であって、その結果、発生しているクッキーが8つの八重奏であることが必要になります。 通知してください、Deleteメッセージ(セクション3.14、3.15、および4.8を見る)をuni方向のトランスミッションであり、既存のISAKMP SAの保護でします、その結果、新しいクッキーを世代に要求しません。 これへの1つの例外がPhase1交換の間のNotifyメッセージの伝達です、SAの設立を終了する前に。 セクション3.14と4.8は追加詳細を明らかにします。
3 ISAKMP Payloads
3 ISAKMP有効搭載量
ISAKMP payloads provide modular building blocks for constructing ISAKMP messages. The presence and ordering of payloads in ISAKMP is defined by and dependent upon the Exchange Type Field located in the ISAKMP Header (see Figure 2). The ISAKMP payload types are discussed in sections 3.4 through 3.15. The descriptions of the ISAKMP payloads, messages, and exchanges (see Section 4) are shown using network octet ordering.
ISAKMPペイロードはISAKMPメッセージを構成するのにモジュールのブロックを提供します。 ISAKMPでのペイロードの存在と注文は、ISAKMP Headerに位置するExchange Type Fieldに定義されていて依存しています(図2を見てください)。 セクション3.4〜3.15でISAKMPペイロードタイプについて議論します。 ISAKMPペイロード、メッセージ、および交換(セクション4を見る)の記述はネットワーク八重奏注文を使用するのが示されます。
3.1 ISAKMP Header Format
3.1 ISAKMPヘッダー形式
An ISAKMP message has a fixed header format, shown in Figure 2, followed by a variable number of payloads. A fixed header simplifies parsing, providing the benefit of protocol parsing software that is less complex and easier to implement. The fixed header contains the information required by the protocol to maintain state, process payloads and possibly prevent denial of service or replay attacks.
ISAKMPメッセージには、可変数のペイロードが支えた図2に示された固定ヘッダー形式があります。 それほど複雑でなくて、より実装しやすいプロトコル構文解析ソフトウェアの利益を提供して、固定ヘッダーは構文解析を簡素化します。 固定ヘッダーは状態を維持して、ペイロードを処理して、ことによるとサービスか反射攻撃の否定を防ぐためにプロトコルによって必要とされた情報を含んでいます。
The ISAKMP Header fields are defined as follows:
ISAKMP Header分野は以下の通り定義されます:
o Initiator Cookie (8 octets) - Cookie of entity that initiated SA
establishment, SA notification, or SA deletion.
o 創始者Cookie(8つの八重奏)--SA設立、SA通知、またはSA削除を開始した実体のクッキー。
o Responder Cookie (8 octets) - Cookie of entity that is responding
to an SA establishment request, SA notification, or SA deletion.
o 応答者Cookie(8つの八重奏)--SA設立要求、SA通知、またはSA削除に応じている実体のクッキー。
Maughan, et. al. Standards Track [Page 21] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[21ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initiator !
! Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Responder !
! Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Message ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
創始者..クッキー..応答者..クッキー; 次..有効搭載量..交換..タイプ..旗..メッセージ..ID..長さ
Figure 2: ISAKMP Header Format
図2: ISAKMPヘッダー形式
o Next Payload (1 octet) - Indicates the type of the first payload
in the message. The format for each payload is defined in
sections 3.4 through 3.16. The processing for the payloads is
defined in section 5.
o 次の有効搭載量(1つの八重奏)--メッセージの最初のペイロードのタイプを示します。 各ペイロードのための書式はセクション3.4〜3.16で定義されます。 ペイロードのための処理はセクション5で定義されます。
Next Payload Type Value
NONE 0
Security Association (SA) 1
Proposal (P) 2
Transform (T) 3
Key Exchange (KE) 4
Identification (ID) 5
Certificate (CERT) 6
Certificate Request (CR) 7
Hash (HASH) 8
Signature (SIG) 9
Nonce (NONCE) 10
Notification (N) 11
Delete (D) 12
Vendor ID (VID) 13
RESERVED 14 - 127
Private USE 128 - 255
Next Payload Type Value NONE 0 Security Association (SA) 1 Proposal (P) 2 Transform (T) 3 Key Exchange (KE) 4 Identification (ID) 5 Certificate (CERT) 6 Certificate Request (CR) 7 Hash (HASH) 8 Signature (SIG) 9 Nonce (NONCE) 10 Notification (N) 11 Delete (D) 12 Vendor ID (VID) 13 RESERVED 14 - 127 Private USE 128 - 255
o Major Version (4 bits) - indicates the major version of the ISAKMP
protocol in use. Implementations based on this version of the
ISAKMP Internet-Draft MUST set the Major Version to 1.
Implementations based on previous versions of ISAKMP Internet-
Drafts MUST set the Major Version to 0. Implementations SHOULD
o 主要なバージョン(4ビット)--ISAKMPプロトコルの主要なバージョンを使用中に示します。 ISAKMPインターネット草稿のこのバージョンに基づく実装はメージャーバージョンを1に設定しなければなりません。 ISAKMPインターネット草稿の旧バージョンに基づいた実装はメージャーバージョンを0に設定しなければなりません。 実装はそうするべきです。
Maughan, et. al. Standards Track [Page 22] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[22ページ]。
never accept packets with a major version number larger than its
own.
メジャーバージョン番号がそれ自身のより大きい状態でパケットを決して受け入れないでください。
o Minor Version (4 bits) - indicates the minor version of the
ISAKMP protocol in use. Implementations based on this version of
the ISAKMP Internet-Draft MUST set the Minor Version to 0.
Implementations based on previous versions of ISAKMP Internet-
Drafts MUST set the Minor Version to 1. Implementations SHOULD
never accept packets with a minor version number larger than its
own, given the major version numbers are identical.
o 小さい方のバージョン(4ビット)--ISAKMPプロトコルの小さい方のバージョンを使用中に示します。 ISAKMPインターネット草稿のこのバージョンに基づく実装はMinorバージョンを0に設定しなければなりません。 ISAKMPインターネット草稿の旧バージョンに基づいた実装はMinorバージョンを1に設定しなければなりません。 マイナーバージョン番号がそれ自身のより大きい状態で実装SHOULDはパケットを決して受け入れないで、考えて、メジャーバージョン番号は同じです。
o Exchange Type (1 octet) - indicates the type of exchange being
used. This dictates the message and payload orderings in the
ISAKMP exchanges.
o 交換Type(1つの八重奏)--使用される交換のタイプを示します。 これはISAKMP交換におけるメッセージとペイロード受注業務を書き取ります。
Exchange Type Value
NONE 0
Base 1
Identity Protection 2
Authentication Only 3
Aggressive 4
Informational 5
ISAKMP Future Use 6 - 31
DOI Specific Use 32 - 239
Private Use 240 - 255
交換タイプはなにも評価しません。0 唯一の3の攻撃的な4情報の5ISAKMP未来の1つの基地のアイデンティティ保護2認証は6--31DOI特定的用法32--239私用240を使用します--、255
o Flags (1 octet) - indicates specific options that are set for the
ISAKMP exchange. The flags listed below are specified in the
Flags field beginning with the least significant bit, i.e the
Encryption bit is bit 0 of the Flags field, the Commit bit is bit
1 of the Flags field, and the Authentication Only bit is bit 2 of
the Flags field. The remaining bits of the Flags field MUST be
set to 0 prior to transmission.
o 旗(1つの八重奏)--ISAKMP交換に設定される特定のオプションを示します。 以下に記載された旗は最下位ビットで始まるFlags分野で指定されます、そして、Encryptionが噛み付いたi.eはFlags分野のビット0です、そして、CommitビットはFlags分野のビット1です、そして、Authentication OnlyビットはFlags分野のビット2です。 トランスミッションの前にFlags分野の残っているビットを0に設定しなければなりません。
-- E(ncryption Bit) (1 bit) - If set (1), all payloads following
the header are encrypted using the encryption algorithm
identified in the ISAKMP SA. The ISAKMP SA Identifier is the
combination of the initiator and responder cookie. It is
RECOMMENDED that encryption of communications be done as soon
as possible between the peers. For all ISAKMP exchanges
described in section 4.1, the encryption SHOULD begin after
both parties have exchanged Key Exchange payloads. If the
E(ncryption Bit) is not set (0), the payloads are not
encrypted.
-- E(ncryption Bit)(1ビット)--(1) 設定されるなら、ヘッダーに続くすべてのペイロードが、ISAKMP SAで特定された暗号化アルゴリズムを使用することで暗号化されています。 ISAKMP SA Identifierは創始者と応答者クッキーの組み合わせです。 できるだけ早く同輩の間でコミュニケーションの暗号化をするのは、RECOMMENDEDです。 セクション4.1で説明されたすべてのISAKMP交換のために、双方がKey Exchangeペイロードを交換した後に暗号化SHOULDは始まります。 E(ncryption Bit)がセット(0)でないなら、ペイロードは暗号化されていません。
Maughan, et. al. Standards Track [Page 23] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[23ページ]。
-- C(ommit Bit) (1 bit) - This bit is used to signal key exchange
synchronization. It is used to ensure that encrypted material
is not received prior to completion of the SA establishment.
The Commit Bit can be set (at anytime) by either party
participating in the SA establishment, and can be used during
both phases of an ISAKMP SA establishment. However, the value
MUST be reset after the Phase 1 negotiation. If set(1), the
entity which did not set the Commit Bit MUST wait for an
Informational Exchange containing a Notify payload (with the
CONNECTED Notify Message) from the entity which set the Commit
Bit. In this instance, the Message ID field of the
Informational Exchange MUST contain the Message ID of the
original ISAKMP Phase 2 SA negotiation. This is done to
ensure that the Informational Exchange with the CONNECTED
Notify Message can be associated with the correct Phase 2 SA.
The receipt and processing of the Informational Exchange
indicates that the SA establishment was successful and either
entity can now proceed with encrypted traffic communication.
In addition to synchronizing key exchange, the Commit Bit can
be used to protect against loss of transmissions over
unreliable networks and guard against the need for multiple
re-transmissions.
-- C(ommit Bit)(1ビット)--このビットは、主要な交換同期に合図するのに使用されます。 それは、暗号化された材料がSA設立の完成の前に受け取られないのを保証するのに使用されます。 Commit BitをSA設立に参加する何れの当事者が用意ができることができて(いつでも)、ISAKMP SA設立の両方の段階の間、使用できます。 しかしながら、Phase1交渉の後に値をリセットしなければなりません。 (1) 設定されるなら、Commit Bitを設定しなかった実体はCommit Bitを設定した実体からNotifyペイロードを含む(CONNECTED Notify Messageと共に)Informational Exchangeを待たなければなりません。 この場合、Informational ExchangeのMessage ID分野はオリジナルのISAKMP Phase2SA交渉のMessage IDを含まなければなりません。 正しいPhase2SAにCONNECTED Notify MessageとInformational Exchangeを関連づけることができるのを保証するためにこれをします。 Informational Exchangeの領収書と処理は、SA設立がうまくいって、どちらの実体も現在暗号化されたトラフィックコミュニケーションを続けることができるのを示します。 主要な交換を同時にさせることに加えて、複数の再トランスミッションの必要性に対して頼り無いネットワークと警備の上のトランスミッションの損失から守るのにCommit Bitを使用できます。
NOTE: It is always possible that the final message of an
exchange can be lost. In this case, the entity expecting to
receive the final message of an exchange would receive the
Phase 2 SA negotiation message following a Phase 1 exchange or
encrypted traffic following a Phase 2 exchange. Handling of
this situation is not standardized, but we propose the
following possibilities. If the entity awaiting the
Informational Exchange can verify the received message (i.e.
Phase 2 SA negotiation message or encrypted traffic), then
they MAY consider the SA was established and continue
processing. The other option is to retransmit the last ISAKMP
message to force the other entity to retransmit the final
message. This suggests that implementations may consider
retaining the last message (locally) until they are sure the
SA is established.
以下に注意してください。 交換の最終的なメッセージを失うことができるのはいつも可能です。 この場合、Phase2交換に続いて、Phase1交換か暗号化されたトラフィックに続いて、交換の最終的なメッセージを受け取るためにはおめでたの予定の実体はPhase2SA交渉メッセージを受け取るでしょう。 この状況の取り扱いは標準化されませんが、私たちは以下の可能性を提案します。 Informational Exchangeを待つ実体が受信されたメッセージ(すなわち、Phase2SA交渉メッセージか暗号化されたトラフィック)について確かめることができるなら、彼らは、SAが設立されたと考えて、処理し続けるかもしれません。 別の選択肢はもう片方の実体に最終的なメッセージを再送させる最後のISAKMPメッセージを再送することです。 これは、実装が、それらがSAが設立されるのを確信するまで(局所的に)最後のメッセージを保有すると考えるかもしれないのを示します。
-- A(uthentication Only Bit) (1 bit) - This bit is intended for
use with the Informational Exchange with a Notify payload and
will allow the transmission of information with integrity
checking, but no encryption (e.g. "emergency mode"). Section
4.8 states that a Phase 2 Informational Exchange MUST be sent
under the protection of an ISAKMP SA. This is the only
exception to that policy. If the Authentication Only bit is
set (1), only authentication security services will be applied
to the entire Notify payload of the Informational Exchange and
-- (uthentication Only Bit)(1ビット)--このビットは、NotifyペイロードがあるInformational Exchangeとの使用のために意図して、保全がチェックしている情報伝送を許容しますが、どんな暗号化(例えば、「非常時のモード」)も許容しないでしょう。 セクション4.8は、ISAKMP SAの保護でPhase2Informational Exchangeを送らなければならないと述べます。 これはその方針への唯一の例外です。 そして認証セキュリティー・サービスだけがAuthentication Onlyビットがセット(1)であるなら、Informational Exchangeの全体のNotifyペイロードに適用される。
Maughan, et. al. Standards Track [Page 24] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[24ページ]。
the payload will not be encrypted.
ペイロードは暗号化されないでしょう。
o Message ID (4 octets) - Unique Message Identifier used to
identify protocol state during Phase 2 negotiations. This value
is randomly generated by the initiator of the Phase 2
negotiation. In the event of simultaneous SA establishments
(i.e. collisions), the value of this field will likely be
different because they are independently generated and, thus, two
security associations will progress toward establishment.
However, it is unlikely there will be absolute simultaneous
establishments. During Phase 1 negotiations, the value MUST be
set to 0.
o メッセージID(4つの八重奏)--ユニークなMessage Identifierは以前はPhase2交渉の間、よくプロトコル状態を特定していました。 この値はPhase2交渉の創始者によって手当たりしだいに生成されます。 同時のSA施設(すなわち、衝突)の場合、それらが独自に生成されるので、この分野の値はおそらく異なるでしょう、そして、その結果、2つのセキュリティ協会が設立に向かって進歩をするでしょう。 しかしながら、絶対同時の施設があるのは、ありそうもないです。 Phase1交渉の間、0に値を設定しなければなりません。
o Length (4 octets) - Length of total message (header + payloads)
in octets. Encryption can expand the size of an ISAKMP message.
o 長さ(4つの八重奏)--八重奏における、総メッセージ(ヘッダー+ペイロード)の長さ。 暗号化はISAKMPメッセージのサイズを広くすることができます。
3.2 Generic Payload Header
3.2 ジェネリック有効搭載量ヘッダー
Each ISAKMP payload defined in sections 3.4 through 3.16 begins with a generic header, shown in Figure 3, which provides a payload "chaining" capability and clearly defines the boundaries of a payload.
セクション3.4〜3.16で定義されたそれぞれのISAKMPペイロードは図3で見せられたジェネリックヘッダーと共に始まります。図は、ペイロード「推論」能力を提供して、明確にペイロードの境界を定義します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 3: Generic Payload Header
図3: ジェネリック有効搭載量ヘッダー
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
the "chaining" capability.
o 次の有効搭載量(1つの八重奏)--メッセージの次のペイロードのペイロードタイプへの識別子。 現在のペイロードがメッセージの最終であるなら、この分野は0になるでしょう。 この分野は「推論」能力を提供します。
o RESERVED (1 octet) - Unused, set to 0.
o RESERVED(1つの八重奏)--未使用であり、0にセットしてください。
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o 有効搭載量Length(2つの八重奏)--ジェネリックペイロードヘッダーを含む現在のペイロードの八重奏における長さ。
3.3 Data Attributes
3.3 データ属性
There are several instances within ISAKMP where it is necessary to represent Data Attributes. An example of this is the Security Association (SA) Attributes contained in the Transform payload
Data Attributesを表すのが必要であるISAKMPの中にいくつかのインスタンスがあります。 この例はTransformペイロードに含まれたSecurity Association(SA)属性です。
Maughan, et. al. Standards Track [Page 25] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[25ページ]。
(described in section 3.6). These Data Attributes are not an ISAKMP payload, but are contained within ISAKMP payloads. The format of the Data Attributes provides the flexibility for representation of many different types of information. There can be multiple Data Attributes within a payload. The length of the Data Attributes will either be 4 octets or defined by the Attribute Length field. This is done using the Attribute Format bit described below. Specific information about the attributes for each domain will be described in a DOI document, e.g. IPSEC DOI [IPDOI].
(セクション3.6で、説明されます。) これらのData AttributesはISAKMPペイロードではありませんが、ISAKMPペイロードの中に含まれています。 Data Attributesの形式は多くの異なったタイプの情報の表現に柔軟性を提供します。 ペイロードの中に複数のData Attributesがあることができます。 Data Attributesの長さは、Attribute Length分野によって4つの八重奏か定義するようにならされるでしょう。 これは以下で説明されたAttribute Formatビットを使用し終わっています。 各ドメインへの属性に関する特殊情報はDOIドキュメント、例えば、IPSEC DOI[IPDOI]で説明されるでしょう。
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! 属性タイプ!AF=0属性の長さF! ! 結果と考える..値..属性値..伝える
Figure 4: Data Attributes
図4: データ属性
The Data Attributes fields are defined as follows:
Data Attributes分野は以下の通り定義されます:
o Attribute Type (2 octets) - Unique identifier for each type of
attribute. These attributes are defined as part of the DOI-
specific information.
o Type(2つの八重奏)を結果と考えてください--それぞれのタイプの属性のためのユニークな識別子。 これらの属性はDOI特殊情報の一部と定義されます。
The most significant bit, or Attribute Format (AF), indicates
whether the data attributes follow the Type/Length/Value (TLV)
format or a shortened Type/Value (TV) format. If the AF bit is a
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.
最も重要なビット、またはAttribute Format(AF)が、データ属性がType/長さ/値(TLV)の形式か短くされたType/値(テレビ)の形式に続くかどうかを示します。 (0) そして、AFビットがゼロであるなら、Data AttributesはType/長さ/値(TLV)のフォームのものです。 AFビットが1つ(1)であるなら、Data AttributesはType/値のフォームのものです。
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 Length(2つの八重奏)を結果と考えてください--Attribute Valueの八重奏における長さ。 AFビットが1つ(1)であるときに、Attribute Valueは2つの八重奏にすぎません、そして、Attribute Length分野は存在していません。
o Attribute Value (variable length) - Value of the attribute
associated with the DOI-specific 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 Value(可変長)を結果と考えてください--DOI特有のAttribute Typeに関連している属性の値。 AFビットがゼロであるなら、(0)、この分野には、Attribute Length分野によって定義された可変長があります。 AFビットが1つ(1)であるなら、Attribute Valueには、2つの八重奏の長さがあります。
Maughan, et. al. Standards Track [Page 26] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[26ページ]。
3.4 Security Association Payload
3.4 セキュリティ協会有効搭載量
The Security Association Payload is used to negotiate security attributes and to indicate the Domain of Interpretation (DOI) and Situation under which the negotiation is taking place. Figure 5 shows the format of the Security Association payload.
Security Association有効搭載量は、セキュリティー属性を交渉して、Interpretation(DOI)と交渉が行われているSituationのDomainを示すのに使用されます。 図5はSecurity Associationペイロードの書式を示しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Situation ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Situation ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Security Association Payload
図5: セキュリティ協会有効搭載量
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 MUST NOT
contain the values for the Proposal or Transform payloads as they
are considered part of the security association negotiation. For
example, this field would contain the value "10" (Nonce payload)
in the first message of a Base Exchange (see Section 4.4) and the
value "0" in the first message of an Identity Protect Exchange
(see Section 4.5).
o 次の有効搭載量(1つの八重奏)--メッセージの次のペイロードのペイロードタイプへの識別子。 現在のペイロードがメッセージの最終であるなら、この分野は0になるでしょう。 それらがセキュリティ協会交渉の一部であると考えられるとき、この分野はProposalかTransformペイロードのための値を含んではいけません。 例えば、この分野が値を含んでいるだろう、「「アイデンティティの最初のメッセージの0インチは交換を保護(セクション4.5を見てください)」という塩基置換(セクション4.4を見る)と価値の最初のメッセージの10インチ(一回だけのペイロード)
o RESERVED (1 octet) - Unused, set to 0.
o RESERVED(1つの八重奏)--未使用であり、0にセットしてください。
o Payload Length (2 octets) - Length in octets of the entire
Security Association payload, including the SA payload, all
Proposal payloads, and all Transform payloads associated with the
proposed Security Association.
o Payload Length (2 octets) - Length in octets of the entire Security Association payload, including the SA payload, all Proposal payloads, and all Transform payloads associated with the proposed Security Association.
o Domain of Interpretation (4 octets) - Identifies the DOI (as
described in Section 2.1) under which this negotiation is taking
place. The DOI is a 32-bit unsigned integer. A DOI value of 0
during a Phase 1 exchange specifies a Generic ISAKMP SA which can
be used for any protocol during the Phase 2 exchange. The
necessary SA Attributes are defined in A.4. A DOI value of 1 is
assigned to the IPsec DOI [IPDOI]. All other DOI values are
reserved to IANA for future use. IANA will not normally assign a
DOI value without referencing some public specification, such as
o Domain of Interpretation (4 octets) - Identifies the DOI (as described in Section 2.1) under which this negotiation is taking place. The DOI is a 32-bit unsigned integer. A DOI value of 0 during a Phase 1 exchange specifies a Generic ISAKMP SA which can be used for any protocol during the Phase 2 exchange. The necessary SA Attributes are defined in A.4. A DOI value of 1 is assigned to the IPsec DOI [IPDOI]. All other DOI values are reserved to IANA for future use. IANA will not normally assign a DOI value without referencing some public specification, such as
Maughan, et. al. Standards Track [Page 27] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 27] RFC 2408 ISAKMP November 1998
an Internet RFC. Other DOI's can be defined using the description
in appendix B. This field MUST be present within the Security
Association payload.
an Internet RFC. Other DOI's can be defined using the description in appendix B. This field MUST be present within the Security Association payload.
o Situation (variable length) - A DOI-specific field that
identifies the situation under which this negotiation is taking
place. The Situation is used to make policy decisions regarding
the security attributes being negotiated. Specifics for the IETF
IP Security DOI Situation are detailed in [IPDOI]. This field
MUST be present within the Security Association payload.
o Situation (variable length) - A DOI-specific field that identifies the situation under which this negotiation is taking place. The Situation is used to make policy decisions regarding the security attributes being negotiated. Specifics for the IETF IP Security DOI Situation are detailed in [IPDOI]. This field MUST be present within the Security Association payload.
3.5 Proposal Payload
3.5 Proposal Payload
The Proposal Payload contains information used during Security Association negotiation. The proposal consists of security mechanisms, or transforms, to be used to secure the communications channel. Figure 6 shows the format of the Proposal Payload. A description of its use can be found in section 4.2.
The Proposal Payload contains information used during Security Association negotiation. The proposal consists of security mechanisms, or transforms, to be used to secure the communications channel. Figure 6 shows the format of the Proposal Payload. A description of its use can be found in section 4.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal # ! Protocol-Id ! SPI Size !# of Transforms!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI (variable) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SPI (variable) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Proposal Payload Format
Figure 6: Proposal Payload Format
The Proposal Payload fields are defined as follows:
The Proposal Payload fields are defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of the
next payload in the message. This field MUST only contain the
value "2" or "0". If there are additional Proposal payloads in
the message, then this field will be 2. If the current Proposal
payload is the last within the security association proposal,
then this field will be 0.
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. This field MUST only contain the value "2" or "0". If there are additional Proposal payloads in the message, then this field will be 2. If the current Proposal payload is the last within the security association proposal, then this field will be 0.
o RESERVED (1 octet) - Unused, set to 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the entire
Proposal payload, including generic payload header, the Proposal
payload, and all Transform payloads associated with this
proposal. In the event there are multiple proposals with the
same proposal number (see section 4.2), the Payload Length field
o Payload Length (2 octets) - Length in octets of the entire Proposal payload, including generic payload header, the Proposal payload, and all Transform payloads associated with this proposal. In the event there are multiple proposals with the same proposal number (see section 4.2), the Payload Length field
Maughan, et. al. Standards Track [Page 28] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 28] RFC 2408 ISAKMP November 1998
only applies to the current Proposal payload and not to all
Proposal payloads.
only applies to the current Proposal payload and not to all Proposal payloads.
o Proposal # (1 octet) - Identifies the Proposal number for the
current payload. A description of the use of this field is found
in section 4.2.
o Proposal # (1 octet) - Identifies the Proposal number for the current payload. A description of the use of this field is found in section 4.2.
o Protocol-Id (1 octet) - Specifies the protocol identifier for the
current negotiation. Examples might include IPSEC ESP, IPSEC AH,
OSPF, TLS, etc.
o Protocol-Id (1 octet) - Specifies the protocol identifier for the current negotiation. Examples might include IPSEC ESP, IPSEC AH, OSPF, TLS, etc.
o SPI Size (1 octet) - Length in octets of the SPI as defined by
the Protocol-Id. In the case of ISAKMP, the Initiator and
Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,
therefore, the SPI Size is irrelevant and MAY be from zero (0) to
sixteen (16). If the SPI Size is non-zero, the content of the
SPI field MUST be ignored. If the SPI Size is not a multiple of
4 octets it will have some impact on the SPI field and the
alignment of all payloads in the message. The Domain of
Interpretation (DOI) will dictate the SPI Size for other
protocols.
o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). If the SPI Size is non-zero, the content of the SPI field MUST be ignored. If the SPI Size is not a multiple of 4 octets it will have some impact on the SPI field and the alignment of all payloads in the message. The Domain of Interpretation (DOI) will dictate the SPI Size for other protocols.
o # of Transforms (1 octet) - Specifies the number of transforms
for the Proposal. Each of these is contained in a Transform
payload.
o # of Transforms (1 octet) - Specifies the number of transforms for the Proposal. Each of these is contained in a Transform payload.
o SPI (variable) - The sending entity's SPI. In the event the SPI
Size is not a multiple of 4 octets, there is no padding applied
to the payload, however, it can be applied at the end of the
message.
o SPI (variable) - The sending entity's SPI. In the event the SPI Size is not a multiple of 4 octets, there is no padding applied to the payload, however, it can be applied at the end of the message.
The payload type for the Proposal Payload is two (2).
The payload type for the Proposal Payload is two (2).
3.6 Transform Payload
3.6 Transform Payload
The Transform Payload contains information used during Security Association negotiation. The Transform payload consists of a specific security mechanism, or transforms, to be used to secure the communications channel. The Transform payload also contains the security association attributes associated with the specific transform. These SA attributes are DOI-specific. Figure 7 shows the format of the Transform Payload. A description of its use can be found in section 4.2.
The Transform Payload contains information used during Security Association negotiation. The Transform payload consists of a specific security mechanism, or transforms, to be used to secure the communications channel. The Transform payload also contains the security association attributes associated with the specific transform. These SA attributes are DOI-specific. Figure 7 shows the format of the Transform Payload. A description of its use can be found in section 4.2.
Maughan, et. al. Standards Track [Page 29] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 29] RFC 2408 ISAKMP November 1998
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform # ! Transform-Id ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ SA 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform # ! Transform-Id ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ SA Attributes ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Transform Payload Format
Figure 7: Transform Payload Format
The Transform Payload fields are defined as follows:
The Transform Payload fields are defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of the
next payload in the message. This field MUST only contain the
value "3" or "0". If there are additional Transform payloads in
the proposal, then this field will be 3. If the current
Transform payload is the last within the proposal, then this
field will be 0.
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. This field MUST only contain the value "3" or "0". If there are additional Transform payloads in the proposal, then this field will be 3. If the current Transform payload is the last within the proposal, then this field will be 0.
o RESERVED (1 octet) - Unused, set to 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header, Transform values,
and all SA Attributes.
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header, Transform values, and all SA Attributes.
o Transform # (1 octet) - Identifies the Transform number for the
current payload. If there is more than one transform proposed
for a specific protocol within the Proposal payload, then each
Transform payload has a unique Transform number. A description
of the use of this field is found in section 4.2.
o Transform # (1 octet) - Identifies the Transform number for the current payload. If there is more than one transform proposed for a specific protocol within the Proposal payload, then each Transform payload has a unique Transform number. A description of the use of this field is found in section 4.2.
o Transform-Id (1 octet) - Specifies the Transform identifier for
the protocol within the current proposal. These transforms are
defined by the DOI and are dependent on the protocol being
negotiated.
o Transform-Id (1 octet) - Specifies the Transform identifier for the protocol within the current proposal. These transforms are defined by the DOI and are dependent on the protocol being negotiated.
o RESERVED2 (2 octets) - Unused, set to 0.
o RESERVED2 (2 octets) - Unused, set to 0.
o SA Attributes (variable length) - This field contains the
security association attributes as defined for the transform
given in the Transform-Id field. The SA Attributes SHOULD be
represented using the Data Attributes format described in section
3.3. If the SA Attributes are not aligned on 4-byte boundaries,
o SA Attributes (variable length) - This field contains the security association attributes as defined for the transform given in the Transform-Id field. The SA Attributes SHOULD be represented using the Data Attributes format described in section 3.3. If the SA Attributes are not aligned on 4-byte boundaries,
Maughan, et. al. Standards Track [Page 30] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 30] RFC 2408 ISAKMP November 1998
then subsequent payloads will not be aligned and any padding will
be added at the end of the message to make the message 4-octet
aligned.
then subsequent payloads will not be aligned and any padding will be added at the end of the message to make the message 4-octet aligned.
The payload type for the Transform Payload is three (3).
The payload type for the Transform Payload is three (3).
3.7 Key Exchange Payload
3.7 Key Exchange Payload
The Key Exchange Payload supports a variety of key exchange techniques. Example key exchanges are Oakley [Oakley], Diffie- Hellman, the enhanced Diffie-Hellman key exchange described in X9.42 [ANSI], and the RSA-based key exchange used by PGP. Figure 8 shows the format of the Key Exchange payload.
The Key Exchange Payload supports a variety of key exchange techniques. Example key exchanges are Oakley [Oakley], Diffie- Hellman, the enhanced Diffie-Hellman key exchange described in X9.42 [ANSI], and the RSA-based key exchange used by PGP. Figure 8 shows the format of the Key Exchange payload.
The Key Exchange Payload fields are defined as follows:
The Key Exchange Payload fields are defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of the
nextpayload in the message. If the current payload is the last
in the message, then this field will be 0.
o Next Payload (1 octet) - Identifier for the payload type of the nextpayload in the message. If the current payload is the last in the message, then this field will be 0.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Key Exchange Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Key Exchange Payload Format
Figure 8: Key Exchange Payload Format
o RESERVED (1 octet) - Unused, set to 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o Key Exchange Data (variable length) - Data required to generate a
session key. The interpretation of this data is specified by the
DOI and the associated Key Exchange algorithm. This field may
also contain pre-placed key indicators.
o Key Exchange Data (variable length) - Data required to generate a session key. The interpretation of this data is specified by the DOI and the associated Key Exchange algorithm. This field may also contain pre-placed key indicators.
The payload type for the Key Exchange Payload is four (4).
The payload type for the Key Exchange Payload is four (4).
Maughan, et. al. Standards Track [Page 31] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 31] RFC 2408 ISAKMP November 1998
3.8 Identification Payload
3.8 Identification Payload
The Identification Payload contains DOI-specific data used to exchange identification information. This information is used for determining the identities of communicating peers and may be used for determining authenticity of information. Figure 9 shows the format of the Identification Payload.
The Identification Payload contains DOI-specific data used to exchange identification information. This information is used for determining the identities of communicating peers and may be used for determining authenticity of information. Figure 9 shows the format of the Identification Payload.
The Identification Payload fields are defined as follows:
The Identification Payload fields are defined as follows:
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.
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.
o RESERVED (1 octet) - Unused, set to 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o ID Type (1 octet) - Specifies the type of Identification being
used.
o ID Type (1 octet) - Specifies the type of Identification being used.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! DOI Specific ID Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! DOI Specific ID Data ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Identification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Identification Payload Format
Figure 9: Identification Payload Format
This field is DOI-dependent.
This field is DOI-dependent.
o DOI Specific ID Data (3 octets) - Contains DOI specific
Identification data. If unused, then this field MUST be set to
0.
o DOI Specific ID Data (3 octets) - Contains DOI specific Identification data. If unused, then this field MUST be set to 0.
o Identification Data (variable length) - Contains identity
information. The values for this field are DOI-specific and the
format is specified by the ID Type field. Specific details for
the IETF IP Security DOI Identification Data are detailed in
[IPDOI].
o Identification Data (variable length) - Contains identity information. The values for this field are DOI-specific and the format is specified by the ID Type field. Specific details for the IETF IP Security DOI Identification Data are detailed in [IPDOI].
Maughan, et. al. Standards Track [Page 32] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 32] RFC 2408 ISAKMP November 1998
The payload type for the Identification Payload is five (5).
The payload type for the Identification Payload is five (5).
3.9 Certificate Payload
3.9 Certificate Payload
The Certificate Payload provides a means to transport certificates or other certificate-related information via ISAKMP and can appear in any ISAKMP message. Certificate payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. The Certificate payload MUST be accepted at any point during an exchange. Figure 10 shows the format of the Certificate Payload.
The Certificate Payload provides a means to transport certificates or other certificate-related information via ISAKMP and can appear in any ISAKMP message. Certificate payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. The Certificate payload MUST be accepted at any point during an exchange. Figure 10 shows the format of the Certificate Payload.
NOTE: Certificate types and formats are not generally bound to a DOI - it is expected that there will only be a few certificate types, and that most DOIs will accept all of these types.
NOTE: Certificate types and formats are not generally bound to a DOI - it is expected that there will only be a few certificate types, and that most DOIs will accept all of these types.
The Certificate Payload fields are defined as follows:
The Certificate Payload fields are defined as follows:
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.
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.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Cert Encoding ! ! +-+-+-+-+-+-+-+-+ ! ~ Certificate Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Certificate Payload Format
Figure 10: Certificate Payload Format
o RESERVED (1 octet) - Unused, set to 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o Certificate Encoding (1 octet) - This field indicates the type of
certificate or certificate-related information contained in the
Certificate Data field.
o Certificate Encoding (1 octet) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field.
Maughan, et. al. Standards Track [Page 33] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 33] RFC 2408 ISAKMP November 1998
Certificate Type Value
NONE 0
PKCS #7 wrapped X.509 certificate 1
PGP Certificate 2
DNS Signed Key 3
X.509 Certificate - Signature 4
X.509 Certificate - Key Exchange 5
Kerberos Tokens 6
Certificate Revocation List (CRL) 7
Authority Revocation List (ARL) 8
SPKI Certificate 9
X.509 Certificate - Attribute 10
RESERVED 11 - 255
Certificate Type Value NONE 0 PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 X.509 Certificate - Signature 4 X.509 Certificate - Key Exchange 5 Kerberos Tokens 6 Certificate Revocation List (CRL) 7 Authority Revocation List (ARL) 8 SPKI Certificate 9 X.509 Certificate - Attribute 10 RESERVED 11 - 255
o Certificate Data (variable length) - Actual encoding of
certificate data. The type of certificate is indicated by the
Certificate Encoding field.
o Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Encoding field.
The payload type for the Certificate Payload is six (6).
The payload type for the Certificate Payload is six (6).
3.10 Certificate Request Payload
3.10 Certificate Request Payload
The Certificate Request Payload provides a means to request certificates via ISAKMP and can appear in any message. Certificate Request payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. The Certificate Request payload MUST be accepted at any point during the exchange. The responder to the Certificate Request payload MUST send its certificate, if certificates are supported, based on the values contained in the payload. If multiple certificates are required, then multiple Certificate Request payloads SHOULD be transmitted. Figure 11 shows the format of the Certificate Request Payload.
The Certificate Request Payload provides a means to request certificates via ISAKMP and can appear in any message. Certificate Request payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. The Certificate Request payload MUST be accepted at any point during the exchange. The responder to the Certificate Request payload MUST send its certificate, if certificates are supported, based on the values contained in the payload. If multiple certificates are required, then multiple Certificate Request payloads SHOULD be transmitted. Figure 11 shows the format of the Certificate Request Payload.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert. Type ! !
+-+-+-+-+-+-+-+-+ !
~ Certificate 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Cert. Type ! ! +-+-+-+-+-+-+-+-+ ! ~ Certificate Authority ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Certificate Request Payload Format
Figure 11: Certificate Request Payload Format
Maughan, et. al. Standards Track [Page 34] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 34] RFC 2408 ISAKMP November 1998
The Certificate Payload fields are defined as follows:
The Certificate Payload fields are defined as follows:
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.
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.
o RESERVED (1 octet) - Unused, set to 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o Certificate Type (1 octet) - Contains an encoding of the type of
certificate requested. Acceptable values are listed in section
3.9.
o Certificate Type (1 octet) - Contains an encoding of the type of certificate requested. Acceptable values are listed in section 3.9.
o Certificate Authority (variable length) - Contains an encoding of
an acceptable certificate authority for the type of certificate
requested. As an example, for an X.509 certificate this field
would contain the Distinguished Name encoding of the Issuer Name
of an X.509 certificate authority acceptable to the sender of
this payload. This would be included to assist the responder in
determining how much of the certificate chain would need to be
sent in response to this request. If there is no specific
certificate authority requested, this field SHOULD not be
included.
o Certificate Authority (variable length) - Contains an encoding of an acceptable certificate authority for the type of certificate requested. As an example, for an X.509 certificate this field would contain the Distinguished Name encoding of the Issuer Name of an X.509 certificate authority acceptable to the sender of this payload. This would be included to assist the responder in determining how much of the certificate chain would need to be sent in response to this request. If there is no specific certificate authority requested, this field SHOULD not be included.
The payload type for the Certificate Request Payload is seven (7).
The payload type for the Certificate Request Payload is seven (7).
Maughan, et. al. Standards Track [Page 35] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 35] RFC 2408 ISAKMP November 1998
3.11 Hash Payload
3.11 Hash Payload
The Hash Payload contains data generated by the hash function (selected during the SA establishment exchange), over some part of the message and/or ISAKMP state. This payload may be used to verify the integrity of the data in an ISAKMP message or for authentication of the negotiating entities. Figure 12 shows the format of the Hash Payload.
The Hash Payload contains data generated by the hash function (selected during the SA establishment exchange), over some part of the message and/or ISAKMP state. This payload may be used to verify the integrity of the data in an ISAKMP message or for authentication of the negotiating entities. Figure 12 shows the format of the Hash Payload.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Hash 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Hash Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Hash Payload Format
Figure 12: Hash Payload Format
The Hash Payload fields are defined as follows:
The Hash Payload fields are defined as follows:
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.
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.
o RESERVED (1 octet) - Unused, set to 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o Hash Data (variable length) - Data that results from applying the
hash routine to the ISAKMP message and/or state.
o Hash Data (variable length) - Data that results from applying the hash routine to the ISAKMP message and/or state.
Maughan, et. al. Standards Track [Page 36] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 36] RFC 2408 ISAKMP November 1998
3.12 Signature Payload
3.12 Signature Payload
The Signature Payload contains data generated by the digital signature function (selected during the SA establishment exchange), over some part of the message and/or ISAKMP state. This payload is used to verify the integrity of the data in the ISAKMP message, and may be of use for non-repudiation services. Figure 13 shows the format of the Signature Payload.
The Signature Payload contains data generated by the digital signature function (selected during the SA establishment exchange), over some part of the message and/or ISAKMP state. This payload is used to verify the integrity of the data in the ISAKMP message, and may be of use for non-repudiation services. Figure 13 shows the format of the Signature Payload.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Signature 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Signature Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Signature Payload Format
Figure 13: Signature Payload Format
The Signature Payload fields are defined as follows:
The Signature Payload fields are defined as follows:
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.
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.
o RESERVED (1 octet) - Unused, set to 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o Signature Data (variable length) - Data that results from
applying the digital signature function to the ISAKMP message
and/or state.
o Signature Data (variable length) - Data that results from applying the digital signature function to the ISAKMP message and/or state.
The payload type for the Signature Payload is nine (9).
The payload type for the Signature Payload is nine (9).
3.13 Nonce Payload
3.13 Nonce Payload
The Nonce Payload contains random data used to guarantee liveness during an exchange and protect against replay attacks. Figure 14 shows the format of the Nonce Payload. If nonces are used by a particular key exchange, the use of the Nonce payload will be dictated by the key exchange. The nonces may be transmitted as part of the key exchange data, or as a separate payload. However, this is defined by the key exchange, not by ISAKMP.
The Nonce Payload contains random data used to guarantee liveness during an exchange and protect against replay attacks. Figure 14 shows the format of the Nonce Payload. If nonces are used by a particular key exchange, the use of the Nonce payload will be dictated by the key exchange. The nonces may be transmitted as part of the key exchange data, or as a separate payload. However, this is defined by the key exchange, not by ISAKMP.
Maughan, et. al. Standards Track [Page 37] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 37] RFC 2408 ISAKMP November 1998
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Nonce Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Nonce Payload Format
Figure 14: Nonce Payload Format
The Nonce Payload fields are defined as follows:
The Nonce Payload fields are defined as follows:
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.
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.
o RESERVED (1 octet) - Unused, set to 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o Nonce Data (variable length) - Contains the random data generated
by the transmitting entity.
o Nonce Data (variable length) - Contains the random data generated by the transmitting entity.
The payload type for the Nonce Payload is ten (10).
The payload type for the Nonce Payload is ten (10).
3.14 Notification Payload
3.14 Notification Payload
The Notification Payload can contain both ISAKMP and DOI-specific data and is used to transmit informational data, such as error conditions, to an ISAKMP peer. It is possible to send multiple Notification payloads in a single ISAKMP message. Figure 15 shows the format of the Notification Payload.
Notification有効搭載量は、ISAKMPとDOI特有のデータの両方を含むことができて、情報のデータを送るのに使用されます、エラー条件などのように、ISAKMP同輩に。 ただ一つのISAKMPメッセージで複数のNotificationペイロードを送るのは可能です。 図15はNotification有効搭載量の書式を示しています。
Notification which occurs during, or is concerned with, a Phase 1 negotiation is identified by the Initiator and Responder cookie pair in the ISAKMP Header. The Protocol Identifier, in this case, is ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP Header identifies the ISAKMP SA. If the notification takes place prior to the completed exchange of keying information, then the notification will be unprotected.
どれがPhase1交渉がInitiatorによって特定されることを起こって、心配しているか、そして、ResponderクッキーがISAKMP Headerで対にする通知。 この場合プロトコルIdentifierはISAKMPです、そして、ISAKMP Headerのクッキー組がISAKMP SAを特定するので、SPI値は0です。 通知が合わせる情報の完成した交換の前に行われると、通知は保護がなくなるでしょう。
Maughan, et. al. Standards Track [Page 38] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[38ページ]。
Notification which occurs during, or is concerned with, a Phase 2 negotiation is identified by the Initiator and Responder cookie pair in the ISAKMP Header and the Message ID and SPI associated with the current negotiation. One example for this type of notification is to indicate why a proposal was rejected.
通知のどれがPhase2交渉がISAKMP HeaderとMessage IDのInitiatorとResponderクッキー組によって特定されることを起こって、心配しているか、そして、SPIは現在の交渉と交際しました。 このタイプに関する通知のための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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Notification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
次..有効搭載量..予約..ペイロード長..ドメイン..解釈; プロトコルID!SPIサイズ!はメッセージタイプ!+++++++++++++++++++++++++++++++++に通知します!~セキュリティパラメタが(SPI!)~ +++++++++++++++++++++++++++++++++! ~、に索引をつける、通知データ~!+++++++++++++++++++++++++++++++++
Figure 15: Notification Payload Format
図15: 通知有効搭載量形式
The Notification Payload fields are defined as follows:
Notification有効搭載量分野は以下の通り定義されます:
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.
o 次の有効搭載量(1つの八重奏)--メッセージの次のペイロードのペイロードタイプへの識別子。 現在のペイロードがメッセージの最終であるなら、この分野は0になるでしょう。
o RESERVED (1 octet) - Unused, set to 0.
o RESERVED(1つの八重奏)--未使用であり、0にセットしてください。
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o 有効搭載量Length(2つの八重奏)--ジェネリックペイロードヘッダーを含む現在のペイロードの八重奏における長さ。
o Domain of Interpretation (4 octets) - Identifies the DOI (as
described in Section 2.1) under which this notification is taking
place. For ISAKMP this value is zero (0) and for the IPSEC DOI
it is one (1). Other DOI's can be defined using the description
in appendix B.
o Interpretation(4つの八重奏)のドメイン--この通知が行われているDOI(セクション2.1で説明されるように)を特定します。 ISAKMPに関しては、この値は(0)ではありません、そして、IPSEC DOIに関して、それは1つ(1)です。 付録Bで記述を使用することでDOIの他のものを定義できます。
o Protocol-Id (1 octet) - Specifies the protocol identifier for the
current notification. Examples might include ISAKMP, IPSEC ESP,
IPSEC AH, OSPF, TLS, etc.
o プロトコルイド(1つの八重奏)--現在の通知のためのプロトコル識別子を指定します。 例はISAKMP、IPSEC ESP、IPSEC AH、OSPF、TLSなどを含むかもしれません。
Maughan, et. al. Standards Track [Page 39] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[39ページ]。
o SPI Size (1 octet) - Length in octets of the SPI as defined by
the Protocol-Id. In the case of ISAKMP, the Initiator and
Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,
therefore, the SPI Size is irrelevant and MAY be from zero (0) to
sixteen (16). If the SPI Size is non-zero, the content of the
SPI field MUST be ignored. The Domain of Interpretation (DOI)
will dictate the SPI Size for other protocols.
o SPI Size(1つの八重奏)--Protocolアイダホ州の定義されるとしてのSPIの八重奏における長さ ISAKMPの場合では、ISAKMP HeaderからのInitiatorとResponderクッキー組がISAKMP SPIであり、したがって、SPI Sizeは無関係であり、どんな(0)からも16(16)に来ていないかもしれません。 SPI Sizeが非ゼロであるなら、SPI分野の内容を無視しなければなりません。 Interpretation(DOI)のDomainは他のプロトコルのためにSPI Sizeを書き取るでしょう。
o Notify Message Type (2 octets) - Specifies the type of
notification message (see section 3.14.1). Additional text, if
specified by the DOI, is placed in the Notification Data field.
o Message Type(2つの八重奏)に通知してください。--通知メッセージ(セクション3.14.1を見る)のタイプを指定します。 DOIによって指定されるなら、追加テキストはNotification Data分野に置かれます。
o SPI (variable length) - Security Parameter Index. The receiving
entity's SPI. The use of the SPI field is described in section
2.4. The length of this field is determined by the SPI Size
field and is not necessarily aligned to a 4 octet boundary.
o SPI(可変長)--セキュリティParameter Index。 受信実体のSPI。 SPI分野の使用はセクション2.4で説明されます。 この分野の長さは、SPI Size分野のそばで断固として、必ず4八重奏境界に並べられるというわけではありません。
o Notification Data (variable length) - Informational or error data
transmitted in addition to the Notify Message Type. Values for
this field are DOI-specific.
o 通知Data(可変長)--情報か誤りデータはNotify Message Typeに加えて送られました。 この分野への値はDOI特有です。
The payload type for the Notification Payload is eleven (11).
Notification有効搭載量のためのペイロードタイプは11(11)です。
3.14.1 Notify Message Types
3.14.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. For example, a secure front end or security gateway may use the Notify message to synchronize SA communication. The table below lists the Nofitication messages and their corresponding values. Values in the Private Use range are expected to be DOI-specific values.
通知情報はなぜSAを設立できなかったかを指定するエラーメッセージであるかもしれません。 また、SAデータベースを管理するプロセスが同輩プロセスで交信したがっているのは、状態データであるかもしれません。 例えば、安全なフロントエンドかセキュリティゲートウェイがSAコミュニケーションを同期させるNotifyメッセージを使用するかもしれません。 以下のテーブルはNofiticationメッセージとそれらの換算値をリストアップします。 兵士のUse範囲の値はDOI特有の値であると予想されます。
NOTIFY MESSAGES - ERROR TYPES
メッセージに通知してください--誤りタイプ
Errors Value
INVALID-PAYLOAD-TYPE 1
DOI-NOT-SUPPORTED 2
SITUATION-NOT-SUPPORTED 3
INVALID-COOKIE 4
INVALID-MAJOR-VERSION 5
INVALID-MINOR-VERSION 6
INVALID-EXCHANGE-TYPE 7
INVALID-FLAGS 8
INVALID-MESSAGE-ID 9
INVALID-PROTOCOL-ID 10
INVALID-SPI 11
誤りは1無効のペイロードタイプサポートされなかったサポートされなかった土井2状況3無効のクッキー4無効の主要なバージョン5無効の小さい方のバージョン6無効の交換タイプ7無効の旗の8無効のMESSAGE ID9無効のPROTOCOL ID10無効のSPI11を評価します。
Maughan, et. al. Standards Track [Page 40] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[40ページ]。
INVALID-TRANSFORM-ID 12
ATTRIBUTES-NOT-SUPPORTED 13
NO-PROPOSAL-CHOSEN 14
BAD-PROPOSAL-SYNTAX 15
PAYLOAD-MALFORMED 16
INVALID-KEY-INFORMATION 17
INVALID-ID-INFORMATION 18
INVALID-CERT-ENCODING 19
INVALID-CERTIFICATE 20
CERT-TYPE-UNSUPPORTED 21
INVALID-CERT-AUTHORITY 22
INVALID-HASH-INFORMATION 23
AUTHENTICATION-FAILED 24
INVALID-SIGNATURE 25
ADDRESS-NOTIFICATION 26
NOTIFY-SA-LIFETIME 27
CERTIFICATE-UNAVAILABLE 28
UNSUPPORTED-EXCHANGE-TYPE 29
UNEQUAL-PAYLOAD-LENGTHS 30
RESERVED (Future Use) 31 - 8191
Private Use 8192 - 16383
本命がサポートされない状態でタイプであっているので選ばれなかったNOTがサポートした無効のTRANSFORM IDの12の属性13提案の全く15のペイロード奇形の16 17 18無効の本命コード化14悪い提案構文無効の主要な情報無効のID情報19が20を病人と同じくらい証明する、21の無効の本命権威; 22 無効のハッシュ情報23SA生涯に通知している25の26 27証明書入手できない28 29不平等なペイロード長アドレス通知サポートされない交換タイプ30が控えた認証で失敗した24無効の署名(今後の使用)31--8191私用8192--16383
NOTIFY MESSAGES - STATUS TYPES
Status Value
CONNECTED 16384
RESERVED (Future Use) 16385 - 24575
DOI-specific codes 24576 - 32767
Private Use 32768 - 40959
RESERVED (Future Use) 40960 - 65535
NOTIFY MESSAGES--16385--24575のSTATUS TYPES Status Value CONNECTED16384RESERVED(将来のUse)のDOI特有のコード24576--32767兵士のUse32768--40959RESERVED(将来のUse)40960--65535
3.15 Delete Payload
3.15は有効搭載量を削除します。
The Delete Payload contains a protocol-specific security association identifier that the sender has removed from its security association database and is, therefore, no longer valid. Figure 16 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 with the Delete payload.
Delete有効搭載量は、送付者がセキュリティ協会データベースから取り除いたプロトコル特有のセキュリティ協会識別子を含んでいて、したがって、もう有効ではありません。 図16はDelete有効搭載量の書式を示しています。 各SPI MUSTがしかしながら、Deleteペイロードで複数のSPIsを送るためには、そうであることは同じプロトコルのために可能です。 DeleteペイロードでプロトコルIdentifiersの混合を実行してはいけません。
Deletion which is concerned with an ISAKMP SA will contain a Protocol-Id of ISAKMP and the SPIs are the initiator and responder cookies from the ISAKMP Header. Deletion which is concerned with a Protocol SA, such as ESP or AH, will contain the Protocol-Id of that protocol (e.g. ESP, AH) and the SPI is the sending entity's SPI(s).
SPIsはISAKMP HeaderからのISAKMP SAに関する削除がISAKMPのプロトコルイドを含んで、創始者と応答者クッキーです。 超能力かAHなどのSAがそのプロトコル(例えば、超能力、AH)のプロトコルイドとSPIを含むことをプロトコルに心配させる削除は送付実体のSPI(s)です。
Maughan, et. al. Standards Track [Page 41] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[41ページ]。
NOTE: The Delete Payload is not a request for the responder to delete an SA, but an advisory from the initiator to the responder. If the responder chooses to ignore the message, the next communication from the responder to the initiator, using that security association, will fail. A responder is not expected to acknowledge receipt of a Delete payload.
以下に注意してください。 創始者から応答者までDelete有効搭載量は応答者がSAを削除するという要求ではなく、状況報告です。 応答者が、メッセージを無視するのを選ぶと、そのセキュリティ協会を使用して、次の応答者から創始者までのコミュニケーションは失敗するでしょう。 応答者が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 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!ペイロード長!+++++++++++++++++++++++++++++++++! 解釈(DOI)のドメインを予約しました!; プロトコル..イド..サイズ..セキュリティ..パラメタ..インデックス
Figure 16: Delete Payload Format
図16: 有効搭載量書式を削除してください。
The Delete Payload fields are defined as follows:
Delete有効搭載量分野は以下の通り定義されます:
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.
o 次の有効搭載量(1つの八重奏)--メッセージの次のペイロードのペイロードタイプへの識別子。 現在のペイロードがメッセージの最終であるなら、この分野は0になるでしょう。
o RESERVED (1 octet) - Unused, set to 0.
o RESERVED(1つの八重奏)--未使用であり、0にセットしてください。
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o 有効搭載量Length(2つの八重奏)--ジェネリックペイロードヘッダーを含む現在のペイロードの八重奏における長さ。
o Domain of Interpretation (4 octets) - Identifies the DOI (as
described in Section 2.1) under which this deletion is taking
place. For ISAKMP this value is zero (0) and for the IPSEC DOI
it is one (1). Other DOI's can be defined using the description
in appendix B.
o Interpretation(4つの八重奏)のドメイン--この削除が行われているDOI(セクション2.1で説明されるように)を特定します。 ISAKMPに関しては、この値は(0)ではありません、そして、IPSEC DOIに関して、それは1つ(1)です。 付録Bで記述を使用することでDOIの他のものを定義できます。
o Protocol-Id (1 octet) - ISAKMP can establish security
associations for various protocols, including ISAKMP and IPSEC.
This field identifies which security association database to
apply the delete request.
o プロトコルイド(1つの八重奏)--ISAKMPはISAKMPとIPSECを含む様々なプロトコルのためにセキュリティ協会を設立できます。 この分野が、どのセキュリティ協会データベースを適用したらよいかを特定する、要求を削除してください。
Maughan, et. al. Standards Track [Page 42] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[42ページ]。
o SPI Size (1 octet) - Length in octets of the SPI as defined by
the Protocol-Id. In the case of ISAKMP, the Initiator and
Responder cookie pair is the ISAKMP SPI. In this case, the SPI
Size would be 16 octets for each SPI being deleted.
o SPI Size(1つの八重奏)--Protocolアイダホ州の定義されるとしてのSPIの八重奏における長さ ISAKMPの場合では、InitiatorとResponderクッキー組はISAKMP SPIです。 この場合、削除される各SPIあたりSPI Sizeは16の八重奏でしょう。
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. Values for this
field are DOI and protocol specific. The length of this field is
determined by the SPI Size and # of SPIs fields.
o セキュリティParameter Index(es)(可変長)--削除する特定のセキュリティ協会を特定します。 この分野への値はDOIとプロトコル特有です。 この分野の長さはSPIs分野のSPI Sizeと#によって測定されます。
The payload type for the Delete Payload is twelve (12).
Delete有効搭載量のためのペイロードタイプは12(12)です。
3.16 Vendor ID Payload
3.16 ベンダーID有効搭載量
The Vendor ID Payload 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 backwards compatibility. This is not a general extension facility of ISAKMP. Figure 17 shows the format of the Vendor ID Payload.
Vendor ID有効搭載量はベンダーの定義された定数を含んでいます。 定数は、それらの実装のリモートインスタンスを特定して、認識するのにベンダーによって使用されます。 このメカニズムで、ベンダーは後方に互換性を維持している間、新機能を実験できます。 これはISAKMPの一般的な拡大施設ではありません。 図17はVendor ID有効搭載量の書式を示しています。
The Vendor ID payload is not an announcement from the sender that it will send private payload types. A vendor sending the Vendor ID MUST not make any assumptions about private payloads that it may send unless a Vendor ID is received as well. Multiple Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to understand any Vendor ID payloads. An implementation is NOT REQUIRED to send any Vendor ID payload at all. If a private payload was sent without prior agreement to send it, a compliant implementation may reject a proposal with a notify message of type INVALID-PAYLOAD-TYPE.
Vendor IDペイロードは送付者からの個人的なペイロードタイプを送るという発表ではありません。 Vendor IDがまた、受け取られない場合、Vendor IDを送るベンダーはそれが送るかもしれない個人的なペイロードに関する少しの仮定もしてはいけません。 複数のVendor IDペイロードを送るかもしれません。 実装はどんなVendor IDペイロードも理解するNOT REQUIREDです。 実装は全くどんなVendor IDペイロードも送るNOT REQUIREDです。 個人的なペイロードを送ったなら、それを送るために、対応する実装がaで申し込みを拒絶するかもしれないという事前同意がなければ、タイプINVALID有効搭載量TYPEに関するメッセージに通知してください。
If a Vendor ID payload is sent, it MUST be sent during the Phase 1 negotiation. Reception of a familiar Vendor ID payload in the Phase 1 negotiation allows an implementation to make use of Private USE payload numbers (128-255), described in section 3.1 for vendor specific extensions during Phase 2 negotiations. The definition of "familiar" is left to implementations to determine. Some vendors may wish to implement another vendor's extension prior to standardization. However, this practice SHOULD not be widespread and vendors should work towards standardization instead.
Vendor IDペイロードを送るなら、Phase1交渉の間、それを送らなければなりません。 Phase1交渉における、身近なVendor IDペイロードのレセプションで、実装はベンダーの特定の拡大のためにPhase2交渉の間にセクション3.1で説明された兵士のUSEペイロード番号(128-255)を利用できます。 「なじみ深いこと」の定義が決定するのが実装に残されます。 標準化の前に別のベンダーの拡大を実装したがっているかもしれないベンダーもあります。 しかしながら、これがSHOULDを練習する、広範囲にしてください、そして、ベンダーは代わりに標準化をめざして努力するべきです。
The vendor defined constant MUST be unique. The choice of hash and text to hash is left to the vendor to decide. As an example, vendors could generate their vendor id by taking a plain (non-keyed) hash of a string containing the product name, and the version of the product.
ベンダーの定義された定数はユニークであるに違いありません。 論じ尽くすハッシュとテキストの選択が決めるのがベンダーに残されます。 例として、ベンダーは、製品名を含むストリングの明瞭な(非合わせられた)ハッシュ、および製品のバージョンを取ることによって、それらのベンダーイドを生成することができるでしょう。
Maughan, et. al. Standards Track [Page 43] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[43ページ]。
A hash is used instead of a vendor registry to avoid local cryptographic policy problems with having a list of "approved" products, to keep away from maintaining a list of vendors, and to allow classified products to avoid having to appear on any list. For instance:
ハッシュは、ベンダー登録の代わりに「承認された」製品のリストを持つことに関するローカルの暗号の方針問題を避けて、ベンダーのリストを維持するのから遠ざけて、分類された製品が、どんなリストにも現れなければならないのを避けるのを許容するのに使用されます。 例えば:
"Example Company IPsec. Version 97.1"
「例のIPsec会社。」 バージョン97.1インチ
(not including the quotes) has MD5 hash: 48544f9b1fe662af98b9b39e50c01a5a, when using MD5file. Vendors may include all of the hash, or just a portion of it, as the payload length will bound the data. There are no security implications of this hash, so its choice is arbitrary.
(引用文を含んでいません)には、MD5ハッシュがあります: MD5fileを使用するときの48544f9b1fe662af98b9b39e50c01a5a。 ベンダーはハッシュのすべて、またはまさしくそれの部分を含めるかもしれません、ペイロード長がバウンドにデータを望んでいるとき。 このハッシュのセキュリティ含意が全くないので、選択は任意です。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Vendor ID (VID) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
次..有効搭載量..予約..ペイロード長..ベンダー..ID
Figure 17: Vendor ID Payload Format
図17: ベンダーID有効搭載量形式
The Vendor ID Payload fields are defined as follows:
Vendor ID有効搭載量分野は以下の通り定義されます:
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.
o 次の有効搭載量(1つの八重奏)--メッセージの次のペイロードのペイロードタイプへの識別子。 現在のペイロードがメッセージの最終であるなら、この分野は0になるでしょう。
o RESERVED (1 octet) - Unused, set to 0.
o RESERVED(1つの八重奏)--未使用であり、0にセットしてください。
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o 有効搭載量Length(2つの八重奏)--ジェネリックペイロードヘッダーを含む現在のペイロードの八重奏における長さ。
o Vendor ID (variable length) - Hash of the vendor string plus
version (as described above).
o ベンダーID(可変長)--ベンダーストリングとバージョン(上で説明されるように)のハッシュ。
The payload type for the Vendor ID Payload is thirteen (13).
Vendor ID有効搭載量のためのペイロードタイプは13(13)です。
4 ISAKMP Exchanges
4 ISAKMP交換
ISAKMP supplies the basic syntax of a message exchange. The basic building blocks for ISAKMP messages are the payload types described in section 3. This section describes the procedures for SA
ISAKMPは交換処理の基本的な構文を供給します。 ISAKMPメッセージのための基本的なブロックはセクション3で説明されたペイロードタイプです。 このセクションはSAのために手順について説明します。
Maughan, et. al. Standards Track [Page 44] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[44ページ]。
establishment and SA modification, followed by a default set of exchanges that MAY be used for initial interoperability. Other exchanges will be defined depending on the DOI and key exchange. [IPDOI] and [IKE] are examples of how this is achieved. Appendix B explains the procedures for accomplishing these additions.
初期の相互運用性に使用されるかもしれない交換のデフォルトセットによって続かれた設立とSA変更。 DOIと主要な交換によって、他の交換は定義されるでしょう。 [IPDOI]と[IKE]はこれがどう達成されるかに関する例です。 付録Bで、これらの追加を達成するための手順がわかります。
4.1 ISAKMP Exchange Types
4.1 ISAKMP交換タイプ
ISAKMP allows the creation of exchanges for the establishment of Security Associations and keying material. There are currently five default Exchange Types defined for ISAKMP. Sections 4.4 through 4.8 describe these exchanges. Exchanges define the content and ordering of ISAKMP messages during communications between peers. Most exchanges will include all the basic payload types - SA, KE, ID, SIG - and may include others. The primary difference between exchange types is the ordering of the messages and the payload ordering within each message. While the ordering of payloads within messages is not mandated, for processing efficiency it is RECOMMENDED that the Security Association payload be the first payload within an exchange. Processing of each payload within an exchange is described in section 5.
ISAKMPはSecurity Associationsと合わせることの材料の設立への交換の作成を許容します。 現在、ISAKMPのために定義された5デフォルトExchange Typesがあります。 セクション4.4〜4.8はこれらの交換について説明します。 交換は同輩のコミュニケーションの間、ISAKMPメッセージの内容と注文を定義します。 ほとんどの交換が、すべての基本的なペイロードタイプ(SA、KE、ID SIG)を含んで、他のものを含むかもしれません。 交換タイプのプライマリ違いは各メッセージの中で注文されるメッセージとペイロードの注文です。 メッセージの中のペイロードの注文を強制しませんが、処理効率のために、Security Associationペイロードが交換の中の最初のペイロードであることはRECOMMENDEDです。 交換の中のそれぞれのペイロードの処理はセクション5で説明されます。
Sections 4.4 through 4.8 provide a default set of ISAKMP exchanges. These exchanges provide different security protection for the exchange itself and information exchanged. The diagrams in each of the following sections show the message ordering for each exchange type as well as the payloads included in each message, and provide basic notes describing what has happened after each message exchange. None of the examples include any "optional payloads", like certificate and certificate request. Additionally, none of the examples include an initial exchange of ISAKMP Headers (containing initiator and responder cookies) which would provide protection against clogging (see section 2.5.3).
セクション4.4〜4.8はISAKMP交換のデフォルトセットを提供します。 これらの交換はそれ自体と情報が交換した交換のための異なった機密保持を提供します。 それぞれの以下のセクションのダイヤグラムは、それぞれの交換タイプのために注文して、各メッセージにペイロードを含んでいて、メッセージを示していて、何が各交換処理の後に起こったかを説明する基本の注意を提供します。 例のいずれも証明書と証明書要求のようにどんな「任意のペイロード」も含んでいません。 さらに、例のいずれも目詰まりに対する保護を提供するISAKMP Headers(創始者と応答者クッキーを含んでいる)の初期の交換を含んでいません(セクション2.5.3を見てください)。
The defined exchanges are not meant to satisfy all DOI and key exchange protocol requirements. If the defined exchanges meet the DOI requirements, then they can be used as outlined. If the defined exchanges do not meet the security requirements defined by the DOI, then the DOI MUST specify new exchange type(s) and the valid sequences of payloads that make up a successful exchange, and how to build and interpret those payloads. All ISAKMP implementations MUST implement the Informational Exchange and SHOULD implement the other four exchanges. However, this is dependent on the definition of the DOI and associated key exchange protocols.
定義された交換はすべてのDOIと主要な交換プロトコル要件を満たすことになっていません。 定義された交換がDOI必要条件を満たすなら、概説されているようにそれらを使用できます。 定義された交換がDOIによって定義されたセキュリティ必要条件を満たさないなら、土井はそれらのペイロードをうまくいっている交換を作るペイロードと、造って、どう解釈するかに関する新しい交換タイプと有効な系列を指定しなければなりません。 すべてのISAKMP実装がInformational Exchangeを実装しなければなりません、そして、SHOULDは他の4回の交換を実装します。 しかしながら、これはDOIと関連主要な交換プロトコルの定義に依存しています。
Maughan, et. al. Standards Track [Page 45] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[45ページ]。
As discussed above, these exchange types can be used in either phase of negotiation. However, they may provide different security properties in each of the phases. With each of these exchanges, the combination of cookies and SPI fields identifies whether this exchange is being used in the first or second phase of a negotiation.
上で議論するように、交渉のどちらのフェーズにもこれらの交換タイプを使用できます。 しかしながら、彼らは異なったセキュリティ資産をそれぞれのフェーズに提供するかもしれません。 それぞれのこれらの交換で、クッキーとSPI分野の組み合わせは、この交換が交渉の1番目か2番目のフェーズに使用されているかどうか特定します。
4.1.1 Notation
4.1.1 記法
The following notation is used to describe the ISAKMP exchange types, shown in the next section, with the message formats and associated payloads:
以下の記法はメッセージ・フォーマットと関連ペイロードで次のセクションで見せられたISAKMP交換タイプについて説明するのに使用されます:
HDR is an ISAKMP header whose exchange type defines the payload
orderings
SA is an SA negotiation payload with one or more Proposal and
Transform payloads. An initiator MAY provide multiple proposals
for negotiation; a responder MUST reply with only one.
KE is the key exchange payload.
IDx is the identity payload for "x". x can be: "ii" or "ir"
for the ISAKMP initiator and responder, respectively, or x can
be: "ui", "ur" (when the ISAKMP daemon is a proxy negotiator),
for the user initiator and responder, respectively.
HASH is the hash payload.
SIG is the signature payload. The data to sign is exchange-specific.
AUTH is a generic authentication mechanism, such as HASH or SIG.
NONCE is the nonce payload.
'*' signifies payload encryption after the ISAKMP header. This
encryption MUST begin immediately after the ISAKMP header and
all payloads following the ISAKMP header MUST be encrypted.
HDRによる交換タイプがペイロード受注業務SAを定義するISAKMPヘッダーが1ProposalとTransformペイロードがあるSA交渉ペイロードであるということです。 創始者は交渉のための複数の提案を提供するかもしれません。 応答者は1だけで返答しなければなりません。 KEは主要な交換ペイロードです。 IDxは「x」のためのアイデンティティペイロードです。xは以下の通りであることができます。 または、「ii」、「不-、」 ISAKMP創始者と応答者のためにそれぞれ、xは以下の通りであることができます。 ユーザ創始者と応答者のためのそれぞれ「urである」(ISAKMPデーモンがプロキシ交渉者であるときに)"ui"。 HASHはハッシュペイロードです。 SIGは署名ペイロードです。 署名するデータは交換特有です。 AUTHはHASHかSIGなどのジェネリック認証機構です。 NONCEは一回だけのペイロードです。 '*'はISAKMPヘッダーの後にペイロード暗号化を意味します。 この暗号化はISAKMPヘッダー直後始まらなければなりません、そして、ISAKMPヘッダーに続くすべてのペイロードを暗号化しなければなりません。
=> signifies "initiator to responder" communication
<= signifies "responder to initiator" communication
=>が意味する、「応答者への創始者」コミュニケーション<=は「創始者への応答者」コミュニケーションを意味します。
4.2 Security Association Establishment
4.2 セキュリティ協会設立
The Security Association, Proposal, and Transform payloads are used to build ISAKMP messages for the negotiation and establishment of SAs. An SA establishment message consists of a single SA payload followed by at least one, and possibly many, Proposal payloads and at least one, and possibly many, Transform payloads associated with each Proposal payload. Because these payloads are considered together, the SA payload will point to any following payloads and not to the Proposal payload included with the SA payload. The SA Payload contains the DOI and Situation for the proposed SA. Each Proposal payload contains a Security Parameter Index (SPI) and ensures that the SPI is associated with the Protocol-Id in accordance with the Internet Security Architecture [SEC-ARCH]. Proposal payloads may or may not have the same SPI, as this is implementation dependent. Each
Security Association、Proposal、およびTransformペイロードは、SAsの交渉と設立へのメッセージをISAKMPに築き上げるのに使用されます。 SA設立メッセージは少なくとも1、ことによると多く、ペイロードの、そして、少なくとも1のProposal、およびことによると多く(それぞれのProposalペイロードに関連しているTransformペイロード)が支えたただ一つのSAペイロードから成ります。 これらのペイロードが一緒に考えられるので、SAペイロードはSAペイロードで含まれていたProposalペイロードではなく、どんな次のペイロードにも指すでしょう。 SA有効搭載量は提案されたSAのためのDOIとSituationを含んでいます。 それぞれのProposalペイロードは、Security Parameter Index(SPI)を含んでいて、インターネットSecurity Architecture[SEC-ARCH]によると、SPIがプロトコルイドに関連しているのを確実にします。 これが実装に依存しているので、提案ペイロードには、同じSPIがあるかもしれません。 それぞれ
Maughan, et. al. Standards Track [Page 46] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[46ページ]。
Transform Payload contains the specific security mechanisms to be used for the designated protocol. It is expected that the Proposal and Transform payloads will be used only during SA establishment negotiation. The creation of payloads for security association negotiation and establishment described here in this section are applicable for all ISAKMP exchanges described later in sections 4.4 through 4.8. The examples shown in 4.2.1 contain only the SA, Proposal, and Transform payloads and do not contain other payloads that might exist for a given ISAKMP exchange.
変換有効搭載量は指定されたプロトコルに使用されるべき特定のセキュリティー対策を含んでいます。 ProposalとTransformペイロードがSA設立交渉だけの間使用されると予想されます。 すべてのISAKMP交換に、セキュリティ協会交渉とここ、このセクションで説明された設立が適切であるので、ペイロードの作成は中で後でセクション4.4〜4.8について説明しました。 目立つ例、4.2、.1、SA、Proposal、およびTransformペイロードだけを含んでください、そして、与えられたISAKMP交換のために存在するかもしれない他のペイロードは含まないでください。
The Proposal payload provides the initiating entity with the capability to present to the responding entity the security protocols and associated security mechanisms for use with the security association being negotiated. If the SA establishment negotiation is for a combined protection suite consisting of multiple protocols, then there MUST be multiple Proposal payloads each with the same Proposal number. These proposals MUST be considered as a unit and MUST NOT be separated by a proposal with a different proposal number. The use of the same Proposal number in multiple Proposal payloads provides a logical AND operation, i.e. Protocol 1 AND Protocol 2. The first example below shows an ESP AND AH protection suite. If the SA establishment negotiation is for different protection suites, then there MUST be multiple Proposal payloads each with a monotonically increasing Proposal number. The different proposals MUST be presented in the initiator's preference order. The use of different Proposal numbers in multiple Proposal payloads provides a logical OR operation, i.e. Proposal 1 OR Proposal 2, where each proposal may have more than one protocol. The second example below shows either an AH AND ESP protection suite OR just an ESP protection suite. Note that the Next Payload field of the Proposal payload points to another Proposal payload (if it exists). The existence of a Proposal payload implies the existence of one or more Transform payloads.
Proposalペイロードはセキュリティ関係が交渉されている状態で使用のためにセキュリティプロトコルと関連セキュリティー対策を応じる実体に提示する能力を開始実体に提供します。 複数のプロトコルから成る結合した保護スイートにSA設立交渉があるなら、それぞれ複数のProposalペイロードが同じProposal番号と共にあるに違いありません。 これらの提案は、ユニットであるとみなさなければならなくて、異なった提案番号で提案で切り離されてはいけません。 複数のProposalペイロードにおける同じProposal番号の使用は論理的なAND演算(すなわち、プロトコル1ANDプロトコル2)を提供します。 以下の最初の例はESP AND AH保護スイートを示しています。 異なった保護スイートにSA設立交渉があるなら、それぞれ複数のProposalペイロードが単調に増加するProposal番号と共にあるに違いありません。 創始者の好みの命令に異なった提案を提示しなければなりません。 複数のProposalペイロードにおける異なったProposal番号の使用は論理的なOR演算、すなわち、Proposal1OR Proposal2を提供します。そこでは、各提案が1つ以上のプロトコルを持っているかもしれません。 以下の2番目の例はまさしく超能力保護スイートをAH AND ESP保護スイートORに示しています。 ProposalペイロードのNext有効搭載量分野が別のProposalペイロードを示すことに注意してください(存在しているなら)。 Proposalペイロードの存在は1個以上のTransformペイロードの存在を含意します。
The Transform payload provides the initiating entity with the capability to present to the responding entity multiple mechanisms, or transforms, for a given protocol. The Proposal payload identifies a Protocol for which services and mechanisms are being negotiated. The Transform payload allows the initiating entity to present several possible supported transforms for that proposed protocol. There may be several transforms associated with a specific Proposal payload each identified in a separate Transform payload. The multiple transforms MUST be presented with monotonically increasing numbers in the initiator's preference order. The receiving entity MUST select a single transform for each protocol in a proposal or reject the entire proposal. The use of the Transform number in multiple Transform payloads provides a second level OR operation, i.e. Transform 1 OR Transform 2 OR Transform 3. Example 1 below shows two possible transforms for ESP and a single transform for AH. Example 2 below
The Transform payload provides the initiating entity with the capability to present to the responding entity multiple mechanisms, or transforms, for a given protocol. The Proposal payload identifies a Protocol for which services and mechanisms are being negotiated. The Transform payload allows the initiating entity to present several possible supported transforms for that proposed protocol. There may be several transforms associated with a specific Proposal payload each identified in a separate Transform payload. The multiple transforms MUST be presented with monotonically increasing numbers in the initiator's preference order. The receiving entity MUST select a single transform for each protocol in a proposal or reject the entire proposal. The use of the Transform number in multiple Transform payloads provides a second level OR operation, i.e. Transform 1 OR Transform 2 OR Transform 3. Example 1 below shows two possible transforms for ESP and a single transform for AH. Example 2 below
Maughan, et. al. Standards Track [Page 47] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 47] RFC 2408 ISAKMP November 1998
shows one transform for AH AND one transform for ESP OR two transforms for ESP alone. Note that the Next Payload field of the Transform payload points to another Transform payload or 0. The Proposal payload delineates the different proposals.
shows one transform for AH AND one transform for ESP OR two transforms for ESP alone. Note that the Next Payload field of the Transform payload points to another Transform payload or 0. The Proposal payload delineates the different proposals.
When responding to a Security Association payload, the responder MUST send a Security Association payload with the selected proposal, which may consist of multiple Proposal payloads and their associated Transform payloads. Each of the Proposal payloads MUST contain a single Transform payload associated with the Protocol. The responder SHOULD retain the Proposal # field in the Proposal payload and the Transform # field in each Transform payload of the selected Proposal. Retention of Proposal and Transform numbers should speed the initiator's protocol processing by negating the need to compare the respondor's selection with every offered option. These values enable the initiator to perform the comparison directly and quickly. The initiator MUST verify that the Security Association payload received from the responder matches one of the proposals sent initially.
When responding to a Security Association payload, the responder MUST send a Security Association payload with the selected proposal, which may consist of multiple Proposal payloads and their associated Transform payloads. Each of the Proposal payloads MUST contain a single Transform payload associated with the Protocol. The responder SHOULD retain the Proposal # field in the Proposal payload and the Transform # field in each Transform payload of the selected Proposal. Retention of Proposal and Transform numbers should speed the initiator's protocol processing by negating the need to compare the respondor's selection with every offered option. These values enable the initiator to perform the comparison directly and quickly. The initiator MUST verify that the Security Association payload received from the responder matches one of the proposals sent initially.
4.2.1 Security Association Establishment Examples
4.2.1 Security Association Establishment Examples
This example shows a Proposal for a combined protection suite with two different protocols. The first protocol is presented with two transforms supported by the proposer. The second protocol is presented with a single transform. An example for this proposal might be: Protocol 1 is ESP with Transform 1 as 3DES and Transform 2 as DES AND Protocol 2 is AH with Transform 1 as SHA. The responder MUST select from the two transforms proposed for ESP. The resulting protection suite will be either (1) 3DES AND SHA OR (2) DES AND SHA, depending on which ESP transform was selected by the responder. Note this example is shown using the Base Exchange.
This example shows a Proposal for a combined protection suite with two different protocols. The first protocol is presented with two transforms supported by the proposer. The second protocol is presented with a single transform. An example for this proposal might be: Protocol 1 is ESP with Transform 1 as 3DES and Transform 2 as DES AND Protocol 2 is AH with Transform 1 as SHA. The responder MUST select from the two transforms proposed for ESP. The resulting protection suite will be either (1) 3DES AND SHA OR (2) DES AND SHA, depending on which ESP transform was selected by the responder. Note this example is shown using the Base Exchange.
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
/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Nonce ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SA Pay ! Domain of Interpretation (DOI) !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! Situation !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans. = 2!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Transform! 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 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Nonce ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SA Pay ! Domain of Interpretation (DOI) ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! Situation ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Proposal ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans. = 2! Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Transform! RESERVED ! Payload Length !
Maughan, et. al. Standards Track [Page 48] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 48] RFC 2408 ISAKMP November 1998
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This second example shows a Proposal for two different protection suites. The SA Payload was omitted for space reasons. The first protection suite is presented with one transform for the first protocol and one transform for the second protocol. The second protection suite is presented with two transforms for a single protocol. An example for this proposal might be: Proposal 1 with Protocol 1 as AH with Transform 1 as MD5 AND Protocol 2 as ESP with Transform 1 as 3DES. This is followed by Proposal 2 with Protocol 1 as ESP with Transform 1 as DES and Transform 2 as 3DES. The responder MUST select from the two different proposals. If the second Proposal is selected, the responder MUST select from the two transforms for ESP. The resulting protection suite will be either (1) MD5 AND 3DES OR the selection between (2) DES OR (3) 3DES.
This second example shows a Proposal for two different protection suites. The SA Payload was omitted for space reasons. The first protection suite is presented with one transform for the first protocol and one transform for the second protocol. The second protection suite is presented with two transforms for a single protocol. An example for this proposal might be: Proposal 1 with Protocol 1 as AH with Transform 1 as MD5 AND Protocol 2 as ESP with Transform 1 as 3DES. This is followed by Proposal 2 with Protocol 1 as ESP with Transform 1 as DES and Transform 2 as 3DES. The responder MUST select from the two different proposals. If the second Proposal is selected, the responder MUST select from the two transforms for ESP. The resulting protection suite will be either (1) MD5 AND 3DES OR the selection between (2) DES OR (3) 3DES.
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
/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! 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 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Proposal ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length !
Maughan, et. al. Standards Track [Page 49] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 49] RFC 2408 ISAKMP November 1998
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 2 ! Proposal # = 2! Protocol ID ! SPI Size !# of Trans. = 2!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Transform! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Proposal ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 2 ! Proposal # = 2! Protocol ID ! SPI Size !# of Trans. = 2! Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Transform! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = 0 ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SA Attributes ! \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3 Security Association Modification
4.3 Security Association Modification
Security Association modification within ISAKMP is accomplished by creating a new SA and initiating communications using that new SA. Deletion of the old SA can be done anytime after the new SA is established. Deletion of the old SA is dependent on local security policy. Modification of SAs by using a "Create New SA followed by Delete Old SA" method is done to avoid potential vulnerabilities in synchronizing modification of existing SA attributes. The procedure for creating new SAs is outlined in section 4.2. The procedure for deleting SAs is outlined in section 5.15.
Security Association modification within ISAKMP is accomplished by creating a new SA and initiating communications using that new SA. Deletion of the old SA can be done anytime after the new SA is established. Deletion of the old SA is dependent on local security policy. Modification of SAs by using a "Create New SA followed by Delete Old SA" method is done to avoid potential vulnerabilities in synchronizing modification of existing SA attributes. The procedure for creating new SAs is outlined in section 4.2. The procedure for deleting SAs is outlined in section 5.15.
Maughan, et. al. Standards Track [Page 50] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 50] RFC 2408 ISAKMP November 1998
Modification of an ISAKMP SA (phase 1 negotiation) follows the same procedure as creation of an ISAKMP SA. There is no relationship between the two SAs and the initiator and responder cookie pairs SHOULD be different, as outlined in section 2.5.3.
Modification of an ISAKMP SA (phase 1 negotiation) follows the same procedure as creation of an ISAKMP SA. There is no relationship between the two SAs and the initiator and responder cookie pairs SHOULD be different, as outlined in section 2.5.3.
Modification of a Protocol SA (phase 2 negotiation) follows the same procedure as creation of a Protocol SA. The creation of a new SA is protected by the existing ISAKMP SA. There is no relationship between the two Protocol SAs. A protocol implementation SHOULD begin using the newly created SA for outbound traffic and SHOULD continue to support incoming traffic on the old SA until it is deleted or until traffic is received under the protection of the newly created SA. As stated previously in this section, deletion of an old SA is then dependent on local security policy.
Modification of a Protocol SA (phase 2 negotiation) follows the same procedure as creation of a Protocol SA. The creation of a new SA is protected by the existing ISAKMP SA. There is no relationship between the two Protocol SAs. A protocol implementation SHOULD begin using the newly created SA for outbound traffic and SHOULD continue to support incoming traffic on the old SA until it is deleted or until traffic is received under the protection of the newly created SA. As stated previously in this section, deletion of an old SA is then dependent on local security policy.
4.4 Base Exchange
4.4 Base Exchange
The Base Exchange is designed to allow the Key Exchange and Authentication related information to be transmitted together. Combining the Key Exchange and Authentication-related information into one message reduces the number of round-trips at the expense of not providing identity protection. Identity protection is not provided because identities are exchanged before a common shared secret has been established and, therefore, encryption of the identities is not possible. The following diagram shows the messages with the possible payloads sent in each message and notes for an example of the Base Exchange.
The Base Exchange is designed to allow the Key Exchange and Authentication related information to be transmitted together. Combining the Key Exchange and Authentication-related information into one message reduces the number of round-trips at the expense of not providing identity protection. Identity protection is not provided because identities are exchanged before a common shared secret has been established and, therefore, encryption of the identities is not possible. The following diagram shows the messages with the possible payloads sent in each message and notes for an example of the Base Exchange.
BASE EXCHANGE
BASE EXCHANGE
# Initiator Direction Responder NOTE (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation
# Initiator Direction Responder NOTE (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation
(2) <= HDR; SA; NONCE
Basic SA agreed upon
(3) HDR; KE; =>
IDii; AUTH Key Generated (by responder)
Initiator Identity Verified by
Responder
(4) <= HDR; KE;
IDir; AUTH
Responder Identity Verified by
Initiator Key Generated (by
initiator) SA established
(2) <= HDR; SA; NONCE Basic SA agreed upon (3) HDR; KE; => IDii; AUTH Key Generated (by responder) Initiator Identity Verified by Responder (4) <= HDR; KE; IDir; AUTH Responder Identity Verified by Initiator Key Generated (by initiator) SA established
Maughan, et. al. Standards Track [Page 51] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 51] RFC 2408 ISAKMP November 1998
In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes). Random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange.
In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes). Random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange.
In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Again, random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Again, random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
In the third (3) and fourth (4) messages, the initiator and responder, respectively, exchange keying material used to arrive at a common shared secret and identification information. This information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
In the third (3) and fourth (4) messages, the initiator and responder, respectively, exchange keying material used to arrive at a common shared secret and identification information. This information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
4.5 Identity Protection Exchange
4.5 Identity Protection Exchange
The Identity Protection Exchange is designed to separate the Key Exchange information from the Identity and Authentication related information. Separating the Key Exchange from the Identity and Authentication related information provides protection of the communicating identities at the expense of two additional messages. Identities are exchanged under the protection of a previously established common shared secret. The following diagram shows the messages with the possible payloads sent in each message and notes for an example of the Identity Protection Exchange.
The Identity Protection Exchange is designed to separate the Key Exchange information from the Identity and Authentication related information. Separating the Key Exchange from the Identity and Authentication related information provides protection of the communicating identities at the expense of two additional messages. Identities are exchanged under the protection of a previously established common shared secret. The following diagram shows the messages with the possible payloads sent in each message and notes for an example of the Identity Protection Exchange.
Maughan, et. al. Standards Track [Page 52] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 52] RFC 2408 ISAKMP November 1998
IDENTITY PROTECTION EXCHANGE
IDENTITY PROTECTION EXCHANGE
# Initiator Direction Responder NOTE
(1) HDR; SA => Begin ISAKMP-SA or
Proxy negotiation
(2) <= HDR; SA
Basic SA agreed upon
(3) HDR; KE; NONCE =>
(4) <= HDR; KE; NONCE
Key Generated (by
Initiator and
Responder)
(5) HDR*; IDii; AUTH =>
Initiator Identity
Verified by
Responder
(6) <= HDR*; IDir; AUTH
Responder Identity
Verified by
Initiator
SA established
# Initiator Direction Responder NOTE (1) HDR; SA => Begin ISAKMP-SA or Proxy negotiation (2) <= HDR; SA Basic SA agreed upon (3) HDR; KE; NONCE => (4) <= HDR; KE; NONCE Key Generated (by Initiator and Responder) (5) HDR*; IDii; AUTH => Initiator Identity Verified by Responder (6) <= HDR*; IDir; AUTH Responder Identity Verified by Initiator SA established
In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes).
In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes).
In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
In the third (3) and fourth (4) messages, the initiator and responder, respectively, exchange keying material used to arrive at a common shared secret and random information which is used to guarantee liveness and protect against replay attacks. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
In the third (3) and fourth (4) messages, the initiator and responder, respectively, exchange keying material used to arrive at a common shared secret and random information which is used to guarantee liveness and protect against replay attacks. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
In the fifth (5) and sixth (6) messages, the initiator and responder, respectively, exchange identification information and the results of the agreed upon authentication function. This information is
In the fifth (5) and sixth (6) messages, the initiator and responder, respectively, exchange identification information and the results of the agreed upon authentication function. This information is
Maughan, et. al. Standards Track [Page 53] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 53] RFC 2408 ISAKMP November 1998
transmitted under the protection of the common shared secret. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
transmitted under the protection of the common shared secret. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
4.6 Authentication Only Exchange
4.6 Authentication Only Exchange
The Authentication Only Exchange is designed to allow only Authentication related information to be transmitted. The benefit of this exchange is the ability to perform only authentication without the computational expense of computing keys. Using this exchange during negotiation, none of the transmitted information will be encrypted. However, the information may be encrypted in other places. For example, if encryption is negotiated during the first phase of a negotiation and the authentication only exchange is used in the second phase of a negotiation, then the authentication only exchange will be encrypted by the ISAKMP SAs negotiated in the first phase. The following diagram shows the messages with possible payloads sent in each message and notes for an example of the Authentication Only Exchange.
The Authentication Only Exchange is designed to allow only Authentication related information to be transmitted. The benefit of this exchange is the ability to perform only authentication without the computational expense of computing keys. Using this exchange during negotiation, none of the transmitted information will be encrypted. However, the information may be encrypted in other places. For example, if encryption is negotiated during the first phase of a negotiation and the authentication only exchange is used in the second phase of a negotiation, then the authentication only exchange will be encrypted by the ISAKMP SAs negotiated in the first phase. The following diagram shows the messages with possible payloads sent in each message and notes for an example of the Authentication Only Exchange.
AUTHENTICATION ONLY EXCHANGE
AUTHENTICATION ONLY EXCHANGE
# Initiator Direction Responder NOTE
(1) HDR; SA; NONCE => Begin ISAKMP-SA or
Proxy negotiation
(2) <= HDR; SA; NONCE;
IDir; AUTH
Basic SA agreed upon
Responder Identity
Verified by Initiator
(3) HDR; IDii; AUTH =>
Initiator Identity
Verified by Responder
SA established
# Initiator Direction Responder NOTE (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation (2) <= HDR; SA; NONCE; IDir; AUTH Basic SA agreed upon Responder Identity Verified by Initiator (3) HDR; IDii; AUTH => Initiator Identity Verified by Responder SA established
In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes). Random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange.
In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes). Random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange.
In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Again, random information which is used to
In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Again, random information which is used to
Maughan, et. al. Standards Track [Page 54] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 54] RFC 2408 ISAKMP November 1998
guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the responder transmits identification information. All of this information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the responder transmits identification information. All of this information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
In the third message (3), the initiator transmits identification information. This information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
In the third message (3), the initiator transmits identification information. This information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
4.7 Aggressive Exchange
4.7 Aggressive Exchange
The Aggressive Exchange is designed to allow the Security Association, Key Exchange and Authentication related payloads to be transmitted together. Combining the Security Association, Key Exchange, and Authentication-related information into one message reduces the number of round-trips at the expense of not providing identity protection. Identity protection is not provided because identities are exchanged before a common shared secret has been established and, therefore, encryption of the identities is not possible. Additionally, the Aggressive Exchange is attempting to establish all security relevant information in a single exchange. The following diagram shows the messages with possible payloads sent in each message and notes for an example of the Aggressive Exchange.
The Aggressive Exchange is designed to allow the Security Association, Key Exchange and Authentication related payloads to be transmitted together. Combining the Security Association, Key Exchange, and Authentication-related information into one message reduces the number of round-trips at the expense of not providing identity protection. Identity protection is not provided because identities are exchanged before a common shared secret has been established and, therefore, encryption of the identities is not possible. Additionally, the Aggressive Exchange is attempting to establish all security relevant information in a single exchange. The following diagram shows the messages with possible payloads sent in each message and notes for an example of the Aggressive Exchange.
Maughan, et. al. Standards Track [Page 55] RFC 2408 ISAKMP November 1998
Maughan, et. al. Standards Track [Page 55] RFC 2408 ISAKMP November 1998
AGGRESSIVE EXCHANGE
AGGRESSIVE EXCHANGE
# Initiator Direction Responder NOTE
(1) HDR; SA; KE; => Begin ISAKMP-SA or
Proxy negotiation
NONCE; IDii and Key Exchange
# Initiator Direction Responder NOTE (1) HDR; SA; KE; => Begin ISAKMP-SA or Proxy negotiation NONCE; IDii and Key Exchange
(2) <= HDR; SA; KE;
NONCE; IDir; AUTH
Initiator Identity
Verified by Responder
Key Generated
Basic SA agreed upon
(3) HDR*; AUTH =>
Responder Identity
Verified by Initiator
SA established
(2) <= HDR; SA; KE; NONCE; IDir; AUTH Initiator Identity Verified by Responder Key Generated Basic SA agreed upon (3) HDR*; AUTH => Responder Identity Verified by Initiator SA established
In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes). There can be only one Proposal and one Transform offered (i.e. no choices) in order for the aggressive exchange to work. Keying material used to arrive at a common shared secret and random information which is used to guarantee liveness and protect against replay attacks are also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the initiator transmits identification information.
最初のメッセージ(1)では、創始者はそれが与えられた状況のためにトラフィックを保護するために適切であることを検討する提案を生成します。 Security Association、Proposal、およびTransformペイロードはSecurity Associationペイロード(記法目的のための)に含まれています。 1Proposalしかあることができませんでした、そして、1Transformが攻撃的な交換の注文で働くと申し出ました(すなわち、選択がありません)。 また、一般的な共有秘密キーに到着するのに使用される材料を合わせて、活性を保証して、反射攻撃から守るのに使用される無作為の情報は伝えられます。 無作為の情報は双方でSHOULDを提供しました。認証機構によって使用されて、交換への参加の共有された証拠を提供してください。 さらに、創始者は識別情報を伝えます。
In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Keying material used to arrive at a common shared secret and random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the responder transmits identification information. All of this information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
2番目のメッセージ(2)では、応答者はそれがSecurity Association、Proposal、およびTransformペイロードで受け入れた保護スイートを示します。 材料を合わせるのは以前はよく一般的な共有秘密キーに到着する予定でした、そして、また、活性を保証して、反射攻撃から守るのに使用される無作為の情報は伝えられます。 無作為の情報は双方でSHOULDを提供しました。認証機構によって使用されて、交換への参加の共有された証拠を提供してください。 さらに、応答者は識別情報を伝えます。 この情報のすべてが認証機能での同意の保護で伝えられます。 提案された保護スイートを全く受け入れないなら、ローカルの安全保障政策は応答者の動作を決めます。 1つの可能な動作がInformational Exchangeの一部としてのNotifyペイロードのトランスミッションです。
Maughan, et. al. Standards Track [Page 56] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[56ページ]。
In the third (3) message, the initiator transmits the results of the agreed upon authentication function. This information is transmitted under the protection of the common shared secret. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
3(3)番目のメッセージでは、創始者は認証機能で同意の結果を伝えます。 この情報は一般的な共有秘密キーの保護で伝えられます。 誤りがこれらのメッセージの間、発生するなら、ローカルの安全保障政策は動作を決めます。 1つの可能な動作がInformational Exchangeの一部としてのNotifyペイロードのトランスミッションです。
4.8 Informational Exchange
4.8 情報の交換
The Informational Exchange is designed as a one-way transmittal of information that can be used for security association management. The following diagram shows the messages with possible payloads sent in each message and notes for an example of the Informational Exchange.
Informational Exchangeはセキュリティ協会管理に使用できる情報の一方通行の譲渡として設計されています。 以下のダイヤグラムは、可能なペイロードがあるメッセージがInformational Exchangeに関する例のための各メッセージと注意を送ったのを示します。
INFORMATIONAL EXCHANGE
情報の交換
# Initiator Direction Responder NOTE
(1) HDR*; N/D => Error Notification or Deletion
# 創始者方向応答者注意(1)HDR*。 N/Dは>エラー通知か削除と等しいです。
In the first message (1), the initiator or responder transmits an ISAKMP Notify or Delete payload.
最初のメッセージ(1)では、創始者か応答者がISAKMP NotifyかDeleteペイロードを伝えます。
If the Informational Exchange occurs prior to the exchange of keying meterial during an ISAKMP Phase 1 negotiation, there will be no protection provided for the Informational Exchange. Once keying material has been exchanged or an ISAKMP SA has been established, the Informational Exchange MUST be transmitted under the protection provided by the keying material or the ISAKMP SA.
Informational ExchangeがISAKMP Phase1交渉の間、meterialを合わせる交換の前に起こると、Informational Exchangeに提供されたノー・プロテクションがあるでしょう。 いったん材料を合わせるのを交換したか、またはISAKMP SAを設立すると、合わせることの材料かISAKMP SAによって提供された保護でInformational Exchangeを伝えなければなりません。
All exchanges are similar in that with the beginning of any exchange, cryptographic synchronization MUST occur. The Informational Exchange is an exchange and not an ISAKMP message. Thus, the generation of an Message ID (MID) for an Informational Exchange SHOULD be independent of IVs of other on-going communication. This will ensure cryptographic synchronization is maintained for existing communications and the Informational Exchange will be processed correctly. The only exception to this is when the Commit Bit of the ISAKMP Header is set. When the Commit Bit is set, the Message ID field of the Informational Exchange MUST contain the Message ID of the original ISAKMP Phase 2 SA negotiation, rather than a new Message ID (MID). This is done to ensure that the Informational Exchange with the CONNECTED Notify Message can be associated with the correct Phase 2 SA. For a description of the Commit Bit, see section 3.1.
すべての交換が暗号の同期がどんな交換の始まりでも起こらなければならないという点において同様です。 Informational ExchangeはISAKMPメッセージではなく、交換です。 したがって、Informational Exchange SHOULDのためのMessage ID(MID)の世代は他の継続しているコミュニケーションのIVsの如何にかかわらずそうです。 これは、暗号の同期が既存のコミュニケーションのために維持されて、Informational Exchangeが正しく処理されるのを確実にするでしょう。 これへの唯一の例外がISAKMP HeaderのCommit Bitが用意ができている時です。 Commit Bitが用意ができているとき、Informational ExchangeのMessage ID分野は新しいMessage ID(MID)よりむしろオリジナルのISAKMP Phase2SA交渉のMessage IDを含まなければなりません。 正しいPhase2SAにCONNECTED Notify MessageとInformational Exchangeを関連づけることができるのを保証するためにこれをします。 Commit Bitの記述に関しては、セクション3.1を見てください。
Maughan, et. al. Standards Track [Page 57] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[57ページ]。
5 ISAKMP Payload Processing
5 ISAKMP有効搭載量処理
Section 3 describes the ISAKMP payloads. These payloads are used in the exchanges described in section 4 and can be used in exchanges defined for a specific DOI. This section describes the processing for each of the payloads. This section suggests the logging of events to a system audit file. This action is controlled by a system security policy and is, therefore, only a suggested action.
セクション3はISAKMPペイロードについて説明します。 これらのペイロードをセクション4で説明された交換に使用して、特定のDOIのために定義された交換に使用できます。 このセクションはそれぞれのペイロードのための処理について説明します。 このセクションはイベントの伐採をシステム監査ファイルに示します。 この動作は、システム安全保障政策で制御されて、したがって、提案された動作にすぎません。
5.1 General Message Processing
5.1 一般教書処理
Every ISAKMP message has basic processing applied to insure protocol reliability, and to minimize threats, such as denial of service and replay attacks. All processing SHOULD include packet length checks to insure the packet received is at least as long as the length given in the ISAKMP Header. If the ISAKMP message length and the value in the Payload Length field of the ISAKMP Header are not the same, then the ISAKMP message MUST be rejected. The receiving entity (initiator or responder) MUST do the following:
あらゆるISAKMPメッセージで、プロトコルの信頼性を保障して、サービスと反射攻撃の否定などの脅威を最小にするために基本的な処理を適用します。 すべての処理SHOULDが、受け取られたパケットがISAKMP Headerで与えられた長さと少なくとも同じくらい長いのを保障するためにパケット長チェックを含んでいます。 ISAKMP Headerの有効搭載量Length分野のISAKMPメッセージ長と値が同じでないなら、ISAKMPメッセージを拒絶しなければなりません。 受信実体(創始者か応答者)は以下をしなければなりません:
1. The event, UNEQUAL PAYLOAD LENGTHS, MAY be logged in the
appropriate system audit file.
1. イベント(UNEQUAL PAYLOAD LENGTHS)は適切なシステム監査ファイルに登録されるかもしれません。
2. An Informational Exchange with a Notification payload containing
the UNEQUAL-PAYLOAD-LENGTHS message type MAY be sent to the
transmitting entity. This action is dictated by a system
security policy.
2. NotificationペイロードがUNEQUAL有効搭載量LENGTHSメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
When transmitting an ISAKMP message, the transmitting entity (initiator or responder) MUST do the following:
ISAKMPメッセージを送るとき、伝える実体(創始者か応答者)は以下をしなければなりません:
1. Set a timer and initialize a retry counter.
1. タイマを設定してください、そして、再試行カウンタを初期化してください。
NOTE: Implementations MUST NOT use a fixed timer. Instead,
transmission timer values should be adjusted dynamically based on
measured round trip times. In addition, successive
retransmissions of the same packet should be separated by
increasingly longer time intervals (e.g., exponential backoff).
以下に注意してください。 実装は固定タイマを使用してはいけません。 代わりに、トランスミッションタイマ値は測定周遊旅行時間に基づいてダイナミックに調整されるべきです。 さらに、ますますより長い時間間隔(例えば、指数のbackoff)で同じパケットの連続した「再-トランスミッション」は切り離されるべきです。
2. If the timer expires, the ISAKMP message is resent and the retry
counter is decremented.
2. タイマが期限が切れるなら、ISAKMPメッセージを再送します、そして、再試行カウンタを減少させます。
3. If the retry counter reaches zero (0), the event, RETRY LIMIT
REACHED, MAY be logged in the appropriate system audit file.
3. 再試行カウンタの範囲が(0)のゼロに合っているなら、イベント(RETRY LIMIT REACHED)は適切なシステム監査ファイルに登録されるかもしれません。
4. The ISAKMP protocol machine clears all states and returns to
IDLE.
4. ISAKMPプロトコルマシンは、すべての州をきれいにして、IDLEに戻ります。
Maughan, et. al. Standards Track [Page 58] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[58ページ]。
5.2 ISAKMP Header Processing
5.2 ISAKMPヘッダー処理
When creating an ISAKMP message, the transmitting entity (initiator or responder) MUST do the following:
ISAKMPメッセージを作成するとき、伝える実体(創始者か応答者)は以下をしなければなりません:
1. Create the respective cookie. See section 2.5.3 for details.
1. それぞれのクッキーを作成してください。 詳細に関してセクション2.5.3を見てください。
2. Determine the relevant security characteristics of the session
(i.e. DOI and situation).
2. セッション(すなわち、DOIと状況)の関連セキュリティの特性を決定してください。
3. Construct an ISAKMP Header with fields as described in section
3.1.
3. セクション3.1で説明されるように分野があるISAKMP Headerを組み立ててください。
4. Construct other ISAKMP payloads, depending on the exchange type.
4. 交換タイプに頼って、他のISAKMPペイロードを構成してください。
5. Transmit the message to the destination host as described in
section5.1.
5. section5.1で説明されるようにメッセージをあて先ホストに送ってください。
When an ISAKMP message is received, the receiving entity (initiator or responder) MUST do the following:
ISAKMPメッセージが受信されているとき、受信実体(創始者か応答者)は以下をしなければなりません:
1. Verify the Initiator and Responder "cookies". If the cookie
validation fails, the message is discarded and the following
actions are taken:
1. 創始者と応答者「クッキー」について確かめてください。 クッキー合法化が失敗するなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID COOKIE, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID COOKIE)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-COOKIE message type MAY be sent to
the transmitting entity. This action is dictated by a
system security policy.
(b) NotificationペイロードがINVALID-COOKIEメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
2. Check the Next Payload field to confirm it is valid. If the Next
Payload field validation fails, the message is discarded and the
following actions are taken:
2. Next有効搭載量分野をチェックして、それが有効であると確認してください。 Next有効搭載量分野合法化が失敗するなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID NEXT PAYLOAD, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID NEXT PAYLOAD)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-PAYLOAD-TYPE message type MAY be sent
to the transmitting entity. This action is dictated by a
system security policy.
(b) NotificationペイロードがINVALID有効搭載量TYPEメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
3. Check the Major and Minor Version fields to confirm they are
correct (see section 3.1). If the Version field validation
fails, the message is discarded and the following actions are
3. メージャーとMinorバージョン分野をチェックして、それらが正しいと(セクション3.1を見てください)確認してください。 バージョン分野合法化が失敗するなら、メッセージは捨てられます、そして、以下の動作は捨てられます。
Maughan, et. al. Standards Track [Page 59] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[59ページ]。
taken:
取られる:
(a) The event, INVALID ISAKMP VERSION, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID ISAKMP VERSION)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-MAJOR-VERSION or INVALID-MINOR-
VERSION message type MAY be sent to the transmitting entity.
This action is dictated by a system security policy.
(b) NotificationペイロードがINVALIDメージャーVERSIONかINVALID-MINORバージョンメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
4. Check the Exchange Type field to confirm it is valid. If the
Exchange Type field validation fails, the message is discarded
and the following actions are taken:
4. Exchange Type分野をチェックして、それが有効であると確認してください。 Exchange Type分野合法化が失敗するなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID EXCHANGE TYPE, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID EXCHANGE TYPE)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-EXCHANGE-TYPE message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
(b) NotificationペイロードがINVALID-EXCHANGE-TYPEメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
5. Check the Flags field to ensure it contains correct values. If
the Flags field validation fails, the message is discarded and
the following actions are taken:
5. Flags分野をチェックして、正しい値を含むのを保証してください。 Flags分野合法化が失敗するなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID FLAGS, MAY be logged in the appropriate
systemaudit file.
(a) イベント(INVALID FLAGS)は適切なsystemauditファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-FLAGS message type MAY be sent to the
transmitting entity. This action is dictated by a system
security policy.
(b) NotificationペイロードがINVALID-FLAGSメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
6. Check the Message ID field to ensure it contains correct values.
If the Message ID validation fails, the message is discarded and
the following actions are taken:
6. Message ID分野をチェックして、正しい値を含むのを保証してください。 Message ID合法化が失敗するなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID MESSAGE ID, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID MESSAGE ID)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-MESSAGE-ID message type MAY be sent
to the transmitting entity. This action is dictated by a
system security policy.
(b) NotificationペイロードがINVALID-MESSAGE-IDメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
7. Processing of the ISAKMP message continues using the value in the
Next Payload field.
7. ISAKMPメッセージの処理は、Next有効搭載量分野で値を使用し続けています。
Maughan, et. al. Standards Track [Page 60] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[60ページ]。
5.3 Generic Payload Header Processing
5.3 ジェネリック有効搭載量ヘッダー処理
When creating any of the ISAKMP Payloads described in sections 3.4 through 3.15 a Generic Payload Header is placed at the beginning of these payloads. When creating the Generic Payload Header, the transmitting entity (initiator or responder) MUST do the following:
セクション3.4〜3.15で説明されたISAKMP有効搭載量のどれかを作成するとき、Generic有効搭載量Headerはこれらのペイロードの始めに置かれます。 Generic有効搭載量Headerを作成するとき、伝える実体(創始者か応答者)は以下をしなければなりません:
1. Place the value of the Next Payload in the Next Payload field.
These values are described in section 3.1.
1. Next有効搭載量分野のNext有効搭載量の値を置いてください。 これらの値はセクション3.1で説明されます。
2. Place the value zero (0) in the RESERVED field.
2. 値ゼロの(0)をRESERVED分野に置いてください。
3. Place the length (in octets) of the payload in the Payload Length
field.
3. 有効搭載量Length分野のペイロードの長さ(八重奏における)を置いてください。
4. Construct the payloads as defined in the remainder of this
section.
4. このセクションの残りで定義されるようにペイロードを構成してください。
When any of the ISAKMP Payloads are received, the receiving entity (initiator or responder) MUST do the following:
ISAKMP有効搭載量のどれかが受け取られているとき、受信実体(創始者か応答者)は以下をしなければなりません:
1. Check the Next Payload field to confirm it is valid. If the Next
Payload field validation fails, the message is discarded and the
following actions are taken:
1. Next有効搭載量分野をチェックして、それが有効であると確認してください。 Next有効搭載量分野合法化が失敗するなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID NEXT PAYLOAD, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID NEXT PAYLOAD)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-PAYLOAD-TYPE message type MAY be sent
to the transmitting entity. This action is dictated by a
system security policy.
(b) NotificationペイロードがINVALID有効搭載量TYPEメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
2. Verify the RESERVED field contains the value zero. If the value
in the RESERVED field is not zero, the message is discarded and
the following actions are taken:
2. RESERVED分野について確かめてください。値ゼロを含んでいます。 RESERVED分野の値がゼロでないなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID RESERVED FIELD, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID RESERVED FIELD)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED
message type MAY be sent to the transmitting entity. This
action is dictated by a system security policy.
(b) NotificationペイロードがBAD-PROPOSAL-SYNTAXか有効搭載量MALFORMEDメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
3. Process the remaining payloads as defined by the Next Payload
field.
3. Next有効搭載量分野によって定義されるように残っているペイロードを処理してください。
Maughan, et. al. Standards Track [Page 61] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[61ページ]。
5.4 Security Association Payload Processing
5.4 セキュリティ協会有効搭載量処理
When creating a Security Association Payload, the transmitting entity (initiator or responder) MUST do the following:
Security Association有効搭載量を作成するとき、伝える実体(創始者か応答者)は以下をしなければなりません:
1. Determine the Domain of Interpretation for which this negotiation
is being performed.
1. この交渉が実行されているInterpretationのDomainを決定してください。
2. Determine the situation within the determined DOI for which this
negotiation is being performed.
2. この交渉が実行されている断固としたDOIの中で状況を決定してください。
3. Determine the proposal(s) and transform(s) within the situation.
These are described, respectively, in sections 3.5 and 3.6.
3. 提案を決定してください、そして、状況の中で(s)を変えてください。 これらはセクション3.5と3.6でそれぞれ説明されます。
4. Construct a Security Association payload.
4. Security Associationペイロードを構成してください。
5. Transmit the message to the receiving entity as described in
section 5.1.
5. セクション5.1で説明されるように受信実体にメッセージを送ってください。
When a Security Association payload is received, the receiving entity (initiator or responder) MUST do the following:
Security Associationペイロードが受け取られているとき、受信実体(創始者か応答者)は以下をしなければなりません:
1. Determine if the Domain of Interpretation (DOI) is supported. If
the DOI determination fails, the message is discarded and the
following actions are taken:
1. Interpretation(DOI)のDomainがサポートされるかどうか決定してください。 DOI決断が失敗するなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID DOI, MAY be logged in the appropriate
system audit file.
(a) イベント(INVALID DOI)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the DOI-NOT-SUPPORTED message type MAY be sent to
the transmitting entity. This action is dictated by a
system security policy.
(b) Notificationペイロードが土井NOT SUPPORTEDメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
2. Determine if the given situation can be protected. If the
Situation determination fails, the message is discarded and the
following actions are taken:
2. 与えられた状況を保護できるかどうか決定してください。 Situation決断が失敗するなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID SITUATION, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID SITUATION)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the SITUATION-NOT-SUPPORTED message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
(b) NotificationペイロードがSITUATION NOT SUPPORTEDメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
3. Process the remaining payloads (i.e. Proposal, Transform) of the
Security Association Payload. If the Security Association
3. Security Association有効搭載量の残っているペイロード(すなわち、Proposal、Transform)を処理してください。 セキュリティ協会です。
Maughan, et. al. Standards Track [Page 62] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[62ページ]。
Proposal (as described in sections 5.5 and 5.6) is not accepted,
then the following actions are taken:
提案(セクション5.5と5.6で説明されるように)を受け入れません、次に、以下の行動を取ります:
(a) The event, INVALID PROPOSAL, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID PROPOSAL)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the NO-PROPOSAL-CHOSEN message type MAY be sent
to the transmitting entity. This action is dictated by a
system security policy.
(b) NotificationペイロードがPROPOSAL-CHOSENがないメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
5.5 Proposal Payload Processing
5.5 提案有効搭載量処理
When creating a Proposal Payload, the transmitting entity (initiator or responder) MUST do the following:
Proposal有効搭載量を作成するとき、伝える実体(創始者か応答者)は以下をしなければなりません:
1. Determine the Protocol for this proposal.
1. この提案のためにプロトコルを決定してください。
2. Determine the number of proposals to be offered for this protocol
and the number of transforms for each proposal. Transforms are
described in section 3.6.
2. このプロトコルのために提供されるという提案の数と各提案のための変換の数を測定してください。 変換はセクション3.6で説明されます。
3. Generate a unique pseudo-random SPI.
3. ユニークな擬似ランダムがSPIであると生成してください。
4. Construct a Proposal payload.
4. Proposalペイロードを構成してください。
When a Proposal payload is received, the receiving entity (initiator or responder) MUST do the following:
Proposalペイロードが受け取られているとき、受信実体(創始者か応答者)は以下をしなければなりません:
1. Determine if the Protocol is supported. If the Protocol-ID field
is invalid, the payload is discarded and the following actions
are taken:
1. プロトコルがサポートされるかどうか決定してください。 Protocol ID分野が無効であるなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID PROTOCOL, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID PROTOCOL)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-PROTOCOL-ID message type MAY be sent
to the transmitting entity. This action is dictated by a
system security policy.
(b) NotificationペイロードがINVALID PROTOCOL IDメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
2. Determine if the SPI is valid. If the SPI is invalid, the
payload is discarded and the following actions are taken:
2. SPIが有効であるかどうか決定してください。 SPIが無効であるなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID SPI, MAY be logged in the appropriate
system audit file.
(a) イベント(INVALID SPI)は適切なシステム監査ファイルに登録されるかもしれません。
Maughan, et. al. Standards Track [Page 63] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[63ページ]。
(b) An Informational Exchange with a Notification payload
containing the INVALID-SPI message type MAY be sent to the
transmitting entity. This action is dictated by a system
security policy.
(b) NotificationペイロードがINVALID-SPIメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
3. Ensure the Proposals are presented according to the details given
in section 3.5 and 4.2. If the proposals are not formed
correctly, the following actions are taken:
3. セクション3.5と4.2に述べられる詳細に応じてProposalsが寄贈されるのを確実にしてください。 正しく提案を形成しないなら、以下の行動を取ります:
(a) Possible events, BAD PROPOSAL SYNTAX, INVALID PROPOSAL, are
logged in the appropriate system audit file.
(a) 可能なイベント(BAD PROPOSAL SYNTAX、INVALID PROPOSAL)は適切なシステム監査ファイルに登録されます。
(b) An Informational Exchange with a Notification payload
containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED
message type MAY be sent to the transmitting entity. This
action is dictated by a system security policy.
(b) NotificationペイロードがBAD-PROPOSAL-SYNTAXか有効搭載量MALFORMEDメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
4. Process the Proposal and Transform payloads as defined by the
Next Payload field. Examples of processing these payloads are
given in section 4.2.1.
4. Next有効搭載量分野によって定義されるようにProposalとTransformペイロードを処理してください。 これらのペイロードを処理する例はセクション4.2.1で出されます。
5.6 Transform Payload Processing
5.6 変換有効搭載量処理
When creating a Transform Payload, the transmitting entity (initiator or responder) MUST do the following:
Transform有効搭載量を作成するとき、伝える実体(創始者か応答者)は以下をしなければなりません:
1. Determine the Transform # for this transform.
1. これのためのTransform#が変形することを決定してください。
2. Determine the number of transforms to be offered for this
proposal. Transforms are described in sections 3.6.
2. 変換の数がこの提案のために提供されることを決定してください。 変換はセクション3.6で説明されます。
3. Construct a Transform payload.
3. Transformペイロードを構成してください。
When a Transform payload is received, the receiving entity (initiator or responder) MUST do the following:
Transformペイロードが受け取られているとき、受信実体(創始者か応答者)は以下をしなければなりません:
1. Determine if the Transform is supported. If the Transform-ID
field contains an unknown or unsupported value, then that
Transform payload MUST be ignored and MUST NOT cause the
generation of an INVALID TRANSFORM event. If the Transform-ID
field is invalid, the payload is discarded and the following
actions are taken:
1. Transformがサポートされるかどうか決定してください。 Transform-ID分野が未知の、または、サポートされない値を含んでいるなら、そのTransformペイロードは、無視しなければならなくて、INVALID TRANSFORMイベントの世代を引き起こしてはいけません。 Transform-ID分野が無効であるなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID TRANSFORM, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID TRANSFORM)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-TRANSFORM-ID message type MAY be sent
(b) NotificationペイロードがINVALID-TRANSFORM-IDメッセージタイプを含んでいるInformational Exchangeを送るかもしれません。
Maughan, et. al. Standards Track [Page 64] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[64ページ]。
to the transmitting entity. This action is dictated by a
system security policy.
伝える実体に。 この動作はシステム安全保障政策で書き取られます。
2. Ensure the Transforms are presented according to the details
given in section 3.6 and 4.2. If the transforms are not formed
correctly, the following actions are taken:
2. セクション3.6と4.2に述べられる詳細に応じてTransformsが寄贈されるのを確実にしてください。 正しく変換を形成しないなら、以下の行動を取ります:
(a) Possible events, BAD PROPOSAL SYNTAX, INVALID TRANSFORM,
INVALID ATTRIBUTES, are logged in the appropriate system
audit file.
(a) 可能なイベント(BAD PROPOSAL SYNTAX、INVALID TRANSFORM、INVALID ATTRIBUTES)は適切なシステム監査ファイルに登録されます。
(b) An Informational Exchange with a Notification payload
containing the BAD-PROPOSAL-SYNTAX, PAYLOAD-MALFORMED or
ATTRIBUTES-NOT-SUPPORTED message type MAY be sent to the
transmitting entity. This action is dictated by a system
security policy.
(b) NotificationペイロードがBAD-PROPOSAL-SYNTAXを含んでいるInformational Exchange、有効搭載量MALFORMEDかATTRIBUTES NOT SUPPORTEDメッセージタイプを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
3. Process the subsequent Transform and Proposal payloads as defined
by the Next Payload field. Examples of processing these payloads
are given in section 4.2.1.
3. Next有効搭載量分野によって定義されるようにその後のTransformとProposalペイロードを処理してください。 これらのペイロードを処理する例はセクション4.2.1で出されます。
5.7 Key Exchange Payload Processing
5.7 主要な交換有効搭載量処理
When creating a Key Exchange Payload, the transmitting entity (initiator or responder) MUST do the following:
Key Exchange有効搭載量を作成するとき、伝える実体(創始者か応答者)は以下をしなければなりません:
1. Determine the Key Exchange to be used as defined by the DOI.
1. DOIによって定義されるようにKey Exchangeが使用されることを決定してください。
2. Determine the usage of the Key Exchange Data field as defined by
the DOI.
2. DOIによって定義されるようにKey Exchange Data分野の用法を決定してください。
3. Construct a Key Exchange payload.
3. Key Exchangeペイロードを構成してください。
4. Transmit the message to the receiving entity as described in
section 5.1.
4. セクション5.1で説明されるように受信実体にメッセージを送ってください。
When a Key Exchange payload is received, the receiving entity (initiator or responder) MUST do the following:
Key Exchangeペイロードが受け取られているとき、受信実体(創始者か応答者)は以下をしなければなりません:
1. Determine if the Key Exchange is supported. If the Key Exchange
determination fails, the message is discarded and the following
actions are taken:
1. Key Exchangeがサポートされるかどうか決定してください。 Key Exchange決断が失敗するなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID KEY INFORMATION, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID KEY INFORMATION)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-KEY-INFORMATION message type MAY be
(b) NotificationペイロードがINVALID-KEY-情報メッセージタイプを含んでいるInformational Exchangeはそうです。
Maughan, et. al. Standards Track [Page 65] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[65ページ]。
sent to the transmitting entity. This action is dictated by
a system security policy.
伝える実体に発信しました。 この動作はシステム安全保障政策で書き取られます。
5.8 Identification Payload Processing
5.8 識別有効搭載量処理
When creating an Identification Payload, the transmitting entity (initiator or responder) MUST do the following:
Identification有効搭載量を作成するとき、伝える実体(創始者か応答者)は以下をしなければなりません:
1. Determine the Identification information to be used as defined by
the DOI (and possibly the situation).
1. DOI(そして、ことによると状況)によって定義されるようにIdentification情報が使用されることを決定してください。
2. Determine the usage of the Identification Data field as defined
by the DOI.
2. DOIによって定義されるようにIdentification Data分野の用法を決定してください。
3. Construct an Identification payload.
3. Identificationペイロードを構成してください。
4. Transmit the message to the receiving entity as described in
section 5.1.
4. セクション5.1で説明されるように受信実体にメッセージを送ってください。
When an Identification payload is received, the receiving entity (initiator or responder) MUST do the following:
Identificationペイロードが受け取られているとき、受信実体(創始者か応答者)は以下をしなければなりません:
1. Determine if the Identification Type is supported. This may be
based on the DOI and Situation. If the Identification
determination fails, the message is discarded and the following
actions are taken:
1. Identification Typeがサポートされるかどうか決定してください。 これはDOIとSituationに基づくかもしれません。 Identification決断が失敗するなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID ID INFORMATION, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID ID INFORMATION)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-ID-INFORMATION message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
(b) NotificationペイロードがINVALID ID情報メッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
5.9 Certificate Payload Processing
5.9 証明書有効搭載量処理
When creating a Certificate Payload, the transmitting entity (initiator or responder) MUST do the following:
Certificate有効搭載量を作成するとき、伝える実体(創始者か応答者)は以下をしなければなりません:
1. Determine the Certificate Encoding to be used. This may be
specified by the DOI.
1. Certificate Encodingが使用されることを決定してください。 これはDOIによって指定されるかもしれません。
2. Ensure the existence of a certificate formatted as defined by the
Certificate Encoding.
2. Certificate Encodingによって定義されるようにフォーマットされた証明書の存在を確実にしてください。
3. Construct a Certificate payload.
3. Certificateペイロードを構成してください。
Maughan, et. al. Standards Track [Page 66] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[66ページ]。
4. Transmit the message to the receiving entity as described in
section 5.1.
4. セクション5.1で説明されるように受信実体にメッセージを送ってください。
When a Certificate payload is received, the receiving entity (initiator or responder) MUST do the following:
Certificateペイロードが受け取られているとき、受信実体(創始者か応答者)は以下をしなければなりません:
1. Determine if the Certificate Encoding is supported. If the
Certificate Encoding is not supported, the payload is discarded
and the following actions are taken:
1. Certificate Encodingがサポートされるかどうか決定してください。 Certificate Encodingをサポートしないなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID CERTIFICATE TYPE)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-CERT-ENCODING message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
(b) NotificationペイロードがINVALID-CERT-ENCODINGメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
2. Process the Certificate Data field. If the Certificate Data is
invalid or improperly formatted, the payload is discarded and the
following actions are taken:
2. Certificate Data分野を処理してください。 Certificate Dataが無効であるか不適切にフォーマットしているなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID CERTIFICATE, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID CERTIFICATE)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-CERTIFICATE message type MAY be sent
to the transmitting entity. This action is dictated by a
system security policy.
(b) NotificationペイロードがINVALID-CERTIFICATEメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
5.10 Certificate Request Payload Processing
5.10 証明書要求有効搭載量処理
When creating a Certificate Request Payload, the transmitting entity (initiator or responder) MUST do the following:
Certificate Request有効搭載量を作成するとき、伝える実体(創始者か応答者)は以下をしなければなりません:
1. Determine the type of Certificate Encoding to be requested. This
may be specified by the DOI.
1. Certificate Encodingのタイプが要求されていることを決定してください。 これはDOIによって指定されるかもしれません。
2. Determine the name of an acceptable Certificate Authority which
is to be requested (if applicable).
2. 要求されていることになっている許容できるCertificate Authorityという名前を決定してください(適切であるなら)。
3. Construct a Certificate Request payload.
3. Certificate Requestペイロードを構成してください。
4. Transmit the message to the receiving entity as described in
section 5.1.
4. セクション5.1で説明されるように受信実体にメッセージを送ってください。
When a Certificate Request payload is received, the receiving entity (initiator or responder) MUST do the following:
Certificate Requestペイロードが受け取られているとき、受信実体(創始者か応答者)は以下をしなければなりません:
Maughan, et. al. Standards Track [Page 67] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[67ページ]。
1. Determine if the Certificate Encoding is supported. If the
Certificate Encoding is invalid, the payload is discarded and the
following actions are taken:
1. Certificate Encodingがサポートされるかどうか決定してください。 Certificate Encodingが無効であるなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID CERTIFICATE TYPE, MAY be logged in
the appropriate system audit file.
(a) イベント(INVALID CERTIFICATE TYPE)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-CERT-ENCODING message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
(b) NotificationペイロードがINVALID-CERT-ENCODINGメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
If the Certificate Encoding is not supported, the payload is
discarded and the following actions are taken:
Certificate Encodingをサポートしないなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, CERTIFICATE TYPE UNSUPPORTED, MAY be logged in
the appropriate system audit file.
(a) イベント(CERTIFICATE TYPE UNSUPPORTED)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the CERT-TYPE-UNSUPPORTED message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
(b) NotificationペイロードがCERT-TYPE-UNSUPPORTEDメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
2. Determine if the Certificate Authority is supported for the
specified Certificate Encoding. If the Certificate Authority is
invalid or improperly formatted, the payload is discarded and the
following actions are taken:
2. Certificate Authorityが指定されたCertificate Encodingのためにサポートされるかどうか決定してください。 Certificate Authorityが無効であるか不適切にフォーマットしているなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID CERTIFICATE AUTHORITY, MAY be logged in
the appropriate system audit file.
(a) イベント(INVALID CERTIFICATE AUTHORITY)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-CERT-AUTHORITY message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
(b) NotificationペイロードがINVALID-CERT-AUTHORITYメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
3. Process the Certificate Request. If a requested Certificate Type
with the specified Certificate Authority is not available, then
the payload is discarded and the following actions are taken:
3. 証明書要求を処理してください。 指定されたCertificate Authorityと要求されたCertificate Typeが利用可能でないなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, CERTIFICATE-UNAVAILABLE, MAY be logged in the
appropriate system audit file.
(a) イベント(CERTIFICATE-UNAVAILABLE)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the CERTIFICATE-UNAVAILABLE message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
(b) NotificationペイロードがCERTIFICATE-UNAVAILABLEメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
Maughan, et. al. Standards Track [Page 68] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[68ページ]。
5.11 Hash Payload Processing
5.11 ハッシュ有効搭載量処理
When creating a Hash Payload, the transmitting entity (initiator or responder) MUST do the following:
Hash有効搭載量を作成するとき、伝える実体(創始者か応答者)は以下をしなければなりません:
1. Determine the Hash function to be used as defined by the SA
negotiation.
1. SA交渉で定義されるようにHash機能が使用されることを決定してください。
2. Determine the usage of the Hash Data field as defined by the DOI.
2. DOIによって定義されるようにHash Data分野の用法を決定してください。
3. Construct a Hash payload.
3. Hashペイロードを構成してください。
4. Transmit the message to the receiving entity as described in
section 5.1.
4. セクション5.1で説明されるように受信実体にメッセージを送ってください。
When a Hash payload is received, the receiving entity (initiator or responder) MUST do the following:
Hashペイロードが受け取られているとき、受信実体(創始者か応答者)は以下をしなければなりません:
1. Determine if the Hash is supported. If the Hash determination
fails, the message is discarded and the following actions are
taken:
1. Hashがサポートされるかどうか決定してください。 Hash決断が失敗するなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID HASH INFORMATION, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID HASH INFORMATION)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-HASH-INFORMATION message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
(b) NotificationペイロードがINVALID-HASH-情報メッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
2. Perform the Hash function as outlined in the DOI and/or Key
Exchange protocol documents. If the Hash function fails, the
message is discarded and the following actions are taken:
2. DOI、そして/または、Key Exchangeプロトコルドキュメントに概説されているようにHash機能を実行してください。 Hash機能が失敗するなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID HASH VALUE, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID HASH VALUE)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the AUTHENTICATION-FAILED message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
(b) NotificationペイロードがAUTHENTICATION-FAILEDメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
5.12 Signature Payload Processing
5.12 署名有効搭載量処理
When creating a Signature Payload, the transmitting entity (initiator or responder) MUST do the following:
Signature有効搭載量を作成するとき、伝える実体(創始者か応答者)は以下をしなければなりません:
Maughan, et. al. Standards Track [Page 69] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[69ページ]。
1. Determine the Signature function to be used as defined by the SA
negotiation.
1. SA交渉で定義されるようにSignature機能が使用されることを決定してください。
2. Determine the usage of the Signature Data field as defined by the
DOI.
2. DOIによって定義されるようにSignature Data分野の用法を決定してください。
3. Construct a Signature payload.
3. Signatureペイロードを構成してください。
4. Transmit the message to the receiving entity as described in
section 5.1.
4. セクション5.1で説明されるように受信実体にメッセージを送ってください。
When a Signature payload is received, the receiving entity (initiator or responder) MUST do the following:
Signatureペイロードが受け取られているとき、受信実体(創始者か応答者)は以下をしなければなりません:
1. Determine if the Signature is supported. If the Signature
determination fails, the message is discarded and the following
actions are taken:
1. Signatureがサポートされるかどうか決定してください。 Signature決断が失敗するなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID SIGNATURE INFORMATION, MAY be logged in
the appropriate system audit file.
(a) イベント(INVALID SIGNATURE INFORMATION)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the INVALID-SIGNATURE message type MAY be sent to
the transmitting entity. This action is dictated by a
system security policy.
(b) NotificationペイロードがINVALID-SIGNATUREメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
2. Perform the Signature function as outlined in the DOI and/or Key
Exchange protocol documents. If the Signature function fails,
the message is discarded and the following actions are taken:
2. DOI、そして/または、Key Exchangeプロトコルドキュメントに概説されているようにSignature機能を実行してください。 Signature機能が失敗するなら、メッセージは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID SIGNATURE VALUE, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID SIGNATURE VALUE)は適切なシステム監査ファイルに登録されるかもしれません。
(b) An Informational Exchange with a Notification payload
containing the AUTHENTICATION-FAILED message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
(b) NotificationペイロードがAUTHENTICATION-FAILEDメッセージタイプを含んでいるInformational Exchangeを伝える実体に送るかもしれません。 この動作はシステム安全保障政策で書き取られます。
5.13 Nonce Payload Processing
5.13 一回だけの有効搭載量処理
When creating a Nonce Payload, the transmitting entity (initiator or responder) MUST do the following:
Nonce有効搭載量を作成するとき、伝える実体(創始者か応答者)は以下をしなければなりません:
1. Create a unique random value to be used as a nonce.
1. ユニークな無作為の値を作成して、一回だけとして使用されてください。
2. Construct a Nonce payload.
2. Nonceペイロードを構成してください。
Maughan, et. al. Standards Track [Page 70] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[70ページ]。
3. Transmit the message to the receiving entity as described in
section 5.1.
3. セクション5.1で説明されるように受信実体にメッセージを送ってください。
When a Nonce payload is received, the receiving entity (initiator or responder) MUST do the following:
Nonceペイロードが受け取られているとき、受信実体(創始者か応答者)は以下をしなければなりません:
1. There are no specific procedures for handling Nonce payloads.
The procedures are defined by the exchange types (and possibly
the DOI and Key Exchange descriptions).
1. 取り扱いNonceペイロードのためのどんな特定の手順もありません。 手順は交換タイプ(そして、ことによるとDOIとKey Exchange記述)によって定義されます。
5.14 Notification Payload Processing
5.14 通知有効搭載量処理
During communications it is possible that errors may occur. The Informational Exchange with a Notify Payload provides a controlled method of informing a peer entity that errors have occurred during protocol processing. It is RECOMMENDED that Notify Payloads be sent in a separate Informational Exchange rather than appending a Notify Payload to an existing exchange.
コミュニケーションの間、誤りが発生するのは、可能です。 Notify有効搭載量があるInformational Exchangeは誤りがプロトコル処理の間発生していることを同輩実体に知らせる制御メソッドを提供します。 Notify有効搭載量を既存の交換に追加するより別々のInformational ExchangeでむしろNotify有効搭載量を送るのは、RECOMMENDEDです。
When creating a Notification Payload, the transmitting entity (initiator or responder) MUST do the following:
Notification有効搭載量を作成するとき、伝える実体(創始者か応答者)は以下をしなければなりません:
1. Determine the DOI for this Notification.
1. このNotificationのためにDOIを決定してください。
2. Determine the Protocol-ID for this Notification.
2. このNotificationのためにProtocol IDを決定してください。
3. Determine the SPI size based on the Protocol-ID field. This
field is necessary because different security protocols have
different SPI sizes. For example, ISAKMP combines the Initiator
and Responder cookie pair (16 octets) as a SPI, while ESP and AH
have 4 octet SPIs.
3. Protocol ID分野に基づくSPIサイズを決定してください。 異なったセキュリティプロトコルには異なったSPIサイズがあるので、この分野が必要です。 例えば、ISAKMPはSPIとしてInitiatorとResponderクッキー組(16の八重奏)を合併します、超能力とAHには4八重奏SPIsがありますが。
4. Determine the Notify Message Type based on the error or status
message desired.
4. 誤りかステータスメッセージに基づいたNotify Message Typeが望んでいたことを決定してください。
5. Determine the SPI which is associated with this notification.
5. この通知に関連しているSPIを決定してください。
6. Determine if additional Notification Data is to be included.
This is additional information specified by the DOI.
6. 追加Notification Dataが含まれるつもりであるかどうか決定してください。 これはDOIによって指定された追加情報です。
7. Construct a Notification payload.
7. Notificationペイロードを構成してください。
8. Transmit the message to the receiving entity as described in
section 5.1.
8. セクション5.1で説明されるように受信実体にメッセージを送ってください。
Because the Informational Exchange with a Notification payload is a unidirectional message a retransmission will not be performed. The local security policy will dictate the procedures for continuing.
NotificationペイロードがあるInformational Exchangeが単方向のメッセージであるので、「再-トランスミッション」は実行されないでしょう。 ローカルの安全保障政策は続くための手順を決めるでしょう。
Maughan, et. al. Standards Track [Page 71] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[71ページ]。
However, we RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be logged in the appropriate system audit file by the receiving entity.
しかしながら、私たち、NOTIFICATION PAYLOAD ERRORイベントをあるRECOMMENDが受信実体で適切なシステム監査ファイルにログインしました。
If the Informational Exchange occurs prior to the exchange of keying material during an ISAKMP Phase 1 negotiation there will be no protection provided for the Informational Exchange. Once the keying material has been exchanged or the ISAKMP SA has been established, the Informational Exchange MUST be transmitted under the protection provided by the keying material or the ISAKMP SA.
Informational Exchangeが交換の前に起こると、ISAKMP Phaseの間、材料を合わせるのにおいて、そこでの1つの交渉がInformational Exchangeに提供されたノー・プロテクションになるでしょう。 いったん合わせることの材料を交換したか、またはISAKMP SAを設立すると、合わせることの材料かISAKMP SAによって提供された保護でInformational Exchangeを伝えなければなりません。
When a Notification payload is received, the receiving entity (initiator or responder) MUST do the following:
Notificationペイロードが受け取られているとき、受信実体(創始者か応答者)は以下をしなければなりません:
1. Determine if the Informational Exchange has any protection
applied to it by checking the Encryption Bit and the
Authentication Only Bit in the ISAKMP Header. If the Encryption
Bit is set, i.e. the Informational Exchange is encrypted, then
the message MUST be decrypted using the (in-progress or
completed) ISAKMP SA. Once the decryption is complete the
processing can continue as described below. If the
Authentication Only Bit is set, then the message MUST be
authenticated using the (in-progress or completed) ISAKMP SA.
Once the authentication is completed, the processing can continue
as described below. If the Informational Exchange is not
encrypted or authentication, the payload processing can continue
as described below.
1. Informational Exchangeが何か保護をISAKMP HeaderでEncryption BitとAuthentication Only Bitをチェックすることによってそれに適用させるかどうか決定してください。 Encryption Bitが用意ができているなら、すなわち、Informational Exchangeが暗号化されている、そして、(進行中か完成する)のISAKMP SAを使用して、メッセージを解読しなければなりません。 復号化がいったん完全になると、処理は以下で説明されるように続くことができます。 Authentication Only Bitが用意ができているなら、(進行中か完成する)のISAKMP SAを使用して、メッセージを認証しなければなりません。 処理は、以下で説明されるように一度、認証が終了してい続けることができます。 Informational Exchangeが暗号化していないか、または認証、ペイロード処理が暗号化できるなら、以下で説明されるように、続いてください。
2. Determine if the Domain of Interpretation (DOI) is supported. If
the DOI determination fails, the payload is discarded and the
following action is taken:
2. Interpretation(DOI)のDomainがサポートされるかどうか決定してください。 DOI決断が失敗するなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID DOI, MAY be logged in the appropriate
system audit file.
(a) イベント(INVALID DOI)は適切なシステム監査ファイルに登録されるかもしれません。
3. Determine if the Protocol-Id is supported. If the Protocol-Id
determination fails, the payload is discarded and the following
action is taken:
3. プロトコルイドがサポートされるかどうか決定してください。 プロトコルイド決断が失敗するなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID PROTOCOL-ID, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID PROTOCOL-ID)は適切なシステム監査ファイルに登録されるかもしれません。
4. Determine if the SPI is valid. If the SPI is invalid, the
payload is discarded and the following action is taken:
4. SPIが有効であるかどうか決定してください。 SPIが無効であるなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID SPI, MAY be logged in the appropriate
system audit file.
(a) イベント(INVALID SPI)は適切なシステム監査ファイルに登録されるかもしれません。
Maughan, et. al. Standards Track [Page 72] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[72ページ]。
5. Determine if the Notify Message Type is valid. If the Notify
Message Type is invalid, the payload is discarded and the
following action is taken:
5. Notify Message Typeが有効であるかどうか決定してください。 Notify Message Typeが無効であるなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID MESSAGE TYPE, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID MESSAGE TYPE)は適切なシステム監査ファイルに登録されるかもしれません。
6. Process the Notification payload, including additional
Notification Data, and take appropriate action, according to
local security policy.
6. 追加Notification Dataを含むNotificationペイロードを処理してください、そして、ローカルの安全保障政策に従って、適切な行動を取ってください。
5.15 Delete Payload Processing
5.15は有効搭載量処理を削除します。
During communications it is possible that hosts may be compromised or that information may be intercepted during transmission. Determining whether this has occurred is not an easy task and is outside the scope of this memo. However, if it is discovered that transmissions are being compromised, then it is necessary to establish a new SA and delete the current SA.
コミュニケーションの間、ホストが感染されるかもしれないか、または情報がトランスミッションの間傍受されるのが、可能です。 これが起こったかどうか決定するのを、楽な仕事でなく、このメモの範囲の外にあります。 しかしながら、トランスミッションが感染されていると発見されるなら、新しいSAを設立して、現在のSAを削除するのが必要です。
The Informational Exchange with a Delete Payload provides a controlled method of informing a peer entity that the transmitting entity has deleted the SA(s). Deletion of Security Associations MUST always be performed under the protection of an ISAKMP SA. The receiving entity SHOULD clean up its local SA database. However, upon receipt of a Delete message the SAs listed in the Security Parameter Index (SPI) field of the Delete payload cannot be used with the transmitting entity. The SA Establishment procedure must be invoked to re-establish secure communications.
Delete有効搭載量があるInformational Exchangeは伝える実体がSA(s)を削除したことを同輩実体に知らせる制御メソッドを提供します。 いつもISAKMP SAの保護でSecurity Associationsの削除を実行しなければなりません。 受信実体SHOULDはローカルのSAデータベースをきれいにします。 しかしながら、Deleteメッセージを受け取り次第、伝える実体と共にDeleteペイロードのSecurity Parameter Index(SPI)分野に記載されたSAsは使用できません。 安全なコミュニケーションを復職させるためにSA特権階級手順を呼び出さなければなりません。
When creating a Delete Payload, the transmitting entity (initiator or responder) MUST do the following:
Delete有効搭載量を作成するとき、伝える実体(創始者か応答者)は以下をしなければなりません:
1. Determine the DOI for this Deletion.
1. このDeletionのためにDOIを決定してください。
2. Determine the Protocol-ID for this Deletion.
2. このDeletionのためにProtocol IDを決定してください。
3. Determine the SPI size based on the Protocol-ID field. This
field is necessary because different security protocols have
different SPI sizes. For example, ISAKMP combines the Initiator
and Responder cookie pair (16 octets) as a SPI, while ESP and AH
have 4 octet SPIs.
3. Protocol ID分野に基づくSPIサイズを決定してください。 異なったセキュリティプロトコルには異なったSPIサイズがあるので、この分野が必要です。 例えば、ISAKMPはSPIとしてInitiatorとResponderクッキー組(16の八重奏)を合併します、超能力とAHには4八重奏SPIsがありますが。
4. Determine the # of SPIs to be deleted for this protocol.
4. SPIsの#、がこのプロトコルのために削除されることを決定してください。
5. Determine the SPI(s) which is (are) associated with this
deletion.
5. この削除に関連づけられる(あります)SPI(s)を決定してください。
Maughan, et. al. Standards Track [Page 73] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[73ページ]。
6. Construct a Delete payload.
6. Deleteペイロードを構成してください。
7. Transmit the message to the receiving entity as described in
section 5.1.
7. セクション5.1で説明されるように受信実体にメッセージを送ってください。
Because the Informational Exchange with a Delete payload is a unidirectional message a retransmission will not be performed. The local security policy will dictate the procedures for continuing. However, we RECOMMEND that a DELETE PAYLOAD ERROR event be logged in the appropriate system audit file by the receiving entity.
DeleteペイロードがあるInformational Exchangeが単方向のメッセージであるので、「再-トランスミッション」は実行されないでしょう。 ローカルの安全保障政策は続くための手順を決めるでしょう。 しかしながら、私たち、DELETE PAYLOAD ERRORイベントをあるRECOMMENDが受信実体で適切なシステム監査ファイルにログインしました。
As described above, the Informational Exchange with a Delete payload MUST be transmitted under the protection provided by an ISAKMP SA.
上で説明されるように、ISAKMP SAによって提供された保護でDeleteペイロードがあるInformational Exchangeを伝えなければなりません。
When a Delete payload is received, the receiving entity (initiator or responder) MUST do the following:
Deleteペイロードが受け取られているとき、受信実体(創始者か応答者)は以下をしなければなりません:
1. Because the Informational Exchange is protected by some security
service (e.g. authentication for an Auth-Only SA, encryption for
other exchanges), the message MUST have these security services
applied using the ISAKMP SA. Once the security service processing
is complete the processing can continue as described below. Any
errors that occur during the security service processing will be
evident when checking information in the Delete payload. The
local security policy SHOULD dictate any action to be taken as a
result of security service processing errors.
1. 何らかのセキュリティー・サービス(例えば、AuthだけSAのための認証、他の交換のための暗号化)でInformational Exchangeが保護されるので、メッセージで、ISAKMP SAを使用することでこれらのセキュリティー・サービスを適用しなければなりません。 セキュリティー・サービス処理がいったん完全になると、処理は以下で説明されるように続くことができます。 Deleteペイロードの情報をチェックするとき、セキュリティー・サービス処理の間に発生するどんな誤りも明白になるでしょう。 ローカルの安全保障政策SHOULDは、セキュリティー・サービス整理過程の誤差の結果、取るためにどんな動作も書き取ります。
2. Determine if the Domain of Interpretation (DOI) is supported. If
the DOI determination fails, the payload is discarded and the
following action is taken:
2. Interpretation(DOI)のDomainがサポートされるかどうか決定してください。 DOI決断が失敗するなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID DOI, MAY be logged in the appropriate
system audit file.
(a) イベント(INVALID DOI)は適切なシステム監査ファイルに登録されるかもしれません。
3. Determine if the Protocol-Id is supported. If the Protocol-Id
determination fails, the payload is discarded and the following
action is taken:
3. プロトコルイドがサポートされるかどうか決定してください。 プロトコルイド決断が失敗するなら、ペイロードは捨てます、そして、以下の行動を取ります:
(a) The event, INVALID PROTOCOL-ID, MAY be logged in the
appropriate system audit file.
(a) イベント(INVALID PROTOCOL-ID)は適切なシステム監査ファイルに登録されるかもしれません。
4. Determine if the SPI is valid for each SPI included in the Delete
payload. For each SPI that is invalid, the following action is
taken:
4. Deleteペイロードに各SPIを含んでいるのに、SPIが有効であるかどうか決定してください。 それぞれの無効のSPIにおいて、以下の行動を取ります:
(a) The event, INVALID SPI, MAY be logged in the appropriate
system audit file.
(a) イベント(INVALID SPI)は適切なシステム監査ファイルに登録されるかもしれません。
Maughan, et. al. Standards Track [Page 74] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[74ページ]。
5. Process the Delete payload and take appropriate action, according
to local security policy. As described above, one appropriate
action SHOULD include cleaning up the local SA database.
5. Deleteペイロードを処理してください、そして、ローカルの安全保障政策に従って、適切な行動を取ってください。 上で説明されるように、1つの適切な行動のSHOULDは、ローカルのSAデータベースをきれいにするのを含んでいます。
6 Conclusions
6つの結論
The Internet Security Association and Key Management Protocol (ISAKMP) is a well designed protocol aimed at the Internet of the future. The massive growth of the Internet will lead to great diversity in network utilization, communications, security requirements, and security mechanisms. ISAKMP contains all the features that will be needed for this dynamic and expanding communications environment.
インターネットSecurity AssociationとKey Managementプロトコル(ISAKMP)は未来のインターネットが向けられたよく設定されたプロトコルです。 インターネットの大規模な成長はネットワーク利用、コミュニケーション、セキュリティ要件、およびセキュリティー対策のかなりの多様性につながるでしょう。ISAKMPはこのダイナミックで拡張しているコミュニケーション環境に必要であるすべての特徴を含んでいます。
ISAKMP's Security Association (SA) feature coupled with authentication and key establishment provides the security and flexibility that will be needed for future growth and diversity. This security diversity of multiple key exchange techniques, encryption algorithms, authentication mechanisms, security services, and security attributes will allow users to select the appropriate security for their network, communications, and security needs. The SA feature allows users to specify and negotiate security requirements with other users. An additional benefit of supporting multiple techniques in a single protocol is that as new techniques are developed they can easily be added to the protocol. This provides a path for the growth of Internet security services. ISAKMP supports both publicly or privately defined SAs, making it ideal for government, commercial, and private communications.
認証と主要な設立に結びつけられたISAKMPのSecurity Association(SA)の特徴は今後の成長と多様性に必要であるセキュリティと柔軟性を提供します。 複数の主要な取引技術、暗号化アルゴリズム、認証機構、セキュリティー・サービス、およびセキュリティー属性のこのセキュリティの多様性で、ユーザは彼らのネットワーク、コミュニケーション、および安全要求のために適切なセキュリティを選択できるでしょう。 SAの特徴で、ユーザは、他のユーザとセキュリティ要件を指定して、交渉します。 ただ一つのプロトコルの複数のテクニックをサポートする追加利益は新しいやり方が開発されているので容易にそれらをプロトコルに追加できるということです。 これはインターネットセキュリティー・サービスの成長に経路を提供します。 ISAKMPはそれを政府に理想的であるのと、商業にする公的か個人的に定義されたSAsと私信の両方をサポートします。
ISAKMP provides the ability to establish SAs for multiple security protocols and applications. These protocols and applications may be session-oriented or sessionless. Having one SA establishment protocol that supports multiple security protocols eliminates the need for multiple, nearly identical authentication, key exchange and SA establishment protocols when more than one security protocol is in use or desired. Just as IP has provided the common networking layer for the Internet, a common security establishment protocol is needed if security is to become a reality on the Internet. ISAKMP provides the common base that allows all other security protocols to interoperate.
ISAKMPは複数のセキュリティプロトコルとアプリケーションのためにSAsを設立する能力を提供します。 これらのプロトコルとアプリケーションは、セッション指向である、またはsessionlessであるかもしれません。 1つ以上のセキュリティプロトコルが使用中であるか、または必要であるときに、複数のセキュリティがプロトコルであるとサポートする有1SA設立プロトコルが複数の、そして、ほとんど同じ認証、主要な交換、およびSA設立プロトコルの必要性を排除します。 ちょうどIPが一般的なネットワーク層をインターネットに提供したように、セキュリティがインターネットの現実のものになるつもりであるなら、共通の安全保障設立プロトコルが必要です。 ISAKMPは他のすべてのセキュリティプロトコルが共同利用する一般的なベースを供給します。
ISAKMP follows good security design principles. It is not coupled to other insecure transport protocols, therefore it is not vulnerable or weakened by attacks on other protocols. Also, when more secure transport protocols are developed, ISAKMP can be easily migrated to them. ISAKMP also provides protection against protocol related attacks. This protection provides the assurance that the SAs and keys established are with the desired party and not with an attacker.
ISAKMPは優れた警備体制設計原理に従います。 他の不安定なトランスポート・プロトコルと結合されないで、したがって、それは、被害を受け易くなく、他のプロトコルに対する攻撃で弱められます。 また、より安全なトランスポート・プロトコルが開発されているとき、ISAKMPは容易に移行しているそれらであるかもしれません。 また、ISAKMPはプロトコルに対する保護に関連する攻撃を提供します。 この保護は設立されたSAsとキーが攻撃者と共にいるのではなく、必要なパーティーと共にあるという保証を提供します。
Maughan, et. al. Standards Track [Page 75] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[75ページ]。
ISAKMP also follows good protocol design principles. Protocol specific information only is in the protocol header, following the design principles of IPv6. The data transported by the protocol is separated into functional payloads. As the Internet grows and evolves, new payloads to support new security functionality can be added without modifying the entire protocol.
また、ISAKMPは良いプロトコル設計原理に従います。 IPv6の設計原理に従って、プロトコル特殊情報がプロトコルヘッダーにあるだけです。 プロトコルによって輸送されたデータは機能的なペイロードに切り離されます。 インターネットが成長して、発展するとき、全体のプロトコルを変更しないで、新しいセキュリティが機能性であるとサポートする新しいペイロードを加えることができます。
Maughan, et. al. Standards Track [Page 76] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[76ページ]。
A ISAKMP Security Association Attributes
ISAKMPセキュリティ協会属性
A.1 Background/Rationale
A.1バックグラウンド/原理
As detailed in previous sections, ISAKMP is designed to provide a flexible and extensible framework for establishing and managing Security Associations and cryptographic keys. The framework provided by ISAKMP consists of header and payload definitions, exchange types for guiding message and payload exchanges, and general processing guidelines. ISAKMP does not define the mechanisms that will be used to establish and manage Security Associations and cryptographic keys in an authenticated and confidential manner. The definition of mechanisms and their application is the purview of individual Domains of Interpretation (DOIs).
前項で詳しく述べられるように、ISAKMPはSecurity Associationsと暗号化キーを設立して、管理するのにフレキシブルで広げることができるフレームワークを提供するように設計されています。 ISAKMPによって提供されたフレームワークはヘッダーとペイロード定義から成ります、と交換は誘導しているメッセージ、ペイロード交換、および一般的な処理ガイドラインのためにタイプします。 ISAKMPは認証されて秘密の方法でSecurity Associationsと暗号化キーを設立して、管理するのに使用されるメカニズムを定義しません。 メカニズムの定義と彼らのアプリケーションはInterpretation(DOIs)の個々のDomainsの範囲です。
This section describes the ISAKMP values for the Internet IP Security DOI, supported security protocols, and identification values for ISAKMP Phase 1 negotiations. The Internet IP Security DOI is MANDATORY to implement for IP Security. [Oakley] and [IKE] describe, in detail, the mechanisms and their application for establishing and managing Security Associations and cryptographic keys for IP Security.
このセクションはセキュリティプロトコルであるとサポートされたインターネットIP Security DOIのためのISAKMP値とISAKMP Phase1交渉のための識別値について説明します。 インターネットIP Security DOIはIPのためにSecurityを実装するMANDATORYです。 [オークリー]と[IKE]は詳細にIP SecurityのためにSecurity Associationsと暗号化キーを設立して、管理することのメカニズムと彼らのアプリケーションについて説明します。
A.2 Internet IP Security DOI Assigned Value
A.2インターネットIPセキュリティDOI割り当てられた値
As described in [IPDOI], the Internet IP Security DOI Assigned Number is one (1).
[IPDOI]で説明されるように、インターネットIP Security DOI Assigned Numberは1つ(1)です。
A.3 Supported Security Protocols
セキュリティプロトコルであるとサポートされたA.3
Values for supported security protocols are specified in the most recent "Assigned Numbers" RFC [STD-2]. Presented in the following table are the values for the security protocols supported by ISAKMP for the Internet IP Security DOI.
サポートしているセキュリティプロトコルのための値は最新の「規定番号」RFC[STD-2]で指定されます。 以下のテーブルに提示されているのは、インターネットIP Security DOIのためにISAKMPによってサポートされたセキュリティプロトコルのための値です。
Protocol Assigned Value
RESERVED 0
ISAKMP 1
プロトコル割り当てられた値は0ISAKMP1を予約しました。
All DOIs MUST reserve ISAKMP with a Protocol-ID of 1. All other security protocols within that DOI will be numbered accordingly.
すべてのDOIsが1のProtocol IDと共にISAKMPを予約しなければなりません。 そのDOIの中の他のすべてのセキュリティプロトコルがそれに従って、付番されるでしょう。
Security protocol values 2-15359 are reserved to IANA for future use. Values 15360-16383 are permanently reserved for private use amongst mutually consenting implementations. Such private use values are unlikely to be interoperable across different implementations.
セキュリティプロトコル値2-15359は今後の使用のためにIANAに予約されます。 値15360-16383は永久に、私的使用目的で互いに同意している実装の中で予約されます。 そのような私用値は異なった実装の向こう側に共同利用できさせそうにはありません。
Maughan, et. al. Standards Track [Page 77] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[77ページ]。
A.4 ISAKMP Identification Type Values
A.4 ISAKMP識別タイプ値
The following table lists the assigned values for the Identification Type field found in the Identification payload during a generic Phase 1 exchange, which is not for a specific protocol.
以下のテーブルは特定のプロトコルのためのものでないジェネリックPhase1交換の間にIdentificationペイロードで見つけられたIdentification Type分野に割り当てられた値を記載します。
ID Type Value
ID_IPV4_ADDR 0
ID_IPV4_ADDR_SUBNET 1
ID_IPV6_ADDR 2
ID_IPV6_ADDR_SUBNET 3
IDタイプ値のID_IPV4_ADDR0ID_IPV4_ADDR_サブネット1ID_IPV6_ADDR2ID_IPV6_ADDR_サブネット3
A.4.1 ID_IPV4_ADDR
_A.4.1ID IPV4_ADDR
The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
ID_IPV4_ADDRタイプはただ一つの4(4)八重奏IPv4アドレスを指定します。
A.4.2 ID_IPV4_ADDR_SUBNET
A.4.2ID_IPV4_ADDR_サブネット
The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, represented by two four (4) octet values. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit.
ID_IPV4_ADDR_SUBNETタイプは2つの4(4)八重奏値によって表されたさまざまなIPv4アドレスを指定します。 最初の値はIPv4アドレスです。 2番目はIPv4ネットワークマスクです。 ネットワークマスクの人(1)が、アドレスの対応するビットが固定されているのを示すことに注意してください、ゼロ(0)は「ワイルドカード」ビットを示しますが。
A.4.3 ID_IPV6_ADDR
_A.4.3ID IPV6_ADDR
The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 address.
ID_IPV6_ADDRタイプはただ一つの16(16)八重奏IPv6アドレスを指定します。
A.4.4 ID_IPV6_ADDR_SUBNET
A.4.4ID_IPV6_ADDR_サブネット
The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is an IPv6 address. The second is an IPv6 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit.
ID_IPV6_ADDR_SUBNETタイプは2つの16(16)八重奏値によって表されたさまざまなIPv6アドレスを指定します。 最初の値はIPv6アドレスです。 2番目はIPv6ネットワークマスクです。 ネットワークマスクの人(1)が、アドレスの対応するビットが固定されているのを示すことに注意してください、ゼロ(0)は「ワイルドカード」ビットを示しますが。
Maughan, et. al. Standards Track [Page 78] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[78ページ]。
B Defining a new Domain of Interpretation
Interpretationの新しいDomainを定義するB
The Internet DOI may be sufficient to meet the security requirements of a large portion of the internet community. However, some groups may have a need to customize some aspect of a DOI, perhaps to add a different set of cryptographic algorithms, or perhaps because they want to make their security-relevant decisions based on something other than a host id or user id. Also, a particular group may have a need for a new exchange type, for example to support key management for multicast groups.
インターネットDOIは、インターネット共同体の大半に関するセキュリティ必要条件を満たすために十分であるかもしれません。 しかしながら、いくつかのグループがホストイドかユーザイド以外の何かに恐らくDOIの何らかの局面をカスタム設計して、暗号アルゴリズムについて異なったセットを加えるか、または彼らが自分達のセキュリティ関連している決定を基礎づけて頂きたいので恐らく加える必要性を持っているかもしれません。 また、特定のグループには、例えばマルチキャストグループのためにかぎ管理をサポートするために、新しい交換タイプの必要があるかもしれません。
This section discusses guidelines for defining a new DOI. The full specification for the Internet DOI can be found in [IPDOI].
このセクションは新しいDOIを定義するためのガイドラインについて論じます。 [IPDOI]でインターネットDOIに、完全な仕様を見つけることができます。
Defining a new DOI is likely to be a time-consuming process. If at all possible, it is recommended that the designer begin with an existing DOI and customize only the parts that are unacceptable.
新しいDOIを定義するのは手間がかかったプロセスである傾向があります。 できれば、デザイナーが既存のDOIと共に始まって、容認できない部品だけをカスタム設計するのは、お勧めです。
If a designer chooses to start from scratch, the following MUST be defined:
デザイナーが、最初から始まるのを選ぶなら、以下を定義しなければなりません:
o A "situation": the set of information that will be used to
determine the required security services.
o 「状況」: 必要なセキュリティー・サービスを決定するのに使用される情報のセット。
o The set of security policies that must be supported.
o サポートしなければならない安全保障政策のセット。
o A scheme for naming security-relevant information, including
encryption algorithms, key exchange algorithms, etc.
o 暗号化アルゴリズムを含んでいる主要な交換アルゴリズムなどとセキュリティ関連している情報を命名することの体系
o A syntax for the specification of proposed security services,
attributes, and certificate authorities.
o 提案されたセキュリティー・サービス、属性、および認証局の仕様のための構文。
o The specific formats of the various payload contents.
o 様々なペイロード内容の特定の形式。
o Additional exchange types, if required.
o 必要なら追加交換タイプ。
B.1 Situation
B.1状況
The situation is the basis for deciding how to protect a communications channel. It must contain all of the data that will be used to determine the types and strengths of protections applied in an SA. For example, a US Department of Defense DOI would probably use unpublished algorithms and have additional special attributes to negotiate. These additional security attributes would be included in the situation.
状況はコミュニケーションチャンネルを保護する方法を決める基礎です。 それはタイプを決定するのに使用されるデータのすべてとSAで適用された保護の強さを含まなければなりません。 例えば、米国国防総省DOIはたぶん未発表のアルゴリズムを使用して、交渉する追加特別な属性を持っているでしょう。 これらの追加担保属性は状況に含まれているでしょう。
Maughan, et. al. Standards Track [Page 79] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[79ページ]。
B.2 Security Policies
B.2安全保障政策
Security policies define how various types of information must be categorized and protected. The DOI must define the set of security policies supported, because both parties in a negotiation must trust that the other party understands a situation, and will protect information appropriately, both in transit and in storage. In a corporate setting, for example, both parties in a negotiation must agree to the meaning of the term "proprietary information" before they can negotiate how to protect it.
安全保障政策はどう様々なタイプの情報を分類されて、保護しなければならないかを定義します。 DOIは交渉における双方が、相手が状況を理解して、適切に情報を保護すると信じなければならないのでサポートされた安全保障政策のセットを定義しなければなりません、トランジットとストレージにおける両方。 法人の設定では、例えば、どうそれを保護するかを交渉できる前に交渉における双方は「知的財産情報」という用語の意味に同意しなければなりません。
Note that including the required security policies in the DOI only specifies that the participating hosts understand and implement those policies in a full system context.
DOIの必要な安全保障政策を含んでいるのが、参加しているホストが完全なシステムの背景でそれらの政策を理解して、実施すると指定するだけであることに注意してください。
B.3 Naming Schemes
体系を命名するB.3
Any DOI must define a consistent way to name cryptographic algorithms, certificate authorities, etc. This can usually be done by using IANA naming conventions, perhaps with some private extensions.
どんなDOIも暗号アルゴリズム、認証局などを命名する一貫した方法を定義しなければなりません。 通常、IANA命名規則を使用して、恐らくいくつかの個人的な拡大でこれができます。
B.4 Syntax for Specifying Security Services
セキュリティー・サービスを指定するためのB.4構文
In addition to simply specifying how to name entities, the DOI must also specify the format for complete proposals of how to protect traffic under a given situation.
また、単に実体を命名する方法を指定することに加えて、DOIは与えられた状況の下でどうトラフィックを保護するかに関する完全な提案に形式を指定しなければなりません。
B.5 Payload Specification
B.5有効搭載量仕様
The DOI must specify the format of each of the payload types. For several of the payload types, ISAKMP has included fields that would have to be present across all DOI (such as a certificate authority in the certificate payload, or a key exchange identifier in the key exchange payload).
DOIはペイロードタイプ各人の形式を指定しなければなりません。 いくつかのペイロードタイプのために、ISAKMPはすべてのDOI(証明書ペイロードの認証局、または主要な交換ペイロードの主要な交換識別子などの)の向こう側に現在でなければならない分野を含んでいました。
B.6 Defining new Exchange Types
新しいExchange Typesを定義するB.6
If the basic exchange types are inadequate to meet the requirements within a DOI, a designer can define up to thirteen extra exchange types per DOI. The designer creates a new exchange type by choosing an unused exchange type value, and defining a sequence of messages composed of strings of the ISAKMP payload types.
基本的な交換タイプがDOIの中で条件を満たすために不十分であるなら、デザイナーは1DOIあたり最大13の付加的な交換タイプを定義できます。 デザイナーは未使用の交換タイプ価値を選ぶことによって、新しい交換タイプを創造します、そして、ISAKMPペイロードのストリングで構成されたメッセージの系列を定義するのはタイプされます。
Note that any new exchange types must be rigorously analyzed for vulnerabilities. Since this is an expensive and imprecise undertaking, a new exchange type should only be created when absolutely necessary.
脆弱性のためにどんな新しい交換タイプもきびしく分析しなければならないことに注意してください。 これが高価で不正確な仕事であるので、絶対に必要であるときにだけ、新しい交換タイプは創造されるべきです。
Maughan, et. al. Standards Track [Page 80] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[80ページ]。
Security Considerations
セキュリティ問題
Cryptographic analysis techniques are improving at a steady pace. The continuing improvement in processing power makes once computationally prohibitive cryptographic attacks more realistic. New cryptographic algorithms and public key generation techniques are also being developed at a steady pace. New security services and mechanisms are being developed at an accelerated pace. A consistent method of choosing from a variety of security services and mechanisms and to exchange attributes required by the mechanisms is important to security in the complex structure of the Internet. However, a system that locks itself into a single cryptographic algorithm, key exchange technique, or security mechanism will become increasingly vulnerable as time passes.
暗号の分析技術は一様の速度で向上することです。 処理能力における継続的な改善で、計算上かつての禁止の暗号の攻撃は、より現実的になります。 また、新しい暗号アルゴリズムと公開鍵世代のテクニックは一様の速度で開発することにされます。 新しいセキュリティー・サービスとメカニズムは速度を速めて開発されています。 さまざまなセキュリティー・サービスとメカニズムと、そして、メカニズムによって必要とされた交換属性への選ぶことの一貫したメソッドはインターネットの複雑な構造におけるセキュリティに重要です。 しかしながら、時間が経過するのに応じて、ただ一つの暗号アルゴリズム、主要な取引技術、またはセキュリティー対策にそれ自体をロックするシステムはますます被害を受け易くなるでしょう。
UDP is an unreliable datagram protocol and therefore its use in ISAKMP introduces a number of security considerations. Since UDP is unreliable, but a key management protocol must be reliable, the reliability is built into ISAKMP. While ISAKMP utilizes UDP as its transport mechanism, it doesn't rely on any UDP information (e.g. checksum, length) for its processing.
UDPは頼り無いデータグラムプロトコルです、そして、したがって、ISAKMPにおける使用は多くのセキュリティ問題を紹介します。 UDPが頼り無いのですが、かぎ管理プロトコルが信頼できるに違いないので、ISAKMPは信頼性に組み込まれます。 ISAKMPが移送機構としてUDPを利用している間、それは処理のための少しのUDP情報(例えば、チェックサム、長さ)も当てにしません。
Another issue that must be considered in the development of ISAKMP is the effect of firewalls on the protocol. Many firewalls filter out all UDP packets, making reliance on UDP questionable in certain environments.
ISAKMPの開発で考えなければならない別の問題はプロトコルへのファイアウォールの効果です。 UDPへの信用をある環境で疑わしくして、多くのファイアウォールがすべてのUDPパケットを無視します。
A number of very important security considerations are presented in [SEC-ARCH]. One bears repeating. Once a private session key is created, it must be safely stored. Failure to properly protect the private key from access both internal and external to the system completely nullifies any protection provided by the IP Security services.
多くの非常に重要なセキュリティ問題が[SEC-ARCH]に提示されます。 人は、繰り返すのに堪えます。 個人的なセッションキーがいったん作成されると、安全にそれを保存しなければなりません。 内部の、そして、システムへの外部の両方のアクセスから秘密鍵を適切に保護しない場合、IP Securityサービスで提供されたどんな保護も完全に無効にします。
IANA Considerations
IANA問題
This document contains many "magic" numbers to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional numbers in each of these lists.
このドキュメントはIANAによって維持される多くの「魔法」の数を含んでいます。 それぞれのこれらのリストの追加数を割り当てるのにIANAによって使用されるように、このセクションは評価基準について説明します。
Domain of Interpretation
解釈のドメイン
The Domain of Interpretation (DOI) is a 32-bit field which identifies the domain under which the security association negotiation is taking place. Requests for assignments of new DOIs must be accompanied by a standards-track RFC which describes the specific domain.
Interpretation(DOI)のDomainはセキュリティ協会交渉が行われているドメインを特定する32ビットの分野です。 特定のドメインについて説明する標準化過程RFCは新しいDOIsの課題を求める要求に伴わなければなりません。
Maughan, et. al. Standards Track [Page 81] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[81ページ]。
Supported Security Protocols
セキュリティプロトコルであるとサポートされます。
ISAKMP is designed to provide security association negotiation and key management for many security protocols. Requests for identifiers for additional security protocols must be accompanied by a standards-track RFC which describes the security protocol and its relationship to ISAKMP.
ISAKMPは、多くのセキュリティプロトコルのためのセキュリティ協会交渉とかぎ管理を提供するように設計されています。 セキュリティプロトコルとISAKMPとのその関係について説明する標準化過程RFCは追加担保プロトコルのための識別子に関する要求に伴わなければなりません。
Acknowledgements
承認
Dan Harkins, Dave Carrel, and Derrell Piper of Cisco Systems provided design assistance with the protocol and coordination for the [IKE] and [IPDOI] documents.
シスコシステムズのダン・ハーキンズ、デーヴCarrel、およびDerrellパイパーは[IKE]と[IPDOI]ドキュメントのためのプロトコルとコーディネートをデザイン支援に提供しました。
Hilarie Orman, via the Oakley key exchange protocol, has significantly influenced the design of ISAKMP.
オークリーの主要な交換プロトコルで、Hilarie OrmanはISAKMPのデザインにかなり影響を及ぼしました。
Marsha Gross, Bill Kutz, Mike Oehler, Pete Sell, and Ruth Taylor provided significant input and review to this document.
マーシャGross、ビルKutz、マイク・オーラー、ピートSell、およびルース・テイラーは重要な入力とレビューをこのドキュメントに供給しました。
Scott Carlson ported the TIS DNSSEC prototype to FreeBSD for use with the ISAKMP prototype.
スコット・カールソンは使用のためにISAKMPプロトタイプでTIS DNSSECプロトタイプを無料OSの一つに移植しました。
Jeff Turner and Steve Smalley contributed to the prototype development and integration with ESP and AH.
ジェフ・ターナーとスティーブ・スモリーは超能力とAHとのプロトタイプ開発と統合に貢献しました。
Mike Oehler and Pete Sell performed interoperability testing with other ISAKMP implementors.
マイク・オーラーとピートSellは他のISAKMP作成者との相互運用性テストを実行しました。
Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with LaTeX.
LaTeXとの彼の支援をスパルタInc.のカールMuckenhirnをありがとうございます。
References
参照
[ANSI] ANSI, X9.42: Public Key Cryptography for the Financial
Services Industry -- Establishment of Symmetric Algorithm
Keys Using Diffie-Hellman, Working Draft, April 19, 1996.
[ANSI] ANSI、X9.42: 金融サービス業界のための公開鍵暗号--1996年4月19日のディフィー-ヘルマン、作業草案を使用する左右対称のアルゴリズムキーの設立。
[BC] Ballardie, A., and J. Crowcroft, Multicast-specific
Security Threats and Countermeasures, Proceedings of 1995
ISOC Symposium on Networks & Distributed Systems Security,
pp. 17-30, Internet Society, San Diego, CA, February 1995.
[紀元前] Networks&Distributed Systems Security、ページの1995ISOC SymposiumのBallardie、A.とJ.クロウクロフトとMulticast特有のSecurity ThreatsとCountermeasures、Proceedings 17-30 サンディエゴ(カリフォルニア)1995年2月のインターネット協会。
[Berge] Berge, N., "UNINETT PCA Policy Statements", RFC 1875,
December 1995.
[Berge] Berge、N.、「UNINETT PCA施政方針」、RFC1875、1995年12月。
Maughan, et. al. Standards Track [Page 82] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[82ページ]。
[CW87] Clark, D.D. and D.R. Wilson, A Comparison of Commercial
and Military Computer Security Policies, Proceedings of
the IEEE Symposium on Security & Privacy, Oakland, CA,
1987, pp. 184-193.
Security&Privacy、オークランド(カリフォルニア)1987、ページの[CW87]クラークとD.D.とD.R.ウィルソンとCommercialのA ComparisonとMilitaryコンピュータSecurity Policies、IEEE SymposiumのProceedings 184-193.
[DNSSEC] D. Eastlake III, Domain Name System Protocol Security
Extensions, Work in Progress.
[DNSSEC]D.イーストレークIII、ドメインネームシステムプロトコルセキュリティ拡大は進行中で働いています。
[DOW92] Diffie, W., M.Wiener, P. Van Oorschot, Authentication and
Authenticated Key Exchanges, Designs, Codes, and
Cryptography, 2, 107-125, Kluwer Academic Publishers,
1992.
[DOW92] ディフィーとW.とM.ウインナソーセージとP.バンOorschotと認証と認証された主要な交換とデザイン、コードと暗号、2、107-125Kluwerのアカデミックな出版社、1992
[IAB] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
[IAB] Bellovin、S.、「IABセキュリティー体系ワークショップのレポート」、RFC2316、1998年4月。
[IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKE]ハーキン、D.、およびD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[IPDOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[IPDOI]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[Karn] Karn, P., and B. Simpson, Photuris: Session Key
Management Protocol, Work in Progress.
[Karn] Karn、P.、およびB.シンプソン、Photuris: セッションの主要な管理プロトコル、処理中の作業。
[Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August
10, 1994.
[Kent94] スティーブ・ケント、IPSEC SMIBは ipsec@ans.net 、1994年8月10日までメールします。
[Oakley] Orman, H., "The Oakley Key Determination Protocol", RFC
2412, November 1998.
[オークリー] Orman、H.、「オークリーの主要な決断プロトコル」、RFC2412、1998年11月。
[RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management", RFC
1422, February 1993.
[RFC-1422]ケント、S.、「インターネット電子メールのためのプライバシー増進:」 パートII: 「証明書ベースのKey Management」、RFC1422、1993年2月。
[RFC-1949] Ballardie, A., "Scalable Multicast Key Distribution", RFC
1949, May 1996.
[RFC-1949]Ballardie(A.、「スケーラブルなマルチキャスト主要な分配」、RFC1949)は1996がそうするかもしれません。
[RFC-2093] Harney, H., and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC-2093] ハーニー、H.、およびC.Muckenhirn、「グループKey Managementプロトコル(GKMP)仕様」、RFC2093、1997年7月。
[RFC-2094] Harney, H., and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094, July 1997.
[RFC-2094] ハーニー、H.、およびC.Muckenhirn、「グループKey Managementプロトコル(GKMP)アーキテクチャ」、RFC2094、1997年7月。
[RFC-2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のための主要なワーズ」、BCP14、RFC2119、1997年3月。
Maughan, et. al. Standards Track [Page 83] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[83ページ]。
[Schneier] Bruce Schneier, Applied Cryptography - Protocols,
Algorithms, and Source Code in C (Second Edition), John
Wiley & Sons, Inc., 1996.
[シュナイアー]ブルース・シュナイアー、プロトコル、アルゴリズム、およびC(第2版)、ジョン・ワイリー、および息子Inc.におけるソースコード、適用された暗号--1996。
[SEC-ARCH] Atkinson, R., and S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[SEC-アーチ] 1998年11月のアトキンソン、R.とS.ケント、「インターネットプロトコルのためのセキュリティー体系」RFC2401。
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
[STD-2] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。 参照: http://www.iana.org/numbers.html
Maughan, et. al. Standards Track [Page 84] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[84ページ]。
Authors' Addresses
作者のアドレス
Douglas Maughan National Security Agency ATTN: R23 9800 Savage Road Ft. Meade, MD. 20755-6000
ダグラスMaughan国家安全保障局ATTN: R23 9800サヴェージ道路フィート ミード(MD)。 20755-6000
Phone: 301-688-0847 EMail:wdm@tycho.ncsc.mil
以下に電話をしてください。 301-688-0847メール: wdm@tycho.ncsc.mil
Mark Schneider National Security Agency ATTN: R23 9800 Savage Road Ft. Meade, MD. 20755-6000
シュナイダー国家安全保障局ATTNをマークしてください: R23 9800サヴェージ道路フィート ミード(MD)。 20755-6000
Phone: 301-688-0851 EMail:mss@tycho.ncsc.mil
以下に電話をしてください。 301-688-0851メール: mss@tycho.ncsc.mil
Mark Schertler Securify, Inc. 2415-B Charleston Road Mountain View, CA 94043
マーク・Schertler Securify Inc.2415-BチャールストンRoadマウンテンビュー、カリフォルニア 94043
Phone: 650-934-9303 EMail:mjs@securify.com
以下に電話をしてください。 650-934-9303メール: mjs@securify.com
Jeff Turner RABA Technologies, Inc. 10500 Little Patuxent Parkway Columbia, MD. 21044
ジェフ旋盤工ラバ川Technologies Inc.10500リトル・パタクセントパークウェイコロンビア(MD)。 21044
Phone: 410-715-9399 EMail:jeff.turner@raba.com
以下に電話をしてください。 410-715-9399メール: jeff.turner@raba.com
Maughan, et. al. Standards Track [Page 85] RFC 2408 ISAKMP November 1998
et Maughan、アル。 規格はISAKMP1998年11月にRFC2408を追跡します[85ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Maughan, et. al. Standards Track [Page 86]
et Maughan、アル。 標準化過程[86ページ]
一覧
スポンサーリンク
