RFC1826 日本語訳

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

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

                        IP Authentication Header

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 a mechanism for providing cryptographic
   authentication for IPv4 and IPv6 datagrams.  An Authentication Header
   (AH) is normally inserted after an IP header and before the other
   information being authenticated.

このドキュメントは、IPv4とIPv6データグラムのための暗号の認証を提供するためにメカニズムについて説明します。通常、Authentication Header(AH)はIPヘッダーの後と認証されるもう片方の情報の前に挿入されます。

1. INTRODUCTION

1. 序論

   The Authentication Header is a mechanism for providing strong
   integrity and authentication for IP datagrams.  It might also provide
   non-repudiation, depending on which cryptographic algorithm is used
   and how keying is performed.  For example, use of an asymmetric
   digital signature algorithm, such as RSA, could provide non-
   repudiation.

Authentication Headerは強い保全を提供するためのメカニズムとIPデータグラムのための認証です。また、非拒否を提供するかもしれません、どの暗号アルゴリズムが使用されているか、そして、合わせることがどのように実行されるかによって。 例えば、RSAなどの非対称のデジタル署名アルゴリズムの使用は非拒否を提供するかもしれません。

   Confidentiality, and protection from traffic analysis are not
   provided by the Authentication Header.  Users desiring
   confidentiality should consider using the IP Encapsulating Security
   Protocol (ESP) either in lieu of or in conjunction with the
   Authentication Header [Atk95b].  This document assumes the reader has
   previously read the related IP Security Architecture document which
   defines the overall security architecture for IP and provides
   important background information for this specification [Atk95a].

秘密性、および分析がAuthentication Headerによって提供されないトラフィックからの保護。 秘密性を望んでいるユーザは、Authentication HeaderかAuthentication Header[Atk95b]に関連してIP Encapsulating Securityプロトコル(超能力)を使用すると考えるべきです。 このドキュメントは、読者が以前にIPのために総合的なセキュリティー体系を定義して、この仕様[Atk95a]に重要な基礎的な情報を提供する関連するIP Security Architectureドキュメントを読んだと仮定します。

1.1 Overview

1.1 概要

   The IP Authentication Header seeks to provide security by adding
   authentication information to an IP datagram. This authentication
   information is calculated using all of the fields in the IP datagram
   (including not only the IP Header but also other headers and the user
   data) which do not change in transit.  Fields or options which need
   to change in transit (e.g., "hop count", "time to live", "ident",

IP Authentication Headerは、IPデータグラムに認証情報を加えることによって、セキュリティを提供しようとします。 この認証情報は、IPデータグラム(IP Headerだけではなく、他のヘッダーと利用者データも含んでいる)のトランジットで変化しない分野のすべてを使用することで計算されます。 必要がある分野かオプションがトランジットで変化します。(例えば、「ホップカウント」、「生きる時間」は"identする"です。

Atkinson                    Standards Track                     [Page 1]

RFC 1826                IP Authentication Header             August 1995

アトキンソンStandardsはIP認証ヘッダー1995年8月にRFC1826を追跡します[1ページ]。

   "fragment offset", or "routing pointer") are considered to be zero
   for the calculation of the authentication data.  This provides
   significantly more security than is currently present in IPv4 and
   might be sufficient for the needs of many users.

断片は相殺されました。「」 「ルーティング指針」) 認証データの計算のためのゼロであると考えられます。 これは現在、IPv4に存在していて、多くのユーザの必要性に十分であるかもしれないよりかなり多くのセキュリティを提供します。

   Use of this specification will increase the IP protocol processing
   costs in participating end 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 the receiver
   for each IP datagram containing an Authentication Header.  The impact
   will vary with authentication algorithm used and other factors.

この仕様の使用は、参加しているエンドシステムのIPプロトコル処理コストを増強して、また、コミュニケーション潜在を増強するでしょう。 増強された潜在は主としてAuthentication Headerを含むそれぞれのIPデータグラムのための受信機による認証データの送付者による認証データの計算、計算、および比較のためです。 影響は認証アルゴリズムで中古で他の要素を変えるでしょう。

   In order for the Authentication Header to work properly without
   changing the entire Internet infrastructure, the authentication data
   is carried in its own payload.  Systems that aren't participating in
   the authentication MAY ignore the Authentication Data.  When used
   with IPv6, the Authentication Header is normally placed after the
   Fragmentation and End-to-End headers and before the ESP and
   transport-layer headers.  The information in the other IP headers is
   used to route the datagram from origin to destination.  When used
   with IPv4, the Authentication Header immediately follows an IPv4
   header.

Authentication Headerが適切に全体のインターネット基盤を変えないで働くように、認証データはそれ自身のペイロードで運ばれます。 認証に参加していないシステムはAuthentication Dataを無視するかもしれません。 IPv6と共に使用されると、通常、Authentication HeaderはFragmentationとEndから終わりへのヘッダーの後と超能力とトランスポート層ヘッダーの前に置かれます。 他のIPヘッダーの情報は、発生源から目的地までデータグラムを発送するのに使用されます。 IPv4と共に使用されると、Authentication Headerはすぐに、IPv4ヘッダーに続きます。

   If a symmetric authentication algorithm is used and intermediate
   authentication is desired, then the nodes performing such
   intermediate authentication would need to be provided with the
   appropriate keys.  Possession of those keys would permit any one of
   those systems to forge traffic claiming to be from the legitimate
   sender to the legitimate receiver or to modify the contents of
   otherwise legitimate traffic.  In some environments such intermediate
   authentication might be desirable [BCCH94].  If an asymmetric
   authentication algorithm is used and the routers are aware of the
   appropriate public keys and authentication algorithm, then the
   routers possessing the authentication public key could authenticate
   the traffic being handled without being able to forge or modify
   otherwise legitimate traffic.  Also, Path MTU Discovery MUST be used
   when intermediate authentication of the Authentication Header is
   desired and IPv4 is in use because with this method it is not
   possible to authenticate a fragment of a packet [MD90] [Kno93].

