RFC1827 日本語訳

Network Working Group                                        R. Atkinson
Request for Comments: 1827                     Naval Research Laboratory
Category: Standards Track                                    August 1995

コメントを求めるワーキンググループR.アトキンソン要求をネットワークでつないでください: 1827年の海軍研究試験所カテゴリ: 標準化過程1995年8月

                IP Encapsulating Security Payload (ESP)

セキュリティが有効搭載量であるとカプセル化するIP(超能力)

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)の現行版を参照してください。 このメモの分配は無制限です。

ABSTRACT

要約

   This document describes the IP Encapsulating Security Payload (ESP).
   ESP is a mechanism for providing integrity and confidentiality to IP
   datagrams.  In some circumstances it can also provide authentication
   to IP datagrams.  The mechanism works with both IPv4 and IPv6.

このドキュメントはIP Encapsulating Security有効搭載量(超能力)について説明します。 超能力は、保全と秘密性をIPデータグラムに供給するためのメカニズムです。また、いくつかの事情では、それはIPデータグラムに認証を供給できます。メカニズムはIPv4とIPv6の両方で動きます。

1. INTRODUCTION

1. 序論

   ESP is a mechanism for providing integrity and confidentiality to IP
   datagrams.  It may also provide authentication, depending on which
   algorithm and algorithm mode are used.  Non-repudiation and
   protection from traffic analysis are not provided by ESP.  The IP
   Authentication Header (AH) might provide non-repudiation if used with
   certain authentication algorithms [Atk95b].  The IP Authentication
   Header may be used in conjunction with ESP to provide authentication.
   Users desiring integrity and authentication without confidentiality
   should use the IP Authentication Header (AH) instead of ESP.  This
   document assumes that the reader is familiar with the related
   document "IP Security Architecture", which defines the overall
   Internet-layer security architecture for IPv4 and IPv6 and provides
   important background for this specification [Atk95a].

超能力は、保全と秘密性をIPデータグラムに供給するためのメカニズムです。また、認証を提供するかもしれません、どのアルゴリズムとアルゴリズムモードが使用されているかによって。 トラヒック分析からの非拒否と保護は超能力によって提供されません。 ある認証アルゴリズム[Atk95b]で使用されるなら、IP Authentication Header(AH)は非拒否を提供するかもしれません。 IP Authentication Headerは、認証を提供するのに超能力に関連して使用されるかもしれません。 秘密性なしで保全と認証を望んでいるユーザは超能力の代わりにIP Authentication Header(AH)を使用するべきです。 このドキュメントは、読者が「IPセキュリティー体系」という関連するドキュメントに詳しいと仮定します。(それは、IPv4とIPv6のために総合的なインターネット層のセキュリティー体系を定義して、この仕様[Atk95a]に重要なバックグラウンドを提供します)。

1.1 Overview

1.1 概要

   The IP Encapsulating Security Payload (ESP) seeks to provide
   confidentiality and integrity by encrypting data to be protected and
   placing the encrypted data in the data portion of the IP
   Encapsulating Security Payload.  Depending on the user's security
   requirements, this mechanism may be used to encrypt either a
   transport-layer segment (e.g., TCP, UDP, ICMP, IGMP) or an entire IP
   datagram.  Encapsulating the protected data is necessary to provide
   confidentiality for the entire original datagram.

IP Encapsulating Security有効搭載量(超能力)は、IP Encapsulating Security有効搭載量のデータ部に保護されるためにデータを暗号化して、暗号化されたデータを置くことによって、秘密性と保全を提供しようとします。 ユーザのセキュリティ要件によって、このメカニズムは、トランスポート層セグメント(例えば、TCP、UDP、ICMP、IGMP)か全体のIPデータグラムのどちらかを暗号化するのに使用されるかもしれません。 保護されたデータをカプセル化するのが、全体のオリジナルのデータグラムに秘密性を供給するのに必要です。

Atkinson                    Standards Track                     [Page 1]

RFC 1827             Encapsulating Security Payload          August 1995

1995年8月にセキュリティが有効搭載量であるとカプセル化するアトキンソン標準化過程[1ページ]RFC1827

   Use of this specification 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 encryption and decryption required for each IP datagram
   containing an Encapsulating Security Payload.

この仕様の使用は、参加システムのIPプロトコル処理コストを増強して、また、コミュニケーション潜在を増強するでしょう。 増強された潜在は主としてEncapsulating Security有効搭載量を含むそれぞれのIPデータグラムに必要である暗号化と復号化のためです。

   In Tunnel-mode ESP, the original IP datagram is placed in the
   encrypted portion of the Encapsulating Security Payload and that
   entire ESP frame is placed within a datagram having unencrypted IP
   headers.  The information in the unencrypted IP headers is used to
   route the secure datagram from origin to destination. An unencrypted
   IP Routing Header might be included between the IP Header and the
   Encapsulating Security Payload.

Tunnel-モードで、超能力、オリジナルのIPデータグラムはEncapsulating Security有効搭載量の暗号化された部分に置かれます、そして、IPヘッダーを非暗号化して、その全体の超能力フレームはデータグラムの中に置かれます。 非暗号化されたIPヘッダーの情報は、発生源から目的地まで安全なデータグラムを発送するのに使用されます。 非暗号化されたIPルート設定HeaderはIP HeaderとEncapsulating Security有効搭載量の間に含まれるかもしれません。

   In Transport-mode ESP, the ESP header is inserted into the IP
   datagram immediately prior to the transport-layer protocol header
   (e.g., TCP, UDP, or ICMP). In this mode bandwidth is conserved
   because there are no encrypted IP headers or IP options.

超能力、Transport-モードによる超能力ヘッダーはトランスポート層プロトコルヘッダー(例えば、TCP、UDP、またはICMP)のすぐ前でIPデータグラムに挿入されます。 このモードで、どんな暗号化されたIPヘッダーもIPオプションもないので、帯域幅は保存されます。

   In the case of IP, an IP Authentication Header may be present as a
   header of an unencrypted IP packet, as a header after the IP header
   and before the ESP header in a Transport-mode ESP packet, and also as
   a header within the encrypted portion of a Tunnel-mode ESP packet.
   When AH is present both in the cleartext IP header and also inside a
   Tunnel-mode ESP header of a single packet, the unencrypted IPv6
   Authentication Header is primarily used to provide protection for the
   contents of the unencrypted IP headers and the encrypted
   Authentication Header is used to provide authentication only for the
   encrypted IP packet.  This is discussed in more detail later in this
   document.

