RFC2407 日本語訳
2407 The Internet IP Security Domain of Interpretation for ISAKMP. D.Piper. November 1998. (Format: TXT=67878 bytes) (Obsoleted by RFC4306) (Status: PROPOSED STANDARD)
RFC一覧
英語原文
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.
この文書は、Internet community のための Internet standards track
protocol を明細に記述し、改良のための討議と提案を要求する。このプロ
トコルの標準化状態とステータスについては、"Internet Official
Protocol Standards" (STD 1) の最新版を参照してもらいたい。このメモの
配布は、無制限である。
-----------------------------------------------------------------------
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
-----------------------------------------------------------------------
IESG Note
IESG メモ
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.
Section 4.4.4.2 は、"IPSEC DOI 範囲内のすべての実装は、 ESP_DES をサ
ポートしなければならない (MUST)..." と言明する。暗号解析学の分野での
最近の研究は、次のことを示唆する。それは、DES が多くの application
について十分に強くないかもしれないということである。それゆえ IETF は
近い将来に、必須な暗号一式としての ESP_DES 使用を賛成しないと唱えそ
うである。これは、オプションな使用プロトコルとして残るだろう。IPsec
working group と IETF は (セキュリティとパフォーマンスの関心に注意し
て) 代わりとなるアルゴリズムを一般に選ばないけれども、実装者は、
ESP_3DES の使用による section 4.4.4.3 の勧告に注意を払うことを望むか
もしれない。
-----------------------------------------------------------------------
1. Abstract
1. 要約
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 と Key Management Protocol (ISAKMP) は
Intenet のためのセキュリティアソシエーション管理と暗号鍵確立に関する
枠組を定義する。この枠組は、与えられた Domain of Interpretation
(DOI) 範囲内で行われる定義された交換、ペイロード(s) と処理の指針から
なる。この文書は、Internet IP Security DOI (IPSEC DOI) を定義する。
そしてこれは、IP がセキュリティアソシエーションを取り決めるために
ISAKMP を使用する時、IP との使用のための ISAKMP を例示する。
For a list of changes since the previous version of the IPSEC DOI,
please see Section 7.
IPSEC DOI の前のバージョンからの変更リストについて、Section 7 を参照
してもらいたい。
-----------------------------------------------------------------------
2. Introduction
2. 序論
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 範囲内で、Domain of Interpretation は、セキュリティアソシエー
ションを取り決めるために ISAKMP を使用する関連されたプロトコル(s) を
分類するために使用する。DOI を共有するセキュリティプロトコル(s) は、
共通の名前空間からセキュリティプロトコルと暗号学変換を選択し、鍵交換
識別子を共有する。これらは、Security Association と Identification
ペイロード(s) を含んで、DOI 特定のペイロードデータ内容の共通解釈も共
有する。
Overall, ISAKMP places the following requirements on a DOI
definition:
全体として、ISAKMP は、DOI 定義上で次に述べる要求を並べる:
o define the naming scheme for DOI-specific protocol identifiers
DOI 特定のプロトコル識別子(s) のための名前構成を定義
o define the interpretation for the Situation field
Situation フィールドのための解釈を定義
o define the set of applicable security policies
適用できるセキュリティポリシー(s) のセットを定義
o define the syntax for DOI-specific SA Attributes (Phase II)
DOI 特定の SA Attributes (Phase II) のための syntax を定義
o define the syntax for DOI-specific payload contents
DOI 特定のペイロード内容(s) のための syntax を定義
o define additional Key Exchange types, if needed
もし必要なら、追加の Key Exchange タイプ(s) を定義
o define additional Notification Message types, if needed
もし必要なら、追加の Notification Message タイプ(s) を定義
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.
この文書の残りは、次に述べる要求の例示を詳しく述べる。その要求とは、
協力している host systems and/or firewalls 間で送信される IP パケッ
ト(s) のための認証、完全性、and/or 機密性を提供するため使用する IP
Security (IPSEC) プロトコル(s) に関することである。
For a description of the overall IPSEC architecture, see [ARCH],
[AH], and [ESP].
全体の IPSEC アーキテクチャの記述について、[ARCH], [AH] と [ESP] を
参照しなさい。
-----------------------------------------------------------------------
3. Terms and Definitions
3. 用語と定義
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].
キーワード MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY と OPTIONAL が、この文書で現れた時、
[RFC 2119] で記述されたとして解釈されるべきである。
-----------------------------------------------------------------------
4.1 IPSEC Naming Scheme
4.1 IPSEC 名前構成
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 は、"Assigned Numbers" RFC [STD-2] で
IANA に登録されなければならない。Internet IP Security DOI
(IPSEC DOI) のための IANA Assigned Number は、one (1) である。IPSEC
DOI 範囲内で、すべてのよく知られた識別子は、IPSEC DOI の下で IANA に
登録されなければならない (MUST)。もし別の方法で言及されなければ、こ
の文書内のすべての表(s) は、IPSEC DOI のための IANA Assigned Numbers
を参照する。
All multi-octet binary values are stored in network byte order.
すべての multi-octet binary 値は、network byte order で格納される。
4.2 IPSEC Situation Definition
4.2 IPSEC 状態定義
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 範囲内で、Situation (状態) は、次に述べる情報を提供する。それ
は、incoming (内向けの) Security Association 要求を処理する方法につ
いて、ポリシー決定をおこなうため、responder (応答側) により使用され
ることができる情報である。
Situation Value
--------- -----
SIT_IDENTITY_ONLY 0x01
SIT_SECRECY 0x02
SIT_INTEGRITY 0x04
4.2.1 SIT_IDENTITY_ONLY
4.2.1 SIT_IDENTITY_ONLY 識別子
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 タイプは、次のことを明細に述べる。それは、セキュリ
ティアソシエーションが、関連される Identification Payload に存在する
始点身元情報により識別されることである。さまざまな Identification タ
イプ(s) の完全な記述について、Section 4.6.2 を参照しなさい。すべての
IPSEC DOI 実装(s) は、Phase I Oakley 交換(s) ([IKE], Section 5) の少
なくとも 1 つに Identification Payload を含むことにより
SIT_IDENTITY_ONLY をサポートしなければならない (MUST)。そしてそれら
実装は、Identification Payload を含まないどんなアソシエーションも中
止しなければならない (MUST)。
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.
もし initiator (初期送信側/始動側) が SIT_SECRECY や SIT_INTEGRITY
もサポートしないなら、状態は 4 octet 状態 bitmap のみからなる。そし
て状態は、Labeled Domain Identifier フィールド (図 1, Section 4.6.1)
や、どんな後に続くラベル情報も含まない。反対に、もし initiator が
SIT_SECRECY か SIT_INTEGRITY どちらかをサポートするなら、Labeled
Domain Identifier は、状態ペイロードに含まれなければならない
(MUST)。
4.2.2 SIT_SECRECY
4.2.2 SIT_SECRECY 識別子
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 タイプは、次のことを明細に述べる。それは、セキュリティア
ソシエーションが、ラベルされる secrecy (秘密) を要求する環境で取り決
められていることである。もし SIT_SECRECY が Situation bitmap にある
なら、Situation フィールドは sensitivity (感度) level と compartment
(仕切り) bitmask を含む可変長データにより続かれるだろう。Security
Association Payload 形式の完全な記述について Section 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.
もし initiator が SIT_SECRECY をサポートしないなら、SIT_SECRECY は
Situation bitmap に決してセットされてはならない (MUST NOT)。そして
secrecy level や category (分類) bitmaps が、含まれるかもしれないこ
とはない。
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.
もし responder が SIT_SECRECY をサポートしないなら、SITUATION-NOT-
SUPPORTED Notification Payload が返されるかもしれない (SHOULD)。そし
てセキュリティアソシエーションセットアップは、中止されなければならな
い (MUST)。
4.2.3 SIT_INTEGRITY
4.2.3 SIT_INTEGRITY 識別子
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 bitmap にあるなら、
Situation フィールドは、完全性 level と compartment bitmask を含む可
変長データにより続けられるだろう。もし SIT_SECRECY がそのアソシエー
ションのためにも使用するなら、完全性情報は、可変長 secrecy level と
categories に直ちに続く。Security Association Payload 形式の完全な記
述について、section 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.
もし initiator が SIT_INTEGRITY をサポートしないなら、SIT_INTEGRITY
は、Situation bitmap に決してセットされてはならない (MUST)。そして
完全性 level や category bitmaps は含まれるかもしれないことはない。
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.
もし responder が SIT_INTEGRITY をサポートしないなら、SITUATION-NOT-
SUPPORTED Notification Payload が返されるかもしれない (SHOULD)。そし
てセキュリティアソシエーションセットアップは、中止されなければならな
い (MUST)。
4.3 IPSEC Security Policy Requirements
4.3 IPSEC セキュリティポリシー要求
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 は、どんな実装上にも、特定のセキュリティポリシー要求を課さ
ない。host system ポリシー問題は、この文書の範囲外である。
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.
しかしながら、次に述べる sections は、IPSEC DOI host 実装を設計する
時に、考慮にいれなければならないいくつかの問題に簡単に言及する。この
section は、本質的に情報のみとみなされるべきである。
4.3.1 Key Management Issues
4.3.1 鍵管理問題
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 を実装することに決める多くの systems は、組み合わせる IKE 鍵
管理 daemon に関し、実行の保護されたドメインを提供しようと努力する。
保護されたモードの multiuser operating systems 上で、この鍵管理
daemon は、別々の特権あるプロセスとして、たぶん存在するだろう。
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 kernel へと導入する形式化された
API は、望ましいかもしれない。IP Security アーキテクチャは、host
TCP/IP kernel 間の構造や流れと、その鍵管理提供者について、どんな要求
も並べない。
4.3.2 Static Keying Issues
4.3.2 静的鍵設定問題
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.
静的鍵(s) を実装する host systems は、静的鍵材料を保護するための
steps を取るべきである。それは、保護されるメモリドメインに存在しない
か、TCP/IP kernel により active に使用されていない時にである。そして
その静的鍵(s) は、IPSEC により直接使用するためか、認証目的 ([IKE]
Section 5.4 を参照しなさい) のためどちらでもである。
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.
たとえば、laptop (パソコン) 上で、そのパソコンは、静的鍵(s) を次のよ
うにして設定記憶装置に格納するよう決めるかもしれない。それは、その鍵
自身をプライベートパスワードに従い暗号化して格納することである。
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.
operating system とインストールされた utility software に依存して、
静的鍵(s) を保護することは可能でないかもしれない。いったんそれら鍵が
TCP/IP kernel へと読み込まれた場合である。しかしながら、それら鍵は、
認証のある追加の形式を満たさなければならないことなしに、初期 system
起動でささいに回復可能であるべきでない。
4.3.3 Host Policy Issues
4.3.3 ホストポリシー問題
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 への移行が突然おこなわれるのを想定することは、現実的でない。
host systems は、次に述べる柔軟なポリシーリスト(s) を実装するため用
意されなければならない。そのポリシーリストとは、それら systems がど
の systems と secure に話す (通信する) ことを強く望むかと、それら
systems がどの systems が systems と secure に話す (通信する) ことを
要求するかを記述することである。proxy firewall アドレス(s) の何らか
の概念が、同様に必要とされるかもしれない。
A minimal approach is probably a static list of IP addresses, network
masks, and a security required flag or flags.
最小の方法は、たぶん IP アドレス(s)、network masks とセキュリティで
必要とされる flag や flags の静的なリストである。
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.
より柔軟な実装は、wildcard DNS names (たとえば '*.foo.bar')、in/out
bitmask とオプションとしての firewall アドレスのリストからなるかもし
れない。wildcard DNS name は、incoming (内向け) や outgoing (外向け)
IP アドレス(s) にマッチするため使用される。in/out bitmask は、セキュ
リティが適用されることになっているかどうか、どの方向へかを決定するた
めに使用される。オプションとしての firewall アドレスは、tunnel mode
が中間の firewall を通して目標の system と話すのに必要とされるかどう
かを指し示すために使用される。
4.3.4 Certificate Management
4.3.4 証明書管理
Host systems implementing a certificate-based authentication scheme
will need a mechanism for obtaining and managing a database of
certificates.
証明書ベースの認証方法を実装する host systems は、証明書(s) のデータ
ベースを入手し管理するためのメカニズムを必要とする。
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.
secure DNS は、1 つの証明書配布メカニズムになることになっている。し
かしながら、secure DNS zones の普及力のある可能性は、要約すると多く
の理由のために疑わしい。大いにありそうなことは、hosts が、他の
systems により使用するための自分自身の証明書(s) を外へ出すのと同様に
入手する証明書を持ち込む能力を必要とすることである。この証明書は、
secure な out-of-band (帯域外) メカニズムを通してである。
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.
しかしながら、手動証明書管理は、動的証明書探索メカニズム(s) and/or
プロトコル(s) が利用可能になるとして、それらメカニズムとプロトコルの
導入能力を排除するようにおこなわれるべきでない。
4.4 IPSEC Assigned Numbers
4.4. IPSEC の割り当てられた番号(s)
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.
次に述べる sections は、IPSEC DOI のための Assigned Numbers をリスト
する: Situation Identifiers, Protocol Identifiers, Transform
Identifiers, AH, ESP と IPCOMP Transform Identifiers, Security
Association Attribute Type Values, Labeled Domain Identifiers, ID
Payload Type Values と Notify Message Type Values である。
4.4.1 IPSEC Security Protocol Identifier
4.4.1 IPSEC セキュリティプロトコル識別子
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 提案 syntax は、単一の negotiation 内で、multiple Phase II セ
キュリティプロトコル体系(s) に関し同時に起こる negotiation を考慮に
いれるため明確に設計された。結果として、下でリストされるプロトコル体
系(s) は、同時刻に取り決められることができるプロトコル(s) のセットを
構成する。これは、何のプロトコル体系がともに取り決められるかもしれな
いかに関して、ホストポリシー決定である (?)。
The following table lists the values for the Security Protocol
Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC
DOI.
次に続く表は、IPSEC に関する ISAKMP Proposal Payload で参照される
Security Protocol Identifiers の値をリストする。
Protocol ID Value
----------- -----
RESERVED 0
PROTO_ISAKMP 1
PROTO_IPSEC_AH 2
PROTO_IPSEC_ESP 3
PROTO_IPCOMP 4
4.4.1.1 PROTO_ISAKMP
4.4.1.1 PROTO_ISAKMP 識別子
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 プロトコルの Phase I の間に要求される
メッセージ保護を指定する。IPSEC DOI のために使用される特定の保護メカ
ニズムは、[IKE] で記述される。IPSEC DOI 範囲内のすべての実装(s) は、
PROTO_ISAKMP をサポートしなければならない (MUST)。
NB: ISAKMP reserves the value one (1) across all DOI definitions.
注意: ISAKMP は、すべての DOI 定義を越えて、値 one (1) を予約する。
4.4.1.2 PROTO_IPSEC_AH
4.4.1.2 PROTO_IPSEC_AH 識別子
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 変
換は、データ源認証、完全性保護と replay 検出を提供する。輸出規制に関
する考慮のため、機密性は、どんな PROTO_IPSEC_AH 変換により決して提供
されてはならない (MUST)。
4.4.1.3 PROTO_IPSEC_ESP
4.4.1.3 PROTO_IPSEC_ESP 識別子
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 変換は、データ源認証、完全性保護、 replay 検出と機密性
を提供する。
4.4.1.4 PROTO_IPCOMP
4.4.1.4 PROTO_IPCOMP 識別子
The PROTO_IPCOMP type specifies IP payload compression as defined in
[IPCOMP].
PROTO_IPCOMP タイプは、[IPCOMP] で定義されたとして IP ペイロード圧縮
を指定する。
4.4.2 IPSEC ISAKMP Transform Identifiers
4.4.2 IPSEC ISAKMP 変換識別子
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 Phase I negotiation の一部分として、Key Exchange 提供の
initiator の選択は、ある host system policy 記述を使用しておこなわれ
る。Key Exchange メカニズムの実際の選択は、標準 ISAKMP Phase Payload
を使用しておこなわれる。次の表は、IPSEC DOI の Proposal Payload のた
めの定義された ISAKMP Phase I Transform Identifiers をリストする。
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) とは別の鍵確立プロト
コル(s) を定義することは可能である。この文書の前の versions は、手動
鍵設定と一般的な Key Distribution Center (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 は、ISAKMP と IPSEC に関する、追加の Oakley でない鍵確立プ
ロトコル(s) のための値を含むために、後でなお拡張されることができる。
そのプロトコルとは、Kerberos [RFC-1510] や Group Key Management
Protocol (GKMP) [RFC-2093] のようなのをいう。
4.4.2.1 KEY_IKE
4.4.2.1 KEY_IKE 識別子
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 範囲内のすべての実
装(s) は、KEY_IKE をサポートしなければならない (MUST)。
4.4.3 IPSEC AH Transform Identifiers
4.4.3 IPSEC AH 変換識別子
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.
Authentication Header Protocol (AH: 認証ヘッダ) は、認証、完全性と
replay 検出を提供するために使用される、1 つの必須変換 (?) といくつか
のオプションな変換(s) を定義する。次の表は、IPSEC DOI の ISAKMP
Proposal Payload のため定義された AH Transform Identifiers をリスト
する。
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.
注意: Authentication Algorithm 属性は、適切な AH 保護体系を識別する
ために指定されなければならない (MUST)。たとえば、AH_MD5 は、MD5 を使
用する一般的な AH 変換として最もよいとみなされることができる。AH と
の HMAC 構造を要請するため、HMAC(?) は、HMAC-MD5 にセットされた
Authentication Algorithm 属性とともに AH_MD5 変換 ID を指定する。こ
れは、次の sections で "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.
注意: すべての実装必須なアルゴリズム(s) は、次の sections で、実装し
なければならない "MUST" (たとえば AH_MD5) としてリストされる。すべて
の他のアルゴリズム(s) はオプションであり、何らかの特定の実装で実装さ
れるかもしれない (MAY)。
4.4.3.1 AH_MD5
4.4.3.1 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 範囲内のすべての実装(s) は、Auth(HMAC-MD5) 属性とともに
AH_MD5 をサポートしなければならない (MUST)。この体系は、[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.
Auth(KPDK) 属性との AH_MD5 タイプは、RFC-1826 で記述される AH 変換
(Key/Pad/Data/Key) を指定する。
Use of AH_MD5 with any other Authentication Algorithm attribute value
is currently undefined.
何らかの他の Authentication Algorithm 属性値との AH_MD5 の使用は、現
在定義されていない。
4.4.3.2 AH_SHA
4.4.3.2 AH_SHA 識別子
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 範囲内のすべての実装(s) は、Auth(HMAC-SHA) とともに AH_SHA
をサポートしなければならない (MUST)。この体系は、[HMACSHA] で記述さ
れる HMAC-SHA-1-96 変換として定義される。
Use of AH_SHA with any other Authentication Algorithm attribute value
is currently undefined.
何らかの他の Authentication Algorithm 属性値との AH_SHA の使用は、現
在定義されていない。
4.4.3.3 AH_DES
4.4.3.3 AH_DES 識別子
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 は、DES-MAC 変換である Auth(DES-MAC) 属性とともに AH_DES
を定義する。実装(s) は、この mode のサポートを要求されない。
Use of AH_DES with any other Authentication Algorithm attribute value
is currently undefined.
何らかの他の Authentication Algorithm 属性値との AH_DES の使用は、現
在定義されていない。
4.4.4 IPSEC ESP Transform Identifiers
4.4.4 IPSEC ESP 変換識別子
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.
Encapsulating Security Payload (ESP: 暗号ペイロード) は、データ機密
性を提供するために使用される、1 つの必須変換 (?) と多くのオプション
な変換(s) を定義する。次の表は、IPSEC DOI の ISAKMP Proposal Payload
のため定義された ESP Transform Identifiers をリストする。
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).
注意: 認証、完全性保護と replay 検出が必要とされる時、Authentication
Algorithm 属性は、適切な ESP 保護特性を識別するために指定されなけれ
ばならない (MUST)。たとえば、3DES との HMAC-MD5 認証を要請するため、
3DES(?) は、HMAC-MD5 にセットされた Authentication Algorithm 属性と
の ESP_3DES を指定する。追加の処理要求(s) について、Section 4.5
(Authentication Algorithm) を参照しなさい。
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.
注意: すべての実装必須なアルゴリズム(s) は、次の sections で、実装し
なければならない "MUST" (たとえば ESP_DES) としてリストされる。すべ
ての他のアルゴリズム(s) はオプションであり、何らかの特定の実装で実装
されるかもしれない (MAY)。
4.4.4.1 ESP_DES_IV64
4.4.4.1 ESP_DES_IV64 識別子
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-bit IV を使用している RFC-1827 と RFC-1829
で定義される DES-CBC 変換を指定する。
4.4.4.2 ESP_DES
4.4.4.2 ESP_DES 識別子
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 範囲内のすべての実装(s) は、Auth(HMAC-MD5) 属性とともに
ESP_DES をサポートしなければならない (MUST)。この体系は、HMAC MD5
[HMACMD5] により提供される認証と完全性とで、[DES] 変換として定義され
る。
4.4.4.3 ESP_3DES
4.4.4.3 ESP_3DES 識別子
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 範囲内のすべての実装(s) は、Auth(HMAC-MD5) 属性とともに
ESP_3DES をサポートすることが強く奨励される。この体系は、HMAC MD5
[HMACMD5] により提供される認証と完全性とで、[ESPCBC] 変換として定義
される。
4.4.4.4 ESP_RC5
4.4.4.4 ESP_RC5 識別子
The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC].
ESP_RC5 タイプは、[ESPCBC] で定義されている RC5 変換を指定する。
4.4.4.5 ESP_IDEA
4.4.4.5 ESP_IDEA 識別子
The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC].
ESP_IDEA タイプは、[ESPCBC] で定義されている IDEA 変換を指定する。
4.4.4.6 ESP_CAST
4.4.4.6 ESP_CAST 識別子
The ESP_CAST type specifies the CAST transform defined in [ESPCBC].
ESP_CAST タイプは、[ESPCBC] で定義されている CAST 変換を指定する。
4.4.4.7 ESP_BLOWFISH
4.4.4.7 ESP_BLOWFISH 識別子
The ESP_BLOWFISH type specifies the BLOWFISH transform defined in
[ESPCBC].
ESP_BLOWFISH タイプは、[ESPCBC] で定義されている BLOWFISH 変換を指定
する。
4.4.4.8 ESP_3IDEA
4.4.4.8 ESP_3IDEA 識別子
The ESP_3IDEA type is reserved for triple-IDEA.
ESP_3IDEA タイプは、triple-IDEA のために予約されている。
4.4.4.9 ESP_DES_IV32
4.4.4.9 ESP_DES_IV32 識別子
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-bit IV を使用している RFC-1827 と RFC-1829
で定義される DES-CBC 変換を指定する。
4.4.4.10 ESP_RC4
4.4.4.10 ESP_RC4 識別子
The ESP_RC4 type is reserved for RC4.
ESP_RC4 タイプは、RC4 のために予約されている。
4.4.4.11 ESP_NULL
4.4.4.11 ESP_NULL 識別子
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 が認証、完全性保護と replay 検出のみを要求する
tunnel パケット(s) に使用される存在である時、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 範囲内のすべての実装(s) は、ESP_NULL をサポートしなければ
ならない (MUST)。ESP NULL 変換は、[ESPNULL] で定義される。ESP_NULL
使用に関連する追加の要求(s) について、Section 4.5 の Authentication
Algorithm 属性記述を参照しなさい。
4.4.5 IPSEC IPCOMP Transform Identifiers
4.4.5 IPSEC IPCOMP 変換識別子
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 Compression (IPCOMP) 変換は、IP ペイロード圧縮 ([IPCOMP]) を与え
るため取り決められることができる、オプションな圧縮アルゴリズム(s) を
定義する。次の表は、IPSEC DOI 範囲内の ISAKMP Proposal Payload
のため定義された IPCOMP Transform Identifiers をリストする。
Transform ID Value
------------ -----
RESERVED 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2
IPCOMP_LZS 3
4.4.5.1 IPCOMP_OUI
4.4.5.1 IPCOMP_OUI 識別子
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 タイプは、
特定のベンダアルゴリズムをさらに進んで識別する属性により付随させなけ
ればならない。
4.4.5.2 IPCOMP_DEFLATE
4.4.5.2 IPCOMP_DEFLATE 識別子
The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate
algorithm as specified in [DEFLATE].
IPCOMP_DEFLATE タイプは、[DEFLATE] で明細に述べられるとして、"zlib"
deflate アルゴリズムの使用を指定する。
4.4.5.3 IPCOMP_LZS
4.4.5.3 IPCOMP_LZS 識別子
The IPCOMP_LZS type specifies the use of the Stac Electronics LZS
algorithm as specified in [LZS].
IPCOMP_LZS タイプは、[LZS] で明細に述べられるとして、Stac
Electronics LZS アルゴリズムの使用を指定する。
4.5 IPSEC Security Association Attributes
4.5 IPSEC セキュリティアソシエーション属性
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 属性定義(s) は、IKE negotiation の Phase II で使用される。属
性タイプ(s) は、Basic (B) か Variable-Length (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.
basic として記述される属性(s) は、variable として決してエンコードさ
れることができない (MUST NOT)。もしそれらの値が 2 octets にはめ込む
ことができるなら、variable length 属性(s) は、basic 属性(s) としてエ
ンコードされるかもしれない (MAY)。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 有効期間タイプ
SA Duration
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:
全体のセキュリティアソシエーションについて、time-to-live (生
存時間) を指定しなさい。SA の期限が切れる時、そのアソシエー
ションの下で取り決められたすべての鍵(s) は、再び取り決められ
なければならない。life タイプ値(s) は (次の通りである):
RESERVED 0
seconds 1
kilobytes 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 は、プ
ライベート使用のためである。与えられる Life Type について、
Life Duration 属性値は、構成している lifetime (生存時間) の
実時間長 -- 保護されることができる秒数か Kbytes 数どちらかを
定義する。
If unspecified, the default value shall be assumed to be
28800 seconds (8 hours).
もし指定されないなら、デフォルト値は 28000 秒 (8 時間) であ
ると想定されるべきである。
An SA Life Duration attribute MUST always follow an SA Life
Type which describes the units of duration.
SA Life Duration 属性は、持続時間単位を記述する SA Life Type
の次にいつも来なければならない (MUST)。
See Section 4.5.4 for additional information relating to
lifetime notification.
lifetime 通知に関連する追加の情報について、Section 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 negotiation で使用されるための Oakley Group を指定し
なさい。サポートされる値(s) のリストについて、[IKE] の
Appendix A を参照しなさい。
Encapsulation Mode
カプセル化モード
RESERVED 0
Tunnel 1
Transport 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).
もし指定されないなら、デフォルト値は、unspecifed (指定されな
い) (ホスト依存) であると想定されるべきである。
Authentication Algorithm
認証アルゴリズム
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 変換を正確に識別することを明細に述べら
れなければならないので、Auth Algorithm のためのデフォルト値
は、ない。(ただし) 次のケースを除いてである。
When negotiating ESP without authentication, the Auth
Algorithm attribute MUST NOT be included in the proposal.
認証なしに ESP を取り決める時、Auth Algorithm 属性は、提案に
決して含まれてはならない (MUST NOT)。
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 を取り決める時、Auth Algorithm 属性は、提案
に含まれなければならない (MUST)。そして ESP 変換 ID は、
ESP_NULL でなければならない。
Key Length
鍵長
RESERVED 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.
鍵長は可変鍵長(s) の暗号(s) を使用する変換のために明細に述べ
られなければならないので、Key Length のためのデフォルト値は
ない。固定長暗号(s) について、Key Length 属性は、決して送信
されてはならない (MUST NOT)。
Key Rounds
鍵ラウンド(s)
RESERVED 0
There is no default value for Key Rounds, as it must be
specified for transforms using ciphers with varying numbers
of rounds.
変化するラウンド(s) 数の暗号を使用する変換のために明細に述べ
られなければならないので、Key Rounds のためのデフォルト値は
ない。
Compression Dictionary Size
圧縮辞書サイズ
RESERVED 0
Specifies the log2 maximum size of the dictionary.
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.
プライベートベンダ圧縮アルゴリズムを指定しなさい。最初の
three (3) octets は、IEEE で割り当てられた company_id (OUI)
でなければならない。次の octet は、ベンダ特定の圧縮 subtype
であろう。これは、zero か、ベンダデータの多くの octets によ
り次に続く。
4.5.1 Required Attribute Support
4.5.1 要求される属性サポート
To ensure basic interoperability, all implementations MUST be
prepared to negotiate all of the following attributes.
基本的な相互互換性を保証するために、すべての実装(s) は、次に述べる属
性(s) すべてを取り決めるため用意されなければならない (MUST)。
SA Life Type
SA Duration
Auth Algorithm
4.5.2 Attribute Parsing Requirement (Lifetime)
4.5.2 属性解析に関する要求 (生存時間)
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.
柔軟な semantics を考慮に入れるため、IPSEC DOI は次に述べることを要
求する。それは、適合している ISAKMP 実装は、属性リストを正しく構文解
析しなければならない (MUST) ことである。そして、異なる属性 entries
が他の属性 entries と矛盾しなければ、その属性リストは、同じ属性クラ
スの複数インスタンスを含む。現在、この処理を要求する唯一の属性(s) は
Life Type と Duration である。
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.)
これがなぜ重要であるかを見るために、次の例は、100MB か 24 時間どちら
かの SA Lifetime を指定する、4 つの entry 属性リストの binary
encoding を示す。(属性 encoding 形式の完全な記述について、[ISAKMP]
の Section 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.
もし矛盾する属性(s) が検出されるなら、ATTRIBUTES-NOT-SUPPORTED
Notification Payload が返されるべきである (SHOULD)。そして、セキュリ
ティアソシエーションセットアップは、中止されなければならない
(MUST)。
4.5.3 Attribute Negotiation
4.5.3 属性取り決め
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 が送信されるべきである
(SHOULD)。そして属性値が予約される範囲内でない限り、セキュリティアソ
シエーションセットアップは中止されなければならない (MUST)。
If an implementation receives an attribute value in the reserved
range, an implementation MAY chose to continue based on local policy.
もし実装が予約される範囲内の属性値を受信するなら、実装は、引き続き
local ポリシーに基づくことに決めるかもしれない (MAY)。
4.5.4 Lifetime Notification
4.5.4 生存時間通知
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.
responder が local ポリシーに基づいて望むのより大きい SA lifetime を
initiator が提供する時、受信側は次に述べる 3 つの選択がある:
1) negotiation を完全に落とす; 2) negotiation を完成させる。しかし提
供されたのより小さい lifetime を使用してである; 3) negotiation を完
成させる。そして responder の実際の lifetime を指し示して、initiator
へと助言通知を送信する。responder が実際におこなうことの選択は、実装
特有 and/or local ポリシーに基づかれる。
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.
後者のケースで相互互換性を保証するため、responder が initiator に通
知したいと思う時のみ、IPSEC DOI は次に述べることを要求する: もし
responder が受信に同意するよりも大きい SA lifetime を initiator が提
供するなら、responder は、次に述べる ISAKMP Notification Payload を
含むべきである (SHOULD)。それは、responder の IPSEC SA ペイロードを
含む交換でのペイロードである。Section 4.6.3.1 は、この目的のために使
用されなければならない (MUST) RESPONDER-LIFETIME Notification
Message タイプのペイロード配置を定義する。
4.6 IPSEC Payload Content
4.6 IPSEC ペイロード内容
The following sections describe those ISAKMP payloads whose data
representations are dependent on the applicable DOI.
次の sections は、ISAKMP ペイロード(s) を記述する。このペイロードの
データ表現(s) は、適用できる DOI に依存する。
4.6.1 Security Association Payload
4.6.1 セキュリティアソシエーションペイロード
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 のための Security Association Payload の内容を説
明する。Situation bitmap の記述について Section 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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 次ペイロード ! 予約 ! ペイロード長 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 解釈のドメイン (IPSEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 状態 (bitmap) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ラベルされたドメイン識別子 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 秘密長 (octets で) ! 予約 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 秘密ラベル ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 秘密分類長 (bits で) ! 予約 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 秘密分類 bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 完全性長 (octets で) ! 予約 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 完全性レベル ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 完全性分類長 (bits で) ! 予約 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 完全性分類 bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
図 1: セキュリティアソシエーションペイロード形式
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).
次ペイロード (1 octet) - メッセージ上の次ペイロードのペイロード
タイプのための識別子。もし今のペイロードがメッセージで最後なら
このフィールドは、zero (0) である。
o RESERVED (1 octet) - Unused, must be zero (0).
予約 (1 octet) - 使用されない。zero (0) でなければならない。
o Payload Length (2 octets) - Length, in octets, of the current
payload, including the generic header.
ペイロード長 (2 octets) - 一般的なヘッダを含んで、今のペイロー
ドの octets での長さ。
o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI,
which has been assigned the value one (1).
解釈のドメイン (4 octets) - IPSEC DOI を指定する。そしてそれは
値 one (1) に割り当てられる。
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.
状態 (4 octets) - Security Association Payload の残りを解釈する
ために使用される bitmask。値(s) の完全なリストについて、Section
4.2 を参照しなさい。
o Labeled Domain Identifier (4 octets) - IANA Assigned Number used
to interpret the Secrecy and Integrity information.
ラベルされたドメイン識別子 (4 octets) - Secrecy と Integrity 情
報を解釈するために使用される IANA Assigned Number。
o Secrecy Length (2 octets) - Specifies the length, in octets, of
the secrecy level identifier, excluding pad bits.
秘密長 (2 octets) - pad bits を除外して、secrecy level 識別子の
octets での長さを指定する。
o RESERVED (2 octets) - Unused, must be zero (0).
予約 (2 octets) - 使用されない。zero (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.
秘密レベル (可変長) - 要求される必須 secrecy level を指定する。
secrecy level は、次の 32-bit 境界に配置するように zero (0) で
pad されなければならない (MUST)。
o Secrecy Category Length (2 octets) - Specifies the length, in
bits, of the secrecy category (compartment) bitmap, excluding
pad bits.
秘密分類長 (2 octets) - pad bits を除いて、secrecy category
(仕切り) bitmap の bits での長さを指定する。
o RESERVED (2 octets) - Unused, must be zero (0).
予約 (2 octets) - 使用されない。zero (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.
秘密分類 bitmap (可変長) - 必要とされる secrecy categories (仕
切り) を示すために使用される bitmap。bitmap は、次の 32-bit 境
界で配置するよう zero (0) で pad されなければならない (MUST)。
o Integrity Length (2 octets) - Specifies the length, in octets,
of the integrity level identifier, excluding pad bits.
完全性長 (2 octets) - pad bits を除いて、integrity level 識別子
の octets での長さを指定する。
o RESERVED (2 octets) - Unused, must be zero (0).
予約 (2 octets) - 使用されない。zero (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.
完全性レベル (可変長) - 要求される必須 integrity level を指定す
る。integrity level は、次の 32-bit 境界で配置するように zero
(0) で pad されなければならない (MUST)。
o Integrity Category Length (2 octets) - Specifies the length, in
bits, of the integrity category (compartment) bitmap, excluding
pad bits.
完全性分類長 (2 octets) - pad bits を除いて、integrity category
(compartment) bitmap の bits での長さを指定する。
o RESERVED (2 octets) - Unused, must be zero (0).
予約 (2 octets) - 使用されない。zero (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.
完全性分類 bitmap (可変長) - 要求される integrity categories
(compartments) を示すために使用される bitmap。bitmap は、次の
32-bit 境界で配置するように zero (0) で pad されなければならな
い (MUST)。
4.6.1.1 IPSEC Labeled Domain Identifiers
4.6.1.1 IPSEC ラベルされたドメイン識別子
The following table lists the assigned values for the Labeled Domain
Identifier field contained in the Situation field of the Security
Association Payload.
次の表は、Security Association Payload の Situation フィールドに含ま
れる、Labeled Domain Identifier フィールドのための割り当てられた値を
リストする。
Domain Value
------- -----
RESERVED 0
4.6.2 Identification Payload Content
4.6.2 身元ペイロード内容
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.
Identification Payload は、Security Association の initiator を識別
するために使用される。initiator の身元は、そのアソシエーションのため
正しい host system セキュリティポリシー要求を決定するために
responder により使用されるべきである (SHOULD)。たとえば、host は、IP
アドレス(s) の確実なセットから機密性なしに認証と完全性 (AH) と、IP
アドレス(s) の他の範囲から機密性 (ESP) のある完全な認証を要求するこ
とに決めるかもしれない。Identification Payload は、この決定をおこな
うため、responder により使用されることができる情報を提供する。
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.
Phase I negotiations の間、ID port と protocol フィールドは、zero か
UDP port 500 にセットされなければならない (MUST)。もし実装がどんな他
の値(s) でも受信するなら、これはエラーとして扱われなければならない
(MUST)。そしてセキュリティアソシエーションセットアップは、中止されな
ければならない (MUST)。このイベントは、監査可能であるべきである
(SHOULD)。
The following diagram illustrates the content of the Identification
Payload.
次の図は、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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 次ペイロード ! 予約 ! ペイロード長 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID タイプ ! プロトコル ID ! ポート !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 身元データ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
図 2: 身元ペイロード形式
The Identification Payload fields are defined as follows:
Identification 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).
次ペイロード (1 octet) - メッセージ内の次ペイロードのペイロード
タイプのための識別子。もし今のペイロードがメッセージで最後であ
るなら、このフィールドは zero (0) である。
o RESERVED (1 octet) - Unused, must be zero (0).
予約 (1 octet) - 使用されない。zero (0) でなければならない。
o Payload Length (2 octets) - Length, in octets, of the
identification data, including the generic header.
ペイロード長 (2 octets) - 一般的なヘッダを含む、身元データの
octets での長さ。
o Identification Type (1 octet) - Value describing the identity
information found in the Identification Data field.
身元タイプ (1 octet) - Identification Data フィールドで見いださ
れる身元情報を記述している値。
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.
プロトコル ID (1 octet) - 関連された IP protocol ID (たとえば、
UDP/TCP) を指定している値。値 zero は、Protocol ID フィールドが
無視されるべきであることを意味する。
o Port (2 octets) - Value specifying an associated port. A value
of zero means that the Port field should be ignored.
ポート (2 octets) - 関連された port を指定している値。値 zero
は、Port フィールドが無視されるべきであることを意味する。
o Identification Data (variable length) - Value, as indicated by
the Identification Type.
身元データ (可変長) - Identification Type により指し示されると
しての値。
4.6.2.1 Identification Type Values
4.6.2.1 身元タイプ値
The following table lists the assigned values for the Identification
Type field found in the Identification Payload.
次の表は、Identification Payload で見いだされる Identification Type
フィールドのための割り当てられた値(s) をリストする。
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 実体が可変長であるタイプ(s) について、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 交換が (何らかの形式の) 証明書(s) を使用して認証される時、local
policy 決定(s) への入力のために使用されるどんな ID も、交換の認証で
使用される証明書に含まれるべきである (SHOULD)。
4.6.2.2 ID_IPV4_ADDR
4.6.2.2 ID_IPV4_ADDR 識別子
The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
ID_IPV4_ADDR タイプは、単一 four (4) octet IPv4 アドレスを指定する。
4.6.2.3 ID_FQDN
4.6.2.3 ID_FQDN 識別子
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 タイプは、fully-qualified domain name 文字列を指定する。
ID_FQDN の例は、"foo.bar.com" である。この文字列は、どんな終端(s)
(文字) も含むべきでない。
4.6.2.4 ID_USER_FQDN
4.6.2.4 ID_USER_FQDN 識別子
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 タイプは、fully-qualified ユーザ名文字列を指定する。
ID_USER_FQDN の例は、"piper@foo.bar.com" である。この文字列は、どん
な終端(s) (文字) も含むべきでない。
4.6.2.5 ID_IPV4_ADDR_SUBNET
4.6.2.5 ID_IPV4_ADDR_SUBNET 識別子
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 つの four (4) octet 値(s) で表現され
た IPv4 アドレス(s) の範囲を指定する。最初の値は、IPv4 アドレスであ
る。2 番目は、IPv4 network mask である。network mask の ones (1s) は
アドレスの一致する bit が固定化されるが、その一方で zeros (0s) は
"wildcard" bit を指し示すことに注意しなさい。
4.6.2.6 ID_IPV6_ADDR
4.6.2.6 ID_IPV6_ADDR 識別子
The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6
address.
ID_IPV6_ADDR タイプは、単一 sixteen (16) octet IPv6 アドレスを指定す
る。
4.6.2.7 ID_IPV6_ADDR_SUBNET
4.6.2.7 ID_IPV6_ADDR_SUBNET 識別子
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 つの sixteen (16) octet 値(s) で表現
された IPv6 アドレス(s) の範囲を指定する。最初の値は、IPv6 アドレス
である。2 番目は、IPv6 network mask である。network mask の ones
(1s) は、アドレスの一致する bit が固定化されるが、その一方で zeros
(0s) は "wildcard" bit を指し示すことに注意しなさい。
4.6.2.8 ID_IPV4_ADDR_RANGE
4.6.2.8 ID_IPV4_ADDR_RANGE 識別子
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 つの four (4) octet 値(s) で表現され
た IPv4 アドレス(s) の範囲を指定する。最初の値は、始まりの IPv4 アド
レス (その値も含む) である。そして 2 番目の値は、終わりの IPv4 アド
レス (その値も含む) である。2 つの指定されたアドレス(s) 間に落ちる
(?) すべてのアドレス(s) は、リスト範囲内であるようにみなされる。
4.6.2.9 ID_IPV6_ADDR_RANGE
4.6.2.9 ID_IPV6_ADDR_RANGE 識別子
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 つの sixteen (6) octet 値(s) で表現さ
れた IPv6 アドレス(s) の範囲を指定する。最初の値は、始まりの IPv6 ア
ドレス (その値も含む) である。そして 2 番目の値は、終わりの IPv6 ア
ドレス (その値も含む) である。2 つの指定されたアドレス(s) 間に落ちる
(?) すべてのアドレス(s) は、リスト範囲内であるようにみなされる。
4.6.2.10 ID_DER_ASN1_DN
4.6.2.10 ID_DER_ASN1_DN 識別子
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 タイプは、本人の ASN.1 X.500 Distributed Name [X.501]
の binary DER encoding を指定する。この本人の証明書(s) は、SA を確立
するために交換されている。
4.6.2.11 ID_DER_ASN1_GN
4.6.2.11 ID_DER_ASN1_GN 識別子
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 タイプは、本人の ASN.1 X.500 GeneralName [X.509] の
binary DER encoding を指定する。この本人の証明書(s) は、SA を確立す
るために交換されている。
4.6.2.12 ID_KEY_ID
4.6.2.12 ID_KEY_ID 識別子
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 タイプは、ベンダ特定の情報を渡すために使用されるかもしれな
いあいまいな byte stream を指定する。この情報は、どの pre-shared key
が Aggressive mode negotiations を認証するために使用されるかを識別す
るために必要とされる。
4.6.3 IPSEC Notify Message Types
4.6.3 IPSEC 通知メッセージタイプ(s)
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 は、Notify Message codes の 2 つの blocks を定義する。 1 つは
エラー(s) のため、1 つは状態メッセージ(s) のためである。ISAKMP は、
DOI 範囲内でのプライベート使用のため、それぞれの block の一部も割り
当てる。IPSEC DOI は、その自分自身の使用のため、次のプライベートメッ
セージタイプ(s) を定義する。
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.
Notification Status Messages は、ISAKMP SA の保護の下で送信されなけ
ればならない (MUST): 最後の Main Mode 交換のペイロードとしてか; Main
Mode か Aggressive Mode 処理が完了した後で別々の Informational
Exchange で; もしくはどんな Quick Mode 交換でのペイロードとして。こ
れらのメッセージ(s) は、Aggressive Mode 交換で決して送信されてはなら
ない (MUST NOT)。それは Aggressive Mode は、Notify Status Message を
その交換へと結びつける必要な保護を提供しないからである。
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.
注意: Notify ペイロードは、Quick Mode でのみ完全に保護される。これは
全体のペイロードが HASH(n) digest で含まれるような場合にである。Main
Mode で、notify ペイロードが暗号化される間、現在のところ、HASH(n)
digests は含まれない。結果として、Main Mode ciphertext での active
な substitution (置換) attack は、notify status message タイプに、
corrupt (汚す) させる。(これは、どんな Main Mode 交換での最後のメッ
セージについて、一般的に正しい。) 危険は小さいけれども、汚れた
notify メッセージは、receiver に、全体の negotiation を中止させるか
もしれない。これは、送信側が fatal (致命的な) error に直面したと考
えてである。
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 Infomational Exchange で送信された時、ISAKMP プ
ロトコルは、Notification Status メッセージ(s) 配送を保証しない。何ら
かの特定のメッセージ受信を保証するために、送信側は、定義された Main
Mode か Quick Mode 交換で Notification Payload を含むべきである
(SHOULD)。そして、この交換は再転送タイマにより保護される。
4.6.3.1 RESPONDER-LIFETIME
4.6.3.1 RESPONDER-LIFETIME 識別子
The RESPONDER-LIFETIME status message may be used to communicate the
IPSEC SA lifetime chosen by the responder.
RESPONDER-LIFETIME 状態メッセージは、responder により選ばれた IPSEC
SA lifetime を通信するために使用されるかもしれない。
When present, the Notification Payload MUST have the following
format:
これがある時、Notification Payload は、次の形式を持たなければならな
い (MUST):
o Payload Length - set to length of payload + size of data (var)
ペイロード長 - ペイロード長 + データサイズ (可変長) に設定
o DOI - set to IPSEC DOI (1)
DOI - IPSEC DOI (1) に設定
o Protocol ID - set to selected Protocol ID from chosen SA
プロトコル ID - 選ばれた SA から選ばれたプロトコル ID に設定
o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP
cookies) or four (4) (one IPSEC SPI)
SPI サイズ - sixteen (16) (2 つの 8 octet ISAKMP cookies) か
four (4) (1 つの IPSEC SPI) どちらかに設定
o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3)
通知メッセージタイプ - RESPONDER-LIFETIME (Section 4.6.3) に設
定
o SPI - set to the two ISAKMP cookies or to the sender's inbound
IPSEC SPI
SPI - 2 つの ISAKMP cookies か送信側の内向けの IPSEC SPI に設定
o Notification Data - contains an ISAKMP attribute list with the
responder's actual SA lifetime(s)
通知データ - responder の実際の SA lifetime(s) がある 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.
実装上の注意: Notification Data フィールドが属性リストを含むと言うこ
とは、Notification Data フィールドは長さ 0 で Notification Payload
が関連される属性リストを持つと言うことに等しい (?)。
4.6.3.2 REPLAY-STATUS
4.6.3.2 REPLAY-STATUS 識別子
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 status message は、responder の選択の明確な確認のため
に使用されるかもしれない。その選択とは、responder が anti-replay 検
出をおこなうかどうかである。
When present, the Notification Payload MUST have the following
format:
これがある時、Notification Payload は、次の形式を持たなければならな
い (MUST):
o Payload Length - set to length of payload + size of data (4)
ペイロード長 - ペイロード長 + データサイズ (4) に設定
o DOI - set to IPSEC DOI (1)
DOI - IPSEC DOI (1) に設定
o Protocol ID - set to selected Protocol ID from chosen SA
プロトコル ID - 選ばれた SA から選ばれたプロトコル ID に設定
o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP
cookies) or four (4) (one IPSEC SPI)
SPI サイズ - sixteen (16) (2 つの 8 octet ISAKMP cookies) か
four (4) (1 つの IPSEC SPI) どちらかに設定
o Notify Message Type - set to REPLAY-STATUS
通知メッセージタイプ - REPLAY-STATUS に設定
o SPI - set to the two ISAKMP cookies or to the sender's inbound
IPSEC SPI
SPI - 2 つの ISAKMP cookies か送信側の内向けの IPSEC SPI に設定
o Notification Data - a 4 octet value:
0 = replay detection disabled
1 = replay detection enabled
通知データ - 4 octet 値:
0 = replay 検出未使用
1 = replay 検出使用
4.6.3.3 INITIAL-CONTACT
4.6.3.3 INITIAL-CONTACT 識別子
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 status message は、あるサイドが他のサイドへ、これが
remote system で確立されている最初の SA であると通知したい時、使用さ
れるかもしれない。この Notification Message の受信側は、それからどん
な存在している SA も削除するように決定するかもしれない。この SA は、
送信する system が reboot したか、もとの SA と関連された鍵材料へとも
はやアクセスしないかという想定の下で、送信する system が持つものであ
る。使用される時、Notification Data フィールドの内容は、null である
べきである (SHOULD) (すなわち、Payload Length は、Notification
Payload の固定された長さに設定されるべきである)。
When present, the Notification Payload MUST have the following
format:
これがある時、Notification Payload は、次の形式を持たなければならな
い (MUST):
o Payload Length - set to length of payload + size of data (0)
ペイロード長 - ペイロード長 + データサイズ (0) に設定
o DOI - set to IPSEC DOI (1)
DOI - IPSEC DOI (1) に設定
o Protocol ID - set to selected Protocol ID from chosen SA
プロトコル ID - 選ばれた SA から選ばれたプロトコル ID に設定
o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies)
SPI サイズ - sixteen (16) (2 つの 8 octet ISAKMP cookies) に設
定
o Notify Message Type - set to INITIAL-CONTACT
通知メッセージタイプ - INITIAL-CONTACT に設定
o SPI - set to the two ISAKMP cookies
SPI - 2 つの ISAKMP cookies に設定
o Notification Data -
通知データ - <含まれない>
4.7 IPSEC Key Exchange Requirements
4.7 IPSEC 鍵交換要求
The IPSEC DOI introduces no additional Key Exchange types.
IPSEC DOI は、追加の Key Exchange タイプ(s) を導入しない。
-----------------------------------------------------------------------
5. Security Considerations
5. セキュリティに関する考察
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.
この全体のメモは、Internet Key Exchange プロトコル ([IKE]) に関係す
る。このプロトコルは、秘密と認証された方法で暗号学鍵材料の派生を与え
るために、ISAKMP ([ISAKMP]) と Oakley ([Oakley]) を組み合わせる。こ
の文書で確かめられたさまざまなセキュリティプロトコル(s) と変換(s) の
特定の論議は、関連される基本文書(s) と暗号参考文献(s) で見つけれるこ
とができる。
-----------------------------------------------------------------------
6. IANA Considerations
6. 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. All values not
explicitly defined in previous sections are reserved to IANA.
この文書は、IANA により維持される多くの "magic" 番号(s) を含む。この
section は、これらリスト(s) のそれぞれに追加の番号(s) を割り当てるた
め、IANA により使用される基準を説明する。前の sections で明示的に定
義されないすべての値(s) は、IANA に予約される。
6.1 IPSEC Situation Definition
6.1 IPSEC 状態定義
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.
Situation Definition は、環境を表す 32-bit bitmask である。IPSEC SA
proposal と negotiation は、この環境の下で実行される。新しい
situations 割り当てのための要求は、関連される bit のための解釈を記述
する 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 が standards-track になければ (すなわち informational か
experimental RFC)、RFC が発行され変換識別子が割り当てられる前に、
IESG により明示的に批評され認可されるべきである。
The upper two bits are reserved for private use amongst cooperating
systems.
上の 2 つの bits は、協力している systems 間のプライベート使用のため
に予約されている。
6.2 IPSEC Security Protocol Identifiers
6.2 IPSEC セキュリティプロトコル識別子
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.
Security Protocol Identifier は、取り決めれているセキュリティプロト
コル体系を識別する 8-bit 値である。新しいセキュリティプロトコル割り
当てのための要求は、要求されるセキュリティプロトコルを記述する RFC
により付随されなければならない。[AH] と [ESP] がセキュリティプロトコ
ル文書(s) の例である。
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 が standards-track になければ (すなわち informational か
experimental RFC)、RFC が発行され変換識別子が割り当てられる前に、
IESG により明示的に批評され認可されるべきである。
The values 249-255 are reserved for private use amongst cooperating
systems.
値 249-255 は、協力している systems 間のプライベート使用のために予約
されている。
6.3 IPSEC ISAKMP Transform Identifiers
6.3 IPSEC ISAKMP 変換識別子
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 は、negotiation のために使用される
鍵交換プロトコルを識別する 8-bit 値である。新しい ISAKMP 変換識別子
割り当てのための要求は、要求される鍵交換プロトコルを記述する RFC に
より付随されなければならない。[IKE] は、1 つのそのような文書の例であ
る。
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 が standards-track になければ (すなわち informational か
experimental RFC)、RFC が発行され変換識別子が割り当てられる前に、
IESG により明示的に批評され認可されるべきである。
The values 249-255 are reserved for private use amongst cooperating
systems.
値 249-255 は、協力している systems 間のプライベート使用のために予約
されている。
6.4 IPSEC AH Transform Identifiers
6.4 IPSEC AH 変換識別子
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-bit 値である。新しい 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 が standard-track になければ (すなわち informational か
experimental RFC)、RFC が発行され変換識別子が割り当てられる前に、
IESG により明示的に批評され認可されるべきである。
The values 249-255 are reserved for private use amongst cooperating
systems.
値 249-255 は、協力している systems 間のプライベート使用のために予約
されている。
6.5 IPSEC ESP Transform Identifiers
6.5 IPSEC ESP 変換識別子
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-bit 値である。新しい 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 が standards-track になければ (すなわち informational か
experimental RFC)、RFC が発行され変換識別子が割り当てられる前に、
IESG により明示的に批評され認可されるべきである。
The values 249-255 are reserved for private use amongst cooperating
systems.
値 249-255 は、協力している systems 間のプライベート使用のために予約
されている。
6.6 IPSEC IPCOMP Transform Identifiers
6.6 IPSEC IPCOMP 変換識別子
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-level 圧
縮を提供するために使用される特定アルゴリズムを識別する 8-bit 値であ
る。新しい IPCOMP 変換識別子割り当てのための要求は、IPCOMP 枠組
([IPCOMP]) 範囲内でアルゴリズムをどのように使用するかを記述する RFC
により付随されなければならない。その上、要求されるアルゴリズムは、公
表されなければならなく、public domain でなければならない。
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 が standard-track になければ (すなわち informational か
experimental 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 が公表のため認可されるアルゴリズム(s) のために予約さ
れている。値 48-63 は、協力している systems 間のプライベート使用のた
めに予約されている。値 64-255 は、将来の拡張のために予約されている。
6.7 IPSEC Security Association Attributes
6.7 IPSEC セキュリティアソシエーション属性(s)
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 Security Association Attribute は、16-bit タイプとその関連され
る値からなる。IPSEC SA 属性(s) は、ISAKMP peers 間のいろいろな値を渡
すために使用される。新しい IPSEC SA 属性(s) 割り当てのための要求は、
属性 encoding (Basic/Variable-Length) とその正当な値を記述する
Internet Draft により付随されなければならない。この文書の Section
4.5 は、そのような記述の例を提供する。
The values 32001-32767 are reserved for private use amongst
cooperating systems.
値 32001-32767 は、協力している systems 間のプライベート使用のために
予約されている。
6.8 IPSEC Labeled Domain Identifiers
6.8 IPSEC ラベルされるドメイン識別子
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 Labeled Domain Identifier は、名前空間を識別する 32-bit 値であ
る。Secrecy と Integrity levels と categories 値は、その名前空間で存
在するように述べられる。新しい IPSEC Labeled Domain Identifiers 割り
当てのための要求は、要求あり次第認められるべきである。付随する文書は
要求されない。適切である時、Internet Drafts が奨励されるけれども。
The values 0x80000000-0xffffffff are reserved for private use amongst
cooperating systems.
値 0x80000000-0xffffffff は、協力している systems 間のプライベート使
用のために予約されている。
6.9 IPSEC Identification Type
6.9 IPSEC 身元タイプ
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 Identification Type は、可変長 Identification Payload 解釈のた
めの識別として使用される 8-bit 値である。新しい IPSEC Identification
Types 割り当てのための要求は、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 が standard-track になければ (すなわち informational か
experimental RFC)、RFC が発行され変換識別子が割り当てられる前に、
IESG により明示的に批評され認可されるべきである。
The values 249-255 are reserved for private use amongst cooperating
systems.
値 249-255 は、協力している systems 間のプライベート使用のために予約
されている。
6.10 IPSEC Notify Message Types
6.10 IPSEC 通知メッセージタイプ(s)
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 Notify Message Type は、それぞれの DOI の ISAKMP により予約さ
れる値(s) の範囲から得られる 16-bit 値である。error messages (8192-
16383) のための 1 つの範囲と status messages (24576-32767) のための
異なる範囲がある。新しい Notify Message Types 割り当てのための要求は
IPSEC 範囲内の identification タイプをどのように使用するかを記述する
Internet Draft により付随されなければならない。
The values 16001-16383 and the values 32001-32767 are reserved for
private use amongst cooperating systems.
値 16001-16383 と値 32001-32767 は、協力している systems 間のプライ
ベート使用のために予約されている。
-----------------------------------------------------------------------
7. Change Log
7. 変更ログ
7.1 Changes from V9
7.1 V9 からの変更
o add explicit reference to [IPCOMP], [DEFLATE], and [LZS]
[IPCOMP], [DEFLATE] と [LZS] への明示的な参考文献を追加
o allow RESPONDER-LIFETIME and REPLAY-STATUS to be directed
at an IPSEC SPI in addition to the ISAKMP "SPI"
RESPONDER-LIFETIME と REPLAY-STATUS を、ISAKMP "SPI" に加えて
IPSEC SPI で方向づけられるにさせる
o added padding exclusion to Secrecy and Integrity Length text
Secrecy と Integrity Length text への padding 除去を追加
o added forward reference to Section 4.5 in Section 4.4.4
Section 4.4.4 の Section 4.5 への前方参照を追加
o update document references
文書の参考文献を更新
7.2 Changes from V8
7.2 V8 からの変更
o update IPCOMP identifier range to better reflect IPCOMP draft
IPCOMP draft をより反映するため IPCOMP 識別子範囲を更新
o update IANA considerations per Jeff/Ted's suggested text
Jeff/Ted の提案された text による IANA considerations を更新
o eliminate references to DES-MAC ID ([DESMAC])
DES-MAC ID ([DESMAC]) への参照を削除
o correct bug in Notify section; ISAKMP Notify values are 16-bits
Notify section の bug を修正; ISAKMP Notify 値は 16-bits
7.3 Changes from V7
7.3 V7 からの変更
o corrected name of IPCOMP (IP Payload Compression)
IPCOMP (IP Payload Compression) の名前を修正
o corrected references to [ESPCBC]
[ESPCBC] への参照を修正
o added missing Secrecy Level and Integrity Level to Figure 1
Figure 1 への欠けた Secrecy Level と Integrity Level を追加
o removed ID references to PF_KEY and ARCFOUR
PF_KEY と ARCFOUR への ID 参照を削除
o updated Basic/Variable text to align with [IKE]
[IKE] で提携する Basic/Variable text を更新
o updated document references and add intro pointer to [ARCH]
文書参考文献を更新。[ARCH] への導入ポインタを追加
o updated Notification requirements; remove aggressive reference
Notification 要求を更新; 積極的な参照を削除
o added clarification about protection for Notify payloads
Notify ペイロードの保護に関する明瞭化を追加
o restored RESERVED to ESP transform ID namespace; moved ESP_NULL
ESP 変換 ID 名前空間に RESERVED を戻す; ESP_NULL を移動
o added requirement for ESP_NULL support and [ESPNULL] reference
ESP_NULL サポートとのための要求と [ESPNULL] 参照を追加
o added clarification on Auth Alg use with AH/ESP
AH/ESP との Auth Alg の明瞭化を追加
o added restriction against using conflicting AH/Auth combinations
矛盾している AH/Auth 組み合わせの使用に対し制限を追加
7.4 Changes from V6
7.4 V6 からの変更
The following changes were made relative to the IPSEC DOI V6:
次に述べる変更は、IPSEC DOI V6 と比較しておこなわれた:
o added IANA Considerations section
IANA Considerations section を追加
o moved most IANA numbers to IANA Considerations section
たいていの IANA 番号を IANA Considerations section に移動
o added prohibition on sending (V) encoding for (B) attributes
(B) 属性について (V) encoding を送信することの禁止を追加
o added prohibition on sending Key Length attribute for fixed
length ciphers (e.g. DES)
固定長暗号 (たとえば DES) について Key Length 属性を送信するこ
との禁止を追加
o replaced references to ISAKMP/Oakley with IKE
ISAKMP/Oakley への参照を IKE に置き換える
o renamed ESP_ARCFOUR to ESP_RC4
ESP_ARCFOUR を ESP_RC4 に名前変更
o updated Security Considerations section
Security Considerations section を更新
o updated document references
文書参考文献を更新
7.5 Changes from V5
7.5 V5 からの変更
The following changes were made relative to the IPSEC DOI V5:
次に述べる変更は、IPSEC DOI V5 と比較しておこなわれた:
o changed SPI size in Lifetime Notification text
Lifetime Notification text の SPI サイズを変更
o changed REPLAY-ENABLED to REPLAY-STATUS
REPLAY-ENABLED を REPLAY-STATUS に変更
o moved RESPONDER-LIFETIME payload definition from Section 4.5.4
to Section 4.6.3.1
Section 4.5.4 から Section 4.6.3.1 へと RESPONDER-LIFETIME ペイ
ロード定義を移動
o added explicit payload layout for 4.6.3.3
4.6.3.3 のための明示的なペイロード配置を追加
o added Implementation Note to Section 4.6.3 introduction
Section 4.6.3 の序論に Implementation Note を追加
o changed AH_SHA text to require SHA-1 in addition to MD5
MD5 に加えて SHA1 を要求するために AH_SHA text を変更
o updated document references
文章参考文献を更新
7.6 Changes from V4
7.6 V4 からの変更
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
AH 変換 ID から Authentication Algorithm 識別子へと互換ある AH
KPDK 認証方法を移動
o added REPLAY-ENABLED notification message type per Architecture
Architecture ごとに REPLAY-ENABLED 通知メッセージタイプを追加
o added INITIAL-CONTACT notification message type per list
リストごとに INITIAL-CONTACT 通知メッセージタイプを追加
o added text to ensure protection for Notify Status messages
Notify Status メッセージの保護を保証するための text を追加
o added Lifetime qualification to attribute parsing section
属性構文解析 section への Lifetime 制限を追加
o added clarification that Lifetime notification is optional
Lifetime 通知がオプションであることの明瞭化を追加
o removed private Group Description list (now points at [IKE])
プライベート Group Description リストを削除 (現在 [IKE] でポイ
ント)
o replaced Terminology with pointer to RFC-2119
Terminology を RFC-2119 へのポインタに置き換え
o updated HMAC MD5 and SHA-1 ID references
HMAC MD5 と SHA-1 ID 参照を更新
o updated Section 1 (Abstract)
Section 1 (Abstract) を更新
o updated Section 4.4 (IPSEC Assigned Numbers)
Section 4.4 (IPSEC Assigned Numbers) を更新
o added restriction for ID port/protocol values for Phase I
Phase I のための ID port/protocol 値の制限を追加
7.7 Changes from V3 to V4
7.7 V3 から V4 への変更
The following changes were made relative to the IPSEC DOI V3, that
was posted to the IPSEC mailing list prior to the Munich IETF:
次に述べる変更は、IPSEC DOI V3 と比較しておこなわれた。Munich IETF
より前に IPSEC mailing list へポストされた:
o added ESP transform identifiers for NULL and ARCFOUR
NULL と ARCFOUR のための ESP 変換識別子を追加
o renamed HMAC Algorithm to Auth Algorithm to accommodate
DES-MAC and optional authentication/integrity for ESP
HMAC Algorithm を Auth Algorithm に名前変更。DES-MAC と ESP の
ためのオプションな認証/完全性に適応させるため。
o added AH and ESP DES-MAC algorithm identifiers
AH と ESP DES-MAC アルゴリズム識別子を追加
o removed KEY_MANUAL and KEY_KDC identifier definitions
KEY_MANUAL と KEY_KDC 識別子定義を削除
o added lifetime duration MUST follow lifetype attribute to
SA Life Type and SA Life Duration attribute definition
lifetime 持続時間が SA Life Type と SA Life Duration 属性定義へ
の lifetype 属性に従わなければならない (MUST) ことの追加
o added lifetime notification and IPSEC DOI message type table
lifetime 通知と IPSEC DOI メッセージタイプ表を追加
o added optional authentication and confidentiality
restrictions to MAC Algorithm attribute definition
MAC Algorithm 属性定義へのオプションな認証と機密性制限を追加
o corrected attribute parsing example (used obsolete attribute)
属性構文解析例を修正 (すたれた属性を使用して)
o corrected several Internet Draft document references
いくつかの Internet Draft 文書参照を修正
o added ID_KEY_ID per ipsec list discussion (18-Mar-97)
ipsec リスト論議ごとに ID_KEY_ID を追加 (18-Mar-97)
o removed Group Description default for PFS QM ([IKE] MUST)
PFS QM のための Group Description デフォルトを削除 ([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.
この文書は、Douglas Maughan, Mark Schertler, Mark Schneider, Jeff
Turner, Dan Harkins と Dave Carrel による前の研究から、ある程度得ら
れた。Matt Thomas, Roy Pereira, Greg Carter と Ran Atkinson は、提案
と、多くのケースで text も提案した。
-----------------------------------------------------------------------
References
参考文献
[AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[ARCH] Kent, S., and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[DEFLATE] Pereira, R., "IP Payload Compression Using DEFLATE", RFC
2394, August 1998.
[ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[ESPCBC] Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[ESPNULL] Glenn, R., and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998.
[DES] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[HMACMD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP
and AH", RFC 2403, November 1998.
[HMACSHA] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[IKE] Harkins, D., and D. Carrel, D., "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IPCOMP] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 2393, August
1998.
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[LZS] Friend, R., and R. Monsour, "IP Payload Compression Using
LZS", RFC 2395, August 1998.
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[X.501] ISO/IEC 9594-2, "Information Technology - Open Systems
Interconnection - The Directory: Models", CCITT/ITU
Recommendation X.501, 1993.
[X.509] ISO/IEC 9594-8, "Information Technology - Open Systems
Interconnection - The Directory: Authentication
Framework", CCITT/ITU Recommendation X.509, 1993.
-----------------------------------------------------------------------
Author's Address
著者のアドレス
Derrell Piper
Network Alchemy
1521.5 Pacific Ave
Santa Cruz, California, 95060
United States of America
Phone: +1 408 460-3822
EMail: ddp@network-alchemy.com
-----------------------------------------------------------------------
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (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.
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.
一覧
スポンサーリンク