左右対称の認証アルゴリズムが使用されていて、中間的認証が望まれているなら、そのような中間的認証を実行するノードは、適切なキーが提供される必要があるでしょう。 それらのキーの所持は、それらのシステムのどれかが正統の送付者から正統の受信機まであるか、またはそうでなければ、正統のトラフィックのコンテンツを変更すると主張するトラフィックを鍛造することを許可するでしょう。 いくつかの環境で、そのような中間的認証は望ましいかもしれません[BCCH94]。 非対称の認証アルゴリズムが使用されていて、ルータが適切な公開鍵と認証アルゴリズムを意識しているなら、認証公開鍵を持っているルータはそうでなければ、正統のトラフィックを鍛造できないか、変更できないで扱われるトラフィックを認証するかもしれません。 また、Authentication Headerの中間的認証が望まれていて、パケット[MD90][Kno93]の断片を認証するのがこのメソッドで可能でないのでIPv4が使用中であるときに、Path MTUディスカバリーを使用しなければなりません。

Atkinson                    Standards Track                     [Page 2]

RFC 1826                IP Authentication Header             August 1995

アトキンソンStandardsはIP認証ヘッダー1995年8月にRFC1826を追跡します[2ページ]。

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, it is not integrated with this specification because of a
   long history in the public literature of subtle flaws in key
   management algorithms and protocols.  The IP Authentication Header
   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 Parameters
   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.

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

   The key management mechanism is used to negotiate a number of
   parameters for each "Security Association", including not only the
   keys but also other information (e.g., the authentication algorithm
   and mode) used by the communicating parties.  The key management
   mechanism creates and maintains a logical table containing the
   several parameters for each current security association.  An
   implementation of the IP Authentication Header will need to read that

かぎ管理メカニズムは各「セキュリティ協会」のための多くのパラメタを交渉するのに使用されます、キーだけではなく、交信パーティーによって使用された他の情報(例えば、認証アルゴリズムとモード)も含んでいて。 かぎ管理メカニズムは、それぞれの現在のセキュリティ協会のためのいくつかのパラメタを含む論理的なテーブルを、作成して、維持します。 IP Authentication Headerの実装は、それを読む必要があるでしょう。

Atkinson                    Standards Track                     [Page 3]

RFC 1826                IP Authentication Header             August 1995

アトキンソンStandardsはIP認証ヘッダー1995年8月にRFC1826を追跡します[3ページ]。

   logical table of security parameters to determine how to process each
   datagram containing an Authentication Header (e.g., to determine
   which algorithm/mode and key to use in authentication).

Authentication Header(例えば認証にどのアルゴリズム/モードとキーを使用したらよいかを決定する)を含む各データグラムを処理する方法を決定するセキュリティパラメタの論理的なテーブル。

   Security Associations are unidirectional.  A bidirectional
   communications session will normally have one Security Association in
   each direction.  For example, when a TCP session exists between two
   systems A and B, there will normally be one Security Association from
   A to B and a separate second Security Assocation from B to A.  The
   receiver assigns the SPI value to the the Security Association with
   that sender.  The other parameters of the Security Association are
   determined in a manner specified by the key management mechanism.
   Section 4 of this document describes in detail the process of
   selecting a Security Association for an outgoing packet and
   identifying the Security Assocation for an incoming packet.

セキュリティAssociationsは単方向です。 通常、双方向のコミュニケーションセッションは各方向に1Security Associationを持つでしょう。 TCPセッションが2台のシステムAとBの間に存在するとき、例えば、AからBまで通常、1Security Associationがあるでしょう、そして、第2の別々のA. Bから受信機までのSecurity Assocationはその送付者と共にSPI値をSecurity Associationに割り当てます。 Security Associationの他のパラメタはかぎ管理メカニズムによって指定された方法で決定します。 このドキュメントのセクション4は詳細に出発しているパケットのためにSecurity Associationを選択して、入って来るパケットのためにSecurity Assocationを特定するプロセスについて説明します。

   The IP Security Architecture document describes key management in
   detail.  It includes specification of the key management requirements
   for this protocol, and is incorporated here by reference [Atk95a].

IP Security Architectureドキュメントは詳細にかぎ管理を説明します。 それは、このプロトコルのためにかぎ管理要件の仕様を含んで、参照[Atk95a]でここに組み込まれます。

3. AUTHENTICATION HEADER SYNTAX

3. 認証ヘッダー構文

   The Authentication Header (AH) may appear after any other headers
   which are examined at each hop, and before any other headers which
   are not examined at an intermediate hop.  The IPv4 or IPv6 header
   immediately preceding the Authentication Header will contain the
   value 51 in its Next Header (or Protocol) field [STD-2].