IPの場合では、IP Authentication Headerは非暗号化されたIPパケットのヘッダーとして存在しているかもしれません、Transport-モード超能力パケットと、Tunnel-モード超能力パケットの暗号化された部分の中のヘッダーとしてもIPヘッダーの後と超能力ヘッダーの前のヘッダーとして。 AHがcleartext IPヘッダーと単一のパケットのTunnel-モード超能力ヘッダーの中にも存在しているとき、unencrypted IPv6 Authentication Headerは非暗号化されたIPヘッダーのコンテンツのための保護を提供するのに主として使用されます、そして、暗号化されたAuthentication Headerは、暗号化されたIPパケットのためだけの認証を提供するのに使用されます。 さらに詳細に後で本書ではこれについて議論します。

   The Encapsulating Security Payload is structured a bit differently
   than other IP payloads. The first component of the ESP payload
   consist of the unencrypted field(s) of the payload.  The second
   component consists of encrypted data.  The field(s) of the
   unencrypted ESP header inform the intended receiver how to properly
   decrypt and process the encrypted data.  The encrypted data component
   includes protected fields for the security protocol and also the
   encrypted encapsulated IP datagram.

Encapsulating Security有効搭載量は他のIPペイロードと異なって少し構造化されます。 超能力ペイロードの最初の部品はペイロードの非暗号化された分野から成ります。 2番目のコンポーネントは暗号化されたデータから成ります。 非暗号化された超能力ヘッダーの分野はどのように適切に暗号化されたデータを解読して、処理するかを所定の受信者に知らせます。 暗号化されたデータ構成要素はセキュリティプロトコルと暗号化されたカプセル化されたIPデータグラムのために保護電界をも含んでいます。

   The concept of a "Security Association" is fundamental to ESP.  It is
   described in detail in the companion document "Security Architecture
   for the Internet Protocol" which is incorporated here by reference
   [Atk95a].  Implementors should read that document before reading this
   one.

「セキュリティ協会」の概念は超能力に基本的です。 参照[Atk95a]でそれはここで法人組織であることの「インターネットプロトコルのためのセキュリティー体系」という仲間ドキュメントで詳細に説明されます。 これを読む前に、作成者はそのドキュメントを読むべきです。

Atkinson                    Standards Track                     [Page 2]

RFC 1827             Encapsulating Security Payload          August 1995

1995年8月にセキュリティが有効搭載量であるとカプセル化するアトキンソン標準化過程[2ページ]RFC1827

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つのベンダーが、項目を含んでいるのを選ぶかもしれません。 別のベンダーは同じ項目を省略するかもしれません。

2. KEY MANAGEMENT

2. かぎ管理

   Key management is an important part of the IP security architecture.
   However, a specific key management protocol is not included in this
   specification because of a long history in the public literature of
   subtle flaws in key management algorithms and protocols.  IP tries to
   decouple the key management mechanisms from the security protocol
   mechanisms.  The only coupling between the key management protocol
   and the security protocol is with the Security Parameter Index (SPI),
   which is described in more detail below.  This decoupling permits
   several different key management mechanisms to be used.  More
   importantly, it permits the key management protocol to be changed or
   corrected without unduly impacting the security protocol
   implementations. Thus, a key management protocol for IP is not
   specified within this memo.  The IP Security Architecture describes
   key management in more detail and specifies the key management
   requirements for IP.  Those key management requirements are
   incorporated here by reference [Atk95a].

かぎ管理はIPセキュリティー体系の重要な部分です。 しかしながら、特定のかぎ管理プロトコルは長い歴史のために微妙な欠点の公共の文学にこの仕様にかぎ管理アルゴリズムとプロトコルで含まれていません。 IPはセキュリティプロトコルメカニズムからかぎ管理メカニズムの衝撃を吸収しようとします。かぎ管理プロトコルとセキュリティプロトコルの間の唯一のカップリングがSecurity Parameter Index(SPI)と共にあります。(Security Parameter Indexはさらに詳細に以下で説明されます)。 このデカップリングは、数個の異なったかぎ管理メカニズムが使用されることを許可します。 より重要に、それは、セキュリティプロトコル実装に過度に影響を与えないでかぎ管理プロトコルを変えるか、または修正するのを許容します。 したがって、IPのためのかぎ管理プロトコルはこのメモの中で指定されません。 IP Security Architectureはさらに詳細にかぎ管理を説明して、IPのためのかぎ管理要件を指定します。 参照[Atk95a]でそれらのかぎ管理要件はここに組み込まれます。

   The key management mechanism is used to negotiate a number of
   parameters for each security association, including not only the keys
   but other information (e.g., the cryptographic algorithms and modes,

かぎ管理メカニズムはそれぞれのセキュリティ協会のための多くのパラメタを交渉するのに使用されます、キーだけではなく、他の情報も含んでいて(例えば、暗号アルゴリズムとモード

Atkinson                    Standards Track                     [Page 3]

RFC 1827             Encapsulating Security Payload          August 1995

1995年8月にセキュリティが有効搭載量であるとカプセル化するアトキンソン標準化過程[3ページ]RFC1827

   security classification level, if any) used by the communicating
   parties.  The key management protocol implementation usually creates
   and maintains a logical table containing the several parameters for
   each current security association. An ESP implementation normally
   needs to read that security parameter table to determine how to
   process each datagram containing an ESP (e.g., which algorithm/mode
   and key to use).

分類がもしあれば平らにするセキュリティ) 交信パーティーによって使用されます。 通常、かぎ管理プロトコル実装は、それぞれの現在のセキュリティ協会のためのいくつかのパラメタを含む論理的なテーブルを、作成して、維持します。 通常、超能力実装は、超能力を含む各データグラムを処理する(例えば、どのアルゴリズム/モードとキーを使用したらよいですか)方法を決定するためにそのセキュリティパラメータ・テーブルを読む必要があります。

3. ENCAPSULATING SECURITY PAYLOAD SYNTAX

