RFC2419 日本語訳

Network Working Group                                         K. Sklower
Request for Comments: 2419            University of California, Berkeley
Obsoletes: 1969                                                 G. Meyer
Category: Standards Track                                          Shiva
                                                          September 1998

Sklowerがコメントのために要求するワーキンググループK.をネットワークでつないでください: 2419 カリフォルニア大学バークレイ校は以下を時代遅れにします。 1969年のG.マイヤーカテゴリ: 標準化過程シバ神1998年9月

         The PPP DES Encryption Protocol, Version 2 (DESE-bis)

ppp DES暗号化プロトコル、バージョン2(2回DESE)

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

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

Abstract

要約

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

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

   The PPP Encryption Control Protocol (ECP) [2] provides a method to
   negotiate and utilize encryption protocols over PPP encapsulated
   links.

PPP Encryption Controlプロトコル(ECP)[2]はリンクであるとカプセル化されたPPPの上で暗号化プロトコルを交渉して、利用するメソッドを提供します。

   This document provides specific details for the use of the DES
   standard [5, 6] for encrypting PPP encapsulated packets.

このドキュメントはパケットであるとカプセル化されたPPPを暗号化するDES規格[5、6]の使用のための特定の詳細を明らかにします。

Acknowledgements

承認

   The authors extend hearty thanks to Fred Baker of Cisco, Philip
   Rakity of Flowpoint, and William Simpson of Daydreamer for helpful
   improvements to the clarity and correctness of the document.

作者はシスコのフレッド・ベイカー、FlowpointのフィリップRakity、およびDaydreamerのウィリアム・シンプソンのおかげでドキュメントの明快と正当性への役立っている改良において心からで広がります。

Table of Contents

目次

   1. Introduction ................................................  2
   1.1. Motivation ................................................  2
   1.2. Conventions ...............................................  2
   2. General Overview ............................................  2
   3. Structure of This Specification .............................  4
   4. DESE Configuration Option for ECP ...........................  4
   5. Packet Format for DESE ......................................  5

1. 序論… 2 1.1. 動機… 2 1.2. コンベンション… 2 2. 概要… 2 3. この仕様の構造… 4 4. ECPのためのDESE設定オプション… 4 5. DESEのためのパケット形式… 5

Sklower & Meyer             Standards Track                     [Page 1]

RFC 2419                 PPP DES Encryption v2            September 1998

SklowerとマイヤーStandards Track[1ページ]RFC2419PPP DES Encryption v2 September 1998

   6. Encryption ..................................................  6
   6.1. Padding Considerations ....................................  7
   6.2. Generation of the Ciphertext ..............................  8
   6.3. Retrieval of the Plaintext ................................  8
   6.4. Recovery after Packet Loss ................................  8
   7. MRU Considerations ..........................................  9
   8. Differences from RFC 1969 ...................................  9
   8.1. When to Pad ...............................................  9
   8.2. Assigned Numbers ..........................................  9
   8.3. Minor Editorial Changes ...................................  9
   9. Security Considerations .....................................  9
   10. References ................................................. 10
   11. Authors' Addresses ......................................... 11
   12. Full Copyright Statement ................................... 12

6. 暗号化… 6 6.1. 問題を水増しします… 7 6.2. 暗号文の世代… 8 6.3. 平文の検索… 8 6.4. パケット損失の後の回復… 8 7. MRU問題… 9 8. RFC1969からの違い… 9 8.1. パッドに… 9 8.2. 数を割り当てます… 9 8.3. 小さい方の社説は変化します… 9 9. セキュリティ問題… 9 10. 参照… 10 11. 作者のアドレス… 11 12. 完全な著作権宣言文… 12

1.  Introduction

1. 序論

1.1.  Motivation

1.1. 動機

   The purpose of this memo is two-fold: to show how one specifies the
   necessary details of a "data" or "bearer" protocol given the context
   of the generic PPP Encryption Control Protocol, and also to provide
   at least one commonly-understood means of secure data transmission
   between PPP implementations.

このメモの目的は二面です: ジェネリックPPP Encryption Controlプロトコルの文脈を考えて、1つがどう「データ」か「運搬人」プロトコルの必要な詳細を指定するかを示していて、また、提供するために、少なくともあるものは一般的にPPP実装の間の安全なデータ伝送の手段を理解していました。

   The DES encryption algorithm is a well studied, understood and widely
   implemented encryption algorithm.  The DES cipher was designed for
   efficient implementation in hardware, and consequently may be
   relatively expensive to implement in software.  However, its
   pervasiveness makes it seem like a reasonable choice for a "model"
   encryption protocol.