Authentication Header(AH)は各ホップで調べられるいかなる他のヘッダーの後、および中間的ホップで調べられないいかなる他のヘッダーの前にも現れるかもしれません。 すぐにAuthentication Headerに先行するIPv4かIPv6ヘッダーがNext Header(または、プロトコル)分野[STD-2]に値51を保管するでしょう。

   Example high-level diagrams of IP datagrams with the Authentication
   Header follow.

Authentication HeaderがあるIPデータグラムの例のハイレベルのダイヤグラムは従います。

 +------------+-------------------+------------+-------+---------------+
 | IPv6 Header| Hop-by-Hop/Routing| Auth Header| Others| Upper Protocol|
 +------------+-------------------+------------+-------+---------------+

+------------+-------------------+------------+-------+---------------+ | IPv6ヘッダー| ホップごとの/ルート設定| Authヘッダー| 他のもの| 上側のプロトコル| +------------+-------------------+------------+-------+---------------+

                Figure 1: IPv6 Example

図1: IPv6の例

Atkinson                    Standards Track                     [Page 4]

RFC 1826                IP Authentication Header             August 1995

アトキンソンStandardsはIP認証ヘッダー1995年8月にRFC1826を追跡します[4ページ]。

   When used with IPv6, the Authentication Header normally appears after
   the IPv6 Hop-by-Hop Header and before the IPv6 Destination Options.

IPv6と共に使用されると、通常、Authentication HeaderはホップによるIPv6 Hop Headerの後とIPv6 Destination Optionsの前に現れます。

    +-------------+--------------+-------------------------------+
    | IPv4 Header |  Auth Header | Upper Protocol (e.g. TCP, UDP)|
    +-------------+--------------+-------------------------------+

+-------------+--------------+-------------------------------+ | IPv4ヘッダー| Authヘッダー| 上側のプロトコル(例えば、TCP、UDP)| +-------------+--------------+-------------------------------+

                   Figure 2:  IPv4 Example

図2: IPv4の例

   When used with IPv4, the Authentication Header normally follows the
   main IPv4 header.

IPv4と共に使用されると、通常、Authentication Headerは主なIPv4ヘッダーに続きます。

3.1 Authentication Header Syntax

3.1認証ヘッダー構文

   The authentication data is the output of the authentication algorithm
   calculated over the the entire IP datagram as described in more
   detail later in this document.  The authentication calculation must
   treat the Authentication Data field itself and all fields that are
   normally modified in transit (e.g., TTL or Hop Limit) as if those
   fields contained all zeros.  All other Authentication Header fields
   are included in the authentication calculation normally.

認証データはさらに詳細に後で本書では説明されるように全体のIPデータグラムの上に計算された認証アルゴリズムの出力です。 まるでそれらの分野がすべてのゼロを含んでいるかのように認証計算はAuthentication Data分野自体と通常、トランジットで変更されるすべての分野(例えば、TTLかHop Limit)を扱わなければなりません。 通常、他のすべてのAuthentication Header分野が認証計算に含まれています。

   The IP Authentication Header has the following syntax:

IP Authentication Headerには、以下の構文があります:

     +---------------+---------------+---------------+---------------+
     | Next Header   | Length        |           RESERVED            |
     +---------------+---------------+---------------+---------------+
     |                    Security Parameters Index                  |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     +     Authentication Data (variable number of 32-bit words)     |
     |                                                               |
     +---------------+---------------+---------------+---------------+
      1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

+---------------+---------------+---------------+---------------+ | 次のヘッダー| 長さ| 予約されます。| +---------------+---------------+---------------+---------------+ | セキュリティパラメタインデックス| +---------------+---------------+---------------+---------------+ | | + 認証Data(可変数の32ビットの単語)| | | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

                   Figure 3:  Authentication Header syntax

図3: 認証Header構文

Atkinson                    Standards Track                     [Page 5]

RFC 1826                IP Authentication Header             August 1995

アトキンソンStandardsはIP認証ヘッダー1995年8月にRFC1826を追跡します[5ページ]。

3.2 Fields of the Authentication Header

3.2 認証ヘッダーのフィールズ

   NEXT HEADER
      8 bits wide.  Identifies the next payload after the Authentication
      Payload.  This values in this field are the set of IP Protocol
      Numbers as defined in the most recent RFC from the Internet
      Assigned Numbers Authority (IANA) describing "Assigned Numbers"
      [STD-2].

幅8ビットのNEXT HEADER。 次のペイロードに、Authentication有効搭載量の後に特定します。 この分野のこの値は「規定番号」[STD-2]について説明しながらインターネットAssigned民数記Authority(IANA)から最新のRFCで定義されるようにIPプロトコル民数記のセットです。

   PAYLOAD LENGTH
      8 bits wide.  The length of the Authentication Data field in 32-
      bit words.  Minimum value is 0 words, which is only used in the
      degenerate case of a "null" authentication algorithm.

幅8ビットのPAYLOAD LENGTH。 32の噛み付いている単語によるAuthentication Data分野の長さ。 最小値は0つの単語です(「ヌル」の認証アルゴリズムの堕落した場合に使用されるだけです)。

   RESERVED
      16 bits wide.  Reserved for future use.  MUST be set to all zeros
      when sent.  The value is included in the Authentication Data
      calculation, but is otherwise ignored by the recipient.

幅16ビットのRESERVED。 今後の使用のために、予約されます。 送ると、すべてのゼロに設定しなければなりません。 値は、Authentication Data計算に含まれていますが、別の方法で受取人によって無視されます。

   SECURITY PARAMETERS INDEX (SPI)
      A 32-bit pseudo-random value identifying the security association
      for this datagram.  The Security Parameters Index value 0 is
      reserved to indicate that "no security association exists".