3. セキュリティがペイロード構文であるとカプセル化します。

   The Encapsulating Security Payload (ESP) may appear anywhere after
   the IP header and before the final transport-layer protocol.  The
   Internet Assigned Numbers Authority has assigned Protocol Number 50
   to ESP [STD-2].  The header immediately preceding an ESP header will
   always contain the value 50 in its Next Header (IPv6) or Protocol
   (IPv4) field.  ESP consists of an unencrypted header followed by
   encrypted data.  The encrypted data includes both the protected ESP
   header fields and the protected user data, which is either an entire
   IP datagram or an upper-layer protocol frame (e.g., TCP or UDP).  A
   high-level diagram of a secure IP datagram follows.

Encapsulating Security有効搭載量(超能力)はIPヘッダーの後と最終的なトランスポート層プロトコルの前にどこでも現れるかもしれません。 インターネットAssigned民数記Authorityは超能力[STD-2]にプロトコルNumber50を割り当てました。 すぐに超能力ヘッダーに先行するヘッダーはNext Header(IPv6)かプロトコル(IPv4)分野にいつも値50を保管するでしょう。 超能力は暗号化されたデータがあとに続いた非暗号化されたヘッダーから成ります。 暗号化されたデータは両方の保護された超能力ヘッダーフィールドと保護された利用者データ(例えば、TCPかUDP)を含んでいます。(全体のIPデータグラムか利用者データは上側の層のプロトコルフレームのどちらかです)。 安全なIPデータグラムのハイレベルのダイヤグラムは従います。

  |<--        Unencrypted              -->|<----    Encrypted   ------>|
  +-------------+--------------------+------------+---------------------+
  | IP Header   | Other IP Headers   | ESP Header | encrypted data      |
  +-------------+--------------------+------------+---------------------+

| <--Unencryptedしました-->| <、-、-、-- 暗号化されます。------>| +-------------+--------------------+------------+---------------------+ | IPヘッダー| 他のIPヘッダー| 超能力ヘッダー| 暗号化されたデータ| +-------------+--------------------+------------+---------------------+

   A more detailed diagram of the ESP Header follows below.

超能力Headerの、より詳細なダイヤグラムは以下に従います。

  +-------------+--------------------+------------+---------------------+
  |             Security Association Identifier (SPI), 32 bits          |
  +=============+====================+============+=====================+
  |             Opaque Transform Data, variable length                  |
  +-------------+--------------------+------------+---------------------+

+-------------+--------------------+------------+---------------------+ | セキュリティAssociation Identifier(SPI)、32ビット| +=============+====================+============+=====================+ | 不透明なTransform Data、可変長| +-------------+--------------------+------------+---------------------+

   Encryption and authentication algorithms, and the precise format of
   the Opaque Transform Data associated with them are known as
   "transforms".  The ESP format is designed to support new transforms
   in the future to support new or additional cryptographic algorithms.
   The transforms are specified by themselves rather than in the main
   body of this specification.  The mandatory transform for use with IP
   is defined in a separate document [KMS95].  Other optional transforms
   exist in other separate specifications and additional transforms
   might be defined in the future.

暗号化と認証アルゴリズム、およびそれらに関連しているOpaque Transform Dataの正確な形式はそうです。「変形」として、知られています。 超能力形式は、将来新しいか追加している暗号アルゴリズムをサポートするために新しい変換をサポートするように設計されています。変換はこの仕様の本体でというよりむしろ自分たちで指定されます。 IPとの使用のための義務的な変換は別々のドキュメント[KMS95]で定義されます。 他の任意の変換は他の別々の仕様に存在しています、そして、追加変換は将来、定義されるかもしれません。

Atkinson                    Standards Track                     [Page 4]

RFC 1827             Encapsulating Security Payload          August 1995

1995年8月にセキュリティが有効搭載量であるとカプセル化するアトキンソン標準化過程[4ページ]RFC1827

3.1 Fields of the Encapsulating Security Payload

3.1 要約のセキュリティ有効搭載量のフィールズ

   The SPI is a 32-bit pseudo-random value identifying the security
   association for this datagram.  If no security association has been
   established, the value of the SPI field shall be 0x00000000.   An SPI
   is similar to the SAID used in other security protocols.  The name
   has been changed because the semantics used here are not exactly the
   same as those used in other security protocols.

SPIはこのデータグラムのためにセキュリティ協会を特定する32ビットの擬似ランダム値です。 セキュリティ協会が全く設立されていないと、SPI分野の値は0×00000000になるでしょう。 SPIは他のセキュリティプロトコルの中古であるサイードと同様です。 ここで使用された意味論がまさにものが他のセキュリティにプロトコルを使用したのと同じでないので、名前を変えました。

   The set of SPI values in the range 0x00000001 though 0x000000FF are
   reserved to the Internet Assigned Numbers Authority (IANA) for future
   use.  A reserved SPI value will not normally be assigned by IANA
   unless the use of that particular assigned SPI value is openly
   specified in an RFC.

インターネットAssigned民数記Authority(IANA)への0x000000FFは今後の使用のために予約されますが、SPIのセットは範囲で0×00000001を評価します。 その特定の割り当てられたSPI価値の使用がRFCでオープンに指定されないと、通常、予約されたSPI値はIANAによって割り当てられないでしょう。

   The SPI is the only mandatory transform-independent field.
   Particular transforms may have other fields unique to the transform.
   Transforms are not specified in this document.

SPIは唯一の義務的な変換から独立している分野です。 特定の変換で、他の分野は変換にユニークになるかもしれません。 変換は本書では指定されません。

3.2 Security Labeling with ESP

3.2 超能力とのセキュリティラベリング

   The encrypted IP datagram need not and does not normally contain any
   explicit Security Label because the SPI indicates the sensitivity
   level.  This is an improvement over the current practices with IPv4
   where an explicit Sensitivity Label is normally used with
   Compartmented Mode Workstations and other systems requiring Security
   Labels [Ken91] [DIA].  In some situations, users MAY choose to carry
   explicit labels (for example, IPSO labels as defined by RFC-1108
   might be used with IPv4) in addition to using the implicit labels
   provided by ESP.  Explicit label options could be defined for use
   with IPv6 (e.g., using the IPv6 End-to-End Options Header or the IPv6
   Hop-by-Hop Options Header).  Implementations MAY support explicit
   labels in addition to implicit labels, but implementations are not
   required to support explicit labels.  Implementations of ESP in
   systems claiming to provide multi-level security MUST support
   implicit labels.