DES暗号化アルゴリズムはよく研究された、理解されている、広く実装している暗号化アルゴリズムです。 DES暗号は、ハードウェアの効率的な実装のために設計されて、その結果、ソフトウェアで実装するために比較的高価であるかもしれません。 しかしながら、普及は「モデル」暗号化プロトコルのための正当な選択のように見えるようにします。

   Source code implementing DES in the "Electronic Code Book Mode" can be
   found in [7].  US export laws forbid the inclusion of
   compilation-ready source code in this document.

[7]で「電子コードブックモード」でDESを実装するソースコードは見つけることができます。 米国輸出法は本書では編集持ち合わせのソースコードの包含を禁じます。

1.2.  Conventions

1.2. コンベンション

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [8].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[8]で説明されるように本書では解釈されることであるべきですか?

2.  General Overview

2. 概要

   The purpose of encrypting packets exchanged between two PPP
   implementations is to attempt to insure the privacy of communication
   conducted via the two implementations.  The encryption process
   depends on the specification of an encryption algorithm and a shared

2つのPPP実装の間で交換されたパケットを暗号化する目的は2つの実装で行われたコミュニケーションのプライバシーを保障するのを試みることです。 暗号化プロセスは共有された暗号化アルゴリズムとaの仕様によります。

Sklower & Meyer             Standards Track                     [Page 2]

RFC 2419                 PPP DES Encryption v2            September 1998

SklowerとマイヤーStandards Track[2ページ]RFC2419PPP DES Encryption v2 September 1998

   secret (usually involving at least a key) between the sender and
   receiver.

送付者と受信機の間で秘密です(通常、少なくともキーにかかわります)。

   Generally, the encryptor will take a PPP packet including the
   protocol field, apply the chosen encryption algorithm, place the
   resulting cipher text (and in this specification, an explicit
   sequence number) in the information field of another PPP packet.  The
   decryptor will apply the inverse algorithm and interpret the
   resulting plain text as if it were a PPP packet which had arrived
   directly on the interface.

一般に、暗号化する人はプロトコル分野を含むPPPパケットを持って行って、選ばれた暗号化アルゴリズムを適用してください、そして、結果として起こる暗号テキスト(この仕様の明白な一連番号)を別のPPPパケットの情報フィールドに置いてください。 decryptorはまるでそれが直接インタフェースで到着したPPPパケットであるかのように、逆さのアルゴリズムを適用して、結果として起こるプレーンテキストを解釈するでしょう。

   The means by which the secret becomes known to both communicating
   elements is beyond the scope of this document; usually some form of
   manual configuration is involved.  Implementations might make use of
   PPP authentication, or the EndPoint Identifier Option described in
   PPP Multilink [3], as factors in selecting the shared secret.  If the
   secret can be deduced by analysis of the communication between the
   two parties, then no privacy is guaranteed.

秘密がともに要素を伝えるのに知られるようになる手段はこのドキュメントの範囲を超えています。 通常、何らかのフォームの手動の構成はかかわります。 実装はPPP認証、またはPPP Multilink[3]で説明されたEndPoint Identifier Optionを利用するかもしれません、共有秘密キーを選択する要素として。 2回のパーティーのコミュニケーションの分析で秘密を推論できるなら、プライバシーは全く保証されません。

   While the US Data Encryption Standard (DES) algorithm [5, 6] provides
   multiple modes of use, this specification selects the use of only one
   mode in conjunction with the PPP Encryption Control Protocol (ECP):
   the Cipher Block Chaining (CBC) mode.  In addition to the US
   Government publications cited above, the CBC mode is also discussed
   in [7], although no C source code is provided for it per se.

米国データ暗号化規格(DES)アルゴリズム[5、6]は使用の複数の方法を提供しますが、この仕様はPPP Encryption Controlプロトコル(ECP)に関連して1つのモードだけの使用を選択します: Cipher Block Chaining(CBC)モード。 また、上で引用された米国政府刊行物に加えて、[7]でCBCモードについて議論します、そういうものとしてCソースコードを全くそれに提供しませんが。

   The initialization vector for this mode is deduced from an explicit
   64-bit nonce, which is exchanged in the clear during the negotiation
   phase.  The 56-bit key required by all DES modes is established as a
   shared secret between the implementations.

このモードのための初期化ベクトルは明白な64ビットの一回だけから推論されます。(それは、交渉段階の間の明確で交換されます)。 すべてのDESモードによって必要とされた56ビットのキーは実装の間の共有秘密キーと書き立てられます。

   One reason for choosing the chaining mode is that it is generally
   thought to require more computation resources to deduce a 64 bit key
   used for DES encryption by analysis of the encrypted communication
   stream when chaining mode is used, compared with the situation where
   each block is encrypted separately with no chaining.  Certainly,
   identical sequences of plaintext will produce different ciphers when
   chaining mode is in effect, thus complicating analysis.