このデータグラムのためにセキュリティ協会を特定するSECURITY PARAMETERS INDEX(SPI)のA32ビットの擬似ランダム価値。 Security Parameters Index値0は、「セキュリティ協会は全く存在しません」と示すために予約されます。

      The set of Security Parameters Index values in the range 1 through
      255 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)への範囲1〜255のSecurity Parameters Index値のセットは今後の使用のために予約されます。 その特定の割り当てられたSPI価値の使用がRFCでオープンに指定されないと、通常、予約されたSPI値はIANAによって割り当てられないでしょう。

   AUTHENTICATION DATA
      This length of this field is variable, but is always an integral
      number of 32-bit words.

この分野のAUTHENTICATION DATA Thisの長さは、可変ですが、いつも整数の32ビットの単語です。

      Many implementations require padding to other alignments, such as
      64-bits, in order to improve performance.  All implementations
      MUST support such padding, which is specified by the Destination
      on a per SPI basis.  The value of the padding field is arbitrarily
      selected by the sender and is included in the Authentication Data
      calculation.

多くの実装が、性能を向上させるために64ビットであることのように他の整列にそっと歩くのを必要とします。 すべての実装がそのような詰め物をサポートしなければなりません。(それは、SPI基礎あたりのaでDestinationによって指定されます)。 詰め物分野の値は、送付者によって任意に選択されて、Authentication Data計算で入れられています。

      An implementation will normally use the combination of Destination
      Address and SPI to locate the Security Association which specifies
      the field's size and use.  The field retains the same format for
      all datagrams of any given SPI and Destination Address pair.

通常、実装は、フィールドのサイズと使用を指定するSecurity Associationの場所を見つけるのにDestination AddressとSPIの組み合わせを使用するでしょう。 分野はどんな与えられたSPIとDestination Address組のすべてのデータグラムのための同じ形式も保有します。

Atkinson                    Standards Track                     [Page 6]

RFC 1826                IP Authentication Header             August 1995

アトキンソンStandardsはIP認証ヘッダー1995年8月にRFC1826を追跡します[6ページ]。

      The Authentication Data fills the field beginning immediately
      after the SPI field.  If the field is longer than necessary to
      store the actual authentication data, then the unused bit
      positions are filled with unspecified, implementation-dependent
      values.

Authentication DataはSPI分野直後始まる分野をいっぱいにしています。 分野が実際の認証データを保存するために必要とするより長いなら、未使用のビット位置は不特定の、そして、実装依存する値で満たされます。

      Refer to each Authentication Transform specification for more
      information regarding the contents of this field.

この分野のコンテンツに関する詳しい情報のためのそれぞれのAuthentication Transform仕様を参照してください。

3.3 Sensitivity Labeling

3.3 感度ラベリング

   As is discussed in greater detail in the IP Security Architecture
   document, IPv6 will normally use implicit Security Labels rather than
   the explicit labels that are currently used with IPv4 [Ken91]
   [Atk95a].  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 the
   Authentication Header.  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.  If explicit labels are
   in use, then the explicit label MUST be included in the
   authentication calculation.

IP Security Architectureドキュメントで詳細によりすばらしい議論するように、通常、IPv6は現在IPv4[Ken91][Atk95a]と共に使用される明白なラベルよりむしろ内在しているSecurity Labelsを使用するでしょう。 いくつかの状況で、ユーザは、Authentication Headerによって提供された内在しているラベルを使用することに加えて明白なラベル(例えば、RFC-1108によって定義されるIPSOラベルはIPv4と共に使用されるかもしれない)を運ぶのを選ぶかもしれません。 IPv6(例えば、IPv6終わりから終わりへのオプションヘッダーかホップごとのIPv6オプションヘッダーを使用する)との使用のために明白なラベルオプションを定義できました。 実装は内在しているラベルに加えて明白なラベルを支えるかもしれませんが、実装は、明白なラベルを支えるのに必要ではありません。 明白なラベルが使用中であるなら、認証計算に明白なラベルを含まなければなりません。

4. CALCULATION OF THE AUTHENTICATION DATA

4. 認証データの計算

   The authentication data carried by the IP Authentication Header is
   usually calculated using a message digest algorithm (for example,
   MD5) either encrypting that message digest or keying the message
   digest directly [Riv92].  Only algorithms that are believed to be
   cryptographically strong one-way functions should be used with the IP
   Authentication Header.

通常、IP Authentication Headerによって運ばれた認証データは、直接[Riv92]そのメッセージダイジェストを暗号化するか、またはメッセージダイジェストを合わせながらメッセージダイジェストアルゴリズム(例えば、MD5)を使用することで計算されます。 暗号で、強い一方向関数がIP Authentication Headerと共に使用されるべきであるということであると信じられているアルゴリズムだけ。

   Because conventional checksums (e.g., CRC-16) are not
   cryptographically strong, they MUST NOT be used with the
   Authentication Header.

従来のチェックサム(例えば、CRC-16)が暗号でそうでないので、強くて、Authentication Headerと共にそれらを使用してはいけません。

   When processing an outgoing IP packet for Authentication, the first
   step is for the sending system to locate the appropriate Security
   Association.  All Security Associations are unidirectional.  The
   selection of the appropriate Security Association for an outgoing IP
   packet is based at least upon the sending userid and the Destination
   Address.  When host-oriented keying is in use, all sending userids
   will share the same Security Association to a given destination.
   When user-oriented keying is in use, then different users or possibly
   even different applications of the same user might use different
   Security Associations.  The Security Association selected will