SPIが感度レベルを示すので、暗号化されたIPデータグラムは、少しも含んでいて、通常、少しの明白なSecurity Labelも含む必要はありません。 これは通常、明白なSensitivity LabelがCompartmented Mode Workstationsと共に使用されるIPv4と他のシステムがSecurity Labels[Ken91][DIA]を必要とすることの現在の実務の上の改良です。 いくつかの状況で、ユーザは、超能力によって提供された内在しているラベルを使用することに加えて明白なラベル(例えば、RFC-1108によって定義されるIPSOラベルはIPv4と共に使用されるかもしれない)を運ぶのを選ぶかもしれません。 IPv6(例えば、IPv6 Endから終わりへのOptions HeaderかホップによるIPv6 Hop Options Headerを使用する)との使用のために明白なラベルオプションを定義できました。 実装は内在しているラベルに加えて明白なラベルを支えるかもしれませんが、実装は、明白なラベルを支えるのに必要ではありません。 マルチレベルセキュリティを提供すると主張するシステムにおける超能力の実装は内在しているラベルを支えなければなりません。

4. ENCAPSULATING SECURITY PROTOCOL PROCESSING

4. セキュリティがプロトコル処理であるとカプセル化します。

   This section describes the steps taken when ESP is in use between two
   communicating parties.  Multicast is different from unicast only in
   the area of key management (See the definition of the SPI, above, for
   more detail on this).  There are two modes of use for ESP.  The first
   mode, which is called "Tunnel-mode", encapsulates an entire IP
   datagram inside ESP.  The second mode, which is called "Transport-
   Mode", encapsulates a transport-layer (e.g., UDP, TCP) frame inside
   ESP.  The term "Transport-mode" must not be misconstrued as
   restricting its use to TCP and UDP. For example, an ICMP message MAY

このセクションはパーティーを伝える超能力が2の間で使用中であるときに取られた方法を説明します。 マルチキャストはかぎ管理の領域だけのユニキャストと異なっています(上のSPIの定義を見てください、これに関するその他の詳細のために)。 超能力において、役に立つ2つのモードがあります。 最初のモード(「トンネルモード」と呼ばれる)は超能力の中で全体のIPデータグラムをカプセル化します。 2番目のモード(「輸送モード」と呼ばれる)は超能力の中でトランスポート層(例えば、UDP、TCP)フレームをカプセル化します。 使用をTCPとUDPに制限するのを「交通機関」という用語に誤解してはいけません。 例えば、ICMPメッセージはそうするかもしれません。

Atkinson                    Standards Track                     [Page 5]

RFC 1827             Encapsulating Security Payload          August 1995

1995年8月にセキュリティが有効搭載量であるとカプセル化するアトキンソン標準化過程[5ページ]RFC1827

   be sent either using the "Transport-mode" or the "Tunnel-mode"
   depending upon circumstance.  ESP processing occurs prior to IP
   fragmentation on output and after IP reassembly on input.  This
   section describes protocol processing for each of these two modes.

状況によって、「交通機関」を使用するか、「トンネルモード」のどちらかを送ってください。 超能力処理は入力のときに出力とIP再アセンブリの後にIP断片化の前に起こります。 このセクションはそれぞれのこれらの2つのモードのためのプロトコル処理について説明します。

4.1 ESP in Tunnel-mode

4.1 トンネルモードにおける超能力

   In Tunnel-mode ESP, the ESP header follows all of the end-to-end
   headers (e.g., Authentication Header, if present in cleartext) and
   immediately precedes an tunnelled IP datagram.

超能力、Tunnel-モードによる超能力ヘッダーは、終わりから終わりへのヘッダー(例えば、Authentication Header、プレゼントであるなら、コネはcleartextされる)の皆、後をつけて、すぐに、トンネルを堀られたIPデータグラムに先行します。

   The sender takes the original IP datagram, encapsulates it into the
   ESP, uses at least the sending userid and Destination Address as data
   to locate the correct Security Association, and then applies the
   appropriate encryption transform.  If host-oriented keying is in use,
   then all sending userids on a given system will have the same
   Security Association for a given Destination Address.  If no key has
   been established, then the key management mechanism is used to
   establish an encryption key for this communications session prior to
   the use of ESP.  The (now encrypted) ESP is then encapsulated in a
   cleartext IP datagram as the last payload.  If strict red/black
   separation is being enforced, then the addressing and other
   information in the cleartext IP headers and optional payloads MAY be
   different from the values contained in the (now encrypted and
   encapsulated) original datagram.

送付者は、オリジナルのIPデータグラムを取って、超能力にそれをカプセル化して、正しいSecurity Associationの場所を見つけるのにデータとして少なくとも送付ユーザIDとDestination Addressを使用して、次に、適切な暗号化変換を適用します。 ホスト指向の合わせるのが使用中であるなら、与えられたシステムの上のすべての送付ユーザIDには、同じSecurity Associationが与えられたDestination Addressのためにあるでしょう。 キーが全く設立されていないなら、かぎ管理メカニズムは、超能力の使用の前にこのコミュニケーションセッションのために主要な暗号化を証明するのに使用されます。 そして、(現在、暗号化されています)の超能力は最後のペイロードとしてcleartext IPデータグラムでカプセル化されます。 厳しい赤の、または、黒い分離が励行されていると、cleartext IPヘッダーと任意のペイロードのアドレシングと他の情報は(現在、暗号化されて、カプセル化されます)オリジナルのデータグラムに含まれた値と異なっているかもしれません。

   The receiver strips off the cleartext IP header and cleartext
   optional IP payloads (if any) and discards them.  It then uses the
   combination of Destination Address and SPI value to locate the
   correct session key to use for this packet.  It then decrypts the ESP
   using the session key that was just located for this packet.

受信機は、cleartext IPヘッダーとcleartextの任意のIPペイロード(もしあれば)を全部はぎ取って、それらを捨てます。 そして、それは、このパケットに使用するために主要な正しいセッションの場所を見つけるのにDestination AddressとSPI価値の組み合わせを使用します。 そして、それは、このパケットのためにただ見つけられたセッションキーを使用することで超能力を解読します。

   If no valid Security Association exists for this session (for
   example, the receiver has no key), the receiver MUST discard the
   encrypted ESP and the failure MUST be recorded in the system log or
   audit log.  This system log or audit log entry SHOULD include the SPI
   value, date/time, cleartext Sending Address, cleartext Destination
   Address, and the cleartext Flow ID.  The log entry MAY also include
   other identifying data.  The receiver might not wish to react by
   immediately informing the sender of this failure because of the
   strong potential for easy-to-exploit denial of service attacks.

