RFC1968 日本語訳

Network Working Group                                           G. Meyer
Request for Comments: 1968                                Spider Systems
Category: Standards Track                                      June 1996

コメントを求めるワーキンググループG.マイヤー要求をネットワークでつないでください: 1968年のクモのシステムカテゴリ: 標準化過程1996年6月

               The PPP Encryption Control Protocol (ECP)

ppp暗号化制御プロトコル(ECP)

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

要約

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.  PPP
   also defines an extensible Link Control Protocol.

Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。 また、PPPは広げることができるLink Controlプロトコルを定義します。

   This document defines a method for negotiating data encryption over
   PPP links.

このドキュメントはPPPリンクの上のデータ暗号化を交渉するためのメソッドを定義します。

Conventions

コンベンション

   The following language conventions are used in the items of
   specification in this document:

以下の言語コンベンションは仕様に関する条項で本書では使用されます:

   o  MUST -- the item is an absolute requirement of the specification.
      MUST is only used where it is actually required for interopera-
      tion, not to try to impose a particular method on implementors
      where not required for interoperability.

o --項目は仕様に関する絶対条件であるに違いありません。 それがinteropera- tionに相互運用性に必要でないところで特定のメソッドを作成者に課そうとしないために実際に必要であるところで使用するだけでよいです。

   o  SHOULD -- the item should be followed for all but exceptional cir-
      cumstances.

o SHOULD--商品はほとんど例外的なcir- cumstancesのために従われるべきです。

   o  MAY or optional -- the item is truly optional and may be followed
      or ignored according to the needs of the implementor.

o 5月か任意である、--作成者の必要性に従って、商品は、本当に、任意であり、従われているか、または無視されるかもしれません。

      The words "should" and "may" are also used, in lower case, in
      their more ordinary senses.

また、単語の“should"と“may"は彼らの、より普通の意味で小文字に使用されます。

Meyer                       Standards Track                     [Page 1]

RFC 1968                     PPP Encryption                    June 1996

マイヤーStandardsはppp暗号化1996年6月にRFC1968を追跡します[1ページ]。

Table of Contents

目次

      1. Introduction ...........................................  2
      2. Encryption Control Protocol (ECP) ......................  2
          2.1 Sending Encrypted Datagrams .......................  3
      3. Additional Packets .....................................  4
          3.1 Reset-Request and Reset-Ack .......................  5
      4. ECP Configuration Options ..............................  6
          4.1 Proprietary Encryption OUI ........................  7
          4.2 Publicly Available Encryption Types ...............  8
          4.3 Negotiating an Encryption Algorithm ...............  9
      5. Security Considerations ................................ 10

1. 序論… 2 2. 暗号化制御プロトコル(ECP)… 2 2.1 発信はデータグラムを暗号化しました… 3 3. 追加パケット… 4 3.1のリセット要求とリセット-Ack… 5 4. ECP設定オプション… 6 4.1 独占暗号化OUI… 7 4.2 公的に手があいている暗号化タイプ… 8 4.3 暗号化アルゴリズムを交渉します… 9 5. セキュリティ問題… 10

1. Introduction

1. 序論

   In order to establish communications over a PPP link, each end of the
   link must first send LCP packets to configure and test the data link
   during Link Establishment phase.  After the link has been
   established, optional facilities may be negotiated as needed.

PPPリンクの上にコミュニケーションを確立するために、リンクの各端は、最初に、Link特権階級段階の間、構成するパケットをLCPに送って、データ・リンクをテストに送らなければなりません。 リンクが設立された後に、任意の施設は必要に応じて交渉されるかもしれません。

   One such facility is data encryption.  A wide variety of encryption
   methods may be negotiated, although typically only one method is used
   in each direction of the link.

そのような施設の1つはデータ暗号化です。 さまざまな暗号化メソッドが交渉されるかもしれません、通常唯一の1つのメソッドがリンクの各方向に使用されますが。

   A different encryption algorithm may be negotiated in each direction,
   for speed, cost, memory or other considerations.

異なった暗号化アルゴリズムは速度、費用、メモリまたは他の問題のために各方向と交渉されるかもしれません。

2. Encryption Control Protocol (ECP)

2. 暗号化制御プロトコル(ECP)

   The Encryption Control Protocol (ECP) is responsible for configuring
   and enabling data encryption algorithms on both ends of the point-
   to-point link.

