RFC1825 日本語訳
1825 Security Architecture for the Internet Protocol. R. Atkinson. August 1995. (Format: TXT=56772 bytes) (Obsoleted by RFC2401) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Atkinson Request for Comments: 1825 Naval Research Laboratory Category: Standards Track August 1995
コメントを求めるワーキンググループR.アトキンソン要求をネットワークでつないでください: 1825年の海軍研究試験所カテゴリ: 標準化過程1995年8月
Security Architecture for the Internet Protocol
インターネットプロトコルのためのセキュリティー体系
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
1. INTRODUCTION
1. 序論
This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. Each security mechanism is specified in a separate document. This document also describes key management requirements for systems implementing those security mechanisms. This document is not an overall Security Architecture for the Internet and is instead focused on IP-layer security.
このメモはIPバージョン4(IPv4)、IPバージョン6(IPv6)、およびそれらが提供するサービスのためにセキュリティー対策について説明します。 各セキュリティー対策は別々のドキュメントで指定されます。 また、このドキュメントはそれらのセキュリティー対策を実装するシステムのためのかぎ管理要件について説明します。このドキュメントは、インターネットへの総合的なSecurity Architectureでなく、代わりにIP-層のセキュリティに焦点を合わせられます。
1.1 Technical Definitions
1.1 技術的な定義
This section provides a few basic definitions that are applicable to this document. Other documents provide more definitions and background information [VK83, HA94].
このセクションはいくつかのこのドキュメントに適切な基本的な定義を提供します。 他のドキュメントは、より多くの定義と基礎的な情報[VK83、HA94]を提供します。
Authentication
The property of knowing that the data received is the same as
the data that was sent and that the claimed sender is in fact
the actual sender.
認証、受け取られたデータが送られたデータと同じであり、事実上、要求された送付者が実際の送付者であることを知る特性。
Integrity
The property of ensuring that data is transmitted from source
to destination without undetected alteration.
そのデータを確実にする特性が伝えられる保全は非検出されるのなしで目的地に変更の出典を明示します。
Confidentiality
The property of communicating such that the intended
recipients know what was being sent but unintended
parties cannot determine what was sent.
意図している受取人が何を知っているかようなものを伝える資産が送られた秘密性にもかかわらず、故意でないパーティーは、何が送られたかを決心できません。
Encryption
A mechanism commonly used to provide confidentiality.
暗号化Aメカニズムは一般的に以前はよく秘密性を提供していました。
Atkinson Standards Track [Page 1] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[1ページ]。
Non-repudiation
The property of a receiver being able to prove that the sender
of some data did in fact send the data even though the sender
might later desire to deny ever having sent that data.
今までに有がそのデータを送ったことを否定する送付者ですが、事実上、いくつかのデータの送付者がデータを送ったと立証できる受信機の特性が、後で望むかもしれない非拒否。
SPI
Acronym for "Security Parameters Index". An unstructured
opaque index which is used in conjunction with the
Destination Address to identify a particular Security
Association.
「セキュリティパラメタは索引をつける」SPI頭文字語。 特定のSecurity Associationを特定するのにDestination Addressに関連して使用される不統一な不明瞭なインデックス。
Security Association
The set of security information relating to a given network
connection or set of connections. This is described in
detail below.
セキュリティAssociation、セキュリティ情報のセットは、接続に与えられたネットワーク接続に関係づけたか、またはセットしました。 これは以下で詳細に説明されます。
Traffic Analysis
The analysis of network traffic flow for the purpose of
deducing information that is useful to an adversary.
Examples of such information are frequency of transmission,
the identities of the conversing parties, sizes of packets,
Flow Identifiers used, etc. [Sch94].
ネットワークトラフィックの分析が目的のために敵の役に立つ情報を推論しながら流れるトラフィックAnalysis。 そのような情報に関する例はトランスミッションの頻度、話しパーティーのアイデンティティ、パケットのサイズ、使用されるFlow Identifiersですなど。 [Sch94。]
1.2 Requirements Terminology
1.2 要件用語
In this document, the words that are used to define the significance of each particular requirement are usually capitalised. These words are:
本書では、通常、それぞれの特定の要件の意味を定義するのに使用される単語は資本化されます。 これらの単語は以下の通りです。
- MUST
- 必須
This word or the adjective "REQUIRED" means that the item is an
absolute requirement of the specification.
「必要である」というこの単語か形容詞が、項目が仕様に関する絶対条件であることを意味します。
- SHOULD
- should
This word or the adjective "RECOMMENDED" means that there might
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case
carefully weighed before taking a different course.
この単語か形容詞がこの項目を無視する特定の事情の正当な理由を存在するかもしれない手段に「推薦しました」が、完全な含意は、理解されていて異なったコースを取る前に慎重に熟慮されたケースであるべきです。
- MAY
- 5月
This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor might choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit the
same item.
「任意である」というこの単語か形容詞が、本当に、この項目が任意であることを意味します。 特定の市場がそれを必要とするか、または例えば製品を高めるので、1つのベンダーが、項目を含んでいるのを選ぶかもしれません。 別のベンダーは同じ項目を省略するかもしれません。
Atkinson Standards Track [Page 2] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[2ページ]。
1.3 Typical Use
1.3 典型的な使用
There are two specific headers that are used to provide security services in IPv4 and IPv6. These headers are the "IP Authentication Header (AH)" [Atk95a] and the "IP Encapsulating Security Payload (ESP)" [Atk95b] header. There are a number of ways in which these IP security mechanisms might be used. This section describes some of the more likely uses. These descriptions are not complete or exhaustive. Other uses can also be envisioned.
IPv4とIPv6にセキュリティー・サービスを供給するのに使用される2個の特定のヘッダーがあります。 これらのヘッダーは「IP認証ヘッダー(ああ)」[Atk95a]と「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」[Atk95b]ヘッダーです。 これらのIPセキュリティー対策が使用されるかもしれない多くの方法があります。 このセクションは、よりありそうな用途のいくつかについて説明します。 これらの記述は、完全でもなくて、また徹底的でもありません。 また、他の用途を思い描くことができます。
The IP Authentication Header is designed to provide integrity and authentication without confidentiality to IP datagrams. The lack of confidentiality ensures that implementations of the Authentication Header will be widely available on the Internet, even in locations where the export, import, or use of encryption to provide confidentiality is regulated. The Authentication Header supports security between two or more hosts implementing AH, between two or more gateways implementing AH, and between a host or gateway implementing AH and a set of hosts or gateways. A security gateway is a system which acts as the communications gateway between external untrusted systems and trusted hosts on their own subnetwork. It also provides security services for the trusted hosts when they communicate with the external untrusted systems. A trusted subnetwork contains hosts and routers that trust each other not to engage in active or passive attacks and trust that the underlying communications channel (e.g., an Ethernet) isn't being attacked.
IP Authentication Headerは、秘密性なしで保全と認証をIPデータグラムに供給するように設計されています。秘密性の不足は、Authentication Headerの実装がインターネットで広く利用可能になるのを確実にします、秘密性を提供する暗号化の輸出、輸入、または使用が規制される位置でさえ。 Authentication Headerは、AHを実装する2門以上の間と、そして、ホストかAHを実装するゲートウェイとホストかゲートウェイのセットの間でAHを実装しながら、2人以上のホストの間でセキュリティをサポートします。 セキュリティゲートウェイは外部の信頼されていないシステムと信じられたホストの間のコミュニケーションゲートウェイとしてそれら自身のサブネットワークに作動するシステムです。 また、彼らが外部の信頼されていないシステムとコミュニケートするとき、それは信じられたホストのためのセキュリティー・サービスを提供します。信じられたサブネットワークは互いが、アクティブであるか受け身の攻撃に従事して、基本的なコミュニケーションチャンネル(例えば、イーサネット)が攻撃されていないと信じないと信じるホストとルータを含んでいます。
In the case where a security gateway is providing services on behalf of one or more hosts on a trusted subnet, the security gateway is responsible for establishing the security association on behalf of its trusted host and for providing security services between the security gateway and the external system(s). In this case, only the gateway need implement AH, while all of the systems behind the gateway on the trusted subnet may take advantage of AH services between the gateway and external systems.
セキュリティゲートウェイが信じられたサブネットの1人以上のホストを代表してサービスを提供している場合では、セキュリティゲートウェイは信じられたホストを代表してセキュリティ協会を設立して、セキュリティゲートウェイと外的システムの間にセキュリティー・サービスを供給するのに原因となります。 この場合、ゲートウェイだけがAHを実装しなければなりません、信じられたサブネットのゲートウェイの後ろのシステムのすべてがゲートウェイと外的システムの間のAHサービスを利用するかもしれませんが。
A security gateway which receives a datagram containing a recognised sensitivity label, for example IPSO [Ken91], from a trusted host should take that label's value into consideration when creating/selecting an Security Association for use with AH between the gateway and the external destination. In such an environment, a gateway which receives a IP packet containing the IP Encapsulating Security Payload (ESP) should add appropriate authentication, including implicit (i.e., contained in the Security Association used) or explicit label information (e.g., IPSO), for the decrypted packet that it forwards to the trusted host that is the ultimate destination. The IP Authentication Header should always be used on packets containing explicit sensitivity labels to ensure end-to-end
使用のためにゲートウェイと外部の目的地の間のAHと共にSecurity Associationを作成するか、または選択するとき、認識された感度ラベルを含むデータグラムを受けるセキュリティゲートウェイ(例えば、IPSO[Ken91])は信じられたホストからそのラベルの値を考慮に入れるはずです。 そのような環境、受信されるゲートウェイでは、IP Encapsulating Security有効搭載量(超能力)を含むIPパケットは適切な認証を加えるはずです、暗黙(すなわち、使用されるSecurity Associationで含まれた)の、または、明白なラベル情報(例えば、IPSO)を含んでいて、それが最終仕向地である信じられたホストに送る解読されたパケットのために。 IP Authentication Headerは、終わらせる終わりを確実にするのに明白な感度ラベルを含むパケットの上でいつも使用されるべきです。
Atkinson Standards Track [Page 3] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[3ページ]。
label integrity. In environments using security gateways, those gateways MUST perform address-based IP packet filtering on unauthenticated packets purporting to be from a system known to be using IP security.
保全をラベルしてください。 セキュリティゲートウェイを使用する環境で、それらのゲートウェイはIPセキュリティを使用しているのが知られているシステムからあることを意味する非認証されたパケットにアドレスベースのIPパケットフィルタリングを実行しなければなりません。
The IP Encapsulating Security Payload (ESP) is designed to provide integrity, authentication, and confidentiality to IP datagrams [Atk95b]. The ESP supports security between two or more hosts implementing ESP, between two or more gateways implementing ESP, and between a host or gateway implementing ESP and a set of hosts and/or gateways. A security gateway is a system which acts as the communications gateway between external untrusted systems and trusted hosts on their own subnetwork and provides security services for the trusted hosts when they communicate with external untrusted systems. A trusted subnetwork contains hosts and routers that trust each other not to engage in active or passive attacks and trust that the underlying communications channel (e.g., an Ethernet) isn't being attacked. Trusted systems always should be trustworthy, but in practice they often are not trustworthy.
IP Encapsulating Security有効搭載量(超能力)は、IPデータグラム[Atk95b]に保全、認証、および秘密性を供給するように設計されています。 超能力は、超能力を実装する2門以上とホストか超能力を実装するゲートウェイとホスト、そして/または、ゲートウェイのセットの間の超能力を実装しながら、2人以上のホストの間でセキュリティをサポートします。 彼らが外部の信頼されていないシステムとコミュニケートするとき、セキュリティゲートウェイは、外部の信頼されていないシステムの間のコミュニケーションゲートウェイとして作動するシステムであり、それら自身のサブネットワークの上でホストを信じて、信じられたホストにセキュリティー・サービスを提供します。信じられたサブネットワークは互いが、アクティブであるか受け身の攻撃に従事して、基本的なコミュニケーションチャンネル(例えば、イーサネット)が攻撃されていないと信じないと信じるホストとルータを含んでいます。 信じられたシステムはいつも信頼できるべきですが、実際には、彼らはしばしば信頼できるというわけではありません。
Gateway-to-gateway encryption is most valuable for building private virtual networks across an untrusted backbone such as the Internet. It does this by excluding outsiders. As such, it is often not a substitute for host-to-host encryption, and indeed the two can be and often should be used together.
ビル私設仮想回線に、ゲートウェイからゲートウェイへの暗号化はインターネットなどの信頼されていないバックボーンの向こう側に最も貴重です。 それは、部外者を排除することによって、これをします。 そういうものとして、それがしばしばホストからホストへの暗号化の代用品であるというわけではなく、本当に、2は、あることができて、しばしば一緒に使用されるべきです。
In the case where a security gateway is providing services on behalf of one or more hosts on a trusted subnet, the security gateway is responsible for establishing the security association on behalf of its trusted host and for providing security services between the security gateway and the external system(s). In this case, only the gateway need implement ESP, while all of the systems behind the gateway on the trusted subnet may take advantage of ESP services between the gateway and external systems.
セキュリティゲートウェイが信じられたサブネットの1人以上のホストを代表してサービスを提供している場合では、セキュリティゲートウェイは信じられたホストを代表してセキュリティ協会を設立して、セキュリティゲートウェイと外的システムの間にセキュリティー・サービスを供給するのに原因となります。 この場合、ゲートウェイだけが超能力を実装しなければなりません、信じられたサブネットのゲートウェイの後ろのシステムのすべてがゲートウェイと外的システムの間の超能力サービスを利用するかもしれませんが。
A gateway which receives a datagram containing a recognised sensitivity label from a trusted host should take that label's value into consideration when creating/selecting a Security Association for use with ESP between the gateway and the external destination. In such an environment, a gateway which receives a IP packet containing the ESP should appropriately label the decrypted packet that it forwards to the trusted host that is the ultimate destination. The IP Authentication Header should always be used on packets containing explicit sensitivity labels to ensure end-to-end label integrity.
使用のためにSecurity Associationを作成するか、またはゲートウェイと外部の目的地の間には、超能力はある状態で選択するとき、信じられたホストから認識された感度ラベルを含むデータグラムを受けるゲートウェイがそのラベルの値を考慮に入れるはずです。 そのような環境、受信されるゲートウェイでは、超能力を含むIPパケットは適切に、それが最終仕向地である信じられたホストに送る解読されたパケットをラベルするはずです。 IP Authentication Headerは、終わりから終わりへのラベル保全を確実にするのに明白な感度ラベルを含むパケットの上でいつも使用されるべきです。
Atkinson Standards Track [Page 4] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[4ページ]。
If there are no security gateways present in the connection, then two end systems that implement ESP may also use it to encrypt only the user data (e.g., TCP or UDP) being carried between the two systems. ESP is designed to provide maximum flexibility so that users may select and use only the security that they desire and need.
また、接続における現在のどんなセキュリティゲートウェイもなければ、超能力を実装する2台のエンドシステムが、利用者データ(例えば、TCPかUDP)だけを暗号化するのに2台のシステムの間まで運ばれながら、それを使用するかもしれません。超能力は、ユーザが彼らが望んでいて、必要とするセキュリティだけを選択して、使用できるように最大の柔軟性を提供するように設計されています。
Routing headers for which integrity has not been cryptographically protected SHOULD be ignored by the receiver. If this rule is not strictly adhered to, then the system will be vulnerable to various kinds of attacks, including source routing attacks [Bel89] [CB94] [CERT95].
保全が暗号で保護されたSHOULDでないヘッダーを発送して、受信機によって無視されてください。この規則が厳密に固く守られないなら、システムは様々な種類の攻撃に害を被りやすくなるでしょう、ソースルーティング攻撃[Bel89][CB94][CERT95]を含んでいて。
While these documents do not specifically discuss IPv4 broadcast, these IP security mechanisms MAY be used with such packets. Key distribution and Security Association management are not trivial for broadcast applications. Also, if symmetric key algorithms are used the value of using cryptography with a broadcast packet is limited because the receiver can only know that the received packet came from one of many systems knowing the correct key to use.
これらのドキュメントが明確にIPv4放送について議論していない間、これらのIPセキュリティー対策はそのようなパケットと共に使用されるかもしれません。 全面散布には、主要な分配とSecurity Association管理は些細ではありません。 また、対称鍵アルゴリズムが使用されて、放送パケットがある使用暗号の値が受信機が限ることができるだけであるので限られているということであるなら、容認されたパケットが使用の正しいキーを知っている多くのシステムの1つから来たのを知ってください。
1.4 Security Associations
1.4 セキュリティ協会
The concept of a "Security Association" is fundamental to both the IP Encapsulating Security Payload and the IP Authentication Header. The combination of a given Security Parameter Index (SPI) and Destination Address uniquely identifies a particular "Security Association". An implementation of the Authentication Header or the Encapsulating Security Payload MUST support this concept of a Security Association. An implementation MAY also support other parameters as part of a Security Association. A Security Association normally includes the parameters listed below, but might include additional parameters as well:
「セキュリティ協会」の概念はIP Encapsulating Security有効搭載量とIP Authentication Headerの両方に基本的です。 与えられたSecurity Parameter Index(SPI)とDestination Addressの組み合わせは唯一特定の「セキュリティ協会」を特定します。 Authentication HeaderかEncapsulating Security有効搭載量の実装はSecurity Associationのこの概念をサポートしなければなりません。 また、実装はSecurity Associationの一部として他のパラメタをサポートするかもしれません。 Security Associationは通常以下にリストアップされたパラメタを含んでいますが、また、追加パラメタを含むかもしれません:
- Authentication algorithm and algorithm mode being used with
the IP Authentication Header [REQUIRED for AH implementations].
- IP Authentication Header[AH実装のためのREQUIRED]と共に使用される認証アルゴリズムとアルゴリズムモード。
- Key(s) used with the authentication algorithm in use with
the Authentication Header [REQUIRED for AH implementations].
- 中に認証アルゴリズムがある状態で使用されるキーはAuthentication Headerと共に[AH実装のためのREQUIRED]を使用します。
- Encryption algorithm, algorithm mode, and transform being
used with the IP Encapsulating Security Payload [REQUIRED for
ESP implementations].
- IP Encapsulating Security有効搭載量[超能力実装のためのREQUIRED]と共に使用される暗号化アルゴリズム、アルゴリズムモード、および変換。
- Key(s) used with the encryption algorithm in use with the
Encapsulating Security Payload [REQUIRED for ESP implementations].
- 中に暗号化アルゴリズムがある状態で使用されるキーはEncapsulating Securityと共に有効搭載量[超能力実装のためのREQUIRED]を使用します。
Atkinson Standards Track [Page 5] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[5ページ]。
- Presence/absence and size of a cryptographic synchronisation or
initialisation vector field for the encryption algorithm [REQUIRED
for ESP implementations].
- 暗号の連動か初期化処理ベクトルの存在/不在とサイズは暗号化アルゴリズムのために[超能力実装のためのREQUIRED]をさばきます。
- Authentication algorithm and mode used with the ESP transform
(if any is in use) [RECOMMENDED for ESP implementations].
- 超能力と共に使用される認証アルゴリズムとモードは変形します(いずれか使用中であるなら)[超能力実装のためのRECOMMENDED]。
- Authentication key(s) used with the authentication algorithm
that is part of the ESP transform (if any) [RECOMMENDED for
ESP implementations].
- 超能力の一部である認証アルゴリズムで使用される認証キーは[超能力実装のためのRECOMMENDED]を変えます(もしあれば)。
- Lifetime of the key or time when key change should occur
[RECOMMENDED for all implementations].
- キーチェンジが起こるはずであるキーか時[すべての実装のためのRECOMMENDED]の生涯。
- Lifetime of this Security Association [RECOMMENDED for all
implementations].
- このSecurity Association[すべての実装のためのRECOMMENDED]の生涯。
- Source Address(es) of the Security Association, might be a
wildcard address if more than one sending system shares the
same Security Association with the destination [RECOMMENDED
for all implementations].
- 1台以上の送付システムが目的地[すべての実装のためのRECOMMENDED]と同じSecurity Associationを共有するなら、Security AssociationのソースAddress(es)はワイルドカードアドレスであるかもしれません。
- Sensitivity level (for example, Secret or Unclassified)
of the protected data [REQUIRED for all systems claiming
to provide multi-level security, RECOMMENDED for all other systems].
- 保護されたデータ[マルチレベルセキュリティ、RECOMMENDEDを他のすべてのシステムに供給すると主張するすべてのシステムのためのREQUIRED]の感度レベル(例えば、SecretかUnclassified)。
The sending host uses the sending userid and Destination Address to select an appropriate Security Association (and hence SPI value). The receiving host uses the combination of SPI value and Destination Address to distinguish the correct association. Hence, an AH implementation will always be able to use the SPI in combination with the Destination Address to determine the security association and related security configuration data for all valid incoming packets. When a formerly valid Security Association becomes invalid, the destination system(s) SHOULD NOT immediately reuse that SPI value and instead SHOULD let that SPI value become stale before reusing it for some other Security Association.
送付ホストは、適切なSecurity Association(そして、したがって、SPI値)を選択するのに送付ユーザIDとDestination Addressを使用します。 受信ホストは、正しい協会を区別するのにSPI値とDestination Addressの組み合わせを使用します。 したがって、AH実装は、Destination Addressと組み合わせてすべての有効な入って来るパケットのためのセキュリティ協会と関連するセキュリティ設定データを決定するのにいつもSPIを使用できるでしょう。 以前有効なSecurity Associationが無効になると、目的地システムSHOULD NOTはすぐにそのSPI値を再利用します、そして、代わりに、ある他のSecurity Associationのためにそれを再利用する前に、SHOULDはそのSPI値を聞き古したであるならせます。
A security association is normally one-way. An authenticated communications session between two hosts will normally have two Security Parameter Indexes in use (one in each direction). The combination of a particular Security Parameter Index and a particular Destination Address uniquely identifies the Security Association. The Destination Address may be a unicast address or a multicast group address.
通常、セキュリティ協会は一方向です。 通常、2人のホストの間の認証されたコミュニケーションセッションには使用中の2Security Parameter Indexesがある、(あるコネ、各方向) 特定のSecurity Parameter Indexと特定のDestination Addressの組み合わせは唯一Security Associationを特定します。 Destination Addressはユニキャストアドレスかマルチキャストグループアドレスであるかもしれません。
Atkinson Standards Track [Page 6] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[6ページ]。
The receiver-orientation of the Security Association implies that, in the case of unicast traffic, the destination system will normally select the SPI value. By having the destination select the SPI value, there is no potential for manually configured Security Associations that conflict with automatically configured (e.g., via a key management protocol) Security Associations. For multicast traffic, there are multiple destination systems but a single destination multicast group, so some system or person will need to select SPIs on behalf of that multicast group and then communicate the information to all of the legitimate members of that multicast group via mechanisms not defined here.
Security Associationの受信機オリエンテーションは、通常、目的地システムがユニキャストトラフィックの場合でSPI値を選択するのを含意します。 目的地にSPI値を選択させることによって、自動的に構成された(例えば、かぎ管理プロトコルで)セキュリティAssociationsと衝突する手動で構成されたSecurity Associationsの可能性が全くありません。 マルチキャストトラフィックのために、複数の目的地システムにもかかわらず、ただ一つの目的地マルチキャストグループがあるので、システムか人が、ここで定義されなかったメカニズムでそのマルチキャストグループの正統のメンバーのすべてにそのマルチキャストグループを代表してSPIsを選択して、次に、情報を伝える必要があるでしょう。
Multiple senders to a multicast group MAY use a single Security Association (and hence Security Parameter Index) for all traffic to that group. In that case, the receiver only knows that the message came from a system knowing the security association data for that multicast group. A receiver cannot generally authenticate which system sent the multicast traffic when symmetric algorithms (e.g., DES, IDEA) are in use. Multicast traffic MAY also use a separate Security Association (and hence SPI) for each sender to the multicast group . If each sender has its own Security Association and asymmetric algorithms are used, then data origin authentication is also a provided service.
マルチキャストグループへの複数の送付者がすべてのトラフィックに、独身のSecurity Association(そして、したがって、Security Parameter Index)をそのグループに使用するかもしれません。 その場合、受信機は、メッセージがそのマルチキャストグループのためのセキュリティ協会データを知っているシステムから来たのを知っているだけです。 左右対称のアルゴリズム(例えば、デス、IDEA)が使用中であるときに、マルチキャストトラフィックを送る場合、一般に、受信機はどのシステムを認証できないか。 また、マルチキャストトラフィックは各送付者に、別々のSecurity Association(そして、したがって、SPI)をマルチキャストグループに使用するかもしれません。各送付者がそれ自身のSecurity Associationを持って、非対称のアルゴリズムが使用されているなら、また、データ発生源認証は提供されたサービスです。
2. DESIGN OBJECTIVES
2. 設計目標
This section describes some of the design objectives of this security architecture and its component mechanisms. The primary objective of this work is to ensure that IPv4 and IPv6 will have solid cryptographic security mechanisms available to users who desire security.
このセクションはこのセキュリティー体系とそのコンポーネントメカニズムの設計目標のいくつかについて説明します。この仕事の主目的はIPv4とIPv6にはセキュリティを望んでいるユーザにとって、利用可能なしっかりした暗号のセキュリティー対策があるのを保証することです。
These mechanisms are designed to avoid adverse impacts on Internet users who do not employ these security mechanisms for their traffic. These mechanisms are intended to be algorithm-independent so that the cryptographic algorithms can be altered without affecting the other parts of the implementation. These security mechanisms should be useful in enforcing a variety of security policies.
これらのメカニズムは、それらのトラフィックにこれらのセキュリティー対策を使わないインターネットユーザの上で悪影響を避けるように設計されています。 これらのメカニズムが実装の他の部品に影響しないで暗号アルゴリズムを変更できるようにアルゴリズムから独立していることを意図します。 これらのセキュリティー対策はさまざまな安全保障政策を実施する際に役に立つべきです。
Standard default algorithms (keyed MD5, DES CBC) are specified to ensure interoperability in the global Internet. The selected default algorithms are the same as the standard default algorithms used in SNMPv2 [GM93].
標準省略時解釈アルゴリズム(合わせられたMD5、DES CBC)は、世界的なインターネットで相互運用性を確実にするために指定されます。 選択されたデフォルトアルゴリズムは標準省略時解釈アルゴリズムがSNMPv2で[GM93]を使用したのと同じです。
Atkinson Standards Track [Page 7] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[7ページ]。
3. IP-LAYER SECURITY MECHANISMS
3. IP-層のセキュリティー対策
There are two cryptographic security mechanisms for IP. The first is the Authentication Header which provides integrity and authentication without confidentiality [Atk95a]. The second is the Encapsulating Security Payload which always provides confidentiality, and (depending on algorithm and mode) might also provide integrity and authentication [Atk95b]. The two IP security mechanisms may be used together or separately.
IPのための2台の暗号のセキュリティー対策があります。 1番目は秘密性[Atk95a]なしで保全と認証を提供するAuthentication Headerです。 2番目はいつも秘密性を提供するEncapsulating Security有効搭載量です、そして、また、(アルゴリズムとモードに依存します)は保全と認証[Atk95b]を提供するかもしれません。 2台のIPセキュリティー対策が一緒にか別々に使用されるかもしれません。
These IP-layer mechanisms do not provide security against a number of traffic analysis attacks. However, there are several techniques outside the scope of this specification (e.g., bulk link encryption) that might be used to provide protection against traffic analysis [VK83].
これらのIP-層のメカニズムは多くのトラヒック分析攻撃に対してセキュリティを提供しません。 しかしながら、トラヒック分析[VK83]に対する保護を提供するのに使用されるかもしれないこの仕様(例えば、大量のリンク暗号化)の範囲の外にいくつかのテクニックがあります。
3.1 AUTHENTICATION HEADER
3.1 認証ヘッダー
The IP Authentication Header holds authentication information for its IP datagram [Atk95a]. It does this by computing a cryptographic authentication function over the IP datagram and using a secret authentication key in the computation. The sender computes the authentication data prior to sending the authenticated IP packet. Fragmentation occurs after the Authentication Header processing for outbound packets and prior to Authentication Header processing for inbound packets. The receiver verifies the correctness of the authentication data upon reception. Certain fields which must change in transit, such as the "TTL" (IPv4) or "Hop Limit" (IPv6) field, which is decremented on each hop, are omitted from the authentication calculation. However the omission of the Hop Limit field does not adversely impact the security provided. Non-repudiation might be provided by some authentication algorithms (e.g., asymmetric algorithms when both sender and receiver keys are used in the authentication calculation) used with the Authentication Header, but it is not necessarily provided by all authentication algorithms that might be used with the Authentication Header. The default authentication algorithm is keyed MD5, which, like all symmetric algorithms, cannot provide non-repudiation by itself. Confidentiality and traffic analysis protection are not provided by the Authentication Header.
IP Authentication HeaderはIPデータグラム[Atk95a]のための認証情報を保持します。 それは、IPデータグラムの上に暗号の認証機能を計算して、計算で主要な秘密の認証を使用することによって、これをします。 認証されたIPパケットを送る前に、送付者は認証データを計算します。 断片化は外国行きのパケットのためのAuthentication Header処理の後と本国行きのパケットのためのAuthentication Header処理の前に起こります。 受信機はレセプションに関する認証データの正当性について確かめます。 各ホップで減少する"TTL"(IPv4)か「ホップ限界」(IPv6)分野などのトランジットで変化しなければならないある一定の分野は認証計算から省略されます。 Hop Limit分野の省略にどのように逆に影響を与えないでも、セキュリティは提供されました。 Authentication Headerと共に使用されるいくつかの認証アルゴリズム(送付者と受信機キーの両方であるときに、例えば非対称のアルゴリズムは認証計算に使用される)で非拒否を提供するかもしれませんが、必ずAuthentication Headerと共に使用されるかもしれないすべての認証アルゴリズムでそれは提供するというわけではありません。 デフォルト認証アルゴリズムは合わせられたMD5です。(すべての左右対称のアルゴリズムのように、そのMD5自身は非拒否を提供できません)。 秘密性とトラヒック分析保護はAuthentication Headerによって提供されません。
Use of the Authentication Header will increase the IP protocol processing costs in participating systems and will also increase the communications latency. The increased latency is primarily due to the calculation of the authentication data by the sender and the calculation and comparison of the authentication data by each receiver for each IP datagram containing an Authentication Header (AH).
Authentication Headerの使用は、参加システムのIPプロトコル処理コストを増強して、また、コミュニケーション潜在を増強するでしょう。 増強された潜在は主としてAuthentication Header(AH)を含むそれぞれのIPデータグラムのための各受信機による認証データの送付者による認証データの計算、計算、および比較のためです。
Atkinson Standards Track [Page 8] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[8ページ]。
The Authentication Header provides much stronger security than exists in most of the current Internet and should not affect exportability or significantly increase implementation cost. While the Authentication Header might be implemented by a security gateway on behalf of hosts on a trusted network behind that security gateway, this mode of operation is not encouraged. Instead, the Authentication Header should be used from origin to final destination.
Authentication Headerは現在のインターネットの大部分に存在しているよりはるかに強いセキュリティを提供して、「外-移植性」に影響するはずがありませんし、また実装費用をかなり増強するはずがありません。 Authentication Headerはセキュリティゲートウェイによってそのセキュリティゲートウェイの後ろの信じられたネットワークのホストを代表して実装されるかもしれませんが、この運転モードは奨励されません。 代わりに、Authentication Headerは発生源から最終的な目的地まで使用されるべきです。
All IPv6-capable hosts MUST implement the IP Authentication Header with at least the MD5 algorithm using a 128-bit key. IPv4-systems claiming to implement the Authentication Header MUST implement the IP Authentication Header with at least the MD5 algorithm using a 128-bit key [MS95]. An implementation MAY support other authentication algorithms in addition to keyed MD5.
128ビットのキーを使用して、すべてのIPv6有能なホストが少なくともMD5アルゴリズムでIP Authentication Headerを実装しなければなりません。 128ビットのキー[MS95]を使用して、Authentication Headerを実装すると主張するIPv4-システムは少なくともMD5アルゴリズムでIP Authentication Headerを実装しなければなりません。 実装は、他の認証が合わせられたMD5に加えたアルゴリズムであるとサポートするかもしれません。
3.2 ENCAPSULATING SECURITY PAYLOAD
3.2 セキュリティがペイロードであるとカプセル化すること。
The IP Encapsulating Security Payload (ESP) is designed to provide integrity, authentication, and confidentiality to IP datagrams [Atk95b]. It does this by encapsulating either an entire IP datagram or only the upper-layer protocol (e.g., TCP, UDP, ICMP) data inside the ESP, encrypting most of the ESP contents, and then appending a new cleartext IP header to the now encrypted Encapsulating Security Payload. This cleartext IP header is used to carry the protected data through the internetwork.
IP Encapsulating Security有効搭載量(超能力)は、IPデータグラム[Atk95b]に保全、認証、および秘密性を供給するように設計されています。 超能力の中で全体のIPデータグラムか上側の唯一の層のどちらかがプロトコル(例えば、TCP、UDP、ICMP)データであるとカプセル化することによって、それはこれをします、超能力コンテンツの大部分を暗号化して、次に、新しいcleartext IPヘッダーを現在暗号化されたEncapsulating Security有効搭載量に追加して。 このcleartext IPヘッダーは、インターネットワークを通して保護されたデータを運ぶのに使用されます。
3.2.1 Description of the ESP Modes
3.2.1 超能力モードの記述
There are two modes within ESP. The first mode, which is known as Tunnel-mode, encapsulates an entire IP datagram within the ESP header. The second mode, which is known as Transport-mode, encapsulates an upper-layer protocol (for example UDP or TCP) inside ESP and then prepends a cleartext IP header.
超能力の中に2つのモードがあります。 最初のモード(Tunnel-モードとして知られている)は超能力ヘッダーの中に全体のIPデータグラムをカプセル化します。 2番目のモード(Transport-モードとして知られている)は、次に、超能力とprependsの中の上側の層のプロトコル(例えば、UDPかTCP)がcleartext IPヘッダーであるとカプセル化します。
3.2.2 Usage of ESP
3.2.2 超能力の用法
ESP works between hosts, between a host and a security gateway, or between security gateways. This support for security gateways permits trustworthy networks behind a security gateway to omit encryption and thereby avoid the performance and monetary costs of encryption, while still providing confidentiality for traffic transiting untrustworthy network segments. When both hosts directly implement ESP and there is no intervening security gateway, then they may use the Transport- mode (where only the upper layer protocol data (e.g., TCP or UDP) is encrypted and there is no encrypted IP header). This mode reduces both the bandwidth consumed and the protocol processing costs for users that don't need to keep the entire IP datagram confidential.
超能力はホストの間、または、ホストとセキュリティゲートウェイの間、または、セキュリティゲートウェイの間で働いています。 セキュリティゲートウェイのこのサポートは、信頼できないネットワークセグメントを通過しながらまだ秘密性をトラフィックに提供している間、セキュリティゲートウェイの後ろの信頼できるネットワークが暗号化を省略して、その結果、暗号化の性能と通貨のコストを避けることを許可します。 両方のホストが直接超能力を実装して、介入しているセキュリティゲートウェイが全くないと、彼らはTransportモード(上側の層のプロトコルデータ(例えば、TCPかUDP)だけが暗号化されていて、暗号化されたIPヘッダーが全くないところ)を使用するかもしれません。 このモードは全体のIPデータグラムを秘密にする必要はないユーザのために帯域幅が消費した両方とプロトコル処理コストを削減します。
Atkinson Standards Track [Page 9] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[9ページ]。
ESP works with both unicast and multicast traffic.
超能力はユニキャストとマルチキャストトラフィックの両方で働いています。
3.2.3 Performance Impacts of ESP
3.2.3 超能力のパフォーマンス影響
The encapsulating security approach used by ESP can noticeably impact network performance in participating systems, but use of ESP should not adversely impact routers or other intermediate systems that are not participating in the particular ESP association. Protocol processing in participating systems will be more complex when encapsulating security is used, requiring both more time and more processing power. Use of encryption will also increase the communications latency. The increased latency is primarily due to the encryption and decryption required for each IP datagram containing an Encapsulating Security Payload. The precise cost of ESP will vary with the specifics of the implementation, including the encryption algorithm, key size, and other factors. Hardware implementations of the encryption algorithm are recommended when high throughput is desired.
セキュリティアプローチが超能力で使用した要約は顕著に影響を与えることができます。しかし、システム、超能力の使用がそうするべきでない参加における影響ネットワーク性能は逆に特定の超能力協会に参加していないルータか他の中間システムに影響を与えます。 セキュリティをカプセル化するのが使用されているとき、参加システムにおけるプロトコル処理は、より複雑になるでしょう、より多くの時間と、より多くの処理能力の両方を必要として。 また、暗号化の使用はコミュニケーション潜在を増強するでしょう。 増強された潜在は主としてEncapsulating Security有効搭載量を含むそれぞれのIPデータグラムに必要である暗号化と復号化のためです。 超能力の正確な費用は実装の詳細で異なるでしょう、暗号化アルゴリズム、主要なサイズ、および他の要素を含んでいて。 高生産性が望まれているとき、暗号化アルゴリズムのハードウェア実装はお勧めです。
For interoperability throughout the worldwide Internet, all conforming implementations of the IP Encapsulating Security Payload MUST support the use of the Data Encryption Standard (DES) in Cipher-Block Chaining (CBC) Mode as detailed in the ESP specification. Other confidentiality algorithms and modes may also be implemented in addition to this mandatory algorithm and mode. Export and use of encryption are regulated in some countries [OTA94].
世界的なインターネット中の相互運用性のために、IP Encapsulating Security有効搭載量の実装をすべて従わせると、Cipher-ブロックChaining(CBC)モードにおけるデータ暗号化規格(DES)の使用は超能力仕様で詳しく述べられるようにサポートしなければなりません。 また、他の秘密性アルゴリズムとモードはこの義務的なアルゴリズムとモードに加えて実装されるかもしれません。 暗号化の輸出と使用はいくつかの国[OTA94]で規制されます。
3.3 COMBINING SECURITY MECHANISMS
3.3 セキュリティー対策を結合すること。
In some cases the IP Authentication Header might be combined with the IP Encapsulating Security Protocol to obtain the desired security properties. The Authentication Header always provides integrity and authentication and can provide non-repudiation if used with certain authentication algorithms (e.g., RSA). The Encapsulating Security Payload always provides integrity and confidentiality and can also provide authentication if used with certain authenticating encryption algorithms. Adding the Authentication Header to a IP datagram prior to encapsulating that datagram using the Encapsulating Security Protocol might be desirable for users wishing to have strong integrity, authentication, confidentiality, and perhaps also for users who require strong non-repudiation. When the two mechanisms are combined, the placement of the IP Authentication Header makes clear which part of the data is being authenticated. Details on combining the two mechanisms are provided in the IP Encapsulating Security Payload specification [At94b].
いくつかの場合、IP Authentication Headerは、必要なセキュリティ資産を入手するためにIP Encapsulating Securityプロトコルに結合されるかもしれません。 ある認証アルゴリズム(例えば、RSA)で使用されるなら、Authentication Headerはいつも保全と認証を提供して、非拒否を提供できます。 ある暗号化アルゴリズムを認証しながら使用されるなら、Encapsulating Security有効搭載量は、いつも保全と秘密性を提供して、また、認証を提供できます。強い保全、認証、秘密性を持ちたがっているユーザと恐らく強い非拒否を必要とするユーザにとっても、Encapsulating Securityプロトコルを使用することでそのデータグラムをカプセル化する前にIPデータグラムにAuthentication Headerを加えるのは望ましいかもしれません。 2つのメカニズムが結合されているとき、Authentication Headerがどの部分からデータを取り除かせるIPのプレースメントは認証されています。 2つのメカニズムを結合することに関する詳細はIP Encapsulating Security有効搭載量仕様[At94b]に明らかにされます。
Atkinson Standards Track [Page 10] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[10ページ]。
3.4 OTHER SECURITY MECHANISMS
3.4 他のセキュリティー対策
Protection from traffic analysis is not provided by any of the security mechanisms described above. It is unclear whether meaningful protection from traffic analysis can be provided economically at the Internet Layer and it appears that few Internet users are concerned about traffic analysis. One traditional method for protection against traffic analysis is the use of bulk link encryption. Another technique is to send false traffic in order to increase the noise in the data provided by traffic analysis. Reference [VK83] discusses traffic analysis issues in more detail.
トラヒック分析からの保護は上で説明されたセキュリティー対策のいずれによっても提供されません。 インターネットLayerでトラヒック分析からの重要な保護を経済的に前提とすることができて、わずかなインターネットユーザしかトラヒック分析に関して心配していないように見えるかどうかが不明瞭です。 トラヒック分析に対する保護のための1つの伝統的方法は大量のリンク暗号化の使用です。 別のテクニックはトラヒック分析で提供されたデータにおける雑音を増強するために誤ったトラフィックを送ることです。 参照[VK83]はさらに詳細にトラヒック分析問題について議論します。
4. KEY MANAGEMENT
4. かぎ管理
The Key Management protocol that will be used with IP layer security is not specified in this document. However, because the key management protocol is coupled to AH and ESP only via the Security Parameters Index (SPI), we can meaningfully define AH and ESP without having to fully specify how key management is performed. We envision that several key management systems will be usable with these specifications, including manual key configuration. Work is ongoing within the IETF to specify an Internet Standard key management protocol.
IP層のセキュリティと共に使用されるKey Managementプロトコルは本書では指定されません。 しかしながら、かぎ管理プロトコルがSecurity Parameters Index(SPI)を通してだけAHと超能力と結合されるので、かぎ管理がどう実行されるかを完全に指定する必要はなくて、私たちは意味深長にAHと超能力を定義できます。 私たちはこれらの仕様で使用可能であり、手動の主要な構成を含んでいて、システムがそうするその数個のかぎ管理を思い描きます。 仕事はインターネットStandardかぎ管理プロトコルを指定するIETFの中で進行中です。
Support for key management methods where the key management data is carried within the IP layer is not a design objective for these IP- layer security mechanisms. Instead these IP-layer security mechanisms will primarily use key management methods where the key management data will be carried by an upper layer protocol, such as UDP or TCP, on some specific port number or where the key management data will be distributed manually.
かぎ管理データがIP層の中で運ばれるかぎ管理メソッドのサポートはこれらのIP層のセキュリティー対策のための設計目標ではありません。代わりに、これらのIP-層のセキュリティー対策は主として、かぎ管理データが上側の層のプロトコルによって運ばれるかぎ管理メソッドを使用するでしょう、UDPやTCPのように、何らかの特定のポートナンバーかそれともかぎ管理データがどこで手動で分配されるかに関して。
This design permits clear decoupling of the key management mechanism from the other security mechanisms, and thereby permits one to substitute new and improved key management methods without having to modify the implementations of the other security mechanisms. This separation of mechanism is clearly wise given the long history of subtle flaws in published key management protocols [NS78, NS81]. What follows in this section is a brief discussion of a few alternative approaches to key management. Mutually consenting systems may additionally use other key management approaches by private prior agreement.
このデザインは、他のセキュリティー対策からかぎ管理メカニズムの明確なデカップリングを許可して、その結果、1つが他のセキュリティー対策の実装を変更する必要はなくて新しくて改良されたかぎ管理メソッドを代入することを許可します。発行されたかぎ管理プロトコル[NS78、NS81]における、微妙な欠点の長い歴史を考えて、メカニズムのこの分離は明確に賢明です。 このセクションで続くことはかぎ管理へのいくつかの代替的アプローチの簡潔な議論です。 互いに、同意システムは個人的な事前同意でさらに、他のかぎ管理アプローチを使用するかもしれません。
4.1 Manual Key Distribution
4.1 手動の主要な分配
The simplest form of key management is manual key management, where a person manually configures each system with its own key and also with the keys of other communicating systems. This is quite practical in
最も簡単な形式のかぎ管理は手動のかぎ管理です。(そこでは、人がそれ自身のキーと他の交信システムこのキーをもってもそれぞれのシステムがかなり実用的であることを手動で構成します)。
Atkinson Standards Track [Page 11] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[11ページ]。
small, static environments but does not scale. It is not a viable medium-term or long-term approach, but might be appropriate and useful in many environments in the near-term. For example, within a small LAN it is entirely practical to manually configure keys for each system. Within a single administrative domain it is practical to configure keys for each router so that the routing data can be protected and to reduce the risk of an intruder breaking into a router. Another case is where an organisation has an encrypting firewall between the internal network and the Internet at each of its sites and it connects two or more sites via the Internet. In this case, the encrypting firewall might selectively encrypt traffic for other sites within the organisation using a manually configured key, while not encrypting traffic for other destinations. It also might be appropriate when only selected communications need to be secured.
しかし、小さくて、静的な環境、比例しません。 それは、短期間多くの環境で実行可能な中期でない長期のアプローチではありませんが、適切であって、役に立つかもしれません。 例えば、小さいLANの中では、各システムのために手動でキーを構成するのは完全に実用的です。 ただ一つの管理ドメインの中では、ルーティングデータを保護できて、各ルータのためにキーを構成して、ルータに侵入している侵入者の危険を減少させるのは実用的です。 別のケースはそれぞれのサイトの機構が内部のネットワークとインターネットの間に暗号化ファイアウォールを持っているところです、そして、それはインターネットを通して2つ以上のサイトをつなげます。 この場合、暗号化ファイアウォールは、他の目的地にトラフィックを暗号化していない間、機構の中で手動で構成されたキーを使用することで他のサイトに選択的にトラフィックを暗号化するかもしれません。 また、選択されるだけであるならコミュニケーションが、機密保護される必要があるのも、適切であるかもしれません。
4.2 Some Existing Key Management Techniques
4.2 いくつかの既存のKey Managementのテクニック
There are a number of key management algorithms that have been described in the public literature. Needham & Schroeder have proposed a key management algorithm which relies on a centralised key distribution system [NS78, NS81]. This algorithm is used in the Kerberos Authentication System developed at MIT under Project Athena [KB93]. Diffie and Hellman have devised an algorithm which does not require a centralised key distribution system [DH76]. Unfortunately, the original Diffie-Hellman technique is vulnerable to an active "man in the middle" attack [Sch93, p. 43-44]. However, this vulnerability can be mitigated by using signed keys to authentically bootstrap into the Diffie-Hellman exchange [Sch93, p. 45].
公共の文学で説明される多くのかぎ管理アルゴリズムがあります。 ニーダムとシュローダーは集中化された主要な流通制度[NS78、NS81]を当てにするかぎ管理アルゴリズムを提案しました。 このアルゴリズムはProjectアテーナー[KB93]の下でMITで開発されたケルベロスAuthentication Systemで使用されます。 ディフィーとヘルマンは集中化された主要な流通制度[DH76]を必要としないアルゴリズムを工夫しました。 残念ながら、オリジナルのディフィー-ヘルマンのテクニックは「中央の男性」活発な攻撃に被害を受け易いです。[Sch93、p。 43-44]. しかしながら、ほんとうにディフィー-ヘルマンの交換に独力で進むのに署名しているキーを使用することによって、この脆弱性を緩和できます。[Sch93、p。 45].
4.3 Automated Key Distribution
4.3 自動化された主要な分配
Widespread deployment and use of IP security will require an Internet-standard scalable key management protocol. Ideally such a protocol would support a number of protocols in the Internet protocol suite, not just IP security. There is work underway within the IETF to add signed host keys to the Domain Name System [EK94] The DNS keys enable the originating party to authenticate key management messages with the other key management party using an asymmetric algorithm. The two parties would then have an authenticatible communications channel that could be used to create a shared session key using Diffie-Hellman or other means [DH76] [Sch93].
IPセキュリティの広範囲の展開と使用はインターネット標準のスケーラブルなかぎ管理プロトコルを必要とするでしょう。 理想的に、そのようなプロトコルはIPだけではなく、インターネット・プロトコル群の多くのプロトコルにセキュリティをサポートするでしょう。 ドメインネームシステム[EK94]のホストキーであると署名されて、DNSキーが、起因するパーティーがもう片方のかぎ管理パーティーが非対称のアルゴリズムを使用しているかぎ管理メッセージを認証するのを可能にすると言い足すために、IETFの中の進行中の仕事があります。 そして、2回のパーティーには、ディフィー-ヘルマンを使用することで共有されたセッションキーを作成するのに使用できたauthenticatibleコミュニケーションチャンネルか他の手段[DH76][Sch93]があるでしょう。
4.4 Keying Approaches for IP
4.4 IPのためのアプローチを合わせること。
There are two keying approaches for IP. The first approach, called host-oriented keying, has all users on host 1 share the same key for use on traffic destined for all users on host 2. The second approach, called user-oriented keying, lets user A on host 1 have one
IPのためのアプローチを合わせる2があります。 ホスト指向の合わせると呼ばれる最初のアプローチで、ホスト1の上のすべてのユーザがすべてのユーザのために運命づけられたトラフィックにおける使用のためにホスト2の上で同じキーを共有します。 利用者志向合わせると呼ばれる2番目のアプローチで、ホスト1の上のユーザAは1つを持つことができます。
Atkinson Standards Track [Page 12] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[12ページ]。
or more unique session keys for its traffic destined for host 2; such session keys are not shared with other users on host1. For example, user A's ftp session might use a different key than user A's telnet session. In systems claiming to provide multi-level security, user A will typically have at least one key per sensitivity level in use (e.g., one key for UNCLASSIFIED traffic, a second key for SECRET traffic, and a third key for TOP SECRET traffic). Similarly, with user-oriented keying one might use separate keys for information sent to a multicast group and control messages sent to the same multicast group.
または、トラフィックのための、よりユニークなセッションキーはホスト2のために運命づけられました。 そのようなセッションキーはhost1の上の他のユーザと共有されません。 例えば、ユーザAのftpセッションはユーザAのtelnetセッションと異なったキーを使用するかもしれません。 マルチレベルセキュリティを提供すると主張するシステムでは、ユーザAは使用中の感度レベル(TOP SECRETトラフィックのための例えば、UNCLASSIFIEDトラフィックのための1個のキー、SECRETトラフィックに、主要な1秒、および3番目のキー)あたり少なくとも1個のキーを通常持つでしょう。 同様に、利用者志向合わせることで、1つはマルチキャストグループに送られた情報と同じマルチキャストグループに送られたコントロールメッセージに別々のキーを使用するかもしれません。
In many cases, a single computer system will have at least two mutually suspicious users A and B that do not trust each other. When host-oriented keying is used and mutually suspicious users exist, it is sometimes possible for user A to determine the host-oriented key via well known methods, such as a Chosen Plaintext attack. Once user A has improperly obtained the key in use, user A can then either read user B's encrypted traffic or forge traffic from user B. When user- oriented keying is used, certain kinds of attack from one user onto another user's traffic are not possible.
多くの場合、ただ一つのコンピュータ・システムには、互いを信じない少なくとも2人の互いに疑わしげなユーザAとBがいるでしょう。 ホスト指向の合わせるのがユーザが存在するのが中古であって、互いに疑わしげであるときに、ユーザAがよく知られているメソッドでホスト指向のキーを決定するのは、時々可能です、Chosen Plaintext攻撃のように。 ユーザAがいったん不適切に使用中のキーを入手すると、次に、ユーザAが暗号化されたトラフィックをユーザビーズに読み込むことができますか、またはユーザB.Whenユーザ指向の合わせるのからの鍛造トラフィックは使用されています、1人のユーザからの別のユーザのトラフィックに対する攻撃の種類が可能でないことを確信しています。
IP Security is intended to be able to provide Authentication, Integrity, and Confidentiality for applications operating on connected end systems when appropriate algorithms are in use. Integrity and Confidentiality can be provided by host-oriented keying when appropriate dynamic key management techniques and appropriate algorithms are in use. However, authentication of principals using applications on end-systems requires that processes running applications be able to request and use their own Security Associations. In this manner, applications can make use of key distribution facilities that provide authentication.
IP Securityが適切なアルゴリズムが使用中であるときに接続エンドシステムを作動させるアプリケーションにAuthentication、Integrity、およびConfidentialityを提供できることを意図します。 適切なダイナミックなかぎ管理のテクニックと適切なアルゴリズムが使用中であるときに、ホスト指向の合わせることで保全とConfidentialityを提供できます。 しかしながら、エンドシステムにおけるアプリケーションを使用する校長の認証は、アプリケーションを実行するプロセスがそれら自身のSecurity Associationsを要求して、使用できるのを必要とします。 この様に、アプリケーションは認証を提供する主要な分配施設を利用できます。
Hence, support for user-oriented keying SHOULD be present in all IP implementations, as is described in the "IP Key Management Requirements" section below.
したがって、利用者志向合わせるSHOULDのために、そのままなすべてのIP実装におけるプレゼントが「IP Key Management要件」セクション下で説明されていたなら、サポートします。
4.5 Multicast Key Distribution
4.5 マルチキャストの主要な分配
Multicast key distribution is an active research area in the published literature as of this writing. For multicast groups having relatively few members, manual key distribution or multiple use of existing unicast key distribution algorithms such as modified Diffie-Hellman appears feasible. For very large groups, new scalable techniques will be needed. The use of Core-Based Trees (CBT) to provide session key management as well as multicast routing might be an approach used in the future [BFC93].
マルチキャストの主要な分配はこの書くこと現在発行された文学のアクティブな研究領域です。 比較的わずかなメンバーがいるマルチキャストグループに関しては、変更されたディフィー-ヘルマンなどの既存のユニキャスト主要な分配アルゴリズムの手動の主要な分配か複数の使用が可能に見えます。 非常に大きいグループにおいて、新しいスケーラブルなテクニックが必要でしょう。 マルチキャストルーティングと同様にセッションかぎ管理を提供するベースのCore Trees(CBT)の使用は将来使用されたアプローチであるかもしれません[BFC93]。
Atkinson Standards Track [Page 13] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[13ページ]。
4.6 IP Key Management Requirements
4.6 IP Key Management要件
This section defines key management requirements for all IPv6 implementations and for those IPv4 implementations that implement the IP Authentication Header, the IP Encapsulating Security Payload, or both. It applies equally to the IP Authentication Header and the IP Encapsulating Security Payload.
このセクションはすべてのIPv6実装とそれらのIPv4実装のためのIPがAuthentication Header、IP Encapsulating Security有効搭載量、または両方であると実装するかぎ管理要件を定義します。 それは等しくIP Authentication HeaderとIP Encapsulating Security有効搭載量に適用されます。
All such implementations MUST support manual configuration of Security Associations.
そのようなすべての実装がSecurity Associationsの手動の構成をサポートしなければなりません。
All such implementations SHOULD support an Internet standard Security Association establishment protocol (e.g., IKMP, Photuris) once such a protocol is published as an Internet standards-track RFC.
そのようなプロトコルがインターネット標準化過程RFCとしていったん発表されると、そのようなすべての実装SHOULDが、インターネット標準Security Association設立プロトコルが(例えば、IKMP、Photuris)であるとサポートします。
Implementations MAY also support other methods of configuring Security Associations.
また、実装はSecurity Associationsを構成する他のメソッドをサポートするかもしれません。
Given two endpoints, it MUST be possible to have more than one concurrent Security Association for communications between them. Implementations on multi-user hosts SHOULD support user granularity (i.e., "user-oriented") Security Associations.
2つの終点を考えて、それらのコミュニケーションのための1同時発生のSecurity Associationを持っているのは可能であるに違いありません。 マルチユーザホストSHOULDサポートユーザ粒状(すなわち、「利用者志向」の)セキュリティAssociationsの上の実装。
All such implementations MUST permit the configuration of host- oriented keying.
そのようなすべての実装がホストの指向の合わせることの構成を可能にしなければなりません。
A device that encrypts or authenticates IP packets originated other systems, for example a dedicated IP encryptor or an encrypting gateway, cannot generally provide user-oriented keying for traffic originating on other systems. Such systems MAY additionally implement support for user-oriented keying for traffic originating on other systems.
IPパケットを暗号化するか、または認証するデバイスは例えば他のシステム、ひたむきなIP暗号化する人または暗号化ゲートウェイを溯源して、一般に、他のシステムの上で起因するトラフィックのための利用者志向合わせることを提供できません。そのようなシステムは、さらに、他のシステムの上で起因するトラフィックのための利用者志向合わせることのサポートを実装するかもしれません。
The method by which keys are configured on a particular system is implementation-defined. A flat file containing security association identifiers and the security parameters, including the key(s), is an example of one possible method for manual key distribution. An IP system MUST take reasonable steps to protect the keys and other security association information from unauthorised examination or modification because all of the security lies in the keys.
キーが特定のシステムの上で構成されるメソッドは実装で定義されています。 キーを含むセキュリティ協会識別子とセキュリティパラメタを含む平坦なファイルは手動の主要な分配のための1つの可能なメソッドに関する例です。 IPシステムは、セキュリティのすべてがキーに横たわっているので権限のない試験か変更からキーと他のセキュリティ協会情報を保護するために合理的な方法を採らなければなりません。
5. USAGE
5. 用法
This section describes the possible use of the security mechanisms provided by IP in several different environments and applications in order to give the implementer and user a better idea of how these mechanisms can be used to reduce security risks.
このセクションはセキュリティ危険を減少させるのにどうこれらのメカニズムを使用できるかに関する、より良い考えをimplementerとユーザに与えるためにIPによっていくつかの異なった環境とアプリケーションに提供されたセキュリティー対策の活用可能性について説明します。
Atkinson Standards Track [Page 14] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[14ページ]。
5.1 USE WITH FIREWALLS
5.1 ファイアウォールとの使用
Firewalls are not uncommon in the current Internet [CB94]. While many dislike their presence because they restrict connectivity, they are unlikely to disappear in the near future. Both of these IP mechanisms can be used to increase the security provided by firewalls.
ファイアウォールは現在のインターネット[CB94]で珍しくはありません。 彼らが接続性を制限するので、多くがそれらの存在が嫌ですが、それらは近い将来、見えなくなりそうにはありません。 ファイアウォールによって提供されたセキュリティを増強するのにこれらのIPメカニズムの両方を使用できます。
Firewalls used with IP often need to be able to parse the headers and options to determine the transport protocol (e.g., UDP or TCP) in use and the port number for that protocol. Firewalls can be used with the Authentication Header regardless of whether that firewall is party to the appropriate Security Assocation, but a firewall that is not party to the applicable Security Association will not normally be able to decrypt an encrypted upper-layer protocol to view the protocol or port number needed to perform per-packet filtering OR to verify that the data (e.g., source, destination, transport protocol, port number) being used for access control decisions is correct and authentic. Hence, authentication might be performed not only within an organisation or campus but also end to end with remote systems across the Internet. This use of the Authentication Header with IP provides much more assurance that the data being used for access control decisions is authentic.
IPと共に使用されるファイアウォールは、しばしばそのプロトコルのために使用中のトランスポート・プロトコル(例えば、UDPかTCP)とポートナンバーを測定するためにヘッダーとオプションを分析できる必要があります。 そのファイアウォールが適切なSecurity Assocationに関係するかどうかにかかわらずAuthentication Headerと共にファイアウォールを使用できますが、通常、適切なSecurity Associationに関係しないファイアウォールは、アクセス制御決定に使用されるデータ(例えば、ソース、目的地、トランスポート・プロトコルは数を移植する)が正しくて、正統であることを確かめるために1パケットフィルタリングあたりのORを実行するのに必要であるプロトコルかポートナンバーを見るために暗号化された上側の層のプロトコルを解読することができないでしょう。 したがって、機構かキャンパスだけの中で実行されるのではなく、認証は、リモートシステムがインターネットのむこうにある状態で終わるために終わりもするかもしれません。 IPとのAuthentication Headerのこの使用はアクセス制御決定に使用されるデータが正統であるというずっと多くの保証を提供します。
Organisations with two or more sites that are interconnected using commercial IP service might wish to use a selectively encrypting firewall. If an encrypting firewall were placed between each site of a company and the commercial IP service provider, the firewall could provide an encrypted IP tunnel among all the company's sites. It could also encrypt traffic between the company and its suppliers, customers, and other affiliates. Traffic with the Network Information Center, with public Internet archives, or some other organisations might not be encrypted because of the unavailability of a standard key management protocol or as a deliberate choice to facilitate better communications, improved network performance, and increased connectivity. Such a practice could easily protect the company's sensitive traffic from eavesdropping and modification.
商業IPサービスを利用することでインタコネクトされる2つ以上のサイトによる機構は選択的に暗号化しているファイアウォールを使用したがっているかもしれません。 暗号化ファイアウォールが会社の各サイトと商業IPサービスプロバイダーの間に置かれるなら、ファイアウォールは暗号化されたIPトンネルを会社のサイトに提供するかもしれないでしょうに。 また、それは会社と、供給者と、顧客と、他の系列の間のトラフィックを暗号化するかもしれません。 公共のインターネットアーカイブ、またはある他の機構をもっているインフォメーション・センターがそうするかもしれないNetworkがあるトラフィックが標準のかぎ管理プロトコルの使用不能か慎重な選択として、より良いコミュニケーションを容易にするために暗号化されないで、改良されて、性能の、そして、増強された接続性をネットワークでつないでください。 そのような習慣は盗聴と変更から会社の敏感なトラフィックを容易に保護するかもしれません。
Some organisations (e.g., governments) might wish to use a fully encrypting firewall to provide a protected virtual network over commercial IP service. The difference between that and a bulk IP encryption device is that a fully encrypting firewall would provide filtering of the decrypted traffic as well as providing encryption of IP packets.
機構(例えば、政府)の中には商業IPサービスの上に保護された仮想ネットワークを提供するのに完全に暗号化しているファイアウォールを使用したがっているかもしれないものもあります。 それと大量のIP暗号化デバイスの違いは完全に暗号化しているファイアウォールがIPパケットの暗号化を提供することと同様に解読されたトラフィックのフィルタリングを提供するだろうということです。
Atkinson Standards Track [Page 15] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[15ページ]。
5.2 USE WITH IP MULTICAST
5.2 IPマルチキャストとの使用
In the past several years, the Multicast Backbone (MBONE) has grown rapidly. IETF meetings and other conferences are now regularly multicast with real-time audio, video, and whiteboards. Many people are now using teleconferencing applications based on IP Multicast in the Internet or in private internal networks. Others are using IP multicasting to support distributed simulation or other applications. Hence it is important that the security mechanisms in IP be suitable for use in an environment where multicast is the general case.
過去数年間で、Multicast Backbone(MBONE)は急速に成長しました。 現在定期的にIETFミーティングと他の会議はリアルタイムのオーディオ、ビデオ、およびホワイトボードがあるマルチキャストです。 多くの人々が現在、インターネットか内緒で内部のネットワークでIP Multicastに基づく電子会議アプリケーションを使用しています。 他のものは、分配されたシミュレーションか他のアプリケーションをサポートするのにIPマルチキャスティングを使用しています。 したがって、IPのセキュリティー対策がマルチキャストが一般的なケースである環境における使用に適しているのは、重要です。
The Security Parameters Indexes (SPIs) used in the IP security mechanisms are receiver-oriented, making them well suited for use in IP multicast [Atk95a, Atk95b]. Unfortunately, most currently published multicast key distribution protocols do not scale well. However, there is active research in this area. As an interim step, a multicast group could repeatedly use a secure unicast key distribution protocol to distribute the key to all members or the group could pre-arrange keys using manual key distribution.
IPセキュリティー対策で使用されるSecurity Parameters Indexes(SPIs)が受信機指向である、上手にそれらを作るのはIPマルチキャスト[Atk95a、Atk95b]における使用のために適合しました。 残念ながら、ほとんどの現在発行されたマルチキャスト主要な分配プロトコルはよく比例しません。 しかしながら、活発な研究がこの領域にあります。 中間の段階として、マルチキャストグループがすべてのメンバーのキーを分配するのに繰り返して安全なユニキャスト主要な分配プロトコルを使用できましたか、またはグループは、手動の主要な分配を使用することでキーについて根回しできるでしょう。
5.3 USE TO PROVIDE QOS PROTECTION
5.3 保護をQOSに供給する使用
The recent IAB Security Workshop identified Quality of Service protection as an area of significant interest [BCCH]. The two IP security mechanisms are intended to provide good support for real- time services as well as multicasting. This section describes one possible approach to providing such protection.
最近のIAB Security Workshopは、Service保護のQualityが重要に関心[BCCH]の領域であると認識しました。 2台のIPセキュリティー対策がマルチキャスティングと同様に本当の時間指定サービスの良いサポートを提供することを意図します。 このセクションは1つの可能なアプローチをそのような保護を提供するのに説明します。
The Authentication Header might be used, with appropriate key management, to provide authentication of packets. This authentication is potentially important in packet classification within routers. The IPv6 Flow Identifier might act as a Low-Level Identifier (LLID). Used together, packet classification within routers becomes straightforward if the router is provided with the appropriate keying material. For performance reasons the routers might authenticate only every Nth packet rather than every packet, but this is still a significant improvement over capabilities in the current Internet. Quality of service provisioning is likely to also use the Flow ID in conjunction with a resource reservation protocol, such as RSVP [ZDESZ93]. Thus, the authenticated packet classification can be used to help ensure that each packet receives appropriate handling inside routers.
Authentication Headerは、パケットの認証を提供するのに適切なかぎ管理で使用されるかもしれません。 この認証はルータの中でパケット分類で潜在的に重要です。 IPv6 Flow IdentifierはLow-レベルIdentifier(LLID)として機能するかもしれません。 適切な合わせることの材料をルータに提供するなら、ルータの中の一緒に使用されたパケット分類は簡単になります。 性能理由で、ルータはあらゆるパケットよりむしろあらゆるだけNthパケットを認証するかもしれませんが、それでも、これは現在のインターネットの能力の上のかなりの改善です。 また、サービスの質の食糧を供給するのも資源予約プロトコルに関連してFlow IDを使用しそうです、RSVP[ZDESZ93]などのように。 したがって、各パケットがルータで適切な取り扱いを受けるのを確実にするのを助けるのに認証されたパケット分類を使用できます。
5.4 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS
5.4 COMPARTMENTEDにおける使用かマルチレベルネットワーク
A multi-level secure (MLS) network is one where a single network is used to communicate data at different sensitivity levels (e.g., Unclassified and Secret) [DoD85] [DoD87]. Many governments have
マルチレベルの安全な(MLS)ネットワークはただ一つのネットワークが異なった感度レベル(例えば、UnclassifiedとSecret)[DoD85][DoD87]でデータを伝えるのに使用されるものです。 多くの政府はそうしました。
Atkinson Standards Track [Page 16] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[16ページ]。
significant interest in MLS networking [DIA]. The IP security mechanisms have been designed to support MLS networking. MLS networking requires the use of strong Mandatory Access Controls (MAC), which ordinary users are incapable of controlling or violating [BL73]. This section pertains only to the use of these IP security mechanisms in MLS environments.
MLSネットワーク[DIA]への重要な関心。 IPセキュリティー対策は、MLSがネットワークであるとサポートするように設計されています。 MLSネットワークは強いMandatory Access Controls(MAC)[BL73]の使用を必要とします。(Mandatory Access Controlsに制御できないか、一般ユーザは違反できません)。 このセクションはMLS環境におけるこれらのIPセキュリティー対策の使用だけに関係します。
The Authentication Header can be used to provide strong authentication among hosts in a single-level network. The Authentication Header can also be used to provide strong assurance for both mandatory access control decisions in multi-level networks and discretionary access control decisions in all kinds of networks. If explicit IP sensitivity labels (e.g., IPSO) [Ken91] are used and confidentiality is not considered necessary within the particular operational environment, the Authentication Header is used to provide authentication for the entire packet, including cryptographic binding of the sensitivity level to the IP header and user data. This is a significant improvement over labeled IPv4 networks where the label is trusted even though it is not trustworthy because there is no authentication or cryptographic binding of the label to the IP header and user data. IPv6 will normally use implicit sensitivity labels that are part of the Security Association but not transmitted with each packet instead of using explicit sensitivity labels. All explicit IP sensitivity labels MUST be authenticated using either ESP, AH, or both.
ただ一つのレベルネットワークのホストに強い認証を提供するのにAuthentication Headerを使用できます。 また、マルチレベルネットワークにおける義務的なアクセス制御決定と任意のアクセス制御決定の両方のための強い保証をすべての種類のネットワークに提供するのにAuthentication Headerを使用できます。 明白なIP感度ラベル(例えば、IPSO)[Ken91]が使用されていて、秘密性が特定の運用環境の中で必要であることは考えられないなら、Authentication Headerが全体のパケットのための認証を提供するのに使用されます、IPヘッダーと利用者データに感度レベルの暗号の結合を含めて。 これはIPヘッダーと利用者データへのラベルをどんな認証も暗号の結合もないのでそれが信頼できませんが、ラベルが信じられるラベルされたIPv4ネットワークの上のかなりの改善です。 通常、IPv6は各パケットが明白な感度ラベルを使用することの代わりにあるSecurity Associationにもかかわらず、伝えられないことの一部である内在している感度ラベルを使用するでしょう。 超能力、AHか両方のどちらかを使用して、すべての明白なIP感度ラベルを認証しなければなりません。
The Encapsulating Security Payload can be combined with appropriate key policies to provide full multi-level secure networking. In this case each key must be used only at a single sensitivity level and compartment. For example, Key "A" might be used only for sensitive Unclassified packets, while Key "B" is used only for Secret/No- compartments traffic, and Key "C" is used only for Secret/No-Foreign traffic. The sensitivity level of the protected traffic MUST NOT dominate the sensitivity level of the Security Association used with that traffic. The sensitivity level of the Security Association MUST NOT dominate the sensitivity level of the key that belongs to that Security Association. The sensitivity level of the key SHOULD be the same as the sensitivity level of the Security Association. The Authentication Header can also have different keys for the same reasons, with the choice of key depending in part on the sensitivity level of the packet.
完全なマルチレベル安全なネットワークを提供するためにEncapsulating Security有効搭載量を適切な重要政策に結合できます。 この場合、ただ一つの感度レベルとコンパートメントだけで各キーを使用しなければなりません。 例えば、Key「A」は敏感なUnclassifiedパケットにだけ使用されるかもしれません、キー「B」は秘密/いいえ、コンパートメントトラフィックにだけ使用されます、そして、キー「C」は秘密の、または、外国でないトラフィックにだけ使用されますが。 保護されたトラフィックの感度レベルはそのトラフィックと共に使用されるSecurity Associationの感度レベルを支配してはいけません。 Security Associationの感度レベルはそのSecurity Associationに属すキーの感度レベルを支配してはいけません。 感度レベル、主要なSHOULDでは、Security Associationの感度レベルと同じにしてください。 また、Authentication Headerは同じ理由で異なったキーを持つことができます、一部パケットの感度レベルへの主要な依存の選択で。
Encryption is very useful and desirable even when all of the hosts are within a protected environment. The Internet-standard encryption algorithm could be used, in conjunction with appropriate key management, to provide strong Discretionary Access Controls (DAC) in conjunction with either implicit sensitivity labels or explicit sensitivity labels (such as IPSO provides for IPv4 [Ken91]). Some
ホストが皆、保護された環境の中にいるときさえ、暗号化は、非常に役に立って望ましいです。 内在している感度ラベルか明白な感度ラベル(IPSOがIPv4[Ken91]に備えるようなもの)のどちらかに関連して強いDiscretionary Access Controls(DAC)を提供するのに適切なかぎ管理に関連してインターネット標準暗号化アルゴリズムを使用できました。 いくつか
Atkinson Standards Track [Page 17] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[17ページ]。
environments might consider the Internet-standard encryption algorithm sufficiently strong to provide Mandatory Access Controls (MAC). Full encryption SHOULD be used for all communications between multi-level computers or compartmented mode workstations even when the computing environment is considered to be protected.
環境は、インターネット標準暗号化アルゴリズムがMandatory Access Controls(MAC)を提供できるくらい強いと考えるかもしれません。 コンピューティング環境が保護されると考えられるときさえ、完全な暗号化SHOULDはマルチレベルのコンピュータのすべてのコミュニケーションに使用されたか、またはモードワークステーションをcompartmentedしました。
6. SECURITY CONSIDERATIONS
6. セキュリティ問題
This entire memo discusses the Security Architecture for the Internet Protocol. It is not a general security architecture for the Internet, but is instead focused on the IP layer.
この全体のメモはインターネットプロトコルのためにSecurity Architectureについて議論します。 それは、インターネットへの一般的なセキュリティー体系ではありませんが、代わりにIP層に焦点を合わせられます。
Cryptographic transforms for ESP which use a block-chaining algorithm and lack a strong integrity mechanism are vulnerable to a cut-and- paste attack described by Bellovin and should not be used unless the Authentication Header is always present with packets using that ESP transform [Bel95].
そして、超能力のためのブロック連鎖アルゴリズムを使用して、強い保全メカニズムを欠いている暗号の変換がカットに被害を受け易い、-、-パケットがその超能力変換[Bel95]を使用していてAuthentication Headerがいつも存在しているというわけではないなら、ペーストの攻撃をBellovinが説明して、使用するべきではありません。
If more than one sender uses shares a Security Association with a destination, then the receiving system can only authenticate that the packet was sent from one of those systems and cannot authenticate which of those systems sent it. Similarly, if the receiving system does not check that the Security Association used for a packet is valid for the claimed Source Address of the packet, then the receiving system cannot authenticate whether the packet's claimed Source Address is valid. For example, if senders "A" and "B" each have their own unique Security Association with destination "D" and "B" uses its valid Security Association with D but forges a Source Address of "A", then "D" will be fooled into believing the packet came from "A" unless "D" verifies that the claimed Source Address is party to the Security Association that was used.
1人の送付者が使用する以上がSecurity Associationを共有するなら、目的地、受電方式が認証できるだけであるその時と共に、パケットがそれらのシステムの1つから送られて、それらのシステムについてどれを認証できないかがそれを送りました。 同様に、受電方式がそうしないなら、パケットの要求されたSource Addressには、Security Associationがパケットに使用したチェックは有効です、パケットが、Source Addressが有効であると主張したか否かに関係なく、受電方式が認証できないその時。 例えば、それぞれ送付者「A」と「B」には目的地「D」とのそれら自身のユニークなセキュリティ協会があって、「B」がDとの有効なセキュリティ協会を使用しますが、「A」のソースアドレスを偽造すると、「D」は「D」が、要求されたソースアドレスがパーティーであることを確かめない場合パケットが「A」から来たと信じているように使用されたセキュリティ協会にだまされるでしょう。
Users need to understand that the quality of the security provided by the mechanisms provided by these two IP security mechanisms depends completely on the strength of the implemented cryptographic algorithms, the strength of the key being used, the correct implementation of the cryptographic algorithms, the security of the key management protocol, and the correct implementation of IP and the several security mechanisms in all of the participating systems. The security of the implementation is in part related to the security of the operating system which embodies the security implementations. For example, if the operating system does not keep the private cryptologic keys (that is, all symmetric keys and the private asymmetric keys) confidential, then traffic using those keys will not be secure. If any of these is incorrect or insufficiently secure, little or no real security will be provided to the user. Because different users on the same system might not trust each other, each user or each session should usually be keyed separately. This will
ユーザは、これらの2台のIPセキュリティー対策によって提供されたメカニズムによって提供されたセキュリティの品質を完全参加システムのすべての実装している暗号アルゴリズムの強さ、使用されるキーの強さ、暗号アルゴリズムの正しい実装、かぎ管理プロトコルのセキュリティ、およびIPと数個のセキュリティー対策の正しい実装に依存するのを理解する必要があります; 実装のセキュリティはセキュリティ実装を具体化するオペレーティングシステムのセキュリティに一部関連します。 例えば、オペレーティングシステムが個人的なcryptologicキー(すなわち、すべての対称鍵と個人的な非対称のキー)を秘密に保たないと、それらのキーを使用するトラフィックが安全にならないでしょう。 これらのどれかが不正確であるか、または不十分に安全であるなら、物上担保はまずユーザに提供されないでしょう。 同じシステムの上の異なったユーザが互いを信じないかもしれないので、通常、各ユーザか各セッションが別々に合わせられるべきです。 これはそうするでしょう。
Atkinson Standards Track [Page 18] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[18ページ]。
also tend to increase the work required to cryptanalyse the traffic since not all traffic will use the same key.
また、主要な状態ですべてのトラフィックでないの以来のトラフィックが同じように使用するcryptanalyseに必要である仕事を増強する傾向があってください。
Certain security properties (e.g., traffic analysis protection) are not provided by any of these mechanisms. One possible approach to traffic analysis protection is appropriate use of link encryption [VK83]. Users must carefully consider which security properties they require and take active steps to ensure that their needs are met by these or other mechanisms.
あるセキュリティ資産(例えば、トラヒック分析保護)はこれらのメカニズムのいずれによっても提供されません。トラヒック分析保護への1つの可能なアプローチがリンク暗号化[VK83]が適切な使用です。 ユーザは、彼らがどのセキュリティの特性を必要とするかを慎重に考えて、彼らの需要がこれらか他のメカニズムによって満たされるのを保証するために積極的な手段を取らなければなりません。
Certain applications (e.g., electronic mail) probably need to have application-specific security mechanisms. Application-specific security mechanisms are out of the scope of this document. Users interested in electronic mail security should consult the RFCs describing the Internet's Privacy-Enhanced Mail system. Users concerned about other application-specific mechanisms should consult the online RFCs to see if suitable Internet Standard mechanisms exist.
あるアプリケーション(例えば、電子メール)はたぶんアプリケーション特有のセキュリティー対策を必要とします。このドキュメントの範囲の外にアプリケーション特有のセキュリティー対策があります。 電子メールセキュリティに興味を持っているユーザはインターネットのPrivacyによって高められたメールシステムについて説明するRFCsに相談するべきです。 他のアプリケーション特有のメカニズムに関して心配しているユーザは、適当なインターネットStandardメカニズムが存在するかどうか確認するためにオンラインRFCsに相談するべきです。
ACKNOWLEDGEMENTS
承認
Many of the concepts here are derived from or were influenced by the US Government's SDNS security protocol specifications, the ISO/IEC's NLSP specification, or from the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93]. The work done for SNMP Security and SNMPv2 Security influenced the choice of default cryptological algorithms and modes [GM93]. Steve Bellovin, Steve Deering, Richard Hale, George Kamis, Phil Karn, Frank Kastenholz, Perry Metzger, Dave Mihelcic, Hilarie Orman and Bill Simpson provided careful critiques of early versions of this document.
または、ここの概念の多くが派生する、米国政府のSDNSセキュリティプロトコル仕様、ISO/IECのNLSP仕様、または、提案されたswIPeセキュリティプロトコル[SDNS、ISO、IB93、IBK93]から影響を及ぼされました。 SNMP SecurityとSNMPv2 Securityのために行われた仕事はデフォルトcryptologicalアルゴリズムとモード[GM93]の選択に影響を及ぼしました。 スティーブBellovin、スティーブ・デアリング、リチャード・ヘール、ジョージKamis、フィルKarn、フランクKastenholz、ペリーメッツガー、デーヴMihelcic、Hilarie Orman、およびビル・シンプソンはこのドキュメントの早めのバージョンの慎重な批評を提供しました。
REFERENCES
参照
[Atk95a] Atkinson, R., "IP Authentication Header", RFC 1826, NRL,
August 1995.
[Atk95a] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、NRL、1995年8月。
[Atk95b] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
NRL, August 1995.
[Atk95b]アトキンソン、R.、「セキュリティが有効搭載量であるとカプセル化するIP」、RFC1827、NRL、1995年8月。
[BCCH94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
of IAB Workshop on Security in the Internet Architecture",
RFC 1636, USC/Information Sciences Institute, MIT, Trusted
Information Systems, INRIA, June 1994.
[BCCH94] ブレーデン、R.、クラーク、D.、クロッカー、S.、およびC.Huitema、「インターネットアーキテクチャにおけるセキュリティに関するIABワークショップのレポート」、RFC1636、USC/情報科学研究所(MIT)は情報システムを信じました、INRIA、1994年6月。
[Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP
Protocol Suite", ACM Computer Communications Review, Vol. 19,
No. 2, March 1989.
[Bel89]スティーブンM.Bellovin、ACMコンピュータコミュニケーションは「TCP/IPプロトコル群の警備上の問題」と見直します、Vol.19、No.2、1989年3月。
Atkinson Standards Track [Page 19] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[19ページ]。
[Bel95] Steven M. Bellovin, Presentation at IP Security Working
Group Meeting, Proceedings of the 32nd Internet Engineering
Task Force, March 1995, Internet Engineering Task Force,
Danvers, MA.
[Bel95]スティーブンM.Bellovin、IPセキュリティワーキンググループミーティングにおけるプレゼンテーション、第32インターネット・エンジニアリング・タスク・フォースの議事、1995年3月、インターネット・エンジニアリング・タスク・フォース、ダンバース、MA。
[BFC93] A. Ballardie, P. Francis, & J. Crocroft, "Core Based Trees:
An Architecture for Scalable Inter-Domain Multicast Routing",
Proceedings of ACM SIGCOMM 93, ACM Computer Communications
Review, Volume. 23, Number 4, October 1993, pp. 85-95.
[BFC93] A.Ballardie、P.フランシス、およびJ.Crocroft、「コアは木を基礎づけました」。 「スケーラブルな相互ドメインマルチキャストルート設定のためのアーキテクチャ」、ACM SIGCOMM93、ACMコンピュータコミュニケーションレビュー、ボリュームの議事。 23 Number4、1993年10月、ページ 85-95.
[BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems:
Mathematical Foundations and Model", Technical Report
M74-244, The MITRE Corporation, Bedford, MA, May 1973.
[BL73]ベルとD.E.とLaPadula、L.J.、「コンピュータシステムズを機密保護してください」 「数学の財団とモデル」、技術報告書M74-244、斜め継ぎ社、ベッドフォード、MAは1973がそうするかもしれません。
[CB94] William R. Cheswick & Steven M. Bellovin, Firewalls &
Internet Security, Addison-Wesley, Reading, MA, 1994.
[CB94]ウィリアムR.チェスウィックとスティーブンM.Bellovin、ファイアウォール、およびインターネットセキュリティ、アディソン-ウエスリー、読書、MA、1994。
[DIA] US Defense Intelligence Agency, "Compartmented Mode
Workstation Specification", Technical Report
DDS-2600-6243-87.
[DIA]米国国防情報庁、「Compartmentedモードワークステーション仕様」、技術報告書DDS-2600-6243-87。
[DoD85] US National Computer Security Center, "Department of Defense
Trusted Computer System Evaluation Criteria", DoD
5200.28-STD, US Department of Defense, Ft. Meade, MD.,
December 1985.
[DoD85]米国の国家のコンピュータセキュリティセンター、「国防総省はコンピュータシステム評価を信じました」、DoD 5200.28-STD、米国国防総省フィート ミード(MD)、12月1985日
[DoD87] US National Computer Security Center, "Trusted Network
Interpretation of the Trusted Computer System Evaluation
Criteria", NCSC-TG-005, Version 1, US Department of Defense,
Ft. Meade, MD., 31 July 1987.
[DoD87]米国の国家のコンピュータセキュリティセンター、「信じられたコンピュータシステム評価の信じられたネットワーク解釈」、NCSC-TG-005、バージョン1、米国国防総省、フィート ミード(MD)、1987年7月31日。
[DH76] W. Diffie & M. Hellman, "New Directions in Cryptography",
IEEE Transactions on Information Theory, Vol. IT-22, No. 6,
November 1976, pp. 644-654.
[DH76]W.ディフィーとM.ヘルマン、「暗号に関する新傾向」、情報Theoryの上のIEEE Transactions、Vol.IT-22、No.6、1976年11月、ページ 644-654.
[EK94] D. Eastlake III & C. Kaufman, "Domain Name System Protocol
Security Extensions", Work in Progress.
「ドメインネームシステムプロトコルセキュリティ拡大」という[EK94]D.イーストレークIIIとC.コーフマンは進行中で働いています。
[GM93] Galvin J., and K. McCloghrie, "Security Protocols for
version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN
Systems, April 1993.
[GM93] ガルビンJ.、およびK.McCloghrie、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためのセキュリティプロトコル」、RFC1446、Trusted情報システム、ヒューズLAN Systems(1993年4月)。
[HA94] Haller, N., and R. Atkinson, "On Internet Authentication",
RFC 1704, Bell Communications Research, NRL, October 1994.
[HA94] ハラー、N.とR.アトキンソン、「インターネット認証」、RFC1704、ベルコミュニケーションズ・リサーチ、NRL、1994年10月。
[Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6)
Specification, Work in Progress, October 1994.
[Hin94]ボブHinden(エディタ)、インターネットプロトコルバージョン6(IPv6)仕様、Progress、1994年10月のWork。
Atkinson Standards Track [Page 20] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[20ページ]。
[ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
DIS 11577, International Standards Organisation, Geneva,
Switzerland, 29 November 1992.
[ISO] ISO/IEC JTC1/SC6、ネットワーク層セキュリティプロトコル、ISO-IEC不-11577、世界規格機構、ジュネーブ(スイス)1992年11月29日。
[IB93] John Ioannidis and Matt Blaze, "Architecture and
Implementation of Network-layer Security Under Unix",
Proceedings of USENIX Security Symposium, Santa Clara, CA,
October 1993.
[IB93]のジョンIoannidisとマットBlazeと、「ネットワーク層セキュリティ下のunixのアーキテクチャと実装」、USENIXセキュリティシンポジウム(サンタクララ(カリフォルニア)1993年10月)の議事
[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer
Security for IP", presentation at the Spring 1993 IETF Meeting,
Columbus, Ohio.
[IBK93]ジョンIoannidis(マット炎、およびフィルKarn)は「以下を強打します」。 「IPのためのネットワーク層のSecurity」、Spring1993IETF Meeting、コロンブス、オハイオでのプレゼンテーション。
[Ken91] Kent, S., "US DoD Security Options for the Internet Protocol",
RFC 1108, BBN Communications, November 1991.
[Ken91] ケント、S.、「インターネットプロトコルのための米国のDoDセキュリティオプション」、RFC1108、BBNコミュニケーション、1991年11月。
[Ken93] Kent, S., "Privacy Enhancement for Internet Electronic Mail:
Part II: Certificate-Based Key Management", RFC 1422,
BBN Communications, February 1993.
[Ken93]ケント、S.、「インターネット電子メールのためのプライバシー増進:」 パートII: 「証明書ベースのKey Management」、RFC1422、BBNコミュニケーション、1993年2月。
[KB93] Kohl, J., and B. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, Digital Equipment Corporation,
USC/Information Sciences Institute, September 1993.
[KB93] コール、J.、およびB.ヌーマン、「ケルベロスは認証サービス(V5)をネットワークでつなぎます」、RFC1510、DEC、科学が設けるUSC/情報、1993年9月。
[MS95] Metzger, P., and W. Simpson, "IP Authentication with Keyed
MD5", RFC 1828, Piermont, Daydreamer, August 1995.
[MS95] メッツガー、P.とW.シンプソン、「合わせられたMD5"、RFC1828、ピアモント空想家、1995年8月とのIP認証。」
[KMS95] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC
Transform", RFC 1829, Qualcomm, Inc., Piermont, Daydreamer,
August 1995.
[KMS95]KarnとP.とメッツガー、P.とW.シンプソン、「DES-CBCが変える超能力」RFC1829、クアルコムInc.、ピアモント、空想家、1995年8月。
[NS78] R.M. Needham & M.D. Schroeder, "Using Encryption for
Authentication in Large Networks of Computers", Communications
of the ACM, Vol. 21, No. 12, December 1978, pp. 993-999.
[NS78]R.M.ニーダムとM.D.シュローダー、「認証にコンピュータの大きいネットワークに暗号化を使用します」、ACM、Vol.21、No.12、1978年12月、ページのCommunications 993-999.
[NS81] R.M. Needham & M.D. Schroeder, "Authentication Revisited",
ACM Operating Systems Review, Vol. 21, No. 1., 1981.
[NS81]R.M.ニーダムとM.D.シュローダー、「再訪した認証」、ACMオペレーティングシステムレビュー、Vol.21、No.1.、1981。
[OTA94] US Congress, Office of Technology Assessment, "Information
Security & Privacy in Network Environments", OTA-TCT-606,
Government Printing Office, Washington, DC, September 1994.
[OTA94] 米国議会、技術評価局、「ネットワーク環境における情報セキュリティとプライバシー」、OTA-TCT-606、政府印刷局のワシントン、DC(1994年9月)。
[Sch94] Bruce Schneier, Applied Cryptography, Section 8.6,
John Wiley & Sons, New York, NY, 1994.
[Sch94]ブルース・シュナイアー、適用された暗号、セクション8.6、ジョン・ワイリー、および息子、ニューヨーク(ニューヨーク)1994。
Atkinson Standards Track [Page 21] RFC 1825 Security Architecture for IP August 1995
アトキンソンStandardsは1995年8月にIPのためにRFC1825セキュリティー体系を追跡します[21ページ]。
[SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3,
Document SDN.301, Revision 1.5, 15 May 1989, published
in NIST Publication NIST-IR-90-4250, February 1990.
[SDNS]SDNS Secure Data Network System、Securityプロトコル3、SP3、Document SDN.301、Revision1.5(1989年5月15日)はNIST Publication NIST IR90-4250(1990年2月)で発行しました。
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level
Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
[VK83] L.VoydockとS.T.ケントに対して、ACMコンピューティングは、Vol.15、1983年6月No.日2に「ハイレベル・ネットワークにおけるセキュリティー対策」と調査します。
[ZDESZ93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and
D. Zappala, "RSVP: A New Resource ReSerVation Protocol",
IEEE Network magazine, September 1993.
[ZDESZ93] チャン、L.、デアリング、S.、Estrin、D.、Shenker、S.、およびD.Zappala、「RSVP:」 「New Resource ReSerVationプロトコル」、IEEE Network雑誌、1993年9月。
DISCLAIMER
注意書き
The views expressed in this note are those of the author and are not necessarily those of his employer. The Naval Research Laboratory has not passed judgement on the merits, if any, of this work. The author and his employer specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this design.
この注意で言い表された視点は、作者のものであり、必ず彼の雇い主のものであるというわけではありません。 海軍研究試験所はこの仕事についてもしあれば事実判決を通過していません。 作者と彼の雇い主はこのデザインの正しいか不正確な実装か使用から起こることにおけるどんな問題によっても明確に責任を拒否します。
AUTHOR'S ADDRESS
作者のアドレス
Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA
ランドルアトキンソン情報技術事業部海軍研究試験所ワシントン、DC20375-5320米国
Phone: (202) 767-2389 Fax: (202) 404-8590 EMail: atkinson@itd.nrl.navy.mil
以下に電話をしてください。 (202) 767-2389 Fax: (202) 404-8590 メールしてください: atkinson@itd.nrl.navy.mil
Atkinson Standards Track [Page 22]
アトキンソン標準化過程[22ページ]
一覧
スポンサーリンク