どんな有効なSecurity Associationもこのセッションのために存在していないなら(例えば、受信機には、キーが全くありません)、受信機は暗号化された超能力を捨てなければなりません、そして、システムログか監査ログに失敗を記録しなければなりません。 このシステムログか監査ログエントリーSHOULDがSPI値、日付/時間、cleartext Sending Address、cleartext Destination Address、およびcleartext Flow IDを含んでいます。 また、ログエントリーは他の特定データを含むかもしれません。 受信機は、すぐにまでに利用しやすいサービス不能攻撃の強い可能性のためにこの失敗について送付者に知らせながら、反応したがっていないかもしれません。

   If decryption succeeds, the original IP datagram is then removed from
   the (now decrypted) ESP.  This original IP datagram is then processed
   as per the normal IP protocol specification.  In the case of system
   claiming to provide multilevel security (for example, a B1 or
   Compartmented Mode Workstation) additional appropriate mandatory
   access controls MUST be applied based on the security level of the

復号化が成功するなら、オリジナルのIPデータグラムは(現在、解読されます)の超能力から取り外されます。 そして、このオリジナルのIPデータグラムは正常なIPプロトコル仕様に従って処理されます。 多レベルセキュリティ(例えば、B1かCompartmented Mode Workstation)を提供すると主張するシステムの場合では、セキュリティに基づいて平らな状態で追加適切な義務的なアクセス制御を適用しなければなりません。

Atkinson                    Standards Track                     [Page 6]

RFC 1827             Encapsulating Security Payload          August 1995

1995年8月にセキュリティが有効搭載量であるとカプセル化するアトキンソン標準化過程[6ページ]RFC1827

   receiving process and the security level associated with this
   Security Association.  If those mandatory access controls fail, then
   the packet SHOULD be discarded and the failure SHOULD be logged using
   implementation-specific procedures.

プロセスとこのSecurity Associationに関連しているセキュリティー・レベルを取ります。 アクセス制御が失敗して、次に、パケットがSHOULDであることが義務的なそれらが捨てられて失敗SHOULDであるなら、実装特有の手順を用いることで、登録されてください。

4.2 ESP in Transport-mode

4.2 交通機関における超能力

   In Transport-mode ESP, the ESP header follows the end-to-end headers
   (e.g., Authentication Header) and immediately precedes a transport-
   layer (e.g., UDP, TCP, ICMP) header.

超能力、Transport-モードによる超能力ヘッダーは、終わりから終わりへのヘッダー(例えば、Authentication Header)について来て、すぐに、輸送層(例えば、UDP、TCP、ICMP)のヘッダーに先行します。

   The sender takes the original transport-layer (e.g., UDP, TCP, ICMP)
   frame, encapsulates it into the ESP, uses at least the sending userid
   and Destination Address to locate the appropriate Security
   Association, and then applies the appropriate encryption transform.
   If host-oriented keying is in use, then all sending userids on a
   given system will have the same Security Association for a given
   Destination Address. If no key has been established, then the key
   management mechanism is used to establish a encryption key for this
   communications session prior to the encryption.  The (now encrypted)
   ESP is then encapsulated as the last payload of a cleartext IP
   datagram.

送付者は、オリジナルのトランスポート層(例えば、UDP、TCP、ICMP)フレームを取って、超能力にそれをカプセル化して、適切なSecurity Associationの場所を見つけるのに少なくとも送付ユーザIDとDestination Addressを使用して、次に、適切な暗号化変換を適用します。 ホスト指向の合わせるのが使用中であるなら、与えられたシステムの上のすべての送付ユーザIDには、同じSecurity Associationが与えられたDestination Addressのためにあるでしょう。 キーが全く設立されていないなら、かぎ管理メカニズムは、暗号化の前にこのコミュニケーションセッションのために主要な暗号化を証明するのに使用されます。 そして、(現在、暗号化されています)の超能力はcleartext IPデータグラムの最後のペイロードとしてカプセル化されます。

   The receiver processes the cleartext IP header and cleartext optional
   IP headers (if any) and temporarily stores pertinent information
   (e.g., source and destination addresses, Flow ID, Routing Header).
   It then decrypts the ESP using the session key that has been
   established for this traffic, using the combination of the
   destination address and the packet's Security Association Identifier
   (SPI) to locate the correct key.

受信機は、(もしあれば)cleartext IPヘッダーとcleartextの任意のIPヘッダーを処理して、一時、適切な情報(例えば、ソースと送付先アドレス、Flow ID、ルート設定Header)を保存します。 次に、それはこのトラフィックのために設立されたセッションキーを使用することで超能力を解読します、正しいキーの場所を見つけるのに送付先アドレスとパケットのSecurity Association Identifier(SPI)の組み合わせを使用して。

   If no key exists for this session or the attempt to decrypt fails,
   the encrypted ESP MUST be discarded and the failure MUST be recorded
   in the system log or audit log.  If such a failure occurs, the
   recorded log data SHOULD include the SPI value, date/time received,
   clear-text Sending Address, clear-text Destination Address, and the
   Flow ID.  The log data MAY also include other information about the
   failed packet.  If decryption does not work properly for some reason,
   then the resulting data will not be parsable by the implementation's
   protocol engine.  Hence, failed decryption is generally detectable.