Authenticationのために出発しているIPパケットを処理するとき、第一歩は送付システムが適切なSecurity Associationの場所を見つけることです。 すべてのSecurity Associationsが単方向です。 出発しているIPパケットのための適切なSecurity Associationの選択は少なくとも送付ユーザIDとDestination Addressに基づいています。 ホスト指向の合わせるのが使用中であるときに、すべての送付ユーザIDが与えられた目的地と同じSecurity Associationを共有するでしょう。 利用者志向合わせるのが使用中であると、同じユーザの異なったユーザかことによると異なったアプリケーションさえ異なったSecurity Associationsを使用するかもしれません。 選択されたSecurity Associationはそうするでしょう。

Atkinson                    Standards Track                     [Page 7]

RFC 1826                IP Authentication Header             August 1995

アトキンソンStandardsはIP認証ヘッダー1995年8月にRFC1826を追跡します[7ページ]。

   indicate which algorithm, algorithm mode, key, and other security
   properties apply to the outgoing packet.

どのアルゴリズム、アルゴリズムモード、キー、および他のセキュリティの特性が出発しているパケットに適用されるかを示してください。

   Fields which NECESSARILY are modified during transit from the sender
   to the receiver (e.g., TTL and HEADER CHECKSUM for IPv4 or Hop Limit
   for IPv6) and whose value at the receiver are not known with
   certainty by the sender are included in the authentication data
   calculation but are processed specially.  For these fields which are
   modified during transit, the value carried in the IP packet is
   replaced by the value zero for the purpose of the authentication
   calculation.  By replacing the field's value with zero rather than
   omitting these fields, alignment is preserved for the authentication
   calculation.

どのNECESSARILYが送付者から受信機(IPv4のための例えば、TTLとHEADER CHECKSUMかIPv6のためのHop Limit)までのトランジットの間、変更されるか、そして、受信機の値が確実性で送付者によって知られていない分野は、認証データ計算に含まれていますが、特に、処理されます。 トランジットの間に変更されるこれらの分野において、認証計算の目的のためにIPパケットで運ばれた値を値ゼロに取り替えます。 これらの分野を省略するよりむしろフィールドの値をゼロに取り替えることによって、整列は認証計算のために保存されます。

   The sender MUST compute the authentication over the packet as that
   packet will appear at the receiver.  This requirement is placed in
   order to allow for future IP optional headers which the receiver
   might not know about but the sender necessarily knows about if it is
   including such options in the packet.  This also permits the
   authentication of data that will vary in transit but whose value at
   the final receiver is known with certainty by the sender in advance.

そのパケットが受信機に現れるように送付者はパケットの上の認証を計算しなければなりません。この要件は、パケットにそのようなオプションを含んでいるなら周囲で受信機がそうしないかもしれない任意のヘッダーが必ず送付者だけに関して知るのを知っている将来のIPを考慮するために置かれます。 また、これはトランジットにおいて異なりますが、最終的な受信機の値があらかじめ確実性で送付者によって知られているデータの認証を可能にします。

   The sender places the calculated message digest algorithm output into
   the Authentication Data field within the Authentication Header.  For
   purposes of Authentication Data computation, the Authentication Data
   field is considered to be filled with zeros.

送付者はAuthentication Headerの中に計算されたメッセージダイジェストアルゴリズム出力をAuthentication Data分野に置きます。 Authentication Data計算の目的のために、ゼロでAuthentication Data分野がいっぱいにされると考えられます。

   The IPv4 "TIME TO LIVE" and "HEADER CHECKSUM" fields are the only
   fields in the IPv4 base header that are handled specially for the
   Authentication Data calculation.  Reassembly of fragmented packets
   occurs PRIOR to processing by the local IP Authentication Header
   implementation.  The "more" bit is of course cleared upon reassembly.
    Hence, no other fields in the IPv4 header will vary in transit from
   the perspective of the IP Authentication Header implementation.  The
   "TIME TO LIVE" and "HEADER CHECKSUM" fields of the IPv4 base header
   MUST be set to all zeros for the Authentication Data calculation.
   All other IPv4 base header fields are processed normally with their
   actual contents.  Because IPv4 packets are subject to intermediate
   fragmentation in routers, it is important that the reassembly of IPv4
   packets be performed prior to the Authentication Header processing.
   IPv4 Implementations SHOULD use Path MTU Discovery when the IP
   Authentication Header is being used [MD90].  For IPv4, not all
   options are openly specified in a RFC, so it is not possible to
   enumerate in this document all of the options that might normally be
   modified during transit.  The IP Security Option (IPSO) MUST be
   included in the Authentication Data calculation whenever that option
   is present in an IP datagram [Ken91].  If a receiving system does not
   recognise an IPv4 option that is present in the packet, that option