Encryption Controlプロトコル(ECP)はポイントへのポイントリンクの両端でデータ暗号化アルゴリズムを構成して、可能にするのに原因となります。

   ECP uses the same packet exchange mechanism as the Link Control
   Protocol (LCP).  ECP packets may not be exchanged until PPP has
   reached the Network-Layer Protocol phase.  ECP packets received
   before this phase is reached should be silently discarded.

ECPはLink Controlプロトコル(LCP)と同じパケット交換メカニズムを使用します。 PPPがNetwork-層のプロトコルフェーズに達するまで、ECPパケットは交換されないかもしれません。 このフェーズに達する前に受け取られたECPパケットは静かに捨てられるべきです。

   The Encryption Control Protocol is exactly the same as LCP [1] with
   the following exceptions:

Encryption Controlプロトコルはまさに以下の例外でLCP[1]と同じです:

      Frame Modifications

フレーム変更

         The packet may utilise any modifications to the basic frame
         format which have been negotiated during the Link Establishment
         phase.

パケットは基本枠形式へのLink特権階級段階の間に交渉されているどんな変更も利用するかもしれません。

Meyer                       Standards Track                     [Page 2]

RFC 1968                     PPP Encryption                    June 1996

マイヤーStandardsはppp暗号化1996年6月にRFC1968を追跡します[2ページ]。

      Data Link Layer Protocol Field

データリンク層プロトコル分野

         Exactly one ECP packet is encapsulated in the PPP Information
         field, where the PPP Protocol field indicates type hex 8053
         (Encryption Control Protocol).

ちょうど1つのECPパケットがPPP情報分野でカプセルに入れられます。そこで、PPPプロトコル分野は、タイプが8053(暗号化Controlプロトコル)人に魔法をかけるのを示します。

         When individual link data encryption is used in a multiple link
         connection to a single destination [2], the PPP Protocol field
         indicates type hex 8055 (Individual link Encryption Control
         Protocol).

個々のリンクデータ暗号化が複数のリンク結合に単一の目的地[2]に使用されるとき、PPPプロトコル分野は、タイプが8055(個々のリンクEncryption Controlプロトコル)人に魔法をかけるのを示します。

      Code field

コード分野

         ECP uses (decimal) codes 1 through 7 (Configure-Request,
         Configure-Ack, Configure-Nak, Configure-Reject, Terminate-
         Request, Terminate-Ack and Code-Reject); And may also use code
         14 (Reset-Request) and code 15 (Reset-Ack).  Other codes should
         be treated as unrecognised and should result in Code-Rejects.

ECPが1〜7に(10進)のコードを使用する、(要求を構成する、Configure-Ack、Configure-Nak、Configure-廃棄物、Terminate要求、Terminate-Ack、およびCode-廃棄物)、。 そして、使用がも14(リセット要求)とコード15(リセット-Ack)をコード化しますように。 他のコードは、認識されていないとして扱われるべきであり、Code-廃棄物をもたらすべきです。

      Negotiation

交渉

         ECP packets may not be exchanged until PPP has reached the
         Network-Layer Protocol phase.  An implementation should be
         prepared to wait for Authentication and Link Quality
         Determination to finish before timing out waiting for a
         Configure-Ack or other response.

PPPがNetwork-層のプロトコルフェーズに達するまで、ECPパケットは交換されないかもしれません。 実装はAuthenticationとLink Quality Determinationが、以前タイミングが外でConfigure-Ackか他の応答を待ち終えるのを待つように準備されるべきです。

         An implementation MUST NOT transmit data until ECP negotiation
         has completed successfully.  If ECP negotiation is not
         successful the link SHOULD be brought down.

実装はECP交渉が送るまでデータを送ってはいけません。首尾よく完成されます。 SHOULDをリンクしてください。ECP交渉がうまくいかない、降ろされます。

      Configuration Option Types

設定オプションタイプ

         ECP has a distinct set of Configuration Options.

ECPには、Configuration Optionsの異なったセットがあります。

2.1 Sending Encrypted Datagrams

2.1 送付の暗号化されたデータグラム

   Before any encrypted packets may be communicated, PPP must reach the
   Network-Layer Protocol phase, and the Encryption Control Protocol
   must reach the Opened state.