キーが全くこのセッションのために存在していないか、または解読する試みが失敗するなら、暗号化された超能力を捨てなければなりません、そして、システムログか監査ログに失敗を記録しなければなりません。 そのような失敗が起こるなら、記録されたログデータSHOULDはSPI値、日付/受付時刻、クリアテキストSending Address、クリアテキストDestination Address、およびFlow IDを含んでいます。 また、ログデータは失敗したパケットの他の情報を含むかもしれません。 復号化が適切にある理由で働いていないと、結果として起こるデータは実装のプロトコルエンジンで「パー-可能」にならないでしょう。 したがって、一般に、失敗した復号化は検出可能です。

   If decryption succeeds, the original transport-layer (e.g., UDP, TCP,
   ICMP) frame is removed from the (now decrypted) ESP.  The information
   from the cleartext IP header and the now decrypted transport-layer
   header is jointly used to determine which application the data should
   be sent to.  The data is then sent along to the appropriate
   application as normally per IP protocol specification.  In the case
   of a system claiming to provide multilevel security (for example, a

復号化が成功するなら、オリジナルのトランスポート層(例えば、UDP、TCP、ICMP)フレームは(現在、解読されます)の超能力から取り外されます。 cleartext IPヘッダーと現在解読されたトランスポート層ヘッダーからの情報は、データがどのアプリケーションに送られるべきであるかを決定するのに共同で使用されます。 そして、通常IPプロトコル仕様のように適切なアプリケーションにデータを送ります。 多レベルセキュリティを提供すると主張するシステムに関するケース、(例えば、a

Atkinson                    Standards Track                     [Page 7]

RFC 1827             Encapsulating Security Payload          August 1995

1995年8月にセキュリティが有効搭載量であるとカプセル化するアトキンソン標準化過程[7ページ]RFC1827

   B1 or Compartmented Mode Workstation), additional Mandatory Access
   Controls MUST be applied based on the security level of the receiving
   process and the security level of the received packet's Security
   Association.

B1かCompartmented Mode Workstation)、受信プロセスのセキュリティー・レベルと容認されたパケットのSecurity Associationのセキュリティー・レベルに基づいて追加Mandatory Access Controlsを適用しなければなりません。

4.3. Authentication

4.3. 認証

   Some transforms provide authentication as well as confidentiality and
   integrity.  When such a transform is not used, then the
   Authentication Header might be used in conjunction with the
   Encapsulating Security Payload.  There are two different approaches
   to using the Authentication Header with ESP, depending on which data
   is to be authenticated.  The location of the Authentication Header
   makes it clear which set of data is being authenticated.

いくつかの変換が秘密性と保全と同様に認証を提供します。 そのような変換が使用されていないと、Authentication HeaderはEncapsulating Security有効搭載量に関連して使用されるかもしれません。 認証されるかにどのデータがことであるよって、超能力を伴うAuthentication Headerを使用することへの2つの異なるアプローチがあります。 Authentication Headerの位置は、どのセットのデータが認証されているかを断言します。

   In the first usage, the entire received datagram is authenticated,
   including both the encrypted and unencrypted portions, while only the
   data sent after the ESP Header is confidential.  In this usage, the
   sender first applies ESP to the data being protected.  Then the other
   plaintext IP headers are prepended to the ESP header and its now
   encrypted data. Finally, the IP Authentication Header is calculated
   over the resulting datagram according to the normal method.  Upon
   receipt, the receiver first verifies the authenticity of the entire
   datagram using the normal IP Authentication Header process.  Then if
   authentication succeeds, decryption using the normal IP ESP process
   occurs.  If decryption is successful, then the resulting data is
   passed up to the upper layer.

最初の用法で、全体の容認されたデータグラムは認証されます、暗号化されて非暗号化された部分を含んでいて、超能力Headerが秘密になった後にデータだけが発信しましたが。 この用法で、送付者は最初に、保護されるデータに超能力を適用します。 そして、他の平文IPヘッダーは超能力ヘッダーとその現在暗号化されたデータにprependedされます。 最終的に、正常なメソッドによると、IP Authentication Headerは結果として起こるデータグラムの上に計算されます。 領収書では、受信機は、最初に、正常なIP Authentication Headerプロセスを使用することで全体のデータグラムの信憑性について確かめます。 そして、認証が成功するなら、正常なIP超能力プロセスを使用する復号化が起こります。 復号化がうまくいくなら、結果として起こるデータは上側の層まで通過されます。

   If the authentication process were to be applied only to the data
   protected by Tunnel-mode ESP, then the IP Authentication Header would
   be placed normally within that protected datagram.  However, if one
   were using Transport-mode ESP, then the IP Authentication Header
   would be placed before the ESP header and would be calculated across
   the entire IP datagram.

データだけに、超能力は認証過程が適用されることであったならTunnel-モードで保護されていて、次に、通常、IP Authentication Headerはその保護されたデータグラムの中に置かれるでしょう。 しかしながら、1であるなら、Transport-モードを使用するのが、超能力であるなら、次に、IP Authentication Headerは超能力ヘッダーの前に置かれて、全体のIPデータグラムの向こう側に計算されるでしょうに。

   If the Authentication Header is encapsulated within a Tunnel-mode ESP
   header, and both headers have specific security classification levels
   associated with them, and the two security classification levels are
   not identical, then an error has occurred.  That error SHOULD be
   recorded in the system log or audit log using the procedures
   described previously.  It is not necessarily an error for an
   Authentication Header located outside of the ESP header to have a
   different security classification level than the ESP header's
   classification level.  This might be valid because the cleartext IP
   headers might have a different classification level after the data
   has been encrypted using ESP.

Authentication HeaderがTunnel-モード超能力ヘッダーの中にカプセル化されて、両方のヘッダーにはそれらに関連している特定のセキュリティ分類レベルがあって、2つのセキュリティ分類レベルが同じでないなら、誤りは発生しました。 その誤りSHOULDは、システムログに記録されるか、または以前に説明された手順を用いることでログを監査します。 異なったセキュリティ分類レベルを持つのは、必ず超能力ヘッダーの分類レベルより超能力ヘッダーの外に位置したAuthentication Headerための誤りであるというわけではありません。 超能力を使用することでデータを暗号化してある後にcleartext IPヘッダーには異なった分類レベルがあるかもしれないので、これは有効であるかもしれません。

Atkinson                    Standards Track                     [Page 8]

RFC 1827             Encapsulating Security Payload          August 1995

1995年8月にセキュリティが有効搭載量であるとカプセル化するアトキンソン標準化過程[8ページ]RFC1827

5. CONFORMANCE REQUIREMENTS

5. 順応要件

   Implementations that claim conformance or compliance with this
   specification MUST fully implement the header described here, MUST
   support manual key distribution with this header, MUST comply with
   all requirements of the "Security Architecture for the Internet
   Protocol" [Atk95a], and MUST support the use of DES CBC as specified
   in the companion document entitled "The ESP DES-CBC Transform"
   [KMS95].  Implementors MAY also implement other ESP transforms.
   Implementers should consult the most recent version of the "IAB
   Official Standards" RFC for further guidance on the status of this
   document.