推論モードを選ぶ1つの理由は推論モードが状況と比べて使用されるとき、一般に、各ブロックが別々に推論なしでどこに暗号化されるかがDES暗号化に暗号化通信ストリームの分析で使用される64ビットのキーを推論するために、より多くの計算リソースを必要とすると考えられるということです。 推論モードが有効であるときに、確かに、平文の同じ系列は異なった暗号を作成して、その結果、分析を複雑にするでしょう。

   However, if chaining is to extend beyond packet boundaries, both the
   sender and receiver must agree on the order the packets were
   encrypted.  Thus, this specification provides for an explicit 16 bit
   sequence number to sequence decryption of the packets.  This mode of
   operation even allows recovery from occasional packet loss; details
   are also given below.

しかしながら、推論がパケット境界を超えて広がるつもりであるなら、送付者と受信機の両方が、オーダーのときにパケットが暗号化されたのに同意しなければなりません。 したがって、この仕様は16ビットの明白な一連番号にパケットの系列復号化に備えます。 この運転モードは時々のパケット損失からの回復を許しさえします。 また、詳細は以下に述べられます。

Sklower & Meyer             Standards Track                     [Page 3]

RFC 2419                 PPP DES Encryption v2            September 1998

SklowerとマイヤーStandards Track[3ページ]RFC2419PPP DES Encryption v2 September 1998

3.  Structure of This Specification

3. この仕様の構造

   The PPP Encryption Control Protocol (ECP), provides a framework for
   negotiating parameters associated with encryption, such as choosing
   the algorithm.  It specifies the assigned numbers to be used as PPP
   protocol numbers for the "data packets" to be carried as the
   associated "data protocol", and describes the state machine.

PPP Encryption Controlプロトコル(ECP)、アルゴリズムを選ぶことなどの暗号化に関連しているパラメタを交渉するのにフレームワークを提供します。 それは、PPPが「データ・パケット」が関連「データプロトコル」として運ばれるために数について議定書の中で述べるので使用されるために規定番号を指定して、州のマシンについて説明します。

   Thus, a specification for use in that matrix need only describe any
   additional configuration options required to specify a particular
   algorithm, and the process by which one encrypts/decrypts the
   information once the Opened state has been achieved.

したがって、そのマトリクスにおける使用のための仕様は特定のアルゴリズムを指定するのに必要である追加設定オプションについて説明するだけでよくて、どれが、かつて情報がOpened状態であると暗号化するか、または解読するかによってプロセスは実現されました。

4.  DESE Configuration Option for ECP

4. ECPのためのDESE設定オプション

   Description

記述

        The ECP DESE Configuration Option indicates that the issuing
        implementation is offering to employ this specification for
        decrypting communications on the link, and may be thought of as
        a request for its peer to encrypt packets in this manner.

ECP DESE Configuration Optionは、発行実装がリンクに関するコミュニケーションを解読するためのこの仕様を使うと申し出ていて、同輩がこの様にパケットを暗号化するという要求として考えられるかもしれないのを示します。

        The ECP DESE Configuration Option has the following fields,
        which are transmitted from left to right:

ECP DESE Configuration Optionには、以下の野原がいます:(その野原は、左から右まで伝えられます)。

                    Figure 1:  ECP DESE Configuration Option

図1: ECP DESE設定オプション

        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 = 3    |    Length     |         Initial Nonce ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =3をタイプしてください。| 長さ| 一回だけに頭文字をつけてください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type

タイプ

             Type = 3, to indicate the DESE-bis protocol.  The former
             value 1 indicating the previous DESE specification is
             deprecated, i.e.  systems implementing this specification
             MUST NOT offer the former value 1 in a configure-request
             and MUST configure-reject the former value on receipt of a
             configure-request containing it.

=3をタイプして、2回DESEプロトコルを示してください。 そして、前のDESE仕様を示す前の値1が推奨しない、すなわち、この仕様を履行するシステムがaで要求を構成で前の値1を提供してはいけない、廃棄物を構成する、それを含むaを受け取り次第要求を構成している前の値でなければならない。

        Length

長さ

             10

10

Sklower & Meyer             Standards Track                     [Page 4]

RFC 2419                 PPP DES Encryption v2            September 1998

SklowerとマイヤーStandards Track[4ページ]RFC2419PPP DES Encryption v2 September 1998

        Initial Nonce