どんな暗号化されたパケットも伝えられるかもしれない前に、PPPはNetwork-層のプロトコルフェーズに達しなければなりません、そして、Encryption ControlプロトコルはOpened状態に達しなければなりません。

   An encrypted packet is encapsulated in the PPP Information field,
   where the PPP Protocol field indicates type hex 0053 (Encrypted
   datagram).

暗号化されたパケットはPPP情報分野でカプセルに入れられます。そこで、PPPプロトコル分野は、タイプが0053(暗号化されたデータグラム)人に魔法をかけるのを示します。

   When using multiple PPP links to a single destination [2], there are
   two methods of employing data encryption:

単一の目的地[2]への複数のPPPリンクを使用するとき、データ暗号化を使う2つのメソッドがあります:

Meyer                       Standards Track                     [Page 3]

RFC 1968                     PPP Encryption                    June 1996

マイヤーStandardsはppp暗号化1996年6月にRFC1968を追跡します[3ページ]。

   o  The first method is to encrypt the data prior to sending it out
      through the multiple links.

o 最初のメソッドは複数のリンクを通してそれを出す前にデータを暗号化することです。

      The PPP Protocol field MUST indicate type hex 0053.

PPPプロトコル分野は、タイプが0053人に魔法をかけるのを示さなければなりません。

   o  The second is to treat each link as a separate connection, that
      may or may not have encryption enabled.

o 2番目が別々の接続として各リンクを扱うことであり、それは暗号化を可能にするかもしれません。

      On links which have negotiated encryption, the PPP Protocol field
      MUST be type hex 0055 (Individual link encrypted datagram).

暗号化を交渉したリンクの上では、PPPプロトコル分野はタイプ十六進法0055(個々のリンクはデータグラムを暗号化しました)であるに違いない。

   Only one encryption algorithm in each direction is in use at a time,
   and that is negotiated prior to sending the first encrypted frame.
   The PPP Protocol field of the encrypted datagram indicates that the
   frame is encrypted, but not the algorithm with which it was
   encrypted.

各方向への1つの暗号化アルゴリズムだけが一度に使用中です、そして、最初の暗号化されたフレームを送る前に、それは交渉されます。 暗号化されたデータグラムのPPPプロトコル分野は、フレームが暗号化されているのを示しますが、それが暗号化されたアルゴリズムは示しません。

   The maximum length of an encrypted packet transmitted over a PPP link
   is the same as the maximum length of the Information field of a PPP
   encapsulated packet.  If the encryption algorithm is likely to
   increase the size of the message beyond that, multilink should also
   be negotiated to allow fragmentation of the frames (even if only
   using a single link).

PPPリンクの上に伝えられた暗号化されたパケットの最大の長さはPPPの情報分野の最大の長さがパケットをカプセルに入れったのと同じです。 また、暗号化アルゴリズムがそれを超えてメッセージのサイズを増強しそうであるなら、マルチリンクは、フレームの断片化を許すために交渉されるべきです(単一のリンクを使用するだけであっても)。

   If the encryption algorithm carries history between frames, the
   encryption algorithm must supply a way of determining if it is
   passing data reliably, or it must require the use of a reliable
   transport such as LAPB [3].

暗号化アルゴリズムがフレームの間の歴史を運ぶなら、暗号化アルゴリズムがそれがデータを確かに通過しているかどうか決定する方法を供給しなければなりませんか、またはそれはLAPB[3]などの信頼できる輸送の使用を必要としなければなりません。

   Compression may also be negotiated using the Compression Control
   Protocol [5].  To ensure interoperability, plain text MUST be:

また、圧縮は、Compression Controlプロトコル[5]を使用することで交渉されるかもしれません。 プレーンテキストは、相互運用性を確実にするためには、以下の通りでなければなりません。

   o  First compressed.

o 最初に、圧縮されています。

   o  Then encrypted.

o そして、暗号化されています。

   This order has been chosen since it should result in smaller output
   and more secure encryption.

より小さい出力と、より安全な暗号化をもたらすべきであるので、このオーダーは選ばれました。

3. Additional Packets

3. 追加パケット

   The Packet format and basic facilities are already defined for LCP
   [1].

Packet形式と基本施設はLCP[1]のために既に定義されます。

   Up-to-date values of the ECP Code field are specified in the most
   recent "Assigned Numbers" RFC [4].  This specification concerns the
   following values:

ECP Code分野の最新の値は最新の「規定番号」RFC[4]で指定されます。 この仕様は以下の値に関係があります:

Meyer                       Standards Track                     [Page 4]

RFC 1968                     PPP Encryption                    June 1996

マイヤーStandardsはppp暗号化1996年6月にRFC1968を追跡します[4ページ]。

         14      Reset-Request
         15      Reset-Ack

14 リセット要求15リセット-Ack

3.1 Reset-Request and Reset-Ack

3.1のリセット要求とリセット-Ack

   Description

記述

      ECP includes Reset-Request and Reset-Ack Codes in order to provide
      a mechanism for indicating a decryption failure in one direction
      of a decrypted link without affecting traffic in the other
      direction.  Some encryption algorithms may not require this
      mechanism.

ECPは、もう片方の方向にトラフィックに影響しないで解読されたリンクの一方向に復号化失敗を示すのにメカニズムを提供するためにReset-要求とReset-Ack Codesを含んでいます。 いくつかの暗号化アルゴリズムはこのメカニズムを必要としないかもしれません。

      Individual algorithms need to specify a mechanism for determining
      how to detect a decryption failure.  On initial detection of a
      decryption failure, an ECP implementation SHOULD transmit an ECP
      packet with the Code field set to 14 (Reset-Request).  The Data
      field may be filled with any desired data.

独特のアルゴリズムは、復号化失敗を検出する方法を決定するのにメカニズムを指定する必要があります。 復号化失敗、SHOULDが伝えるECP実装の初期の検出のときに、Code分野があるECPパケットは14(リセット要求)にセットしました。 Data分野はどんな必要なデータでも満たされるかもしれません。

      Once a Reset-Request has been sent, any encrypted packets received
      are discarded.  Further Reset-Requests MAY be sent with the same
      Identifier, until a valid Reset-Ack is received.

いったんReset-要求を送ると、暗号化されたパケットが受けたいずれも捨てます。 有効なReset-Ackが受け取られているまで、同じIdentifierと共にさらなるReset-要求を送るかもしれません。

      When the link is busy, one decryption error is usually followed by
      several more before the Reset-Ack can be received.  It is
      undesirable to transmit Reset-Requests more frequently than the
      round-trip-time of the link, since this will result in redundant
      Reset-Requests and Reset-Acks being transmitted and processed.
      The receiver MAY elect to limit transmission of Reset-Requests (to
      say one per second) while a Reset-Ack is outstanding.

リンクが忙しいときに、Reset-Ackを受け取ることができる前に通常、さらに数個が1つの復号化誤りのあとに続いています。 リンクの往復の時間よりReset-要求頻繁に伝わるのは望ましくありません、これが余分なReset-要求と伝えられて、処理されるReset-Acksをもたらすので。 受信機は、Reset-Ackが傑出している間、Reset-要求(1秒あたり1つを言う)の伝達を制限するのを選ぶかもしれません。

      Upon reception of a Reset-Request, the transmitting encrypter is
      reset to an initial state.  An ECP packet MUST be transmitted with
      the Code field set to 15 (Reset-Ack), the Identifier field copied
      from the Reset-Request packet, and the Data field filled with any
      desired data.

Reset-要求のレセプションでは、伝わっているencrypterは初期状態にリセットされます。 Code分野セットで15(リセット-Ack)にECPパケットを伝えなければなりませんでした、そして、Identifier分野はReset-リクエスト・パケットからコピーされました、そして、Data分野はどんな必要なデータでも満ちました。

      On receipt of a Reset-Ack, the receiving decrypter is reset to an
      initial state.  Since there may be several Reset-Acks in the pipe,
      the decrypter MUST be reset for each Reset-Ack which matches the
      currently expected identifier.

Reset-Ackを受け取り次第、受信はより多くのdecrypterに初期状態にリセットされます。 数個のReset-Acksがパイプにあるかもしれないので、現在予想された識別子に合っている各Reset-Ackのためにdecrypterをリセットしなければなりません。

      A summary of the Reset-Request and Reset-Ack packet formats is
      shown below.  The fields are transmitted from left to right.

Reset-要求とReset-Ackパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。

Meyer                       Standards Track                     [Page 5]