「生きる時間」と「ヘッダーチェックサム」がさばくIPv4はIPv4ベースヘッダーで特に、認証データ計算のために扱われる唯一の分野です。 断片化しているパケットのReassemblyは起こります。ローカルアイピーAuthentication Header実装による処理へのPRIOR。 「より多く」のビットがもちろん再アセンブリできれいにされます。 したがって、IPv4ヘッダーの他の分野は全くIP Authentication Header実装の見解とトランジットにおいて異ならないでしょう。 IPv4ベースヘッダーの「生きる時間」と「ヘッダーチェックサム」分野を認証データ計算のためのすべてのゼロに設定しなければなりません。 通常、他のすべてのIPv4ベースヘッダーフィールドがそれらの実際のコンテンツで処理されます。 IPv4パケットはルータにおける中間的断片化を受けることがあるので、IPv4パケットの再アセンブリがAuthentication Header処理の前に実行されるのは、重要です。 IP Authentication Headerが使用されているとき[MD90]、IPv4 Implementations SHOULDはPath MTUディスカバリーを使用します。 IPv4として、すべてのオプションがRFCでオープンに指定されるというわけではないので、本書では通常、トランジットの間に変更されるかもしれないオプションのすべてを列挙するのは可能ではありません。 そのオプションがIPデータグラム[Ken91]に存在しているときはいつも、Authentication Data計算にIP Security Option(IPSO)を含まなければなりません。 受電方式がパケット、そのオプションで存在しているIPv4オプションを認識しないなら

Atkinson                    Standards Track                     [Page 8]

RFC 1826                IP Authentication Header             August 1995

アトキンソンStandardsはIP認証ヘッダー1995年8月にRFC1826を追跡します[8ページ]。

   is included in the Authentication Data calculation.  This means that
   any IPv4 packet containing an IPv4 option that changes during transit
   in a manner not predictable by the sender and which IPv4 option is
   unrecognised by the receiver will fail the authentication check and
   consequently be dropped by the receiver.

Authentication Data計算では、含まれています。 これは、トランジットの間に受信機で送付者であってどのIPv4オプションが認識されていないかによって予測できない方法で変化するIPv4オプションを含むどんなIPv4パケットも認証チェックに失敗して、その結果、受信機によって下げられることを意味します。

   The IPv6 "HOP LIMIT" field is the only field in the IPv6 base header
   that is handled specially for Authentication Data calculation.  The
   value of the HOP LIMIT field is zero for the purpose of
   Authentication Data calculation.  All other fields in the base IPv6
   header MUST be included in the Authentication Data calculation using
   the normal procedures for calculating the Authentication Data.  All
   IPv6 "OPTION TYPE" values contain a bit which MUST be used to
   determine whether that option data will be included in the
   Authentication Data calculation.  This bit is the third-highest-order
   bit of the IPv6 OPTION TYPE field. If this bit is set to zero, then
   the corresponding option is included in the Authentication Data
   calculation.  If this bit is set to one, then the corresponding
   option is replaced by all zero bits of the same length as the option
   for the purpose of the Authentication Data calculation.  The IPv6
   Routing Header "Type 0" will rearrange the address fields within the
   packet during transit from source to destination.  However, this is
   not a problem because the contents of the packet as it will appear at
   the receiver are known to the sender and to all intermediate hops.
   Hence, the IPv6 Routing Header "Type 0" is included in the
   Authentication Data calculation using the normal procedure.

IPv6「ホップ限界」分野はIPv6ベースヘッダーで特に、認証データ計算のために扱われる唯一の分野です。 HOP LIMIT分野の値はAuthentication Data計算の目的のためのゼロです。 Authentication Dataについて計算するのに正常な手順を用いて、Authentication Data計算にベースIPv6ヘッダーの他のすべての分野を含まなければなりません。 IPv6「オプションタイプ」値が少し含むそのオプションデータが認証データ計算に含まれるかどうか決定するのに使用しなければならないすべて。 このビットはIPv6 OPTION TYPE分野の3番目の最上位ビットです。 このビットがゼロに設定されるなら、対応するオプションはAuthentication Data計算に含まれています。 このビットを1つに設定するなら、対応するオプションをAuthentication Data計算の目的のためのオプションと同じすべてのゼロ・ビットの長さに取り替えます。 IPv6ルート設定Header、「0インチが望んでいるタイプはソースから目的地までのトランジットの間、パケットの中でアドレス・フィールドを再配列します」。 しかしながら、パケットの内容が受信機に現れるように送付者と、そして、すべての中間的ホップに知られているので、これは問題ではありません。 したがって、IPv6ルート設定Headerは「正常な手順を用いて、認証データ計算で含まれていた0インチをタイプします」。

   Upon receipt of a packet containing an IP Authentication Header, the
   receiver first uses the Destination Address and SPI value to locate
   the correct Security Association.  The receiver then independently
   verifies that the Authentication Data field and the received data
   packet are consistent.  Again, the Authentication Data field is
   assumed to be zero for the sole purpose of making the authentication
   computation.  Exactly how this is accomplished is algorithm
   dependent.  If the processing of the authentication algorithm
   indicates the datagram is valid, then it is accepted.  If the
   algorithm determines that the data and the Authentication Header do
   not match, then the receiver SHOULD discard the received IP datagram
   as invalid and MUST record the authentication failure in the system
   log or audit log.  If such a failure occurs, the recorded log data
   MUST include the SPI value, date/time received, clear-text Sending
   Address, clear-text Destination Address, and (if it exists) the
   clear-text Flow ID.  The log data MAY also include other information
   about the failed packet.