初期の一回だけ

             This field is an 8 byte quantity which is used by the peer
             implementation to encrypt the first packet transmitted
             after the sender reaches the opened state.

この分野は同輩実装によって使用される、送付者が開かれた状態に着いた後に伝えられた最初のパケットを暗号化する8バイトの量です。

             To guard against replay attacks, the implementation SHOULD
             offer a different value during each ECP negotiation.  An
             example might be to use the number of seconds since Jan
             1st, 1970 (GMT/UT) in the upper 32 bits, and the current
             number of nanoseconds relative to the last second mark in
             the lower 32 bits.

反射攻撃に用心するために、実装SHOULDはそれぞれのECP交渉の間、異価を提供します。 例が1970年1月1日以来の秒数を使用することであるかもしれない、(グリニッジ標準時の/、ユタ) 上側の32ビット、および低級32ビットでの最後の瞬間のマークに比例した数ナノ秒の最新号で。

             Its formulaic role is described in the Encryption section
             below.

公式の役割は下のEncryption部で説明されます。

5.  Packet Format for DESE

5. DESEのためのパケット・フォーマット

   Description

記述

        The DESE packets themselves have the following fields:

DESEパケット自体には、以下の分野があります:

                  Figure 2:  DES Encryption Protocol Packet Format

図2: DES暗号化プロトコルパケット・フォーマット

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Address    |    Control    |     0000      |  Protocol ID  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Seq. No. High | Seq. No. Low  |        Ciphertext ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス| コントロール| 0000 | プロトコルID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq。 いいえ 高値| Seq。 いいえ 安値| 暗号文… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Address and Control

アドレスとコントロール

             These fields MUST be present unless the PPP Address and
             Control Field Compression option (ACFC) has been
             negotiated.

PPP AddressとControl Field Compressionオプション(ACFC)が交渉されていない場合、これらの分野は存在していなければなりません。

        Protocol ID

プロトコルID

             The value of this field is 0x53 or 0x55; the latter
             indicates that ciphertext includes headers for the
             Multilink Protocol, and REQUIRES that the Individual Link
             Encryption Control Protocol has reached the opened state.
             The leading zero MAY be absent if the PPP Protocol Field
             Compression option (PFC) has been negotiated.

この分野の値は、0×53か0×55です。 後者は、暗号文がMultilinkプロトコルのためのヘッダーを含んでいるのを示します、そして、Individual Link Encryption ControlプロトコルにはあるREQUIRESは開かれた状態に達しました。 PPPプロトコルField Compressionオプション(PFC)が交渉されたなら、先行ゼロは欠けているかもしれません。

Sklower & Meyer             Standards Track                     [Page 5]

RFC 2419                 PPP DES Encryption v2            September 1998

SklowerとマイヤーStandards Track[5ページ]RFC2419PPP DES Encryption v2 September 1998

        Sequence Number