RFC 1968                     PPP Encryption                    June 1996

マイヤーStandardsはppp暗号化1996年6月にRFC1968を追跡します[5ページ]。

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Code      |  Identifier   |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Data ...
       +-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+

   Code

コード

      14 for Reset-Request;

14 リセット要求のために。

      15 for Reset-Ack.

15 リセット-Ackのために。

   Identifier

識別子

      On transmission, the Identifier field MUST be changed whenever the
      content of the Data field changes, and whenever a valid reply has
      been received for a previous request.  For retransmissions, the
      Identifier SHOULD remain unchanged.

トランスミッションのときに、Data分野の内容が変化するときはいつも、Identifier分野を変えなければならなくて、a有効であるときはいつも、前の要求のために回答を受け取りました。 「再-トランスミッション」に関しては、Identifier SHOULDは変わりがありません。

      On reception, the Identifier field of the Reset-Request is copied
      into the Identifier field of the Reset-Ack packet.

レセプションでは、Reset-要求のIdentifier分野はReset-AckパケットのIdentifier分野にコピーされます。

   Data

データ

      The Data field is zero or more octets and contains uninterpreted
      data for use by the sender.  The data may consist of any binary
      value and may be of any length from zero to the peer's established
      MRU minus four.

Data分野は、ゼロか、より多くの八重奏であり、送付者による使用のために非解釈されたデータを含んでいます。 データは、どんな2進の価値からも成って、ゼロ〜確立した同輩のMRUまで4を引いたどんな長さのものであるかもしれません。

4. ECP Configuration Options

4. ECP設定オプション

   ECP Configuration Options allow negotiation of encryption algorithms
   and their parameters.  ECP uses the same Configuration Option format
   defined for LCP [1], with a separate set of Options.

ECP Configuration Optionsは暗号化アルゴリズムとそれらのパラメタの交渉を許します。 ECPはLCP[1]のためにOptionsの別々のセットで定義された同じConfiguration Option書式を使用します。

   Configuration Options, in this protocol, indicate algorithms that the
   receiver is willing or able to use to decrypt data sent by the
   sender.  Systems may offer to accept several algorithms, and
   negotiate a single one that will be used.

このプロトコルで、構成Optionsは受信機が望んでいるか、または送付者によって送られたデータを解読するのに使用できるアルゴリズムを示します。 システムは、いくつかのアルゴリズムを受け入れると申し出て、使用されるただ一つのものを交渉するかもしれません。

   Up-to-date values of the ECP Option Type field are specified in the
   most recent "Assigned Numbers" RFC [4].  Current values are assigned
   as follows:

ECP Option Type分野の最新の値は最新の「規定番号」RFC[4]で指定されます。 現行価値は以下の通り割り当てられます:

Meyer                       Standards Track                     [Page 6]

RFC 1968                     PPP Encryption                    June 1996

マイヤーStandardsはppp暗号化1996年6月にRFC1968を追跡します[6ページ]。

         ECP Option      Encryption type

ECP Option Encryptionはタイプします。

         0               OUI
         1               DESE

0 OUI1DESE

   All compliant ECP implementations SHOULD implement ECP option 1 - the
   PPP DES Encryption Protocol (DESE) [6].

すべての言いなりになっているECP実装SHOULDが、ECPがオプション1であると実装します--PPP DES Encryptionプロトコル(DESE)[6]。

   Vendors who want to use proprietary encryption MAY use the OUI
   mechanism to negotiate these without recourse to requesting an
   assigned option number from the Internet Assigned Numbers Authority.
   All other encryption options are registered by IANA.  At the time of
   writing only DESE (option 1) is registered.  Other registered options
   may be found by referring to future versions of the Assigned Numbers
   RFC.

独占暗号化を使用したがっているベンダーは、償還請求なしでインターネットAssigned民数記Authorityから割り当てられたオプション番号を要求するとこれらを交渉するのにOUIメカニズムを使用するかもしれません。 他のすべての暗号化オプションがIANAによって登録されます。 これを書いている時点でDESE(オプション1)だけが登録されています。 他の登録されたオプションは、Assigned民数記RFCの将来のバージョンを示すことによって、見つけられるかもしれません。

4.1 Proprietary Encryption OUI

4.1 独占暗号化OUI

   Description