この仕様への順応か承諾がここで説明されたヘッダーを完全に実装しなければならなくて、このヘッダーと共に手動の主要な分配をサポートしなければならなくて、「インターネットプロトコルのためのセキュリティー体系」[Atk95a]のすべての要件に従わなければならなくて、仲間ドキュメントの指定されるとしてのDES CBCの使用をサポートしなければならないと主張する実装が「ESP DES-CBCは変形すること」に[KMS95]の権利を与えました。 また、作成者は、他の超能力が変換であると実装するかもしれません。Implementersはさらなる指導のためにこのドキュメントの状態に関して「IABの公式の規格」RFCの最新のバージョンに相談するはずです。

6. SECURITY CONSIDERATIONS

6. セキュリティ問題

   This entire document discusses a security mechanism for use with IP.
   This mechanism is not a panacea, but it does provide an important
   component useful in creating a secure internetwork.

この全体のドキュメントは使用のために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が説明して、使用するべきではありません。

   Users need to understand that the quality of the security provided by
   this specification depends completely on the strength of whichever
   encryption algorithm has been implemented, the correctness of that
   algorithm's implementation, upon the security of the key management
   mechanism and its implementation, the strength of the key [CN94]
   [Sch94, p233] and upon the correctness of the ESP and IP
   implementations in all of the participating systems.

ユーザは、この仕様で提供されたセキュリティの品質を完全実装された暗号化アルゴリズム、かぎ管理メカニズムのセキュリティのそのアルゴリズムの実装の正当性の強さと実装、キー[CN94]の強さ[Sch94、p233]の上と、そして、参加システムのすべての超能力とIP実装の正当性に依存するのを理解する必要があります。

   If any of these assumptions do not hold, then little or no real
   security will be provided to the user.  Use of high assurance
   development techniques is recommended for the IP Encapsulating
   Security Payload.

これらの仮定のいずれも成立しないと、物上担保はまずユーザに提供されないでしょう。 高い保証開発のテクニックの使用はIP Encapsulating Security有効搭載量のために推薦されます。

   Users seeking protection from traffic analysis might consider the use
   of appropriate link encryption.  Description and specification of
   link encryption is outside the scope of this note.

トラヒック分析から保護を求めているユーザは適切なリンク暗号化の使用を考えるかもしれません。 この注意の範囲の外にリンク暗号化の記述と仕様があります。

   If user-oriented keying is not in use, then the algorithm in use
   should not be an algorithm vulnerable to any kind of Chosen Plaintext
   attack.  Chosen Plaintext attacks on DES are described in [BS93] and
   [Mat94]. Use of user-oriented keying is recommended in order to
   preclude any sort of Chosen Plaintext attack and to generally make
   cryptanalysis more difficult.  Implementations SHOULD support user-

利用者志向合わせるのが使用中でないなら、使用中のアルゴリズムはどんな種類のChosen Plaintext攻撃にも被害を受け易いアルゴリズムであるべきではありません。 選ばれたPlaintext攻撃は[BS93]と[Mat94]にDESに説明されます。 利用者志向合わせることの使用は、どんな種類のChosen Plaintext攻撃も排除して、一般に暗号文解読術をより難しくすることが勧められます。 実装SHOULDサポートユーザ

Atkinson                    Standards Track                     [Page 9]

RFC 1827             Encapsulating Security Payload          August 1995

1995年8月にセキュリティが有効搭載量であるとカプセル化するアトキンソン標準化過程[9ページ]RFC1827

   oriented keying as is described in the IP Security Architecture
   [Atk95a].

IP Security Architecture[Atk95a]で説明される指向の合わせること。

ACKNOWLEDGEMENTS

承認

   This document benefited greatly from work done by Bill Simpson, Perry
   Metzger, and Phil Karn to make general the approach originally
   defined by the author for SIP, SIPP, and finally IPv6.

このドキュメントは大いに元々SIP、SIPP、および最終的にIPv6のために作者によって定義されたアプローチを一般的にするようにビル・シンプソン、ペリーメッツガー、およびフィルKarnによって行われた仕事の利益を得ました。

   Many of the concepts here are derived from or were influenced by the
   US Government's SP3 security protocol specification, the ISO/IEC's
   NLSP specification, or from the proposed swIPe security protocol
   [SDNS89, ISO92a, IB93, IBK93, ISO92b].  The use of DES for
   confidentiality is closely modeled on the work done for the SNMPv2
   [GM93].  Steve Bellovin, Steve Deering, Dave Mihelcic, and Hilarie
   Orman provided solid critiques of early versions of this memo.

または、ここの概念の多くが派生する、米国政府のSP3セキュリティプロトコル仕様、ISO/IECのNLSP仕様、または、提案されたswIPeセキュリティプロトコル[SDNS89、ISO92a、IB93、IBK93、ISO92b]から影響を及ぼされました。 SNMPv2[GM93]のために行われた仕事は密接にDESの秘密性の使用に似せられます。 スティーブBellovin、スティーブ・デアリング、デーヴMihelcic、およびHilarie Ormanはこのメモの早めのバージョンのしっかりした批評を提供しました。

REFERENCES

参照

   [Atk95a] Atkinson, R., "Security Architecture for the Internet
            Protocol", RFC 1825, NRL, August 1995.

[Atk95a] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC1825、NRL、1995年8月。

   [Atk95b] Atkinson, R., "IP Authentication Header", RFC 1826, NRL,
            August 1995.

