[要約] RFC 2407は、ISAKMPのためのインターネットIPセキュリティドメインの解釈に関するものであり、ISAKMPの目的と要約を提供しています。
Network Working Group D. Piper
Request for Comments: 2407 Network Alchemy
Category: Standards Track November 1998
The Internet IP Security Domain of Interpretation for ISAKMP
ISAKMPの解釈のインターネットIPセキュリティドメイン
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
IESG Note
IESG Note
Section 4.4.4.2 states, "All implememtations within the IPSEC DOI MUST support ESP_DES...". Recent work in the area of cryptanalysis suggests that DES may not be sufficiently strong for many applications. Therefore, it is very likely that the IETF will deprecate the use of ESP_DES as a mandatory cipher suite in the near future. It will remain as an optional use protocol. Although the IPsec working group and the IETF in general have not settled on an alternative algorithm (taking into account concerns of security and performance), implementers may want to heed the recommendations of section 4.4.4.3 on the use of ESP_3DES.
セクション4.4.4.2には、「IPSEC DOI内のすべての実装はESP_DESをサポートする必要がある...」と記載されています。暗号解読の分野における最近の研究は、DESが多くのアプリケーションに対して十分に強力ではない可能性があることを示唆しています。したがって、近い将来、IETFがESP_DESの使用を必須の暗号スイートとして廃止する可能性が非常に高くなります。オプションの使用プロトコルとして残ります。 IPsecワーキンググループとIETFは一般に（セキュリティとパフォーマンスの考慮を考慮して）代替アルゴリズムを決定していませんが、実装者はESP_3DESの使用に関するセクション4.4.4.3の推奨事項に注意する必要があります。
The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges, payloads, and processing guidelines that occur within a given Domain of Interpretation (DOI). This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations.
Internet Security Association and Key Management Protocol（ISAKMP）は、インターネットのセキュリティアソシエーション管理と暗号化キーの確立のためのフレームワークを定義しています。このフレームワークは、定義された交換、ペイロード、および所定の解釈ドメイン（DOI）内で発生する処理ガイドラインで構成されています。このドキュメントでは、IPがISAKMPを使用してセキュリティアソシエーションをネゴシエートするときに、IPで使用するためにISAKMPをインスタンス化するインターネットIPセキュリティDOI（IPSEC DOI）を定義します。
For a list of changes since the previous version of the IPSEC DOI, please see Section 7.
以前のバージョンのIPSEC DOIからの変更点のリストについては、セクション7を参照してください。
Within ISAKMP, a Domain of Interpretation is used to group related protocols using ISAKMP to negotiate security associations. Security protocols sharing a DOI choose security protocol and cryptographic transforms from a common namespace and share key exchange protocol identifiers. They also share a common interpretation of DOI-specific payload data content, including the Security Association and Identification payloads.
ISAKMP内では、ISAMを使用してセキュリティアソシエーションをネゴシエートするために、解釈のドメインを使用して関連プロトコルをグループ化します。 DOIを共有するセキュリティプロトコルは、共通の名前空間からセキュリティプロトコルと暗号変換を選択し、鍵交換プロトコル識別子を共有します。また、セキュリティアソシエーションや識別ペイロードなど、DOI固有のペイロードデータコンテンツの共通の解釈も共有します。
Overall, ISAKMP places the following requirements on a DOI definition:
全体として、ISAKMPはDOI定義に次の要件を課します。
o define the naming scheme for DOI-specific protocol identifiers o define the interpretation for the Situation field o define the set of applicable security policies o define the syntax for DOI-specific SA Attributes (Phase II) o define the syntax for DOI-specific payload contents o define additional Key Exchange types, if needed o define additional Notification Message types, if needed
o DOI固有のプロトコル識別子の命名スキームを定義しますo Situationフィールドの解釈を定義しますo適用可能なセキュリティポリシーのセットを定義しますo DOI固有のSA属性（フェーズII）の構文を定義しますo DOI固有のペイロードコンテンツの構文を定義しますo必要に応じて追加のキー交換タイプを定義しますo必要に応じて追加の通知メッセージタイプを定義します
The remainder of this document details the instantiation of these requirements for using the IP Security (IPSEC) protocols to provide authentication, integrity, and/or confidentiality for IP packets sent between cooperating host systems and/or firewalls.
このドキュメントの残りの部分では、IPセキュリティ（IPSEC）プロトコルを使用して、連携するホストシステムやファイアウォール間で送信されるIPパケットに認証、整合性、および/または機密性を提供するためのこれらの要件の具体化について詳しく説明します。
For a description of the overall IPSEC architecture, see [ARCH], [AH], and [ESP].
IPSECアーキテクチャ全体の説明については、[ARCH]、[AH]、および[ESP]を参照してください。
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].
このドキュメントに記載されているキーワードは、必須、必須、必須、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、およびOPTIONALであり、[RFC 2119]で説明されているように解釈されます。
Within ISAKMP, all DOI's must be registered with the IANA in the "Assigned Numbers" RFC [STD-2]. The IANA Assigned Number for the Internet IP Security DOI (IPSEC DOI) is one (1). Within the IPSEC DOI, all well-known identifiers MUST be registered with the IANA under the IPSEC DOI. Unless otherwise noted, all tables within this document refer to IANA Assigned Numbers for the IPSEC DOI. See Section 6 for further information relating to the IANA registry for the IPSEC DOI.
ISAKMP内では、すべてのDOIが「割り当てられた番号」RFC [STD-2]でIANAに登録されている必要があります。インターネットIPセキュリティDOI（IPSEC DOI）のIANA割り当て番号は1です。 IPSEC DOI内では、すべての既知の識別子をIPSEC DOIの下でIANAに登録する必要があります。特に明記しない限り、このドキュメント内のすべての表は、IPSEC DOIのIANA割り当て番号を参照しています。 IPSEC DOIのIANAレジストリに関する詳細については、セクション6を参照してください。
All multi-octet binary values are stored in network byte order.
すべてのマルチオクテットバイナリ値は、ネットワークバイトオーダーで格納されます。
Within ISAKMP, the Situation provides information that can be used by the responder to make a policy determination about how to process the incoming Security Association request. For the IPSEC DOI, the Situation field is a four (4) octet bitmask with the following values.
ISAKMP内では、シチュエーションは、着信セキュリティアソシエーション要求の処理方法に関するポリシーを決定するためにレスポンダーが使用できる情報を提供します。 IPSEC DOIの場合、Situationフィールドは次の値を持つ4オクテットのビットマスクです。
Situation Value
--------- -----
SIT_IDENTITY_ONLY 0x01
SIT_SECRECY 0x02
SIT_INTEGRITY 0x04
The SIT_IDENTITY_ONLY type specifies that the security association will be identified by source identity information present in an associated Identification Payload. See Section 4.6.2 for a complete description of the various Identification types. All IPSEC DOI implementations MUST support SIT_IDENTITY_ONLY by including an Identification Payload in at least one of the Phase I Oakley exchanges ([IKE], Section 5) and MUST abort any association setup that does not include an Identification Payload.
SIT_IDENTITY_ONLYタイプは、セキュリティアソシエーションが、関連付けられた識別ペイロードに存在するソースID情報によって識別されることを指定します。さまざまな識別タイプの詳細については、セクション4.6.2を参照してください。すべてのIPSEC DOI実装は、少なくとも1つのフェーズI Oakley交換（[IKE]、セクション5）に識別ペイロードを含めることでSIT_IDENTITY_ONLYをサポートしなければならず、識別ペイロードを含まない関連付け設定を中止しなければなりません。
If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the situation consists only of the 4 octet situation bitmap and does not include the Labeled Domain Identifier field (Figure 1, Section 4.6.1) or any subsequent label information. Conversely, if the initiator supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain Identifier MUST be included in the situation payload.
イニシエーターがSIT_SECRECYもSIT_INTEGRITYもサポートしない場合、シチュエーションは4オクテットのシチュエーションビットマップのみで構成され、Labeled Domain Identifierフィールド（図1、セクション4.6.1）または後続のラベル情報は含まれません。逆に、イニシエーターがSIT_SECRECYまたはSIT_INTEGRITYのいずれかをサポートしている場合は、ラベル付きドメイン識別子をシチュエーションペイロードに含める必要があります。
The SIT_SECRECY type specifies that the security association is being negotiated in an environment that requires labeled secrecy. If SIT_SECRECY is present in the Situation bitmap, the Situation field will be followed by variable-length data that includes a sensitivity level and compartment bitmask. See Section 4.6.1 for a complete description of the Security Association Payload format.
SIT_SECRECYタイプは、ラベル付き秘密を必要とする環境でセキュリティアソシエーションがネゴシエートされることを指定します。 SIT_SECRECYがSituationビットマップに存在する場合、Situationフィールドの後には、感度レベルとコンパートメントビットマスクを含む可変長データが続きます。セキュリティアソシエーションのペイロード形式の詳細については、セクション4.6.1を参照してください。
If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be set in the Situation bitmap and no secrecy level or category bitmaps shall be included.
イニシエーターがSIT_SECRECYをサポートしていない場合、SIT_SECRECYをシチュエーションビットマップに設定してはならず（MUST NOT）、機密レベルまたはカテゴリービットマップを含めてはなりません。
If a responder does not support SIT_SECRECY, a SITUATION-NOT-SUPPORTED Notification Payload SHOULD be returned and the security association setup MUST be aborted.
レスポンダがSIT_SECRECYをサポートしていない場合は、SITUATION-NOT-SUPPORTED通知ペイロードを返し、セキュリティアソシエーションのセットアップを中止する必要があります（SHOULD）。
The SIT_INTEGRITY type specifies that the security association is being negotiated in an environment that requires labeled integrity. If SIT_INTEGRITY is present in the Situation bitmap, the Situation field will be followed by variable-length data that includes an integrity level and compartment bitmask. If SIT_SECRECY is also in use for the association, the integrity information immediately follows the variable-length secrecy level and categories. See section 4.6.1 for a complete description of the Security Association Payload format.
SIT_INTEGRITYタイプは、セキュリティアソシエーションがラベル付きの整合性を必要とする環境でネゴシエートされることを指定します。 SIT_INTEGRITYがSituationビットマップに存在する場合、Situationフィールドの後には、整合性レベルとコンパートメントビットマスクを含む可変長データが続きます。 SIT_SECRECYも関連付けに使用されている場合、整合性情報は可変長の機密レベルとカテゴリの直後に続きます。セキュリティアソシエーションのペイロード形式の詳細については、セクション4.6.1を参照してください。
If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST NOT be set in the Situation bitmap and no integrity level or category bitmaps shall be included.
イニシエーターがSIT_INTEGRITYをサポートしていない場合、SIT_INTEGRITYをシチュエーションビットマップに設定してはならず（MUST NOT）、整合性レベルまたはカテゴリービットマップを含めてはなりません。
If a responder does not support SIT_INTEGRITY, a SITUATION-NOT-SUPPORTED Notification Payload SHOULD be returned and the security association setup MUST be aborted.
レスポンダがSIT_INTEGRITYをサポートしていない場合は、SITUATION-NOT-SUPPORTED通知ペイロードを返し、セキュリティアソシエーションのセットアップを中止する必要があります（SHOULD）。
The IPSEC DOI does not impose specific security policy requirements on any implementation. Host system policy issues are outside of the scope of this document.
IPSEC DOIは、実装に特定のセキュリティポリシー要件を課しません。ホストシステムポリシーの問題は、このドキュメントの範囲外です。
However, the following sections touch on some of the issues that must be considered when designing an IPSEC DOI host implementation. This section should be considered only informational in nature.
ただし、次のセクションでは、IPSEC DOIホスト実装を設計するときに考慮する必要があるいくつかの問題に触れます。このセクションは、本質的に情報提供のみを目的としています。
It is expected that many systems choosing to implement ISAKMP will strive to provide a protected domain of execution for a combined IKE key management daemon. On protected-mode multiuser operating systems, this key management daemon will likely exist as a separate privileged process.
ISAKMPの実装を選択する多くのシステムは、IKEキー管理デーモンを組み合わせて実行の保護されたドメインを提供するよう努めることが期待されます。プロテクトモードのマルチユーザーオペレーティングシステムでは、このキー管理デーモンは、独立した特権プロセスとして存在する可能性があります。
In such an environment, a formalized API to introduce keying material into the TCP/IP kernel may be desirable. The IP Security architecture does not place any requirements for structure or flow between a host TCP/IP kernel and its key management provider.
このような環境では、TCP / IPカーネルにキー情報を導入する正式なAPIが望ましい場合があります。 IPセキュリティアーキテクチャでは、ホストTCP / IPカーネルとそのキー管理プロバイダーとの間の構造またはフローに対する要件はありません。
Host systems that implement static keys, either for use directly by IPSEC, or for authentication purposes (see [IKE] Section 5.4), should take steps to protect the static keying material when it is not residing in a protected memory domain or actively in use by the TCP/IP kernel.
静的キーを実装するホストシステムは、IPSECによる直接使用または認証目的（[IKE]セクション5.4を参照）のいずれかで、保護されたメモリドメインに存在しない、またはアクティブに使用されていない場合、静的キー情報を保護するための手順を実行する必要があります。 TCP / IPカーネルによって。
For example, on a laptop, one might choose to store the static keys in a configuration store that is, itself, encrypted under a private password.
たとえば、ラップトップの場合、静的キーを、それ自体がプライベートパスワードで暗号化された構成ストアに格納することを選択できます。
Depending on the operating system and utility software installed, it may not be possible to protect the static keys once they've been loaded into the TCP/IP kernel, however they should not be trivially recoverable on initial system startup without having to satisfy some additional form of authentication.
インストールされているオペレーティングシステムとユーティリティソフトウェアによっては、TCP / IPカーネルに読み込まれた静的キーを保護できない場合がありますが、追加の要件を満たさなければ、システムの初期起動時に簡単に回復することはできません。認証の形式。
It is not realistic to assume that the transition to IPSEC will occur overnight. Host systems must be prepared to implement flexible policy lists that describe which systems they desire to speak securely with and which systems they require speak securely to them. Some notion of proxy firewall addresses may also be required.
IPSECへの移行が夜間に発生すると想定することは現実的ではありません。ホストシステムは、どのシステムが安全に通信したいか、どのシステムが安全に通信する必要があるかを説明する柔軟なポリシーリストを実装できるように準備する必要があります。プロキシファイアウォールアドレスの概念も必要になる場合があります。
A minimal approach is probably a static list of IP addresses, network masks, and a security required flag or flags.
最小限のアプローチは、おそらくIPアドレス、ネットワークマスク、およびセキュリティが必要なフラグの静的リストです。
A more flexible implementation might consist of a list of wildcard DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional firewall address. The wildcard DNS name would be used to match incoming or outgoing IP addresses, the in/out bitmask would be used to determine whether or not security was to be applied and in which direction, and the optional firewall address would be used to indicate whether or not tunnel mode would be needed to talk to the target system though an intermediate firewall.
より柔軟な実装は、ワイルドカードDNS名のリスト（例：「* .foo.bar」）、入出力ビットマスク、およびオプションのファイアウォールアドレスで構成される場合があります。ワイルドカードDNS名を使用して着信または発信IPアドレスを照合し、入出力ビットマスクを使用してセキュリティを適用するかどうかとその方向を決定し、オプションのファイアウォールアドレスを使用して中間ファイアウォールを介してターゲットシステムと通信するには、トンネルモードは必要ありません。
Host systems implementing a certificate-based authentication scheme will need a mechanism for obtaining and managing a database of certificates.
証明書ベースの認証スキームを実装するホストシステムには、証明書のデータベースを取得および管理するメカニズムが必要です。
Secure DNS is to be one certificate distribution mechanism, however the pervasive availability of secure DNS zones, in the short term, is doubtful for many reasons. What's far more likely is that hosts will need an ability to import certificates that they acquire through secure, out-of-band mechanisms, as well as an ability to export their own certificates for use by other systems.
セキュアDNSは1つの証明書配布メカニズムになるはずですが、セキュアDNSゾーンの普及は、短期的には多くの理由で疑わしいものです。はるかに可能性が高いのは、ホストが安全な帯域外メカニズムを介して取得した証明書をインポートする機能と、他のシステムで使用するために独自の証明書をエクスポートする機能を必要とすることです。
However, manual certificate management should not be done so as to preclude the ability to introduce dynamic certificate discovery mechanisms and/or protocols as they become available.
ただし、動的な証明書検出メカニズムやプロトコルが利用可能になったときにそれらを導入する機能を排除するために、手動の証明書管理は行わないでください。
The following sections list the Assigned Numbers for the IPSEC DOI: Situation Identifiers, Protocol Identifiers, Transform Identifiers, AH, ESP, and IPCOMP Transform Identifiers, Security Association Attribute Type Values, Labeled Domain Identifiers, ID Payload Type Values, and Notify Message Type Values.
次のセクションでは、IPSEC DOIに割り当てられた番号をリストします。シチュエーションID、プロトコルID、変換ID、AH、ESP、およびIPCOMP変換ID、セキュリティアソシエーション属性タイプの値、ラベル付きドメインID、IDペイロードタイプの値、および通知メッセージタイプの値。
The ISAKMP proposal syntax was specifically designed to allow for the simultaneous negotiation of multiple Phase II security protocol suites within a single negotiation. As a result, the protocol suites listed below form the set of protocols that can be negotiated at the same time. It is a host policy decision as to what protocol suites might be negotiated together.
ISAKMPプロポーザル構文は、1つのネゴシエーション内で複数のフェーズIIセキュリティプロトコルスイートの同時ネゴシエーションを可能にするように特別に設計されました。その結果、以下にリストされているプロトコルスイートは、同時にネゴシエートできるプロトコルのセットを形成します。これは、どのプロトコルスイートが一緒にネゴシエートされるかに関するホストポリシーの決定です。
The following table lists the values for the Security Protocol Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC DOI.
次の表に、IPSEC DOIのISAKMPプロポーザルペイロードで参照されるセキュリティプロトコル識別子の値を示します。
Protocol ID Value
----------- -----
RESERVED 0
PROTO_ISAKMP 1
PROTO_IPSEC_AH 2
PROTO_IPSEC_ESP 3
PROTO_IPCOMP 4
The PROTO_ISAKMP type specifies message protection required during Phase I of the ISAKMP protocol. The specific protection mechanism used for the IPSEC DOI is described in [IKE]. All implementations within the IPSEC DOI MUST support PROTO_ISAKMP.
PROTO_ISAKMPタイプは、ISAKMPプロトコルのフェーズI中に必要なメッセージ保護を指定します。 IPSEC DOIに使用される特定の保護メカニズムは、[IKE]で説明されています。 IPSEC DOI内のすべての実装は、PROTO_ISAKMPをサポートする必要があります。
NB: ISAKMP reserves the value one (1) across all DOI definitions.
注意：ISAKMPは、すべてのDOI定義にわたって値1を予約します。
The PROTO_IPSEC_AH type specifies IP packet authentication. The default AH transform provides data origin authentication, integrity protection, and replay detection. For export control considerations, confidentiality MUST NOT be provided by any PROTO_IPSEC_AH transform.
PROTO_IPSEC_AHタイプは、IPパケット認証を指定します。デフォルトのAHトランスフォームは、データ発信元認証、整合性保護、およびリプレイ検出を提供します。輸出管理の考慮事項については、PROTO_IPSEC_AH変換によって機密性を提供してはなりません。
The PROTO_IPSEC_ESP type specifies IP packet confidentiality. Authentication, if required, must be provided as part of the ESP transform. The default ESP transform includes data origin authentication, integrity protection, replay detection, and confidentiality.
PROTO_IPSEC_ESPタイプは、IPパケットの機密性を指定します。認証は、必要に応じて、ESPトランスフォームの一部として提供する必要があります。デフォルトのESPトランスフォームには、データ発信元認証、整合性保護、リプレイ検出、および機密性が含まれています。
The PROTO_IPCOMP type specifies IP payload compression as defined in [IPCOMP].
PROTO_IPCOMPタイプは、[IPCOMP]で定義されているIPペイロード圧縮を指定します。
As part of an ISAKMP Phase I negotiation, the initiator's choice of Key Exchange offerings is made using some host system policy description. The actual selection of Key Exchange mechanism is made using the standard ISAKMP Proposal Payload. The following table lists the defined ISAKMP Phase I Transform Identifiers for the Proposal Payload for the IPSEC DOI.
ISAKMPフェーズIネゴシエーションの一部として、ホストシステムポリシーの説明を使用して、開始者がキー交換サービスを選択します。鍵交換メカニズムの実際の選択は、標準のISAKMPプロポーザルペイロードを使用して行われます。次の表に、IPSEC DOIの提案ペイロードに定義されているISAKMPフェーズI変換識別子を示します。
Transform Value
--------- -----
RESERVED 0
KEY_IKE 1
Within the ISAKMP and IPSEC DOI framework it is possible to define key establishment protocols other than IKE (Oakley). Previous versions of this document defined types both for manual keying and for schemes based on use of a generic Key Distribution Center (KDC). These identifiers have been removed from the current document.
ISAKMPおよびIPSEC DOIフレームワーク内で、IKE（Oakley）以外の主要な確立プロトコルを定義することが可能です。このドキュメントの以前のバージョンでは、手動キーイングと一般的なキー配布センター（KDC）の使用に基づくスキームの両方のタイプが定義されていました。これらの識別子は現在のドキュメントから削除されています。
The IPSEC DOI can still be extended later to include values for additional non-Oakley key establishment protocols for ISAKMP and IPSEC, such as Kerberos [RFC-1510] or the Group Key Management Protocol (GKMP) [RFC-2093].
IPSEC DOIは、Kerberos [RFC-1510]やグループキー管理プロトコル（GKMP）[RFC-2093]などのISAKMPおよびIPSECの追加の非オークリーキー確立プロトコルの値を含めるように、後で拡張することもできます。
The KEY_IKE type specifies the hybrid ISAKMP/Oakley Diffie-Hellman key exchange (IKE) as defined in the [IKE] document. All implementations within the IPSEC DOI MUST support KEY_IKE.
KEY_IKEタイプは、[IKE]ドキュメントで定義されているハイブリッドISAKMP / Oakley Diffie-Hellman鍵交換（IKE）を指定します。 IPSEC DOI内のすべての実装は、KEY_IKEをサポートする必要があります。
The Authentication Header Protocol (AH) defines one mandatory and several optional transforms used to provide authentication, integrity, and replay detection. The following table lists the defined AH Transform Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI.
認証ヘッダープロトコル（AH）は、認証、整合性、およびリプレイ検出を提供するために使用される1つの必須およびいくつかのオプションの変換を定義します。次の表に、IPSEC DOIのISAKMPプロポーザルペイロードに定義されているAH変換識別子を示します。
Note: the Authentication Algorithm attribute MUST be specified to identify the appropriate AH protection suite. For example, AH_MD5 can best be thought of as a generic AH transform using MD5. To request the HMAC construction with AH, one specifies the AH_MD5 transform ID along with the Authentication Algorithm attribute set to HMAC-MD5. This is shown using the "Auth(HMAC-MD5)" notation in the following sections.
注：適切なAH保護スイートを識別するために、認証アルゴリズム属性を指定する必要があります。たとえば、AH_MD5は、MD5を使用する一般的なAH変換と考えるのが最も適切です。 AHを使用してHMAC構築を要求するには、AH_MD5変換IDと、HMAC-MD5に設定された認証アルゴリズム属性を指定します。これは、以下のセクションで「Auth（HMAC-MD5）」表記を使用して示されています。
Transform ID Value
------------ -----
RESERVED 0-1
AH_MD5 2
AH_SHA 3
AH_DES 4
Note: all mandatory-to-implement algorithms are listed as "MUST" implement (e.g. AH_MD5) in the following sections. All other algorithms are optional and MAY be implemented in any particular implementation.
注：次のセクションでは、実装から実装までのすべてのアルゴリズムを「MUST」実装（AH_MD5など）として示しています。他のすべてのアルゴリズムはオプションであり、特定の実装で実装される場合があります。
The AH_MD5 type specifies a generic AH transform using MD5. The actual protection suite is determined in concert with an associated SA attribute list. A generic MD5 transform is currently undefined.
AH_MD5タイプは、MD5を使用する一般的なAH変換を指定します。実際の保護スイートは、関連するSA属性リストと連携して決定されます。一般的なMD5変換は現在定義されていません。
All implementations within the IPSEC DOI MUST support AH_MD5 along with the Auth(HMAC-MD5) attribute. This suite is defined as the HMAC-MD5-96 transform described in [HMACMD5].
IPSEC DOI内のすべての実装は、Auth（HMAC-MD5）属性とともにAH_MD5をサポートする必要があります。このスイートは、[HMACMD5]で説明されているHMAC-MD5-96変換として定義されます。
The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH transform (Key/Pad/Data/Key) described in RFC-1826.
AH_MD5タイプとAuth（KPDK）属性は、RFC-1826で説明されているAH変換（キー/パッド/データ/キー）を指定します。
Use of AH_MD5 with any other Authentication Algorithm attribute value is currently undefined.
AH_MD5を他の認証アルゴリズム属性値とともに使用することは、現時点では定義されていません。
The AH_SHA type specifies a generic AH transform using SHA-1. The actual protection suite is determined in concert with an associated SA attribute list. A generic SHA transform is currently undefined.
AH_SHAタイプは、SHA-1を使用する一般的なAH変換を指定します。実際の保護スイートは、関連するSA属性リストと連携して決定されます。一般的なSHA変換は現在定義されていません。
All implementations within the IPSEC DOI MUST support AH_SHA along with the Auth(HMAC-SHA) attribute. This suite is defined as the HMAC-SHA-1-96 transform described in [HMACSHA].
IPSEC DOI内のすべての実装は、Auth（HMAC-SHA）属性とともにAH_SHAをサポートする必要があります。このスイートは、[HMACSHA]で説明されているHMAC-SHA-1-96変換として定義されています。
Use of AH_SHA with any other Authentication Algorithm attribute value is currently undefined.
AH_SHAを他の認証アルゴリズム属性値とともに使用することは、現時点では定義されていません。
The AH_DES type specifies a generic AH transform using DES. The actual protection suite is determined in concert with an associated SA attribute list. A generic DES transform is currently undefined.
AH_DESタイプは、DESを使用する一般的なAH変換を指定します。実際の保護スイートは、関連するSA属性リストと連携して決定されます。一般的なDES変換は現在定義されていません。
The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute to be a DES-MAC transform. Implementations are not required to support this mode.
IPSEC DOIは、AH_DESをAuth（DES-MAC）属性とともにDES-MAC変換として定義します。このモードをサポートするための実装は必要ありません。
Use of AH_DES with any other Authentication Algorithm attribute value is currently undefined.
他の認証アルゴリズム属性値でのAH_DESの使用は現在定義されていません。
The Encapsulating Security Payload (ESP) defines one mandatory and many optional transforms used to provide data confidentiality. The following table lists the defined ESP Transform Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI.
カプセル化セキュリティペイロード（ESP）は、データの機密性を提供するために使用される1つの必須および多くのオプションの変換を定義します。次の表に、IPSEC DOIのISAKMPプロポーザルペイロードに定義されているESP変換識別子を示します。
Note: when authentication, integrity protection, and replay detection are required, the Authentication Algorithm attribute MUST be specified to identify the appropriate ESP protection suite. For example, to request HMAC-MD5 authentication with 3DES, one specifies the ESP_3DES transform ID with the Authentication Algorithm attribute set to HMAC-MD5. For additional processing requirements, see Section 4.5 (Authentication Algorithm).
注：認証、整合性保護、およびリプレイ検出が必要な場合、適切なESP保護スイートを識別するために、認証アルゴリズム属性を指定する必要があります。たとえば、3DESでHMAC-MD5認証を要求するには、認証アルゴリズム属性をHMAC-MD5に設定してESP_3DES変換IDを指定します。その他の処理要件については、セクション4.5（認証アルゴリズム）を参照してください。
Transform ID Value
------------ -----
RESERVED 0
ESP_DES_IV64 1
ESP_DES 2
ESP_3DES 3
ESP_RC5 4
ESP_IDEA 5
ESP_CAST 6
ESP_BLOWFISH 7
ESP_3IDEA 8
ESP_DES_IV32 9
ESP_RC4 10
ESP_NULL 11
Note: all mandatory-to-implement algorithms are listed as "MUST" implement (e.g. ESP_DES) in the following sections. All other algorithms are optional and MAY be implemented in any particular implementation.
注：次のセクションでは、すべての必須から実装までのアルゴリズムを「MUST」実装（ESP_DESなど）として示しています。他のすべてのアルゴリズムはオプションであり、特定の実装で実装される場合があります。
The ESP_DES_IV64 type specifies the DES-CBC transform defined in RFC-1827 and RFC-1829 using a 64-bit IV.
ESP_DES_IV64タイプは、64ビットIVを使用してRFC-1827およびRFC-1829で定義されたDES-CBC変換を指定します。
The ESP_DES type specifies a generic DES transform using DES-CBC. The actual protection suite is determined in concert with an associated SA attribute list. A generic transform is currently undefined.
ESP_DESタイプは、DES-CBCを使用する一般的なDES変換を指定します。実際の保護スイートは、関連するSA属性リストと連携して決定されます。一般的な変換は現在未定義です。
All implementations within the IPSEC DOI MUST support ESP_DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [DES] transform, with authentication and integrity provided by HMAC MD5 [HMACMD5].
IPSEC DOI内のすべての実装は、Auth（HMAC-MD5）属性とともにESP_DESをサポートする必要があります。このスイートは[DES]変換として定義され、HMAC MD5 [HMACMD5]によって認証と整合性が提供されます。
The ESP_3DES type specifies a generic triple-DES transform. The actual protection suite is determined in concert with an associated SA attribute list. The generic transform is currently undefined.
ESP_3DESタイプは、一般的なtriple-DES変換を指定します。実際の保護スイートは、関連するSA属性リストと連携して決定されます。一般的な変換は現在未定義です。
All implementations within the IPSEC DOI are strongly encouraged to support ESP_3DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [ESPCBC] transform, with authentication and integrity provided by HMAC MD5 [HMACMD5].
IPSEC DOI内のすべての実装では、Auth（HMAC-MD5）属性とともにESP_3DESをサポートすることを強くお勧めします。このスイートは[ESPCBC]トランスフォームとして定義され、HMAC MD5 [HMACMD5]によって認証と整合性が提供されます。
The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC].
ESP_RC5タイプは、[ESPCBC]で定義されているRC5変換を指定します。
The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC].
ESP_IDEAタイプは、[ESPCBC]で定義されたIDEA変換を指定します。
The ESP_CAST type specifies the CAST transform defined in [ESPCBC].
ESP_CASTタイプは、[ESPCBC]で定義されているCAST変換を指定します。
The ESP_BLOWFISH type specifies the BLOWFISH transform defined in [ESPCBC].
ESP_BLOWFISHタイプは、[ESPCBC]で定義されたBLOWFISH変換を指定します。
The ESP_3IDEA type is reserved for triple-IDEA.
ESP_3IDEAタイプは、トリプルIDEA用に予約されています。
The ESP_DES_IV32 type specifies the DES-CBC transform defined in RFC-1827 and RFC-1829 using a 32-bit IV.
ESP_DES_IV32タイプは、32ビットIVを使用してRFC-1827およびRFC-1829で定義されたDES-CBC変換を指定します。
The ESP_RC4 type is reserved for RC4.
ESP_RC4タイプはRC4用に予約されています。
The ESP_NULL type specifies no confidentiality is to be provided by ESP. ESP_NULL is used when ESP is being used to tunnel packets which require only authentication, integrity protection, and replay detection.
ESP_NULLタイプは、ESPが機密性を提供しないことを指定します。 ESPが認証、完全性保護、およびリプレイ検出のみを必要とするパケットをトンネリングするために使用されている場合、ESP_NULLが使用されます。
All implementations within the IPSEC DOI MUST support ESP_NULL. The ESP NULL transform is defined in [ESPNULL]. See the Authentication Algorithm attribute description in Section 4.5 for additional requirements relating to the use of ESP_NULL.
IPSEC DOI内のすべての実装は、ESP_NULLをサポートする必要があります。 ESP NULL変換は[ESPNULL]で定義されています。 ESP_NULLの使用に関するその他の要件については、セクション4.5の認証アルゴリズム属性の説明を参照してください。
The IP Compression (IPCOMP) transforms define optional compression algorithms that can be negotiated to provide for IP payload compression ([IPCOMP]). The following table lists the defined IPCOMP Transform Identifiers for the ISAKMP Proposal Payload within the IPSEC DOI.
IP圧縮（IPCOMP）変換は、交渉してIPペイロード圧縮（[IPCOMP]）を提供できるオプションの圧縮アルゴリズムを定義します。次の表に、IPSEC DOI内のISAKMPプロポーザルペイロードに対して定義されているIPCOMP変換識別子を示します。
Transform ID Value
------------ -----
RESERVED 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2
IPCOMP_LZS 3
The IPCOMP_OUI type specifies a proprietary compression transform. The IPCOMP_OUI type must be accompanied by an attribute which further identifies the specific vendor algorithm.
IPCOMP_OUIタイプは、独自の圧縮変換を指定します。 IPCOMP_OUIタイプには、特定のベンダーアルゴリズムをさらに識別する属性が必要です。
The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate algorithm as specified in [DEFLATE].
IPCOMP_DEFLATEタイプは、[DEFLATE]で指定されている「zlib」デフレートアルゴリズムの使用を指定します。
The IPCOMP_LZS type specifies the use of the Stac Electronics LZS algorithm as specified in [LZS].
IPCOMP_LZSタイプは、[LZS]で指定されているStac Electronics LZSアルゴリズムの使用を指定します。
The following SA attribute definitions are used in Phase II of an IKE negotiation. Attribute types can be either Basic (B) or Variable-Length (V). Encoding of these attributes is defined in the base ISAKMP specification.
次のSA属性定義は、IKEネゴシエーションのフェーズIIで使用されます。属性タイプは、基本（B）または可変長（V）のいずれかです。これらの属性のエンコーディングは、ベースISAKMP仕様で定義されています。
Attributes described as basic MUST NOT be encoded as variable. Variable length attributes MAY be encoded as basic attributes if their value can fit into two octets. See [IKE] for further information on attribute encoding in the IPSEC DOI. All restrictions listed in [IKE] also apply to the IPSEC DOI.
基本として記述されている属性は、変数としてエンコードしてはいけません。可変長属性は、その値が2つのオクテットに収まる場合、基本属性としてエンコードされる場合があります。 IPSEC DOIの属性エンコーディングの詳細については、[IKE]を参照してください。 [IKE]にリストされているすべての制限は、IPSEC DOIにも適用されます。
Attribute Types
属性タイプ
class value type
-------------------------------------------------
SA Life Type 1 B
SA Life Duration 2 V
Group Description 3 B
Encapsulation Mode 4 B
Authentication Algorithm 5 B
Key Length 6 B
Key Rounds 7 B
Compress Dictionary Size 8 B
Compress Private Algorithm 9 V
Class Values
クラス値
SA Life Type SA Duration
SAライフタイプSA期間
Specifies the time-to-live for the overall security association. When the SA expires, all keys negotiated under the association (AH or ESP) must be renegotiated. The life type values are:
セキュリティアソシエーション全体の存続可能時間を指定します。 SAの有効期限が切れると、関連付け（AHまたはESP）でネゴシエートされたすべてのキーを再ネゴシエートする必要があります。ライフタイプの値は次のとおりです。
RESERVED 0 seconds 1 kilobytes 2
予約済み0秒1キロバイト2
Values 3-61439 are reserved to IANA. Values 61440-65535 are for private use. For a given Life Type, the value of the Life Duration attribute defines the actual length of the component lifetime -- either a number of seconds, or a number of Kbytes that can be protected.
値3-61439はIANAに予約されています。値61440〜65535は私用です。特定のライフタイプの場合、ライフデュレーション属性の値は、コンポーネントのライフタイムの実際の長さ（秒数、または保護可能なキロバイト数）を定義します。
If unspecified, the default value shall be assumed to be 28800 seconds (8 hours).
指定しない場合、デフォルト値は28800秒（8時間）と見なされます。
An SA Life Duration attribute MUST always follow an SA Life Type which describes the units of duration.
SAライフ期間属性は、期間の単位を説明するSAライフタイプに常に従う必要があります。
See Section 4.5.4 for additional information relating to lifetime notification.
ライフタイム通知に関する追加情報については、セクション4.5.4を参照してください。
Group Description
グループの説明
Specifies the Oakley Group to be used in a PFS QM negotiation. For a list of supported values, see Appendix A of [IKE].
PFS QMネゴシエーションで使用されるOakleyグループを指定します。サポートされている値のリストについては、[IKE]の付録Aを参照してください。
Encapsulation Mode RESERVED 0 Tunnel 1 Transport 2
カプセル化モードRESERVED 0トンネル1トランスポート2
Values 3-61439 are reserved to IANA. Values 61440-65535 are for private use.
値3-61439はIANAに予約されています。値61440〜65535は私用です。
If unspecified, the default value shall be assumed to be unspecified (host-dependent).
指定しない場合、デフォルト値は指定されていないと見なされます（ホスト依存）。
Authentication Algorithm RESERVED 0 HMAC-MD5 1 HMAC-SHA 2 DES-MAC 3 KPDK 4
認証アルゴリズムRESERVED 0 HMAC-MD5 1 HMAC-SHA 2 DES-MAC 3 KPDK 4
Values 5-61439 are reserved to IANA. Values 61440-65535 are for private use.
値5-61439はIANAに予約されています。値61440〜65535は私用です。
There is no default value for Auth Algorithm, as it must be specified to correctly identify the applicable AH or ESP transform, except in the following case.
次の場合を除いて、適切なAHまたはESPトランスフォームを正しく識別するために指定する必要があるため、認証アルゴリズムのデフォルト値はありません。
When negotiating ESP without authentication, the Auth Algorithm attribute MUST NOT be included in the proposal.
認証なしでESPをネゴシエートする場合、認証アルゴリズム属性を提案に含めることはできません。
When negotiating ESP without confidentiality, the Auth Algorithm attribute MUST be included in the proposal and the ESP transform ID must be ESP_NULL.
機密性なしでESPをネゴシエートする場合、認証アルゴリズム属性を提案に含める必要があり、ESP変換IDはESP_NULLでなければなりません。
Key Length RESERVED 0
キーの長さは予約済み0
There is no default value for Key Length, as it must be specified for transforms using ciphers with variable key lengths. For fixed length ciphers, the Key Length attribute MUST NOT be sent.
可変キー長の暗号を使用する変換に指定する必要があるため、キー長のデフォルト値はありません。固定長暗号の場合、キー長属性を送信してはなりません（MUST NOT）。
Key Rounds RESERVED 0
主なラウンド予約0
There is no default value for Key Rounds, as it must be specified for transforms using ciphers with varying numbers of rounds.
キーラウンドのデフォルト値はありません。これは、ラウンドの数が異なる暗号を使用する変換に指定する必要があるためです。
Compression Dictionary Size RESERVED 0
コンプレッションディクショナリサイズRESERVED 0
Specifies the log2 maximum size of the dictionary.
辞書のlog2最大サイズを指定します。
There is no default value for dictionary size.
辞書サイズのデフォルト値はありません。
Compression Private Algorithm
圧縮プライベートアルゴリズム
Specifies a private vendor compression algorithm. The first three (3) octets must be an IEEE assigned company_id (OUI). The next octet may be a vendor specific compression subtype, followed by zero or more octets of vendor data.
プライベートベンダー圧縮アルゴリズムを指定します。最初の3つのオクテットは、IEEEが割り当てたcompany_id（OUI）である必要があります。次のオクテットはベンダー固有の圧縮サブタイプであり、その後にベンダーデータの0個以上のオクテットが続きます。
To ensure basic interoperability, all implementations MUST be prepared to negotiate all of the following attributes.
基本的な相互運用性を確保するために、すべての実装は、以下のすべての属性をネゴシエートするように準備する必要があります。
SA Life Type SA Duration Auth Algorithm
SAライフタイプSA期間認証アルゴリズム
To allow for flexible semantics, the IPSEC DOI requires that a conforming ISAKMP implementation MUST correctly parse an attribute list that contains multiple instances of the same attribute class, so long as the different attribute entries do not conflict with one another. Currently, the only attributes which requires this treatment are Life Type and Duration.
柔軟なセマンティクスを可能にするために、IPSEC DOIでは、異なる属性エントリが互いに競合しない限り、準拠するISAKMP実装が同じ属性クラスの複数のインスタンスを含む属性リストを正しく解析する必要があります。現在、この処理を必要とする属性はライフタイプと期間のみです。
To see why this is important, the following example shows the binary encoding of a four entry attribute list that specifies an SA Lifetime of either 100MB or 24 hours. (See Section 3.3 of [ISAKMP] for a complete description of the attribute encoding format.)
これが重要である理由を確認するために、次の例は、100 MBまたは24時間のSAライフタイムを指定する4つのエントリの属性リストのバイナリエンコーディングを示しています。 （属性エンコード形式の詳細については、[ISAKMP]のセクション3.3を参照してください。）
Attribute #1:
0x80010001 (AF = 1, type = SA Life Type, value = seconds)
Attribute #2:
0x00020004 (AF = 0, type = SA Duration, length = 4 bytes)
0x00015180 (value = 0x15180 = 86400 seconds = 24 hours)
Attribute #3:
0x80010002 (AF = 1, type = SA Life Type, value = KB)
Attribute #4:
0x00020004 (AF = 0, type = SA Duration, length = 4 bytes)
0x000186A0 (value = 0x186A0 = 100000KB = 100MB)
If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED Notification Payload SHOULD be returned and the security association setup MUST be aborted.
競合する属性が検出された場合は、ATTRIBUTES-NOT-SUPPORTED通知ペイロードを返し、セキュリティアソシエーションのセットアップを中止する必要があります（SHOULD）。
If an implementation receives a defined IPSEC DOI attribute (or attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT SHOULD be sent and the security association setup MUST be aborted, unless the attribute value is in the reserved range.
実装がサポートしていない定義済みのIPSEC DOI属性（または属性値）を受け取った場合、属性値が予約された範囲にない限り、ATTRIBUTES-NOT-SUPPORTを送信する必要があり、セキュリティアソシエーションのセットアップを中止する必要があります。
If an implementation receives an attribute value in the reserved range, an implementation MAY chose to continue based on local policy.
実装が予約された範囲の属性値を受け取った場合、実装はローカルポリシーに基づいて続行することを選択できます（MAY）。
When an initiator offers an SA lifetime greater than what the responder desires based on their local policy, the responder has three choices: 1) fail the negotiation entirely; 2) complete the negotiation but use a shorter lifetime than what was offered; 3) complete the negotiation and send an advisory notification to the initiator indicating the responder's true lifetime. The choice of what the responder actually does is implementation specific and/or based on local policy.
イニシエーターが、ローカルポリシーに基づいてレスポンダーが望んでいるよりも長いSAライフタイムを提供する場合、レスポンダーには3つの選択肢があります。1）ネゴシエーションを完全に失敗させる。 2）交渉を完了するが、提供されたものよりも短い有効期間を使用する。 3）ネゴシエーションを完了し、応答側の真の存続期間を示す通知を開始側に送信します。レスポンダが実際に行うことの選択は、実装固有であるか、ローカルポリシーに基づいています。
To ensure interoperability in the latter case, the IPSEC DOI requires the following only when the responder wishes to notify the initiator: if the initiator offers an SA lifetime longer than the responder is willing to accept, the responder SHOULD include an ISAKMP Notification Payload in the exchange that includes the responder's IPSEC SA payload. Section 4.6.3.1 defines the payload layout for the RESPONDER-LIFETIME Notification Message type which MUST be used for this purpose.
後者の場合の相互運用性を確保するために、IPSEC DOIは、レスポンダがイニシエータに通知することを望む場合にのみ、次のことを必要とします。レスポンダのIPSEC SAペイロードを含む交換。セクション4.6.3.1では、この目的で使用する必要があるRESPONDER-LIFETIME通知メッセージタイプのペイロードレイアウトを定義しています。
The following sections describe those ISAKMP payloads whose data representations are dependent on the applicable DOI.
次のセクションでは、データ表現が該当するDOIに依存するISAKMPペイロードについて説明します。
The following diagram illustrates the content of the Security Association Payload for the IPSEC DOI. See Section 4.2 for a description of the Situation bitmap.
次の図は、IPSEC DOIのセキュリティアソシエーションペイロードの内容を示しています。 Situationビットマップの説明については、セクション4.2を参照してください。
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 (IPSEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation (bitmap) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Labeled Domain Identifier !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Secrecy Length (in octets) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Secrecy Level ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Secrecy Cat. Length (in bits) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Secrecy Category Bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Integrity Length (in octets) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Level ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Integ. Cat. Length (in bits) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Category Bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Security Association Payload Format
図1：SAペイロードの形式
The Security Association Payload is defined as follows:
Security Association Payloadは次のように定義されています。
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, this field will be zero (0).
o 次のペイロード（1オクテット）-メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドはゼロ（0）になります。
o RESERVED (1 octet) - Unused, must be zero (0).
o 予約済み（1オクテット）-未使用、ゼロ（0）でなければなりません。
o Payload Length (2 octets) - Length, in octets, of the current payload, including the generic header.
o ペイロード長（2オクテット）-ジェネリックヘッダーを含む現在のペイロードの長さ（オクテット単位）。
o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI, which has been assigned the value one (1).
o 解釈のドメイン（4オクテット）-値1が割り当てられているIPSEC DOIを指定します。
o Situation (4 octets) - Bitmask used to interpret the remainder of the Security Association Payload. See Section 4.2 for a complete list of values.
o 状況（4オクテット）-セキュリティアソシエーションペイロードの残りを解釈するために使用されるビットマスク。値の完全なリストについては、セクション4.2を参照してください。
o Labeled Domain Identifier (4 octets) - IANA Assigned Number used to interpret the Secrecy and Integrity information.
o ラベル付きドメイン識別子（4オクテット）-機密性と整合性の情報を解釈するために使用されるIANA割り当て番号。
o Secrecy Length (2 octets) - Specifies the length, in octets, of the secrecy level identifier, excluding pad bits.
o 秘密の長さ（2オクテット）-パッドビットを除いた秘密レベル識別子の長さをオクテットで指定します。
o RESERVED (2 octets) - Unused, must be zero (0).
o 予約済み（2オクテット）-未使用、ゼロ（0）でなければなりません。
o Secrecy Level (variable length) - Specifies the mandatory secrecy level required. The secrecy level MUST be padded with zero (0) to align on the next 32-bit boundary.
o 機密レベル（可変長）-必須の必須機密レベルを指定します。機密レベルには、次の32ビット境界に合わせるためにゼロ（0）を埋め込む必要があります。
o Secrecy Category Length (2 octets) - Specifies the length, in bits, of the secrecy category (compartment) bitmap, excluding pad bits.
o 機密カテゴリの長さ（2オクテット）-パッドビットを除いた機密カテゴリ（コンパートメント）ビットマップの長さをビット単位で指定します。
o RESERVED (2 octets) - Unused, must be zero (0).
o 予約済み（2オクテット）-未使用、ゼロ（0）でなければなりません。
o Secrecy Category Bitmap (variable length) - A bitmap used to designate secrecy categories (compartments) that are required. The bitmap MUST be padded with zero (0) to align on the next 32-bit boundary.
o 機密カテゴリビットマップ（可変長）-必要な機密カテゴリ（コンパートメント）を指定するために使用されるビットマップ。ビットマップは、次の32ビット境界に揃えるために、ゼロ（0）で埋め込まれる必要があります。
o Integrity Length (2 octets) - Specifies the length, in octets, of the integrity level identifier, excluding pad bits.
o 完全性の長さ（2オクテット）-埋め込みビットを除く完全性レベル識別子の長さをオクテットで指定します。
o RESERVED (2 octets) - Unused, must be zero (0).
o 予約済み（2オクテット）-未使用、ゼロ（0）でなければなりません。
o Integrity Level (variable length) - Specifies the mandatory integrity level required. The integrity level MUST be padded with zero (0) to align on the next 32-bit boundary.
o 整合性レベル（可変長）-必要な必須の整合性レベルを指定します。整合性レベルには、次の32ビット境界に揃えるためにゼロ（0）を埋め込む必要があります。
o Integrity Category Length (2 octets) - Specifies the length, in bits, of the integrity category (compartment) bitmap, excluding pad bits.
o 整合性カテゴリの長さ（2オクテット）-パッドビットを除く、整合性カテゴリ（コンパートメント）ビットマップの長さをビット単位で指定します。
o RESERVED (2 octets) - Unused, must be zero (0).
o 予約済み（2オクテット）-未使用、ゼロ（0）でなければなりません。
o Integrity Category Bitmap (variable length) - A bitmap used to designate integrity categories (compartments) that are required. The bitmap MUST be padded with zero (0) to align on the next 32-bit boundary.
o 整合性カテゴリビットマップ（可変長）-必要な整合性カテゴリ（コンパートメント）を指定するために使用されるビットマップ。ビットマップは、次の32ビット境界に揃えるために、ゼロ（0）で埋め込まれる必要があります。
The following table lists the assigned values for the Labeled Domain Identifier field contained in the Situation field of the Security Association Payload.
次の表は、セキュリティアソシエーションペイロードの[状況]フィールドに含まれる[ラベル付きドメイン識別子]フィールドに割り当てられた値を示しています。
Domain Value
------- -----
RESERVED 0
The Identification Payload is used to identify the initiator of the Security Association. The identity of the initiator SHOULD be used by the responder to determine the correct host system security policy requirement for the association. For example, a host might choose to require authentication and integrity without confidentiality (AH) from a certain set of IP addresses and full authentication with confidentiality (ESP) from another range of IP addresses. The Identification Payload provides information that can be used by the responder to make this decision.
識別ペイロードは、セキュリティアソシエーションの開始者を識別するために使用されます。イニシエーターのIDは、アソシエーションの正しいホストシステムセキュリティポリシー要件を決定するためにレスポンダーによって使用される必要があります（SHOULD）。たとえば、ホストは、特定のIPアドレスのセットからの機密性なしの認証と整合性（AH）と、別の範囲のIPアドレスからの機密性付きの完全認証（ESP）を要求することを選択する場合があります。識別ペイロードは、応答者がこの決定を行うために使用できる情報を提供します。
During Phase I negotiations, the ID port and protocol fields MUST be set to zero or to UDP port 500. If an implementation receives any other values, this MUST be treated as an error and the security association setup MUST be aborted. This event SHOULD be auditable.
フェーズIネゴシエーション中、IDポートとプロトコルフィールドはゼロまたはUDPポート500に設定する必要があります。実装が他の値を受信した場合、これはエラーとして扱われなければならず、セキュリティアソシエーションのセットアップは中止されなければなりません。このイベントは監査可能であるべきです（SHOULD）。
The following diagram illustrates the content of the Identification Payload.
次の図は、識別ペイロードの内容を示しています。
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 ! Protocol ID ! Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Identification Payload Format
図2：識別ペイロードの形式
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, this field will be zero (0).
o 次のペイロード（1オクテット）-メッセージ内の次のペイロードのペイロードタイプの識別子。現在のペイロードがメッセージの最後の場合、このフィールドはゼロ（0）になります。
o RESERVED (1 octet) - Unused, must be zero (0).
o 予約済み（1オクテット）-未使用、ゼロ（0）でなければなりません。
o Payload Length (2 octets) - Length, in octets, of the identification data, including the generic header.
o ペイロード長（2オクテット）-汎用ヘッダーを含む、識別データの長さ（オクテット単位）。
o Identification Type (1 octet) - Value describing the identity information found in the Identification Data field.
o 識別タイプ（1オクテット）-[識別データ]フィールドにある識別情報を説明する値。
o Protocol ID (1 octet) - Value specifying an associated IP protocol ID (e.g. UDP/TCP). A value of zero means that the Protocol ID field should be ignored.
o プロトコルID（1オクテット）-関連付けられたIPプロトコルID（UDP / TCPなど）を指定する値。値がゼロの場合、プロトコルIDフィールドは無視されます。
o Port (2 octets) - Value specifying an associated port. A value of zero means that the Port field should be ignored.
o ポート（2オクテット）-関連付けられたポートを指定する値。ゼロの値は、ポートフィールドを無視する必要があることを意味します。
o Identification Data (variable length) - Value, as indicated by the Identification Type.
o 識別データ（可変長）-識別タイプで示される値。
The following table lists the assigned values for the Identification Type field found in the Identification Payload.
次の表は、識別ペイロードにある識別タイプフィールドに割り当てられた値を示しています。
ID Type Value
------- -----
RESERVED 0
ID_IPV4_ADDR 1
ID_FQDN 2
ID_USER_FQDN 3
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
ID_DER_ASN1_DN 9
ID_DER_ASN1_GN 10
ID_KEY_ID 11
For types where the ID entity is variable length, the size of the ID entity is computed from size in the ID payload header.
IDエンティティが可変長であるタイプの場合、IDエンティティのサイズは、IDペイロードヘッダーのサイズから計算されます。
When an IKE exchange is authenticated using certificates (of any format), any ID's used for input to local policy decisions SHOULD be contained in the certificate used in the authentication of the exchange.
IKE交換が（任意の形式の）証明書を使用して認証される場合、ローカルポリシー決定への入力に使用されるすべてのIDは、交換の認証で使用される証明書に含まれる必要があります（SHOULD）。
The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
ID_IPV4_ADDRタイプは、単一の4オクテットIPv4アドレスを指定します。
The ID_FQDN type specifies a fully-qualified domain name string. An example of a ID_FQDN is, "foo.bar.com". The string should not contain any terminators.
ID_FQDNタイプは、完全修飾ドメイン名文字列を指定します。 ID_FQDNの例は、「foo.bar.com」です。文字列にはターミネータを含めないでください。
The ID_USER_FQDN type specifies a fully-qualified username string, An example of a ID_USER_FQDN is, "piper@foo.bar.com". The string should not contain any terminators.
ID_USER_FQDNタイプは、完全修飾されたユーザー名文字列を指定します。ID_USER_FQDNの例は、「piper@foo.bar.com」です。文字列にはターミネータを含めないでください。
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オクテット値で表されるIPv4アドレスの範囲を指定します。最初の値はIPv4アドレスです。 2つ目はIPv4ネットワークマスクです。ネットワークマスクの1（1）はアドレスの対応するビットが固定であることを示し、0（0）は「ワイルドカード」ビットを示すことに注意してください。
The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 address.
ID_IPV6_ADDRタイプは、単一の16オクテットIPv6アドレスを指定します。
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オクテット値で表されるIPv6アドレスの範囲を指定します。最初の値はIPv6アドレスです。 2つ目はIPv6ネットワークマスクです。ネットワークマスクの1（1）はアドレスの対応するビットが固定であることを示し、0（0）は「ワイルドカード」ビットを示すことに注意してください。
The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses, represented by two four (4) octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list.
ID_IPV4_ADDR_RANGEタイプは、2つの4オクテット値で表されるIPv4アドレスの範囲を指定します。最初の値は開始IPv4アドレス（両端を含む）で、2番目の値は終了IPv4アドレス（両端を含む）です。指定された2つのアドレスの間にあるすべてのアドレスは、リスト内にあると見なされます。
The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list.
ID_IPV6_ADDR_RANGEタイプは、2つの16オクテット値で表されるIPv6アドレスの範囲を指定します。最初の値は開始IPv6アドレス（両端を含む）で、2番目の値は終了IPv6アドレス（両端を含む）です。指定された2つのアドレスの間にあるすべてのアドレスは、リスト内にあると見なされます。
The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501] of the principal whose certificates are being exchanged to establish the SA.
ID_DER_ASN1_DNタイプは、SAを確立するために証明書が交換されるプリンシパルのASN.1 X.500識別名[X.501]のバイナリDERエンコードを指定します。
The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1 X.500 GeneralName [X.509] of the principal whose certificates are being exchanged to establish the SA.
ID_DER_ASN1_GNタイプは、SAを確立するために証明書が交換されるプリンシパルのASN.1 X.500 GeneralName [X.509]のバイナリDERエンコードを指定します。
The ID_KEY_ID type specifies an opaque byte stream which may be used to pass vendor-specific information necessary to identify which pre-shared key should be used to authenticate Aggressive mode negotiations.
ID_KEY_IDタイプは不透明なバイトストリームを指定します。これは、アグレッシブモードネゴシエーションの認証に使用する事前共有キーを識別するために必要なベンダー固有の情報を渡すために使用できます。
ISAKMP defines two blocks of Notify Message codes, one for errors and one for status messages. ISAKMP also allocates a portion of each block for private use within a DOI. The IPSEC DOI defines the following private message types for its own use.
ISAKMPは、通知メッセージコードの2つのブロックを定義します。1つはエラー用、もう1つはステータスメッセージ用です。 ISAKMPは、各ブロックの一部をDOI内でプライベートに使用するために割り当てます。 IPSEC DOIは、独自に使用するために次のプライベートメッセージタイプを定義しています。
Notify Messages - Error Types Value
----------------------------- -----
RESERVED 8192
Notify Messages - Status Types Value
------------------------------ -----
RESPONDER-LIFETIME 24576
REPLAY-STATUS 24577
INITIAL-CONTACT 24578
Notification Status Messages MUST be sent under the protection of an ISAKMP SA: either as a payload in the last Main Mode exchange; in a separate Informational Exchange after Main Mode or Aggressive Mode processing is complete; or as a payload in any Quick Mode exchange. These messages MUST NOT be sent in Aggressive Mode exchange, since Aggressive Mode does not provide the necessary protection to bind the Notify Status Message to the exchange.
通知ステータスメッセージは、ISAKMP SAの保護の下で送信する必要があります。最後のメインモード交換のペイロードとして送信します。メインモードまたはアグレッシブモードの処理が完了した後、別の情報交換で。または、クイックモード交換のペイロードとして。アグレッシブモードでは、ステータス通知メッセージをエクスチェンジにバインドするために必要な保護が提供されないため、これらのメッセージをアグレッシブモードの交換で送信してはなりません。
Nota Bene: a Notify payload is fully protected only in Quick Mode, where the entire payload is included in the HASH(n) digest. In Main Mode, while the notify payload is encrypted, it is not currently included in the HASH(n) digests. As a result, an active substitution attack on the Main Mode ciphertext could cause the notify status message type to be corrupted. (This is true, in general, for the last message of any Main Mode exchange.) While the risk is small, a corrupt notify message might cause the receiver to abort the entire negotiation thinking that the sender encountered a fatal error.
Nota Bene：通知ペイロードは、ペイロード全体がHASH（n）ダイジェストに含まれるクイックモードでのみ完全に保護されます。メインモードでは、通知ペイロードは暗号化されていますが、現在HASH（n）ダイジェストには含まれていません。その結果、メインモード暗号文に対するアクティブな置換攻撃により、ステータス通知メッセージタイプが破損する可能性があります。 （これは通常、メインモード交換の最後のメッセージに当てはまります。）リスクは小さいですが、通知メッセージが破損していると、送信者に致命的なエラーが発生したと考えて、受信者がネゴシエーション全体を中止する場合があります。
Implementation Note: the ISAKMP protocol does not guarantee delivery of Notification Status messages when sent in an ISAKMP Informational Exchange. To ensure receipt of any particular message, the sender SHOULD include a Notification Payload in a defined Main Mode or Quick Mode exchange which is protected by a retransmission timer.
実装上の注意：ISAKMPプロトコルは、ISAKMP Informational Exchangeで送信された場合の通知ステータスメッセージの配信を保証しません。特定のメッセージを確実に受信するために、送信者は、再送信タイマーによって保護されている定義済みのメインモードまたはクイックモードの交換に通知ペイロードを含める必要があります。
The RESPONDER-LIFETIME status message may be used to communicate the IPSEC SA lifetime chosen by the responder.
RESPONDER-LIFETIMEステータスメッセージを使用して、レスポンダが選択したIPSEC SAライフタイムを通知できます。
When present, the Notification Payload MUST have the following format:
存在する場合、通知ペイロードは次の形式にする必要があります。
o Payload Length - set to length of payload + size of data (var) o DOI - set to IPSEC DOI (1) o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP cookies) or four (4) (one IPSEC SPI) o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3) o SPI - set to the two ISAKMP cookies or to the sender's inbound IPSEC SPI o Notification Data - contains an ISAKMP attribute list with the responder's actual SA lifetime(s)
o ペイロードの長さ-ペイロードの長さ+データのサイズ（var）に設定o DOI-IPSEC DOIに設定（1）oプロトコルID-選択したSAから選択したプロトコルIDに設定o SPIサイズ-16（16）のいずれかに設定（2 8オクテットISAKMP cookie）または4（4）（1 IPSEC SPI）o通知メッセージタイプ-RESPONDER-LIFETIMEに設定（セクション4.6.3）o SPI-2つのISAKMP cookieまたは送信者の受信IPSEC SPIに設定o通知データ-レスポンダの実際のSAライフタイムを含むISAKMP属性リストが含まれています
Implementation Note: saying that the Notification Data field contains an attribute list is equivalent to saying that the Notification Data field has zero length and the Notification Payload has an associated attribute list.
実装上の注意：「通知データ」フィールドに属性リストが含まれていると言うことは、「通知データ」フィールドの長さがゼロであり、通知ペイロードに属性リストが関連付けられていると言うことと同じです。
The REPLAY-STATUS status message may be used for positive confirmation of the responder's election on whether or not he is to perform anti-replay detection.
REPLAY-STATUSステータスメッセージは、応答者がアンチリプレイ検出を実行するかどうかを選択したことを確認するために使用できます。
When present, the Notification Payload MUST have the following format:
存在する場合、通知ペイロードは次の形式にする必要があります。
o Payload Length - set to length of payload + size of data (4) o DOI - set to IPSEC DOI (1) o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP cookies) or four (4) (one IPSEC SPI) o Notify Message Type - set to REPLAY-STATUS o SPI - set to the two ISAKMP cookies or to the sender's inbound IPSEC SPI o Notification Data - a 4 octet value:
o ペイロード長-ペイロードの長さ+データのサイズに設定（4）o DOI-IPSEC DOIに設定（1）oプロトコルID-選択したSAから選択したプロトコルIDに設定o SPIサイズ-16（16）のいずれかに設定（2 8オクテットISAKMP Cookie）または4（4）（1 IPSEC SPI）o通知メッセージタイプ-REPLAY-STATUSに設定o SPI-2つのISAKMP Cookieまたは送信者のインバウンドIPSEC SPIに設定o通知データ-4オクテット値：
0 = replay detection disabled 1 = replay detection enabled
0 =リプレイ検出を無効にする1 =リプレイ検出を有効にする
The INITIAL-CONTACT status message may be used when one side wishes to inform the other that this is the first SA being established with the remote system. The receiver of this Notification Message might then elect to delete any existing SA's it has for the sending system under the assumption that the sending system has rebooted and no longer has access to the original SA's and their associated keying material. When used, the content of the Notification Data field SHOULD be null (i.e. the Payload Length should be set to the fixed length of Notification Payload).
INITIAL-CONTACTステータスメッセージは、一方が他方がリモートシステムで確立されている最初のSAであることを他方に通知したい場合に使用できます。この通知メッセージの受信者は、送信側システムが再起動し、元のSAとそれに関連するキー情報にアクセスできなくなったという前提の下で、送信側システムの既存のSAを削除することを選択できます。使用する場合、通知データフィールドの内容はnullにする必要があります（つまり、ペイロードの長さを通知ペイロードの固定長に設定する必要があります）。
When present, the Notification Payload MUST have the following format:
存在する場合、通知ペイロードは次の形式にする必要があります。
o Payload Length - set to length of payload + size of data (0) o DOI - set to IPSEC DOI (1) o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) o Notify Message Type - set to INITIAL-CONTACT o SPI - set to the two ISAKMP cookies o Notification Data - <not included>
o ペイロードの長さ-ペイロードの長さ+データのサイズに設定（0）o DOI-IPSEC DOIに設定（1）oプロトコルID-選択したSAから選択したプロトコルIDに設定o SPIサイズ-16（16）に設定（2 8 -octet ISAKMP cookie）o Notify Message Type-set to INITIAL-CONTACT o SPI-set to the two ISAKMP cookies o Notification Data-<not included>
The IPSEC DOI introduces no additional Key Exchange types.
IPSEC DOIは、追加の鍵交換タイプを導入していません。
This entire memo pertains to the Internet Key Exchange protocol ([IKE]), which combines ISAKMP ([ISAKMP]) and Oakley ([OAKLEY]) to provide for the derivation of cryptographic keying material in a secure and authenticated manner. Specific discussion of the various security protocols and transforms identified in this document can be found in the associated base documents and in the cipher references.
このメモ全体は、ISAKMP（[ISAKMP]）とOakley（[OAKLEY]）を組み合わせて、安全で認証された方法で暗号化キーの派生物を提供するインターネットキーエクスチェンジプロトコル（[IKE]）に関連しています。このドキュメントで特定されているさまざまなセキュリティプロトコルとトランスフォームの具体的な説明は、関連する基本ドキュメントと暗号リファレンスに記載されています。
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. All values not explicitly defined in previous sections are reserved to IANA.
このドキュメントには、IANAによって維持される多くの「マジック」番号が含まれています。このセクションでは、IANAがこれらの各リストに追加の番号を割り当てるために使用する基準について説明します。前のセクションで明示的に定義されていないすべての値は、IANAに予約されています。
The Situation Definition is a 32-bit bitmask which represents the environment under which the IPSEC SA proposal and negotiation is carried out. Requests for assignments of new situations must be accompanied by an RFC which describes the interpretation for the associated bit.
シチュエーション定義は32ビットのビットマスクであり、IPSEC SAプロポーザルとネゴシエーションが実行される環境を表します。新しいシチュエーションの割り当ての要求には、関連ビットの解釈を説明するRFCを添付する必要があります。
If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.
RFCが標準化されていない場合（つまり、情報または実験的なRFCである場合）、RFCが公開されて変換識別子が割り当てられる前に、それをIESGによって明示的に確認および承認する必要があります。
The upper two bits are reserved for private use amongst cooperating systems.
上位2ビットは、協調システム間での私的使用のために予約されています。
The Security Protocol Identifier is an 8-bit value which identifies a security protocol suite being negotiated. Requests for assignments of new security protocol identifiers must be accompanied by an RFC which describes the requested security protocol. [AH] and [ESP] are examples of security protocol documents.
セキュリティプロトコル識別子は、ネゴシエートされているセキュリティプロトコルスイートを識別する8ビットの値です。新しいセキュリティプロトコル識別子の割り当てのリクエストには、リクエストされたセキュリティプロトコルを説明するRFCを添付する必要があります。 [AH]と[ESP]は、セキュリティプロトコルドキュメントの例です。
If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.
RFCが標準化されていない場合（つまり、情報または実験的なRFCである場合）、RFCが公開されて変換識別子が割り当てられる前に、それをIESGによって明示的に確認および承認する必要があります。
The values 249-255 are reserved for private use amongst cooperating systems.
値249-255は、協調システム間での私的使用のために予約されています。
The IPSEC ISAKMP Transform Identifier is an 8-bit value which identifies a key exchange protocol to be used for the negotiation. Requests for assignments of new ISAKMP transform identifiers must be accompanied by an RFC which describes the requested key exchange protocol. [IKE] is an example of one such document.
IPSEC ISAKMP Transform Identifierは、ネゴシエーションに使用される鍵交換プロトコルを識別する8ビットの値です。新しいISAKMP変換識別子の割り当ての要求には、要求された鍵交換プロトコルを説明するRFCを添付する必要があります。 [IKE]はそのようなドキュメントの例です。
If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.
RFCが標準化されていない場合（つまり、情報または実験的なRFCである場合）、RFCが公開されて変換識別子が割り当てられる前に、それをIESGによって明示的に確認および承認する必要があります。
The values 249-255 are reserved for private use amongst cooperating systems.
値249-255は、協調システム間での私的使用のために予約されています。
The IPSEC AH Transform Identifier is an 8-bit value which identifies a particular algorithm to be used to provide integrity protection for AH. Requests for assignments of new AH transform identifiers must be accompanied by an RFC which describes how to use the algorithm within the AH framework ([AH]).
IPSEC AH Transform Identifierは、AHの整合性保護を提供するために使用される特定のアルゴリズムを識別する8ビット値です。新しいAH変換識別子の割り当ての要求には、AHフレームワーク（[AH]）内でアルゴリズムを使用する方法を説明するRFCを添付する必要があります。
If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.
RFCが標準化されていない場合（つまり、情報または実験的なRFCである場合）、RFCが公開されて変換識別子が割り当てられる前に、それをIESGによって明示的に確認および承認する必要があります。
The values 249-255 are reserved for private use amongst cooperating systems.
値249-255は、協調システム間での私的使用のために予約されています。
The IPSEC ESP Transform Identifier is an 8-bit value which identifies a particular algorithm to be used to provide secrecy protection for ESP. Requests for assignments of new ESP transform identifiers must be accompanied by an RFC which describes how to use the algorithm within the ESP framework ([ESP]).
IPSEC ESP Transform Identifierは、ESPの機密保護を提供するために使用される特定のアルゴリズムを識別する8ビット値です。新しいESP変換識別子の割り当ての要求には、ESPフレームワーク（[ESP]）内でアルゴリズムを使用する方法を説明するRFCを添付する必要があります。
If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.
RFCが標準化されていない場合（つまり、情報または実験的なRFCである場合）、RFCが公開されて変換識別子が割り当てられる前に、それをIESGによって明示的に確認および承認する必要があります。
The values 249-255 are reserved for private use amongst cooperating systems.
値249-255は、協調システム間での私的使用のために予約されています。
The IPSEC IPCOMP Transform Identifier is an 8-bit value which identifier a particular algorithm to be used to provide IP-level compression before ESP. Requests for assignments of new IPCOMP transform identifiers must be accompanied by an RFC which describes how to use the algorithm within the IPCOMP framework ([IPCOMP]). In addition, the requested algorithm must be published and in the public domain.
IPSEC IPCOMP Transform Identifierは、ESPの前にIPレベルの圧縮を提供するために使用される特定のアルゴリズムを識別する8ビットの値です。新しいIPCOMP変換識別子の割り当ての要求には、IPCOMPフレームワーク（[IPCOMP]）内でアルゴリズムを使用する方法を説明するRFCを添付する必要があります。さらに、要求されたアルゴリズムは公開され、パブリックドメインにある必要があります。
If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.
RFCが標準化されていない場合（つまり、情報または実験的なRFCである場合）、RFCが公開されて変換識別子が割り当てられる前に、それをIESGによって明示的に確認および承認する必要があります。
The values 1-47 are reserved for algorithms for which an RFC has been approved for publication. The values 48-63 are reserved for private use amongst cooperating systems. The values 64-255 are reserved for future expansion.
1〜47の値は、RFCの公開が承認されているアルゴリズム用に予約されています。値48〜63は、協調システム間での私的使用のために予約されています。値64-255は将来の拡張のために予約されています。
The IPSEC Security Association Attribute consists of a 16-bit type and its associated value. IPSEC SA attributes are used to pass miscellaneous values between ISAKMP peers. Requests for assignments of new IPSEC SA attributes must be accompanied by an Internet Draft which describes the attribute encoding (Basic/Variable-Length) and its legal values. Section 4.5 of this document provides an example of such a description.
IPSECセキュリティアソシエーション属性は、16ビットタイプとそれに関連付けられた値で構成されます。 IPSEC SA属性は、ISAKMPピア間でその他の値を渡すために使用されます。新しいIPSEC SA属性の割り当ての要求には、属性エンコーディング（Basic / Variable-Length）とその正当な値を記述したインターネットドラフトを添付する必要があります。このドキュメントのセクション4.5は、そのような説明の例を提供します。
The values 32001-32767 are reserved for private use amongst cooperating systems.
値32001-32767は、協調システム間での私的使用のために予約されています。
The IPSEC Labeled Domain Identifier is a 32-bit value which identifies a namespace in which the Secrecy and Integrity levels and categories values are said to exist. Requests for assignments of new IPSEC Labeled Domain Identifiers should be granted on demand. No accompanying documentation is required, though Internet Drafts are encouraged when appropriate.
IPSECラベル付きドメイン識別子は32ビット値であり、機密性と整合性のレベルとカテゴリの値が存在すると言われている名前空間を識別します。新しいIPSECラベル付きドメイン識別子の割り当ての要求は、オンデマンドで許可する必要があります。付随するドキュメントは必要ありませんが、必要に応じてインターネットドラフトを推奨します。
The values 0x80000000-0xffffffff are reserved for private use amongst cooperating systems.
値0x80000000-0xffffffffは、協調システム間での私的使用のために予約されています。
The IPSEC Identification Type is an 8-bit value which is used as a discriminant for interpretation of the variable-length Identification Payload. Requests for assignments of new IPSEC Identification Types must be accompanied by an RFC which describes how to use the identification type within IPSEC.
IPSEC識別タイプは8ビット値であり、可変長識別ペイロードの解釈の判別式として使用されます。新しいIPSEC識別タイプの割り当ての要求には、IPSEC内で識別タイプを使用する方法を説明するRFCを添付する必要があります。
If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.
RFCが標準化されていない場合（つまり、情報または実験的なRFCである場合）、RFCが公開されて変換識別子が割り当てられる前に、それをIESGによって明示的に確認および承認する必要があります。
The values 249-255 are reserved for private use amongst cooperating systems.
値249-255は、協調システム間での私的使用のために予約されています。
The IPSEC Notify Message Type is a 16-bit value taken from the range of values reserved by ISAKMP for each DOI. There is one range for error messages (8192-16383) and a different range for status messages (24576-32767). Requests for assignments of new Notify Message Types must be accompanied by an Internet Draft which describes how to use the identification type within IPSEC.
IPSEC通知メッセージタイプは、各DOIのISAKMPによって予約された値の範囲から取得した16ビットの値です。エラーメッセージの範囲は1つ（8192〜16383）で、ステータスメッセージの範囲は別（24576〜32767）です。新しい通知メッセージタイプの割り当てのリクエストには、IPSEC内で識別タイプを使用する方法を説明したインターネットドラフトを添付する必要があります。
The values 16001-16383 and the values 32001-32767 are reserved for private use amongst cooperating systems.
値16001-16383と値32001-32767は、協調システム間での私的使用のために予約されています。
o add explicit reference to [IPCOMP], [DEFLATE], and [LZS] o allow RESPONDER-LIFETIME and REPLAY-STATUS to be directed at an IPSEC SPI in addition to the ISAKMP "SPI" o added padding exclusion to Secrecy and Integrity Length text o added forward reference to Section 4.5 in Section 4.4.4 o update document references
o [IPCOMP]、[DEFLATE]、および[LZS]への明示的な参照を追加o ISAKMP "SPI"に加えて、RESPONDER-LIFETIMEおよびREPLAY-STATUSをIPSEC SPIで送信できるようにします。 oセクション4.4.4のセクション4.5への前方参照を追加oドキュメント参照の更新
o update IPCOMP identifier range to better reflect IPCOMP draft o update IANA considerations per Jeff/Ted's suggested text o eliminate references to DES-MAC ID ([DESMAC]) o correct bug in Notify section; ISAKMP Notify values are 16-bits
o IPCOMPドラフトをより適切に反映するためにIPCOMP識別子の範囲を更新o Jeff / Tedの提案テキストに従ってIANAの考慮事項を更新o DES-MAC ID（[DESMAC]）への参照を削除o通知セクションのバグを修正ISAKMP通知値は16ビットです
o corrected name of IPCOMP (IP Payload Compression) o corrected references to [ESPCBC] o added missing Secrecy Level and Integrity Level to Figure 1 o removed ID references to PF_KEY and ARCFOUR o updated Basic/Variable text to align with [IKE] o updated document references and add intro pointer to [ARCH] o updated Notification requirements; remove aggressive reference o added clarification about protection for Notify payloads o restored RESERVED to ESP transform ID namespace; moved ESP_NULL o added requirement for ESP_NULL support and [ESPNULL] reference o added clarification on Auth Alg use with AH/ESP o added restriction against using conflicting AH/Auth combinations
o IPCOMP（IPペイロード圧縮）の名前を修正o [ESPCBC]への参照を修正o図1に欠落している機密レベルと整合性レベルを追加o PF_KEYとARCFOURへのID参照を削除o [IKE]に合わせて更新された基本/変数テキストo更新されたドキュメント参照と[ARCH]へのイントロポインタを追加o更新された通知要件。積極的な参照を削除o Notifyペイロードの保護に関する説明を追加o ESP変換ID名前空間にRESERVEDを復元ESP_NULLの移動o ESP_NULLサポートの要件と[ESPNULL]参照の追加o AH / ESPでのAuth Algの使用に関する説明の追加o競合するAH / Authの組み合わせの使用に対する制限の追加
The following changes were made relative to the IPSEC DOI V6:
IPSEC DOI V6に関連して、次の変更が行われました。
o added IANA Considerations section o moved most IANA numbers to IANA Considerations section o added prohibition on sending (V) encoding for (B) attributes o added prohibition on sending Key Length attribute for fixed length ciphers (e.g. DES) o replaced references to ISAKMP/Oakley with IKE o renamed ESP_ARCFOUR to ESP_RC4 o updated Security Considerations section o updated document references
o IANA考慮事項セクションを追加oほとんどのIANA番号をIANA考慮事項セクションに移動o（B）属性の（V）エンコードの送信禁止を追加o固定長暗号（DESなど）のキー長属性の送信禁止を追加o ISAKMP / Oakleyへの参照の置き換えIKEを使用o ESP_ARCFOURをESP_RC4に名前変更oセキュリティに関する考慮事項セクションを更新oドキュメント参照を更新
The following changes were made relative to the IPSEC DOI V5:
IPSEC DOI V5に関連して、次の変更が行われました。
o changed SPI size in Lifetime Notification text o changed REPLAY-ENABLED to REPLAY-STATUS o moved RESPONDER-LIFETIME payload definition from Section 4.5.4 to Section 4.6.3.1 o added explicit payload layout for 4.6.3.3 o added Implementation Note to Section 4.6.3 introduction o changed AH_SHA text to require SHA-1 in addition to MD5 o updated document references
o ライフタイム通知テキストのSPIサイズを変更o REPLAY-ENABLEDをREPLAY-STATUSに変更o RESPONDER-LIFETIMEペイロード定義をセクション4.5.4からセクション4.6.3.1に移動o 4.6.3.3の明示的なペイロードレイアウトを追加oセクション4.6に実装ノートを追加3はじめにo MD5に加えてSHA-1を要求するようにAH_SHAテキストを変更o更新されたドキュメント参照
The following changes were made relative to the IPSEC DOI V4:
IPSEC DOI V4に関連して、次の変更が行われました。
o moved compatibility AH KPDK authentication method from AH transform ID to Authentication Algorithm identifier o added REPLAY-ENABLED notification message type per Architecture o added INITIAL-CONTACT notification message type per list o added text to ensure protection for Notify Status messages o added Lifetime qualification to attribute parsing section o added clarification that Lifetime notification is optional o removed private Group Description list (now points at [IKE]) o replaced Terminology with pointer to RFC-2119 o updated HMAC MD5 and SHA-1 ID references o updated Section 1 (Abstract) o updated Section 4.4 (IPSEC Assigned Numbers) o added restriction for ID port/protocol values for Phase I
o 互換性AH KPDK認証方式をAH変換IDから認証アルゴリズム識別子に移動oアーキテクチャごとにREPLAY-ENABLED通知メッセージタイプを追加oリストごとにINITIAL-CONTACT通知メッセージタイプを追加o通知ステータスメッセージを確実に保護するためのテキストを追加o属性にライフタイム資格を追加解析セクションoライフタイム通知がオプションであることの説明を追加oプライベートグループの説明リストを削除（現在は[IKE]を指す）o用語をRFC-2119へのポインターに置き換えo更新されたHMAC MD5およびSHA-1 ID参照o更新されたセクション1（要約） oセクション4.4（IPSEC割り当て番号）の更新oフェーズIのIDポート/プロトコル値の制限を追加
The following changes were made relative to the IPSEC DOI V3, that was posted to the IPSEC mailing list prior to the Munich IETF:
ミュンヘンIETFの前にIPSECメーリングリストに投稿されたIPSEC DOI V3に関連して、次の変更が行われました。
o added ESP transform identifiers for NULL and ARCFOUR
o renamed HMAC Algorithm to Auth Algorithm to accommodate
DES-MAC and optional authentication/integrity for ESP
o added AH and ESP DES-MAC algorithm identifiers
o removed KEY_MANUAL and KEY_KDC identifier definitions
o added lifetime duration MUST follow lifetype attribute to
SA Life Type and SA Life Duration attribute definition
o added lifetime notification and IPSEC DOI message type table
o added optional authentication and confidentiality
restrictions to MAC Algorithm attribute definition
o corrected attribute parsing example (used obsolete attribute)
o corrected several Internet Draft document references
o added ID_KEY_ID per ipsec list discussion (18-Mar-97)
o removed Group Description default for PFS QM ([IKE] MUST)
Acknowledgments
謝辞
This document is derived, in part, from previous works by Douglas Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins, and Dave Carrel. Matt Thomas, Roy Pereira, Greg Carter, and Ran Atkinson also contributed suggestions and, in many cases, text.
このドキュメントの一部は、ダグラスモーガン、マークシャートラー、マークシュナイダー、ジェフターナー、ダンハーキンス、およびデイブキャレルによる以前の作品から派生しています。マット・トーマス、ロイ・ペレイラ、グレッグ・カーター、ラン・アトキンソンも提案を出し、多くの場合、テキストを書いた。
References
参考文献
[AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]ケント、S。、およびR.アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[ARCH] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[ARCH]ケント、S。、およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[DEFLATE] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, August 1998.
[DEFLATE] Pereira、R。、「DEFLATEを使用したIPペイロード圧縮」、RFC 2394、1998年8月。
[ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP] Kent、S。、およびR. Atkinson、「IP Encapsulating Security Payload（ESP）」、RFC 2406、1998年11月。
[ESPCBC] Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[ESPCBC] Pereira、R。、およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、1998年11月。
[ESPNULL] Glenn, R., and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[ESPNULL]グレン、R。、およびS.ケント、「NULL暗号化アルゴリズムとIPsecでのその使用」、RFC 2410、1998年11月。
[DES] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[DES] Madson、C。、およびN. Doraswamy、「The ESP DES-CBC Cipher Algorithm With Explicit IV」、RFC 2405、1998年11月。
[HMACMD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP and AH", RFC 2403, November 1998.
[HMACMD5] Madson、C。、およびR. Glenn、「The Use of HMAC-MD5 within ESP and AH」、RFC 2403、1998年11月。
[HMACSHA] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[HMACSHA] Madson、C。、およびR. Glenn、「The Use of HMAC-SHA-1-96 within ESP and AH」、RFC 2404、1998年11月。
[IKE] Harkins, D., and D. Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE] Harkins、D。、およびD. Carrel、D。、「インターネットキーエクスチェンジ（IKE）」、RFC 2409、1998年11月。
[IPCOMP] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, August 1998.
[IPCOMP] Shacham、A.、Monsour、R.、Pereira、R。、およびM. Thomas、「IP Payload Compression Protocol（IPComp）」、RFC 2393、1998年8月。
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[ISAKMP] Maughan、D.、Schertler、M.、Schneider、M。、およびJ. Turner、「インターネットセキュリティアソシエーションおよびキー管理プロトコル（ISAKMP）」、RFC 2408、1998年11月。
[LZS] Friend, R., and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, August 1998.
[LZS] Friend、R。、およびR. Monsour、「LZSを使用したIPペイロード圧縮」、RFC 2395、1998年8月。
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[OAKLEY]オーマン、H。、「The OAKLEY鍵決定プロトコル」、RFC 2412、1998年11月。
[X.501] ISO/IEC 9594-2, "Information Technology - Open Systems Interconnection - The Directory: Models", CCITT/ITU Recommendation X.501, 1993.
[X.501] ISO / IEC 9594-2、「情報技術-オープンシステム相互接続-ディレクトリ：モデル」、CCITT / ITU勧告X.501、1993。
[X.509] ISO/IEC 9594-8, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT/ITU Recommendation X.509, 1993.
[X.509] ISO / IEC 9594-8、「情報技術-オープンシステム相互接続-ディレクトリ：認証フレームワーク」、CCITT / ITU勧告X.509、1993。
Author's Address
著者のアドレス
Derrell Piper Network Alchemy 1521.5 Pacific Ave Santa Cruz, California, 95060 United States of America
デレルパイパーネットワークアルケミー1521.5 Pacific Ave Santa Cruz、California、95060アメリカ合衆国
Phone: +1 408 460-3822
EMail: ddp@network-alchemy.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。