記述

      This Configuration Option provides a way to negotiate the use of a
      proprietary encryption protocol.

このConfiguration Optionは独占暗号化プロトコルの使用を交渉する方法を提供します。

      Vendor's encryption protocols are distinguished from each other by
      means of an Organisationally Unique Identifier (OUI), namely the
      first three octets of a Vendor's Ethernet address assigned by IEEE
      802.

ベンダーの暗号化プロトコルはすなわち、Organisationally Unique Identifier(OUI)、IEEE802によって割り当てられたVendorのイーサネット・アドレスの最初の3つの八重奏によって互いと区別されます。

      Since the first matching encryption will be used, it is
      recommended that any known OUI encryption options be transmitted
      first, before the common options are used.

最初の合っている暗号化が使用されるので、どんな知られているOUI暗号化オプションも最初に伝えられるのは、お勧めです、一般的なオプションが使用されている前に。

      Before accepting this option, the implementation must verify that
      the OUI identifies a proprietary algorithm that the implementation
      can decrypt, and that any vendor specific negotiation values are
      fully understood.

このオプションを受け入れる前に、実装は、OUIが実装が解読することができる独占アルゴリズムを特定して、どんなベンダーの特定の交渉値も完全に理解されていることを確かめなければなりません。

      A summary of the Proprietary Encryption OUI Configuration Option
      format is shown below.  The fields are transmitted from left to
      right.

Proprietary Encryption OUI Configuration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。

Meyer                       Standards Track                     [Page 7]

RFC 1968                     PPP Encryption                    June 1996

マイヤーStandardsはppp暗号化1996年6月にRFC1968を追跡します[7ページ]。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |       OUI ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            OUI       |    Subtype    |  Values...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| OUI… +++++++++++++++++++++++++++++++++OUI| Subtype| 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

タイプ

       0

0

   Length

長さ

      >= 6

>= 6

   IEEE OUI

IEEE OUI

      The IEEE OUI is the most significant three octets of an Ethernet
      Physical Address, assigned to the vendor by IEEE 802.  This
      identifies the option as being proprietary to the indicated
      vendor.  The bits within the octet are in canonical order, and the
      most significant octet is transmitted first.

IEEE OUIはIEEE802によってベンダーに配属されたイーサネットPhysical Addressの最も重要な3つの八重奏です。 これは示されたベンダーに独占であるとしてオプションを特定します。 八重奏の中のビットが正準なオーダーにあります、そして、最も重要な八重奏は最初に、伝えられます。

   Subtype

Subtype

      This field is specific to each OUI, and indicates an encryption
      type for that OUI.  There is no standardisation for this field.
      Each OUI implements its own values.

この分野は、各OUIに特定であり、そのOUIのために暗号化タイプを示します。 この分野のための規格化が全くありません。 各OUIはそれ自身の値を実装します。

   Values

値

      This field is zero or more octets, and contains additional data as
      determined by the vendor's encryption protocol.

この分野は、ゼロか、より多くの八重奏であり、ベンダーの暗号化プロトコルで決定するように追加データを含んでいます。

4.2 Publicly Available Encryption Types

4.2 公的に手があいている暗号化タイプ

   Description

記述

      These Configuration Options provide a way to negotiate the use of
      a publicly defined encryption algorithm.

これらのConfiguration Optionsは公的に定義された暗号化アルゴリズムの使用を交渉する方法を提供します。

      These protocols should be made available to interested parties,
      but may have certain licencing or export restrictions associated
      with them.  For additional information, refer to the encryption
      protocol documents that define each of the encryption types.

これらのプロトコルには、利害関係者にとって利用可能に作られているべきですが、それらに関連しているあるlicencingか輸出制限があるかもしれません。 追加情報について、暗号化タイプ各人を定義する暗号化プロトコルドキュメントを参照してください。

Meyer                       Standards Track                     [Page 8]

RFC 1968                     PPP Encryption                    June 1996

マイヤーStandardsはppp暗号化1996年6月にRFC1968を追跡します[8ページ]。

      A summary of the Encryption Type Configuration Option format is
      shown below.  The fields are transmitted from left to right.

Encryption Type Configuration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |  Values...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

    Type

タイプ

       1 to 254, indicating the encryption protocol option
       being negotiated.  DESE [6] is option type 1.  Refer to the
       latest Assigned Numbers RFC for other encryption protocols.