IP Authentication Headerを含むパケットを受け取り次第、受信機は、最初に、正しいSecurity Associationの場所を見つけるのにDestination AddressとSPI値を使用します。 そして、受信機は、Authentication Data分野と受信データパケットが一貫していることを独自に確かめます。 一方、Authentication Data分野は認証計算をする唯一の目的のためのゼロであると思われます。 これがちょうどどう優れているかは、アルゴリズムに依存しています。 認証アルゴリズムの処理が、データグラムが有効であることを示すなら、それを受け入れます。 アルゴリズムがデータとAuthentication Headerが合わないで、次に、受信機SHOULDが無効の容認されたIP同じくらいデータグラムを捨てることを決定して、システムログか監査ログに認証失敗を記録しなければならないなら。 そのような失敗が起こるなら、記録されたログデータはSPI値、日付/受付時刻、クリアテキストSending Address、クリアテキストDestination Address、および(存在しているなら)クリアテキストFlow IDを含まなければなりません。 また、ログデータは失敗したパケットの他の情報を含むかもしれません。

Atkinson                    Standards Track                     [Page 9]

RFC 1826                IP Authentication Header             August 1995

アトキンソンStandardsはIP認証ヘッダー1995年8月にRFC1826を追跡します[9ページ]。

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 for use with this option, MUST comply
   with all requirements of the "Security Architecture for the Internet
   Protocol" [Atk95a], and MUST support the use of keyed MD5 as
   described in the companion document entitled "IP Authentication using
   Keyed MD5" [MS95].  Implementations MAY also implement other
   authentication algorithms.  Implementors should consult the most
   recent version of the "IAB Official Standards" RFC for further
   guidance on the status of this document.

この仕様への順応かコンプライアンスを要求する実装は、ここで説明されたヘッダーを完全に実装しなければならなくて、このオプションで使用のための手動の主要な分配をサポートしなければならなくて、「インターネットプロトコルのためのセキュリティー体系」[Atk95a]のすべての要件に従わなければならなくて、「合わせられたMD5"[MS95]を使用するIP認証」と題する仲間ドキュメントで説明されるように合わせられたMD5の使用をサポートしなければなりません。 また、実装は、他の認証がアルゴリズムであると実装するかもしれません。作成者はさらなる指導のためにこのドキュメントの状態に関して「IABの公式の規格」RFCの最新のバージョンに相談するべきです。

6. SECURITY CONSIDERATIONS

6. セキュリティ問題

   This entire RFC discusses an authentication mechanism for IP.  This
   mechanism is not a panacea to the several security issues in any
   internetwork, however it does provide a component useful in building
   a secure internetwork.

この全体のRFCはIPのために認証機構について議論します。 このメカニズムがどんなインターネットワークでもいくつかの安全保障問題への万能薬でない、しかしながら、それは安全なインターネットワークを築き上げる際に役に立つコンポーネントを提供します。

   Users need to understand that the quality of the security provided by
   this specification depends completely on the strength of whichever
   cryptographic algorithm has been implemented, the strength of the key
   being used, the correctness of that algorithm's implementation, upon
   the security of the key management mechanism and its implementation,
   and upon the correctness of the IP Authentication Header and IP
   implementations in all of the participating systems. If any of these
   assumptions do not hold, then little or no real security will be
   provided to the user.  Implementors are encouraged to use high
   assurance methods to develop all of the security relevant parts of
   their products.

ユーザは、この仕様で提供されたセキュリティの品質をキーの強さが使用されることでのかぎ管理メカニズムのセキュリティに関するそのアルゴリズムの実装の正当性であると実装された暗号アルゴリズムとその実装の強さの完全上と、そして、参加システムのすべてのIP Authentication HeaderとIP実装の正当性に依存するのを理解する必要があります。これらの仮定のいずれもするIfは成立しません; そして、物上担保はまずユーザに提供されないでしょう。 作成者がそれらの製品のセキュリティの関連部分のすべてを開発する高い保証メソッドを使用するよう奨励されます。

   Users interested in confidentiality should consider using the IP
   Encapsulating Security Payload (ESP) instead of or in conjunction
   with this specification [Atk95b].  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 [VK83].  Users interested in combining
   the IP Authentication Header with the IP Encapsulating Security
   Payload should consult the IP Encapsulating Security Payload
   specification for details.

秘密性に興味を持っているユーザは、仕様かこの仕様[Atk95b]に関連してIP Encapsulating Security有効搭載量(超能力)を使用すると考えるべきです。 トラヒック分析から保護を求めているユーザは適切なリンク暗号化の使用を考えるかもしれません。 このメモ[VK83]の範囲の外にリンク暗号化の記述と仕様があります。 IP Encapsulating Security有効搭載量にIP Authentication Headerを結合したがっていたユーザは詳細のためのIP Encapsulating Security有効搭載量仕様に相談するべきです。

   One particular issue is that in some cases a packet which causes an
   error to be reported back via ICMP might be so large as not to
   entirely fit within the ICMP message returned.  In such cases, it
   might not be possible for the receiver of the ICMP message to
   independently authenticate the portion of the returned message.  This
   could mean that the host receiving such an ICMP message would either

特定の1冊はICMPメッセージの中で完全に合わないのが戻ったのでいくつかの場合、ICMPを通して誤りの報告を持ちかえるパケットがとても大きいかもしれないということです。 そのような場合、独自に返されたメッセージの部分を認証するICMPメッセージの受信機には、それは可能でないかもしれません。 これは、そのようなICMPメッセージを受け取るホストがそうすることを意味するかもしれません。

Atkinson                    Standards Track                    [Page 10]