[Atk95b] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、NRL、1995年8月。

   [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月。

   [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。

   [BS93]   Eli Biham and Adi Shamir, "Differential Cryptanalysis of the
            Data Encryption Standard", Springer-Verlag, New York, NY,
            1993.

[BS93] イーライBihamとアディシャミル、「データ暗号化規格の差分解読法」、追出石-Verlag、ニューヨーク(ニューヨーク)1993

   [CN94]   John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data:
            Foiling the Two Nemeses", Cryptologia, Vol. 18, No. 23,
            July 1994. pp. 253-280

[CN94]ジョンM.キャロルと様のNudiati、「弱いキーと弱いデータに関して:、」 「Two Nemesesをくじきます」、Cryptologia、Vol.18、No.23、7月1994日ページ 253-280

   [CERT95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks
            and Hijacked Terminal Connections", CA-95:01, January 1995.
            Available via anonymous ftp from info.cert.org.

[CERT95]コンピュータ緊急対応チーム、(本命) 「IPは攻撃とハイジャックされた端末のコネクションズを偽造する」カリフォルニア-95: 01 1995年1月。 info.cert.orgからのアノニマスFTPで、利用可能です。

Atkinson                    Standards Track                    [Page 10]

RFC 1827             Encapsulating Security Payload          August 1995

1995年8月にセキュリティが有効搭載量であるとカプセル化するアトキンソン標準化過程[10ページ]RFC1827

   [DIA]    US Defense Intelligence Agency (DIA), "Compartmented Mode
            Workstation Specification", Technical Report
            DDS-2600-6243-87.

[DIA]米国国防情報庁(DIA)、「Compartmentedモードワークステーション仕様」、技術報告書DDS-2600-6243-87。

   [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月)。

   [Hin94]  Bob Hinden (Editor), Internet Protocol version 6 (IPv6)
            Specification, Work in Progress, October 1994.

[Hin94]ボブHinden(エディタ)、インターネットプロトコルバージョン6(IPv6)仕様、Progress、1994年10月のWork。

   [IB93]   John Ioannidis & Matt Blaze, "Architecture and Implementation
            of Network-layer Security Under Unix", Proceedings of the 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、コロンブス、オハイオでのプレゼンテーション。

   [ISO92a] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
            DIS 11577, International Standards Organisation, Geneva,
            Switzerland, 29 November 1992.

[ISO92a] ISO/IEC JTC1/SC6、ネットワーク層セキュリティプロトコル、ISO-IEC不-11577、世界規格機構、ジュネーブ(スイス)1992年11月29日。

   [ISO92b] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
            DIS 11577, Section 13.4.1, page 33, International Standards
            Organisation, Geneva, Switzerland, 29 November 1992.

[ISO92b]ISO/IEC JTC1/SC6、ネットワーク層セキュリティが議定書を作って、ISO-IECが不-11577であり、セクション13.4は.1です、33ページ、世界規格機構、ジュネーブ(スイス)1992年11月29日。

   [Ken91]  Kent, S., "US DoD Security Options for the Internet
            Protocol", RFC 1108, BBN Communications, November 1991.

[Ken91] ケント、S.、「インターネットプロトコルのための米国のDoDセキュリティオプション」、RFC1108、BBNコミュニケーション、1991年11月。

   [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月。

   [Mat94]  Matsui, M., "Linear Cryptanalysis method for DES Cipher",
            Proceedings of Eurocrypt '93, Berlin, Springer-Verlag, 1994.

[Mat94]松井、M.、「DES Cipherのための直線的なCryptanalysisメソッド」、1994のEurocrypt93年、ベルリン、Springer-VerlagのProceedings

   [NIST77] US National Bureau of Standards, "Data Encryption Standard",
            Federal Information Processing Standard (FIPS) Publication
            46, January 1977.

[NIST77]米国規格基準局、「データ暗号化規格」、連邦情報処理基準(FIPS)公表46、1977年1月。

   [NIST80] US National Bureau of Standards, "DES Modes of Operation"
            Federal Information Processing Standard (FIPS) Publication
            81, December 1980.

1980年12月の[NIST80]米国規格基準局、「DES運転モード」連邦情報処理基準(FIPS)公表81。

Atkinson                    Standards Track                    [Page 11]

RFC 1827             Encapsulating Security Payload          August 1995

1995年8月にセキュリティが有効搭載量であるとカプセル化するアトキンソン標準化過程[11ページ]RFC1827

   [NIST81] US National Bureau of Standards, "Guidelines for Implementing
            and Using the Data Encryption Standard", Federal Information
            Processing Standard (FIPS) Publication 74, April 1981.

[NIST81]米国規格基準局、「データ暗号化規格を実装して、使用するためのガイドライン」、連邦情報処理基準(FIPS)公表74(1981年4月)。

   [NIST88] US National Bureau of Standards, "Data Encryption Standard",
            Federal Information Processing Standard (FIPS) Publication
            46-1, January 1988.

[NIST88]米国規格基準局、「データ暗号化規格」、連邦情報処理基準(FIPS)公表46-1、1988年1月。

   [STD-2]  Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
            RFC 1700, USC/Information Sciences Institute, October 1994.

[STD-2] USC/情報科学が1994年10月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1700。

   [Sch94]  Bruce Schneier, Applied Cryptography, John Wiley & Sons,
            New York, NY, 1994.  ISBN 0-471-59756-2

[Sch94]ブルース・シュナイアー、適用された暗号、ジョン・ワイリー、および息子、ニューヨーク(ニューヨーク)1994。 ISBN0-471-59756-2

   [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3,
            Document SDN.301, Revision 1.5, 15 May 1989, as published
            in NIST Publication NIST-IR-90-4250, February 1990.

[SDNS89]SDNS Secure Data Network System、Securityプロトコル3、SP3、Document SDN.301、Revision1.5、NIST Publication NIST IR90-4250(1990年2月)における発行されるとしての1989年5月15日。

DISCLAIMER

注意書き

   The views and specification here 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 specification.

ここの視点と仕様は、作者のものであり、必ず彼の雇い主のものであるというわけではありません。 海軍研究試験所はこの仕事についてもしあれば事実判決を通過していません。 作者と彼の雇い主はこの仕様の正しいか不正確な実装か使用から起こることにおけるどんな問題によっても明確に責任を拒否します。

AUTHOR'S ADDRESS

作者のアドレス

   Randall Atkinson
   Information Technology Division
   Naval Research Laboratory
   Washington, DC 20375-5320
   USA

ランドルアトキンソン情報技術事業部海軍研究試験所ワシントン、DC20375-5320米国

   Phone:  (202) 404-7090
   Fax:    (202) 404-7942
   EMail:  atkinson@itd.nrl.navy.mil

以下に電話をしてください。 (202) 404-7090 Fax: (202) 404-7942 メールしてください: atkinson@itd.nrl.navy.mil

Atkinson                    Standards Track                    [Page 12]

アトキンソン標準化過程[12ページ]