交渉される暗号化プロトコルオプションを示す1〜254。 DESE[6]はオプションタイプ1です。 他の暗号化プロトコルについて最新のAssigned民数記RFCを参照してください。

    Length

長さ

       >= 2

>= 2

   Values

値

      This field is zero or more octets, and contains additional data as
      determined by the encryption protocol.

この分野は、ゼロか、より多くの八重奏であり、暗号化プロトコルで決定するように追加データを含んでいます。

4.3 Negotiating an Encryption Algorithm

4.3 暗号化アルゴリズムを交渉すること。

   ECP uses LCP option negotiation techniques to negotiate encryption
   algorithms.  In contrast with most other LCP or NCP negotiation of
   multiple options, ECP negotiation is expected to converge on a single
   mutually agreeable option (encryption algorithm) - or none.
   Encryption SHOULD be negotiated in both directions, but the
   algorithms MAY be different.

ECPは、暗号化アルゴリズムを交渉するのにLCPオプション交渉術を使用します。複数のオプションの他のほとんどのLCPかNCP交渉と比べて、ECP交渉がただ一つの互いに快いオプション(暗号化アルゴリズム)、またはなにも集まらないと予想されます。 暗号化SHOULDが両方の方向と交渉されて、アルゴリズムだけが異なっているかもしれません。

   An implementation willing to decrypt using a particular encryption
   algorithm (or one of a set of algorithms) offers the algorithm(s) as
   an option (or options) in an ECP Configure-Request - call this end
   the Decrypter; call the peer the Encrypter.

使用が特定の暗号化アルゴリズムであると解読しても(または、1セットのアルゴリズムの1つ)構わないと思っている実装はECP Configure-要求におけるオプション(または、オプション)としてアルゴリズムを提供します--Decrypterにこの終わりに電話をしてください。 同輩をEncrypterと呼んでください。

   A Decrypter supporting more than one encryption algorithm may send a
   Configure-Request containing either:

1つ以上の暗号化アルゴリズムをサポートするDecrypterはどちらかを含むConfigure-要求を送るかもしれません:

   o  an ordered list of options, with the most-preferred encryption
      algorithm coming first.

o 最も都合のよい暗号化アルゴリズムが一番になっているオプションの規則正しいリスト。

   o  Or may just offer its preferred (not already Rejected) option.

o または、ただ、都合のよい(既にRejectedでない)オプションを提供するかもしれません。

Meyer                       Standards Track                     [Page 9]

RFC 1968                     PPP Encryption                    June 1996

マイヤーStandardsはppp暗号化1996年6月にRFC1968を追跡します[9ページ]。

   An Encrypter wishing to accept the first option (of several) MAY
   Configure-Ack ALL Options to indicate complete acceptance of the
   first-listed, preferred, algorithm.

最初のオプション(数個の)5月のConfigure-Ackのときに最初に、記載されて、都合のよいアルゴリズムの完全な承認を示すためにすべてのOptionsを受け入れたがっているEncrypter。

   Otherwise, if the Encrypter does not recognise - or is unwilling to
   support - an option it MUST send a Configure-Reject for that option.
   Where more than one option is offered, the Encrypter SHOULD
   Configure-Reject all but a single preferred option.

そうでなければ、Encrypterが認識しないか、または不本意である、サポート--それがそのオプションのためにConfigure-廃棄物を送らなければならないオプション。 1つ以上のオプションを提供するところでは、シングル以外のすべてが好んだEncrypter SHOULD Configure-廃棄物ゆだねます。

   If the Encrypter Configure-Rejects all offered ECP options - and the
   Decrypter has no further (non-rejected) options it can offer in a
   Configure-Request - the Encrypter SHOULD take the link down.

Encrypter Configure-廃棄物がすべて、オプションをECPに提供したなら(そして、Decrypterには、それがConfigure-要求で提供できる(非拒絶される)のオプションがこれ以上ありません)、Encrypter SHOULDはリンクを降ろします。

   If the Encrypter recognises an option, but it is not acceptable due
   to values in the request (or optional parameters not in the request),
   it MUST send a Configure-Nak with the option modified appropriately.
   The Configure-Nak MUST contain only those options that will be
   acceptable.  The Decrypter SHOULD send a new Configure-Request with
   only the single preferred option, adjusted as specified in the
   Configure-Nak.