RFC 1826                IP Authentication Header             August 1995

アトキンソンStandardsはIP認証ヘッダー1995年8月にRFC1826を追跡します[10ページ]。

   trust an unauthenticated ICMP message, which might in turn create
   some security problem, or not trust and hence not react appropriately
   to some legitimate ICMP message that should have been reacted to.  It
   is not clear that this issue can be fully resolved in the presence of
   packets that are the same size as or larger than the minimum IP MTU.
   Similar complications arise if an encrypted packet causes an ICMP
   error message to be sent and that packet is truncated.

unauthenticated ICMPメッセージを信じてください。(それは、順番に信頼ではなく、何らかの警備上の問題を作成して、したがって、適切に反応されるべきであった何らかの正統のICMPメッセージに反応しないかもしれません)。 それは、最小のIP MTUほど同じサイズであるパケットがあるときこの問題を完全に解決できるのが明確でもなくて、また大きくもありません。 暗号化されたパケットでICMPエラーメッセージを送るなら、同様の複雑さは起こります、そして、そのパケットは端が欠けています。

   Active attacks are now widely known to exist in the Internet [CER95].
   The presence of active attacks means that unauthenticated source
   routing, either unidirectional (receive-only) or with replies
   following the original received source route represents a significant
   security risk unless all received source routed packets are
   authenticated using the IP Authentication Header or some other
   cryptologic mechanism.  It is noteworthy that the attacks described
   in [CER95] include a subset of those described in [Bel89].

今、活発な攻撃がインターネット[CER95]に存在するのが広く知られています。 活発な攻撃の存在は、それがソースルーティングを非認証したことを意味して、すべての容認されたソース発送されたパケットがIP Authentication Headerかある他のcryptologicメカニズムを使用することで認証されるというわけではないなら、どちらかの単方向(受信専用)か回答が続いていて、元の容認された送信元経路は重要なセキュリティリスクを表します。 [CER95]で説明された攻撃が[Bel89]で説明されたものの部分集合を含んでいるのは、注目に値します。

   The use of IP tunneling with AH creates multiple pairs of endpoints
   that might perform AH processing.  Implementers and administrators
   should carefully consider the impacts of tunneling on authenticity of
   the received tunneled packets.

AHとのIPトンネリングの使用はAH処理を実行するかもしれない複数の組の終点を作成します。 Implementersと管理者は慎重に容認されたトンネルを堀られたパケットの信憑性でトンネルを堀る影響を考えるべきです。

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によって行われた仕事の利益を得ました。

   The basic concept here is derived in large part from the SNMPv2
   Security Protocol work described in [GM93].  Steve Bellovin, Steve
   Deering, Frank Kastenholz, Dave Mihelcic, and Hilarie Orman provided
   thoughtful critiques of early versions of this note.  Francis Dupont
   discovered and pointed out the security issue with ICMP in low IP MTU
   links that is noted just above.

[GM93]で説明されたSNMPv2 Securityプロトコル仕事からここの基本概念を主に得ます。 スティーブBellovin、スティーブ・デアリング、フランクKastenholz、デーヴMihelcic、およびHilarie Ormanはこの注意の早めのバージョンの考え深い批評を提供しました。 フランシス・デュポンは、低いIP MTUリンクの上にちょうど述べられるICMPの安全保障問題を発見して、指摘しました。

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 Encapsulating Security Payload", RFC 1827,
            NRL, August 1995.

[Atk95b]アトキンソン、R.、「セキュリティが有効搭載量であるとカプセル化するIP」、RFC1827、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月。

Atkinson                    Standards Track                    [Page 11]

RFC 1826                IP Authentication Header             August 1995

アトキンソンStandardsはIP認証ヘッダー1995年8月にRFC1826を追跡します[11ページ]。

   [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, pp. 21-34.

[BCCH94] ブレーデン、R.、クラーク、D.、クロッカー、S.、およびC.Huitema、「インターネットアーキテクチャにおけるセキュリティに関するIABワークショップのレポート」、RFC1636、USC/情報Sciences Institute、MIT、Trusted情報システム、INRIA、1994年6月、ページ 21-34.

   [CER95] 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 in
           /pub/cert_advisories.

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

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

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

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

   [Kno93] Knowles, Stev, "IESG Advice from Experience with Path MTU
           Discovery", RFC 1435, FTP Software, March 1993.

[Kno93] ノウルズ、Stev、「経路MTU発見の経験からのIESGアドバイス」、RFC1435、FTPソフトウェア、1993年3月。

   [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認証。」

   [MD90]  Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
           DECWRL, Stanford University, November 1990.

[MD90] ムガール人、J.とS.デアリング、「経路MTU発見」、RFC1191、DECWRL、スタンフォード大学、1990年11月。

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

   [Riv92] Rivest, R., "MD5 Digest Algorithm", RFC 1321, MIT and RSA Data
           Security, Inc., April 1992.

[Riv92] RivestとR.と「MD5ダイジェストアルゴリズム」とRFC1321とMITとRSA Data Security Inc.、1992年4月。

   [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に「ハイレベル・ネットワークにおけるセキュリティー対策」と調査します。

Atkinson                    Standards Track                    [Page 12]

RFC 1826                IP Authentication Header             August 1995

アトキンソンStandardsはIP認証ヘッダー1995年8月にRFC1826を追跡します[12ページ]。

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 INFORMATION

作者情報

   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 13]

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