一連番号

             These 16-bit numbers are assigned by the encryptor
             sequentially starting with 0 (for the first packet
             transmitted once ECP has reached the opened state.

0から始まって、これらの16ビットの数は暗号化する人によって連続して割り当てられます。(一度伝えられた最初のパケットに関しては、ECPは開かれた状態に達しました。

        Ciphertext

暗号文

             The generation of this data is described in the next
             section.

このデータの世代は次のセクションで説明されます。

6.  Encryption

6. 暗号化

   Once the ECP has reached the Opened state, the sender MUST NOT apply
   the encryption procedure to LCP packets nor ECP packets.

一度ECPはOpened状態に達したことがあって、送付者は暗号化手順をLCPパケットに適用してはいけません。または、ECPパケット。

   If the async control character map option has been negotiated on the
   link, the sender applies mapping after the encryption algorithm has
   been run.

async制御文字地図オプションがリンクに関して交渉されたなら、暗号化アルゴリズムを実行してある後に送付者はマッピングを適用します。

   The encryption algorithm is generally to pad the Protocol and
   Information fields of a PPP packet to some multiple of 8 bytes, and
   apply DES in Chaining Block Cipher mode with a 56-bit key K.

暗号化アルゴリズムは、一般に、PPPパケットのプロトコルと情報分野を8バイトの何らかの倍数に水増しして、56ビットの主要なKでChaining Block CipherモードでDESを適用することです。

   There are a lot of details concerning what constitutes the Protocol
   and Information fields, in the presence or non-presence of Multilink,
   and whether the ACFC and PFC options have been negotiated, and the
   sort of padding chosen.

何がMultilinkの存在か非前のプロトコルと情報分野を構成するか、そして、ACFCとPFCオプションが交渉されたかどうかに関する多くの詳細、および選ばれる状態でそっと歩く種類があります。

   Regardless of whether ACFC has been negotiated on the link, the
   sender applies the encryption procedure to only that portion of the
   packet excluding the address and control field.

ACFCがリンクに関して交渉されたかどうかにかかわらず、送付者はアドレスと制御フィールドを除いたパケットのその一部だけに暗号化手順を適用します。

   If the Multilink Protocol has been negotiated and encryption is to be
   construed as being applied to each link separately, then the
   encryption procedure is to be applied to the (possibly extended)
   protocol and information fields of the packet in the Multilink
   Protocol.

暗号化手順は暗号化がMultilinkプロトコルが交渉されて、別々にそれぞれリンクするために適用されるのに理解されることであるならMultilinkプロトコルでパケットの(ことによると広げられます)のプロトコルと情報フィールドに適用されることです。

   If the Multilink Protocol has been negotiated and encryption is to be
   construed as being applied to the bundle, then the multilink
   procedure is to be applied to the resulting DESE packets.

マルチリンク手順は暗号化がMultilinkプロトコルが交渉されて、バンドルに適用されるのに理解されることであるなら結果として起こるDESEパケットに適用されることです。

Sklower & Meyer             Standards Track                     [Page 6]

RFC 2419                 PPP DES Encryption v2            September 1998

SklowerとマイヤーStandards Track[6ページ]RFC2419PPP DES Encryption v2 September 1998

6.1.  Padding Considerations

6.1. 問題を水増しします。

   Since the DES algorithm operates on blocks of 8 octets, plain text
   packets which are of length not a multiple of 8 octets must be
   padded.  This can be injurious to the interpretation of some
   protocols which do not contain an explicit length field in their
   protocol headers.

DESアルゴリズムが8つの八重奏のブロックを作動させるので、倍数ではなく、8つの八重奏の長さのものであるプレーンテキストパケットを水増ししなければなりません。 これは彼らのプロトコルヘッダーに明白な長さの分野を含まないいくつかのプロトコルの解釈に有害である場合があります。

   Since there is no standard directory of protocols which are
   susceptible to corruption through padding, this can lead to confusion
   over which protocols should be protected against padding-induced
   corruption.  Consequently, this specification requires that the
   unambiguous technique described below MUST be applied to ALL plain
   text packets.

詰め物で不正に影響されやすいプロトコルのどんな標準のディレクトリもないので、これはプロトコルが詰め物で誘発された不正に対して保護されるべきである混乱に通じることができます。 その結果、この仕様は、以下で説明された明白なテクニックをすべてのプレーンテキストパケットに適用しなければならないのを必要とします。

   The method of padding is based on that described for the LCP Self-
   Describing-Padding (SDP) option (as defined in RFC 1570 [4]), but
   differs in two respects: first, maximum-pad value is fixed to be 8,
   and second, the method is to be applied to ALL packets, not just
   "specifically identified protocols".

詰め物のメソッドが説明をそっと歩くLCP Self(SDP)オプションのために説明されたそれに基づいている、(RFCで1570[4])を定義しますが、2つの点において異なるとき: まず最初に最大のパッド値が8と、2番目になるように修理されていて、メソッドは単に「明確に、プロトコルを特定すること」ではなく、すべてのパケットに適用されることです。

   Plain text which is not a multiple of 8 octets long MUST be padded
   prior to encrypting the plain text with sufficient octets in the
   sequence of octets 1, 2, 3 ... 7 to make the plain text a multiple of
   8 octets.

八重奏1、2、3の系列における十分な八重奏でプレーンテキストを暗号化する前に、長い間8つの八重奏の倍数でないプレーンテキストを水増ししなければなりません… 7 プレーンテキストを8つの八重奏の倍数にするように。

   Plain text which is already a multiple of 8 octets may require
   padding with a further 8 octets (1, 2, 3 ... 8).  These additional
   octets MUST be appended prior to encrypting the plain text if the
   last octet of the plain text has a value of 1 through 8, inclusive.

既に8つの八重奏の倍数であるプレーンテキストが、より遠い8つの八重奏でそっと歩くのを必要とするかもしれない、(1 2 3 .8) プレーンテキストの最後の八重奏に1〜8の値があるならプレーンテキストを暗号化する前にこれらの追加八重奏を追加しなければなりません、包括的です。

   After the peer has decrypted the cipher text, it strips off the
   Self-Describing-Padding octets, to recreate the original plain text.

同輩が暗号テキストを解読した後に、それは、オリジナルのプレーンテキストを休養させるためにそっと歩くと説明するSelf八重奏を全部はぎ取ります。

   Note that after decrypting, only the content of the last octet need
   be examined to determine how many pad bytes should be removed.
   However, the peer SHOULD discard the frame if all the octets forming
   the padding do not match the scheme just described.

解読する後に最後の八重奏の内容だけがいくつのパッドバイトが取り除かれるべきであるかを決定するために調べられなければならないことに注意してください。 しかしながら、詰め物を形成するすべての八重奏がただ説明された体系に合っていないなら、同輩SHOULDはフレームを捨てます。

   The padding operation described above is performed independently of
   whether or not the LCP Self-Describing-Padding (SDP) option has been
   negotiated.  If it has, SDP would be applied to the packet as a whole
   after it had been ciphered and after the Encryption Protocol
   Identifiers had been prepended.

そっと歩くと説明するLCP Self(SDP)オプションが交渉されたかどうかの如何にかかわらず上で説明された詰め物操作は実行されます。 そうしたなら、それが解かれた後とEncryptionプロトコルIdentifiersがprependedされた後にSDPは全体でパケットに適用されるでしょう。

Sklower & Meyer             Standards Track                     [Page 7]

RFC 2419                 PPP DES Encryption v2            September 1998

SklowerとマイヤーStandards Track[7ページ]RFC2419PPP DES Encryption v2 September 1998

6.2.  Generation of the Ciphertext

6.2. 暗号文の世代

   In this discussion, E[k] will denote the basic DES cipher determined
   by a 56-bit key k acting on 64 bit blocks. and D[k] will denote the
   corresponding decryption mechanism.  The padded plaintext described
   in the previous section then becomes a sequence of 64 bit blocks P[i]
   (where i ranges from 1 to n).  The circumflex character (^)
   represents the bit-wise exclusive-or operation applied to 64-bit
   blocks.

この議論では、E[k]は64ビットのブロックD[k]に影響する56ビットのキーkが対応する復号化メカニズムを指示することを決定している基本的なDES暗号を指示するでしょう。 その時前項で説明されたそっと歩いている平文は64ビットのブロックP[i](iが1〜nまで及ぶところ)の系列になります。 曲折アクセントのキャラクタ(^)は64ビットのブロックに適用されたビット的な排他的論理和操作を表します。

   When encrypting the first packet to be transmitted in the opened
   state let C[0] be the result of applying E[k] to the Initial Nonce
   received in the peer's ECP DESE option; otherwise let C[0] be the
   final block of the previously transmitted packet.

開かれた状態で伝えられるべき最初のパケットを暗号化するときには、C[0]が同輩のECP DESEオプションで受け取られたInitial NonceにE[k]を適用するという結果であることをさせてください。 さもなければ、C[0]が以前に伝えられたパケットの最終的なブロックであることをさせてください。

   The ciphertext for the packet is generated by the iterative process

パケットのための暗号文は繰り返し作業で生成されます。

                        C[i] = E[k](P[i] ^ C[i-1])

C[i]はE[k]と等しいです。(P[i]^C[i-1])

   for i running between 1 and n.

1とnの間稼働するiのために。

6.3.  Retrieval of the Plaintext

6.3. 平文の検索

   When decrypting the first packet received in the opened state, let
   C[0] be the result of applying E[k] to the Initial Nonce transmitted
   in the ECP DESE option.  The first packet will have sequence number
   zero.  For subsequent packets, let C[0] be the final block of the
   previous packet in sequence space.  Decryption is then accomplished
   by

開かれた状態に受け取られた最初のパケットを解読するときには、C[0]がECP DESEオプションで伝えられたInitial NonceにE[k]を適用するという結果であることをさせてください。 最初のパケットには、一連番号ゼロがあるでしょう。 その後のパケットに関しては、系列スペースでC[0]が前のパケットの最終的なブロックであることをさせてください。 そして、復号化は達成されます。

                        P[i] = C[i-1] ^ D[k](C[i]),

P[i]が^C[i-1]D[k]と等しい、(C[i])

   for i running between 1 and n.

1とnの間稼働するiのために。

6.4.  Recovery after Packet Loss

6.4. パケット損失の後の回復

   Packet loss is detected when there is a discontinuity in the sequence
   numbers of consecutive packets.  Suppose packet number N - 1 has an
   unrecoverable error or is otherwise lost, but packets N and N + 1 are
   received correctly.

連続したパケットの一連番号に不連続があるとき、パケット損失は検出されます。 パケット番号であるなら、N--1を回復不能エラーを持っているか、または別の方法で失いますが、正しくパケットNとN+1を受け取ります。

   Since the algorithm in the previous section requires C[0] for packet
   N to be C[last] for packet N - 1, it will be impossible to decode
   packet N.  However, all packets N + 1 and following can be decoded in
   the usual way, since all that is required is the last block of
   ciphertext of the previous packet (in this case packet N, which WAS
   received).

前項のアルゴリズムが[最後に]パケットNがパケットN--1のためのCであるためにC[0]を必要とするので、不断のとおりパケットN.However、すべてのパケットN+1、および次の事柄を解読するのを解読できるのは不可能でしょう、必要であるすべてが前のパケット(この場合受け取られたパケットN)の暗号文の最後のブロックであるので。

Sklower & Meyer             Standards Track                     [Page 8]

RFC 2419                 PPP DES Encryption v2            September 1998

SklowerとマイヤーStandards Track[8ページ]RFC2419PPP DES Encryption v2 September 1998

7.  MRU Considerations

7. MRU問題

   Because padding can occur, and because there is an additional
   protocol field in effect, implementations should take into account
   the growth of the packets.  As an example, if PFC had been
   negotiated, and if the MRU before had been exactly a multiple of 8,
   then the plaintext resulting combining a full sized data packets with
   a one byte protocol field would require an additional 7 bytes of
   padding, and the sequence number would be an additional 2 bytes so
   that the information field in the DESE protocol is now 10 bytes
   larger than that in the original packet.  Because the convention is
   that PPP options are independent of each other, negotiation of DESE
   does not, by itself, automatically increase the MRU value.

詰め物が起こることができて、事実上、追加議定書分野があるので、実装はパケットの成長を考慮に入れるべきです。 例、PFCが交渉されていて、MRUである、以前、まさに8の倍数、次に追加2がDESEプロトコルの情報フィールドがオリジナルのパケットのそれより10バイト大きい現在ためのバイトであったなら1バイトのプロトコル分野があるパケットがそっと歩きながら追加7バイトを必要とする完全な大きさで分けられたデータ、および一連番号を結合しながら結果として生じる平文はそうです。 コンベンションがPPPオプションが互いから独立しているということであるので、DESEの交渉自体は自動的にMRU値を増強しません。

8.  Differences from RFC 1969

8. RFC1969からの違い

8.1.  When to Pad

8.1. いつそっと歩きますか。

   In RFC 1969, the method of Self-Describing Padding was not applied to
   all packets transmitted using DESE.  Following the method of the SDP
   option itself, only "specifically identified protocols", were to be
   padded.  Protocols with an explicit length identifier were exempt.
   (Examples included non-VJ-compressed IP, XNS, CLNP).

RFC1969では、Self-説明PaddingのメソッドはDESEを使用することで伝えられたすべてのパケットに適用されませんでした。 SDPオプション自体のメソッドに従って、唯一の「明確に特定されたプロトコル」はそっと歩くことでした。 明白な長さの識別子があるプロトコルは免除されていました。 (例は圧縮された非VJ IP、XNS、CLNPを含んでいました。)

   In this speficiation, the method is applied to ALL packets.

このspeficiationでは、メソッドはすべてのパケットに適用されます。

   Secondly, this specification is clarified as being completely
   independent of the Self-Describing-Padding option for PPP, and fixes
   the maximum number of padding octets as 8.

第二に、この仕様は、そっと歩くと説明するSelfオプションからPPPにおいて完全に独立しているとしてはっきりさせられて、8として詰め物八重奏の最大数を固定します。

8.2.  Assigned Numbers

8.2. 規定番号

   Since this specification could theoretically cause misinterpretation
   of a packet transmitted according to the previous specification, a
   new type field number has been assigned for the DESE-bis protocol

この仕様が理論的に前の仕様通りに伝えられたパケットの誤解を引き起こす場合があったので、2回DESEプロトコルのために新しいタイプ分野番号を割り当ててあります。

8.3.  Minor Editorial Changes

8.3. 小さい方の編集の変化

   This specification has been designated a standards track document.
   Some other language has been changed for greater clarity.

この仕様は標準化過程ドキュメントに指定されました。 よりすばらしい明快ためにある他の言語を変えました。

9.  Security Considerations

9. セキュリティ問題

   This proposal is concerned with providing confidentiality solely.  It
   does not describe any mechanisms for integrity, authentication or
   nonrepudiation.  It does not guarantee that any message received has
   not been modified in transit through replay, cut-and-paste or active

この提案は唯一秘密性を提供するのに関係があります。 それは保全、認証または非拒否のためにどんなメカニズムについても説明しません。 それは、受け取られたどんなメッセージもトランジットで再生、カットアンドペーストで変更されているか、またはアクティブでないことを保証しません。

Sklower & Meyer             Standards Track                     [Page 9]

RFC 2419                 PPP DES Encryption v2            September 1998

SklowerとマイヤーStandards Track[9ページ]RFC2419PPP DES Encryption v2 September 1998

   tampering.  It does not provide authentication of the source of any
   packet received, or protect against the sender of any packet denying
   its authorship.

改ざん。 それは、受け取られたどんなパケットの源の認証も提供もしませんし、著述業を否定するどんなパケットの送付者からも守りもしません。

   This proposal relies on exterior and unspecified methods for
   authentication and retrieval of shared secrets.  It proposes no new
   technology for privacy, but merely describes a convention for the
   application of the DES cipher to data transmission between PPP
   implementation.

この提案は共有秘密キーの認証と検索のための外の、そして、不特定のメソッドを当てにします。 それは、プライバシーのために新技術を全く提案しませんが、DES暗号の応用のために単にPPP実装の間のデータ伝送にコンベンションについて説明します。

   Any methodology for the protection and retrieval of shared secrets,
   and any limitations of the DES cipher are relevant to the use
   described here.

共有秘密キーの保護と検索、およびDES暗号のどんな制限のためのどんな方法論もそうです。ここで説明された使用に関連しています。

10.  References

10. 参照

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

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

   [2] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June
       1996.

[2] マイヤー、G.、「ppp暗号化プロトコル(ECP)」、RFC1968 1996年6月。

   [3] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti,
       "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.

[3] Sklower、K.、ロイド、B.、マクレガー、G.、カー、D.、およびT.Coradetti、「pppマルチリンクは(MP)について議定書の中で述べます」、RFC1990、1996年8月。

   [4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January
       1994.

[4] シンプソン、W.、エディタ、「ppp LCP拡張子」、RFC1570、1994年1月。

   [5] National Bureau of Standards, "Data Encryption Standard", FIPS
       PUB 46 (January 1977).

[5]規格基準局、「データ暗号化規格」、FIPSパブ46(1977年1月)。

   [6] National Bureau of Standards, "DES Modes of Operation", FIPS PUB
       81 (December 1980).

[6]規格基準局、「DES運転モード」、FIPSパブ81(1980年12月)。

   [7] Schneier, B., "Applied Cryptography - Protocols Algorithms, and
       source code in C", John Wiley & Sons, Inc. 1994.  There is an
       errata associated with the book, and people can get a copy by
       sending e-mail to schneier@counterpane.com.

[7] シュナイアー、B.、「適用されたCryptography--プロトコルAlgorithms、およびC」、ジョン・ワイリー、およびソンスInc.1994におけるソースコード。 本に関連している誤字があります、そして、人々はメールを schneier@counterpane.com に送ることによって、コピーを手に入れることができます。

   [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

[8] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

Sklower & Meyer             Standards Track                    [Page 10]

RFC 2419                 PPP DES Encryption v2            September 1998

SklowerとマイヤーStandards Track[10ページ]RFC2419PPP DES Encryption v2 September 1998

11.  Authors' Addresses

11. 作者のアドレス

   Keith Sklower
   Computer Science Department
   339 Soda Hall, Mail Stop 1776
   University of California
   Berkeley, CA 94720-1776

キースSklowerコンピュータ理学部339ソーダホール、1776カリフォルニア大学バークレー、メールStopカリフォルニア94720-1776

   Phone:  (510) 642-9587
   EMail:  sklower@CS.Berkeley.EDU

以下に電話をしてください。 (510) 642-9587 メールしてください: sklower@CS.Berkeley.EDU

   Gerry M. Meyer
   Cisco Systems Ltd.
   Bothwell House, Pochard Way,
   Strathclyde Business Park,
   Bellshill, ML4 3HB
   Scotland, UK

ゲリーM.マイヤーシスコシステムズ株式会社Bothwell家、ホシハジロ道、ストラスクライドビジネスパーク、Bellshill、ML4 3HBスコットランドイギリス

   Phone: (UK) (pending)
   Fax:   (UK) (pending)
   Email: gemeyer@cisco.com

以下に電話をしてください。 (イギリス) (未定)です。 Fax: (イギリス) (未定)です。 メール: gemeyer@cisco.com

Sklower & Meyer             Standards Track                    [Page 11]

RFC 2419                 PPP DES Encryption v2            September 1998

SklowerとマイヤーStandards Track[11ページ]RFC2419PPP DES Encryption v2 September 1998

12.  Full Copyright Statement

12. 完全な著作権宣言文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Sklower & Meyer             Standards Track                    [Page 12]

Sklowerとマイヤー標準化過程[12ページ]