Encrypterがオプションを認識しますが、それが要求(または、要求でないのにおける任意のパラメタ)における値のために許容できないなら、オプションが適切に変更されている状態で、それはConfigure-Nakを送らなければなりません。 Configure-Nakはそれらの許容できるオプションだけを含まなければなりません。 Decrypter SHOULDはConfigure-Nakで指定されるように調整されたただ一つの都合のよいオプションだけと共に新しいConfigure-要求を送ります。

5. Security Considerations

5. セキュリティ問題

   Negotiation of encryption using PPP is designed to provide protection
   against eavesdropping on that link.  The strength of the protection
   is dependent on the encryption algorithm used and the care with which
   any 'secret' used by the encryption algorithm is protected.

PPPを使用する暗号化の交渉は、そのリンクを立ち聞きすることに対する保護を提供するように設計されています。 保護の強さは暗号化アルゴリズムで使用されるどんな'秘密'も保護される働く暗号化アルゴリズムと注意に依存しています。

   It must be recognised that complete security can only be obtained
   through end-to-end security between hosts.

終わりから終わりへのセキュリティを通して完全なセキュリティをホストの間に得ることができるだけであると認めなければなりません。

References

参照

   [1]  Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", STD
        51, RFC 1661, Daydreamer, July 1994.

[1] シンプソン、W.、エディタ。 「二地点間プロトコル(ppp)」、STD51、RFC1661、空想家、1994年7月。

   [2]  Sklower, K., Lloyd, B., McGregor, G. and and D. Carr, "The PPP
        Multilink Protocol (MP)", RFC 1717, University of California,
        Berkeley, November 1994.

そして、そして、[2]Sklower、K.、ロイド、B.、マクレガー、G.、D.カー、「pppマルチリンクは(MP)について議定書の中で述べます」、RFC1717、カリフォルニア大学バークレイ校1994年11月。

   [3]  Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
        1994.

[3] 底ならし革、D.、「pppの信頼できる送信」、RFC1663、ノベル、1994年7月。

   [4]  Reynolds, J., and Postel, J.; "ASSIGNED NUMBERS", STD 2,
        RFC 1700, USC/Information Sciences Institute, October 1994.

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

   [5]  Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
        1962, Novell, June 1996.

[5] 底ならし革、D.、「ppp圧縮制御プロトコル(CCP)」、RFC1962、ノベル、1996年6月。

Meyer                       Standards Track                    [Page 10]

RFC 1968                     PPP Encryption                    June 1996

マイヤーStandardsはppp暗号化1996年6月にRFC1968を追跡します[10ページ]。

   [6]  Sklower, K., and G. Meyer, "The PPP DES Encryption Protocol
        (DESE)", RFC 1969, University of California, Berkeley, June
        1996.

[6]Sklower、K.、およびG.マイヤー、「ppp DES暗号化プロトコル(DESE)」、RFC1969カリフォルニア大学バークレイ校1996年6月。

Acknowledgements

承認

   The style and approach of this proposal owes much to the work on the
   Compression CP [5].

この提案のスタイルとアプローチはCompression CP[5]への作業から多くを借りています。

Chair's Address

議長のアドレス

   The working group can be contacted via the current chair:

現在のいすを通してワーキンググループに連絡できます:

   Karl Fox
   Ascend Communications
   3518 Riverside Drive, Suite 101
   Columbus, Ohio 43221

カールフォックスはオハイオ コミュニケーション3518リバーサイド・ドライブ、Suite101コロンブス、43221を昇ります。

   EMail: karl@ascend.com

メール: karl@ascend.com

Author's Address

作者のアドレス

   Gerry Meyer
   Spider Systems
   Stanwell Street
   Edinburgh EH6 5NG
   Scotland, UK

ゲリー・マイヤー・Spider Systems Stanwell通りエディンバラEH6 5NGスコットランド、イギリス

   Phone: (UK) 131 554 9424
   Fax:   (UK) 131 554 0649
   EMail: gerry@spider.co.uk

以下に電話をしてください。 (イギリス) 131 554、9424Fax: (イギリス) 0649年の131 554メール: gerry@spider.co.uk

Meyer                       Standards Track                    [Page 11]

マイヤー標準化過程[11ページ]