RFC3365 日本語訳

Network Working Group                                        J. Schiller
Request for Comments: 3365         Massachusetts Institute of Technology
BCP: 61                                                      August 2002
Category: Best Current Practice

コメントを求めるワーキンググループJ.シラー要求をネットワークでつないでください: 3365マサチューセッツ工科大学BCP: 8月61日の2002カテゴリ: 最も良い現在の習慣

                   Strong Security Requirements for
           Internet Engineering Task Force Standard Protocols

インターネット・エンジニアリング・タスク・フォース標準プロトコルのための強いセキュリティ要件

Status of this Memo

このMemoの状態

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

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

Abstract

要約

   It is the consensus of the IETF that IETF standard protocols MUST
   make use of appropriate strong security mechanisms.  This document
   describes the history and rationale for this doctrine and establishes
   this doctrine as a best current practice.

それはIETF標準プロトコルが適切な強いセキュリティー対策を利用しなければならないというIETFのコンセンサスです。このドキュメントは、この主義のために歴史と原理について説明して、最も良い現在の習慣とこの主義を書き立てます。

Table of Contents

目次

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Security Services . . . . . . . . . . . . . . . . . . . . . .   2
   4.  The Properties of the Internet. . . . . . . . . . . . . . . .   3
   5.  IETF Security Technology. . . . . . . . . . . . . . . . . . .   3
   6.  The Danvers Doctrine. . . . . . . . . . . . . . . . . . . . .   4
   7.  MUST is for Implementors. . . . . . . . . . . . . . . . . . .   5
   8.  Is Encryption a MUST? . . . . . . . . . . . . . . . . . . . .   5
   9.  Crypto Seems to Have a Bad Name . . . . . . . . . . . . . . .   6
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   6
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   13. Author's Address  . . . . . . . . . . . . . . . . . . . . . .   7
   14. Full Copyright Statement  . . . . . . . . . . . . . . . . . .   8

1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 用語. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 セキュリティー・サービス. . . . . . . . . . . . . . . . . . . . . . 2 4。 インターネットの特性。 . . . . . . . . . . . . . . . 3 5. IETFセキュリティー技術。 . . . . . . . . . . . . . . . . . . 3 6. ダンバース主義。 . . . . . . . . . . . . . . . . . . . . 4 7. Implementorsのためにあるに違いありません。 . . . . . . . . . . . . . . . . . . 5 8. 暗号化は絶対に必要なものですか? . . . . . . . . . . . . . . . . . . . . 5 9. 暗号は悪名. . . . . . . . . . . . . . . 6 10を持っているように思えます。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 6 11。 承認. . . . . . . . . . . . . . . . . . . . . . 6 12。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 7 13。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 7 14。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 8

Schiller                 Best Current Practice                  [Page 1]

RFC 3365            Encryption Security Requirements         August 2002

シラー最も良い現在の習慣[1ページ]RFC3365暗号化セキュリティ要件2002年8月

1.  Introduction

1. 序論

   The purpose of this document is to document the IETF consensus on
   security requirements for protocols as well as to provide the
   background and motivation for them.

このドキュメントの目的はプロトコル、それらに関するバックグラウンドと動機を提供するというセキュリティ要件に関するIETFコンセンサスを記録することです。

   The Internet is a global network of independently managed networks
   and hosts.  As such there is no central authority responsible for the
   operation of the network.  There is no central authority responsible
   for the provision of security across the network either.

インターネットは独自に管理されたネットワークとホストの世界的なネットワークです。 そういうものとして、ネットワークの操作に原因となるどんな主要な権威もありません。 ネットワークの向こう側にセキュリティの支給に原因となるどんな主要な権威もありません。

   Security needs to be provided end-to-end or host to host.  The IETF's
   security role is to ensure that IETF standard protocols have the
   necessary features to provide appropriate security for the
   application as it may be used across the Internet.  Mandatory to
   implement mechanisms should provide adequate security to protect
   sensitive business applications.

セキュリティは、終わらせる終わりか接待するホストに供給される必要があります。 IETFのセキュリティの役割はIETF標準プロトコルにはそれがインターネットの向こう側に使用されるとき適切なセキュリティをアプリケーションに提供する必要な特徴があるのを保証することです。 メカニズムを実装するのが敏感なビジネス・アプリケーションを保護するために十分な安全性を提供するべきであるのが義務的です。

2.  Terminology

2. 用語

   Although we are not defining a protocol standard in this document we
   will use the terms MUST, MAY, SHOULD and friends in the ways defined
   by [RFC2119].

プロトコル標準を定義していませんが、本書では私たちは[RFC2119]によって定義された方法で用語がそうしなければならない使用、5月、SHOULD、および友人がそうするつもりです。

3.  Security Services

3. セキュリティー・サービス

   [RFC2828] provides a comprehensive listing of internetwork security
   services and their definitions.  Here are three essential
   definitions:

[RFC2828]はインターネットワークセキュリティー・サービスと彼らの定義の包括的なリストを提供します。 ここに、3つの不可欠の定義があります:

   * Authentication service:  A security service that verifies an
     identity claimed by or for an entity, be it a process, computer
     system, or person.  At the internetwork layer, this includes
     verifying that a datagram came from where it purports to originate.
     At the application layer, this includes verifying that the entity
     performing an operation is who it claims to be.

* 認証サービス: プロセス、コンピュータ・システム、または人であることにかかわらず実体か実体のために要求されたアイデンティティについて確かめるセキュリティー・サービス。 インターネットワーク層では、これは、データグラムがそれが起因することを意味するところから来たことを確かめるのを含んでいます。 応用層では、これは、操作を実行する実体がだれを主張するかということであることを確かめるのを含んでいます。

   * Data confidentiality service:  A security service that protects
     data against unauthorized disclosure to unauthorized individuals or
     processes.  (Internet Standards Documents SHOULD NOT use "data
     confidentiality" as a synonym for "privacy", which is a different
     concept.  Privacy refers to the right of an entity, normally a
     person, acting in its own behalf, to determine the degree to which
     it will interact with its environment, including the degree to
     which the entity is willing to share information about itself with
     others.)

* データの機密性サービス: 権限のない個人かプロセスへの不当開示に対してデータを保護するセキュリティー・サービス。 (インターネットStandards Documents SHOULDは「プライバシー」に同義語として「データの機密性」を使用しません。(それは、異なった概念です)。 プライバシーは実体、通常人の右について言及します、それが環境で相互作用する度合いを決定するためにそれ自身の利益で行動して、実体がそれ自体の情報を他のものと共有しても構わないと思っている度合いを含んでいて。)

Schiller                 Best Current Practice                  [Page 2]

RFC 3365            Encryption Security Requirements         August 2002

シラー最も良い現在の習慣[2ページ]RFC3365暗号化セキュリティ要件2002年8月

   * Data integrity service: A security service that protects against
     unauthorized changes to data, including both intentional change
     (including destruction) and accidental change (including loss), by
     ensuring that changes to data are detectable.

* データの保全サービス: 意図的な変化(破壊を含んでいる)と偶然の変化の両方を含んでいて(損失を含んでいて)、データへの変化が確実に検出可能になるようにすることによってデータへの未承認の変更から守るセキュリティー・サービス。

4.  Some Properties of the Internet

4. インターネットのいくつかの特性

   As mentioned earlier, the Internet provides no inherent security.
   Enclaves of networking exist where users believe that security is
   provided by the environment itself.  An example would be a company
   network not connected to the global Internet.

先に述べたように、インターネットはどんな固有のセキュリティも提供しません。 ネットワークの飛び地はユーザが、セキュリティが環境自体によって提供されると信じているところに存在しています。 例は世界的なインターネットに接続されなかった会社のネットワークでしょう。

   One might imagine that protocols designed to operate in such an
   enclave would not require any security services, as the security is
   provided by the environment.

人は、そのような飛び地で作動するように設計されたプロトコルが少しのセキュリティー・サービスも必要としないと想像するかもしれません、環境でセキュリティを提供するとき。

   History has shown that applications that operate using the TCP/IP
   Protocol Suite wind up being used over the Internet.  This is true
   even when the original application was not envisioned to be used in a
   "wide area" Internet environment.  If an application isn't designed
   to provide security, users of the application discover that they are
   vulnerable to attack.

歴史は、結局インターネットの上でTCP/IPプロトコルSuiteを使用することで作動するアプリケーションが使用されるのを示しました。 原出願が「広い領域」インターネット環境で使用されるために思い描かれなかったときさえ、これは本当です。 アプリケーションがセキュリティを提供するように設計されないなら、アプリケーションのユーザは、彼らが攻撃するために被害を受け易いと発見します。

5.  IETF Security Technology

5. IETFセキュリティー技術

   The IETF has several security protocols and standards.  IP Security
   (IPsec [RFC2411]), Transport Layer Security (TLS [RFC2246]) are two
   well known protocols.  Simple Authentication and Security Layer (SASL
   [RFC2222] and the Generic Security Service Application Programming
   Interface (GSSAPI [RFC2743]) provide services within the context of a
   "host" protocol.  They can be viewed as "toolkits" to use within
   another protocol.

IETFには、いくつかのセキュリティプロトコルと規格があります。 IP Security(IPsec[RFC2411])、Transport Layer Security(TLS[RFC2246])は2つのよく知られているプロトコルです。 SASL[RFC2222]とGeneric Security Service Application Programming Interface(GSSAPI[RFC2743])は「ホスト」プロトコルの文脈の中でサービスを提供します。簡単なAuthenticationとSecurity Layer、(別のものの中で使用する「ツールキット」が議定書を作るとき、それらは見ることができます。

   One of the critical choices that a protocol designer must make is
   whether to make use of one of the existing protocols, engineer their
   own protocol to use one of the standard tools or do something
   completely different.

プロトコルデザイナーがしなければならない重要な選択の1つは既存のプロトコルの1つを利用するか、標準のツールの使用1にそれら自身のプロトコルを設計するか、または完全に何か異なったことをするということです。

   There is no one correct answer for all protocols and designers really
   need to look at the threats to their own protocol and design
   appropriate counter-measures.  The purpose of the "Security
   Considerations" Section required to be present in an RFC on the
   Internet Standards Track is to provide a place for protocol designers
   to document the threats and explain the logic to their security
   design.

デザイナーがすべてのプロトコルに答えてください。そうすれば、本当にそれら自身のプロトコルへの脅威を見て、適切な対応策を設計する必要であるのが正しい人はだれもいません。 インターネットStandards Trackの上のRFCに存在しているのが必要である「セキュリティ問題」セクションの目的はプロトコルデザイナーがそれらのセキュリティデザインに脅威を記録して、論理について説明する場所を提供することです。

Schiller                 Best Current Practice                  [Page 3]

RFC 3365            Encryption Security Requirements         August 2002

シラー最も良い現在の習慣[3ページ]RFC3365暗号化セキュリティ要件2002年8月

6.  The Danvers Doctrine

6. ダンバース主義

   At the 32cd IETF held in Danvers, Massachusetts during April of 1995
   the IESG asked the plenary for a consensus on the strength of
   security that should be provided by IETF standards.  Although the
   immediate issue before the IETF was whether or not to support
   "export" grade security (which is to say weak security) in standards
   the question raised the generic issue of security in general.

1995年4月の間のダンバース(マサチューセッツ)で持たれていた32cd IETFでは、IESGはIETF規格によって提供されるべきであるセキュリティの強さに関するコンセンサスを絶対的に求めました。 IETFの前の即座の問題は規格において「輸出」がグレードセキュリティ(弱いセキュリティを言うことになっている)であるとサポートするかどうかということでしたが、質問は一般に、ジェネリック秘密保持の問題を上げました。

   The overwhelming consensus was that the IETF should standardize on
   the use of the best security available, regardless of national
   policies.  This consensus is often referred to as the "Danvers
   Doctrine".

圧倒的なコンセンサスはIETFが最も良いことの使用のときに国策にかかわらず利用可能なセキュリティを標準化するはずであるということでした。 このコンセンサスはしばしば「ダンバース主義」と呼ばれます。

   Over time we have extended the interpretation of the Danvers Doctrine
   to imply that all IETF protocols should operate securely.  How can
   one argue against this?

時間がたつにつれて、私たちは、すべてのIETFプロトコルがしっかりと作動するべきであるのを含意するためにダンバースDoctrineの解釈を広げました。 人はどうしたらこれについて反対の議論をすることができますか?

   Since 1995 the Internet has increasingly come under attack from
   various malicious actors.  In 2000 significant press coverage was
   devoted to Distributed Denial of Service attacks.  However many of
   these attacks were launched by first compromising an Internet
   connected computer system.  Usually many systems are compromised in
   order to launch a significant distributed attack.

1995年以来、インターネットはますます様々な悪意がある俳優から攻撃を受けています。 2000年に、重要なマスコミ報道は分散型サービス妨害攻撃にささげられました。 しかしながら、インターネットが接続コンピュータ・システムであると感染しながら、これらの攻撃の多くが最初にによって着手されました。 通常多くのシステムが、重要な分配された攻撃に着手するために感染されます。

   A conclusion we can draw from all of this is that if we fail to
   provide secure protocols, then the Internet will become less useful
   in providing an international communications infrastructure, which
   appears to be its destiny.

私たちがこのすべてから達することができる結論は私たちが安全なプロトコルを提供しないならインターネットが国際通信インフラストラクチャを提供する際に、より役に立たないようになるということです。インフラストラクチャは運命であるように見えます。

   One of the continuing arguments we hear against building security
   into protocols is the argument that a given protocol is intended only
   for use in "protected" environments where security will not be an
   issue.

私たちがセキュリティをプロトコルに組み込まないように聞く継続する議論の1つは与えられたプロトコルがセキュリティが問題にならない「保護された」環境における使用のためだけに意図するという主張です。

   However it is very hard to predict how a protocol will be used in the
   future.  What may be intended only for a restricted environment may
   well wind up being deployed in the global Internet.  We cannot wait
   until that point to "fix" security problems.  By the time we realize
   this deployment, it is too late.

しかしながら、プロトコルが将来どう使用されるかを非常に予測しにくいです。 結局、たぶん世界的なインターネットで制限された環境だけのために意図するかもしれないことによって配布されるでしょう。 私たちは、警備上の問題を「修理すること」をそのポイントまで待つことができません。私たちがこの展開がわかる時までには、遅過ぎます。

   The solution is that we MUST implement strong security in all
   protocols to provide for the all too frequent day when the protocol
   comes into widespread use in the global Internet.

ソリューションは私たちがプロトコルが世界的なインターネットで普及使用に入るすべて頻繁過ぎる日に提供するためにすべてのプロトコルにおける強いセキュリティを実装しなければならないということです。

Schiller                 Best Current Practice                  [Page 4]

RFC 3365            Encryption Security Requirements         August 2002

シラー最も良い現在の習慣[4ページ]RFC3365暗号化セキュリティ要件2002年8月

7.  MUST is for Implementors

7. Implementorsのためにあるに違いありません。

   We often say that Security is a MUST implement.  It is worth noting
   that there is a significant different between MUST implement and MUST
   use.

私たちは、しばしばSecurityによるaが実装しなければならないということであると言います。 そこでそれに注意する価値がa間に異なった状態で重要であるということです。実装しなければならなくて、使用しなければなりません。

   As mentioned earlier, some protocols may be deployed in secure
   enclaves for which security isn't an issue and security protocol
   processing may add a significant performance degradation.  Therefore
   it is completely reasonable for security features to be an option
   that the end user of the protocol may choose to disable.  Note that
   we are using a fuzzy definition of "end user" here.  We mean not only
   the ultimate end user, but any deployer of a technology, which may be
   an entire enterprise.

先に述べたように、いくつかのプロトコルがセキュリティが問題でなく、セキュリティプロトコル処理が重要な性能退行を加えるかもしれない安全な飛び地で配布されるかもしれません。 したがって、プロトコルのエンドユーザが無効にするのを選ぶかもしれないオプションであるセキュリティ機能に、それは完全に妥当です。 私たちがここで「エンドユーザ」のあいまいな定義を使用していることに注意してください。 私たちは究極の目的のユーザだけではなく、技術のどんなデプロイヤも言っています。(それは、全体の企業であるかもしれません)。

   However security must be a MUST IMPLEMENT so that end users will have
   the option of enabling it when the situation calls for it.

しかしながら、セキュリティは、エンドユーザには状況がそれを求めるとそれを可能にするオプションがあるためのMUST IMPLEMENTでなければなりません。

8.  Is Encryption a MUST?

8. 暗号化は絶対に必要なものですか?

   Not necessarily.  However we need to be a bit more precise here.
   Exactly what security services are appropriate for a given protocol
   depends heavily on the application it is implementing.  Many people
   assume that encryption means confidentiality.  In other words the
   encryption of the content of protocol messages.

必ずしもそうであるというわけではありません。 しかしながら、私たちは、ここでもう少し正確である必要があります。 与えられたプロトコルに、まさにどんなセキュリティー・サービスが適切であるかは大いにそれが実装しているアプリケーションによります。 多くの人々が、その暗号化手段が秘密性であると仮定します。 言い換えれば、プロトコルメッセージの内容の暗号化。

   However there are many applications where confidentiality is not a
   requirement, but authentication and integrity are.

しかしながら、多くの利用が秘密性が要件ではありませんが、認証と保全があるところにあります。

   One example might be in a building control application where we are
   using IP technology to operate heat and vent controls.  There is
   likely no requirement to protect the confidentiality of messages that
   instruct heat vents to open and close.  However authentication and
   integrity are likely important if we are to protect the building from
   a malicious actor raising or lowering the temperature at will.

1つの例が私たちが熱を操作するIP技術を使用しているビル制御アプリケーションと通気コントロール中であるかもしれません。 おそらく、開いて、閉じるよう熱水源に命令するメッセージの秘密性を保護するという要件が全くありません。 しかしながら、私たちが温度を自由自在に上げるか、または下げる悪意がある俳優からビルを保護するつもりであるなら、認証と保全はおそらく重要です。

   Yet we often require cryptographic technology to implement
   authentication and integrity of protocol messages.  So if the
   question is "MUST we implement confidentiality?" the answer will be
   "depends".  However if the question is "MUST we make use of
   cryptographic technology?" the answer is "likely".

しかし、私たちはしばしばプロトコルメッセージの認証と保全を実装する暗号の技術を必要とします。 それで、質問が「私たちは秘密性を実装しなければなりませんか?」であるなら、答えは「依存」でしょう。 しかしながら、質問が「私たちは暗号の技術を利用しなければなりませんか?」であるなら、答えは「ありそうです」。

Schiller                 Best Current Practice                  [Page 5]

RFC 3365            Encryption Security Requirements         August 2002

シラー最も良い現在の習慣[5ページ]RFC3365暗号化セキュリティ要件2002年8月

9.  Crypto Seems to Have a Bad Name

9. 暗号は評判が悪いように思えます。

   The mention of cryptographic technology in many IETF forums causes
   eyes to glaze over and resistance to increase.

多くのIETFフォーラムでの暗号の技術の言及は増加への表面の艶と抵抗の上に目を引き起こします。

   Many people seem to associate the word "cryptography" with concerns
   such as export control and performance.  Some just plain do not
   understand it and therefore shy away from its use.  However many of
   these concerns are unfounded.

多くの人々が、「暗号」という言葉を輸出管理や性能などの関心に関連づけるように思えます。 或るものは、ただ単にそれを理解して、したがって、使用を避けません。 しかしながら、これらの関心の多くが無根拠です。

   Today export control, at least from most of the developed world, is
   becoming less of a concern.  And even where it is a concern, the
   concern is not over cryptography itself but in its use in providing
   confidentiality.

今日、少なくとも開発された世界の大部分から、輸出管理は関心を一体どうならせていません。 そして、それが関心でさえあるところに、関心が暗号自体であるのではなく、秘密性を提供することにおけるその使用であります。

   There are performance issues when you make use of cryptographic
   technology.  However we pride ourselves in the IETF as being
   engineers.  It is an engineering exercise to figure out the
   appropriate way to make use of cryptographic technology so as to
   eliminate or at least minimize the impact of using cryptography
   within a given protocol.

あなたが暗号の技術を利用するとき、性能問題があります。 しかしながら、私たちは技術者であるとしてIETFを誇っています。 それは与えられたプロトコルの中で使用暗号の影響を排除するか、または少なくとも、最小にするのに暗号の技術を利用する適切な方法を理解する工学運動です。

   Finally, as to understanding cryptography, you don't have to.  In
   other words, you do not need to become a cryptographer in order to
   effectively make use of cryptographic technology.  Instead you make
   use of existing well understood ciphers and cipher suites to solve
   the engineering problem you face.

最終的に、暗号を理解することに関するあなたはそうする必要はありません。 言い換えれば、あなたは、事実上、暗号の技術を利用するために暗号使用者になる必要はありません。 代わりに、あなたは、あなたが直面している工学の問題を解決するために存在することの使用をよく理解されている暗号と暗号スイートにします。

   One of the goals that we have in the Security Area of the IETF is to
   come up with guides so that protocol implementers can choose
   appropriate technology without having to understand the minutiae.

私たちがIETFのSecurity Areaに持っている目標の1つはプロトコルimplementersが詳細を理解する必要はなくて適正技術を選ぶことができるようにガイドを思いつくことです。

10.  Security Considerations

10. セキュリティ問題

   This document is about the IETF's requirement that security be
   considered in the implementation of protocols.  Therefore it is
   entirely about security!

このドキュメントはセキュリティがプロトコルの実装で考えられるというIETFの要件に関するものです。 したがって、それは完全なセキュリティに関するものです!

11.  Acknowledgements

11. 承認

   The author would like to acknowledge the participation of the
   Security Area Advisory Group and in particular Rob Shirey, Ran
   Atkinson, Steve Bellovin, Marc Blanchet, Steve Kent, Randy Bush, Dave
   Crocker, Stephen Farrell, Paul Hoffman, Russ Housley, Christian
   Huitema, Melinda Shore, Adam Shostack and Kurt D. Zeilenga.

作者はSecurity Area Advisory Group、特にロブShirey、Ranアトキンソン、スティーブBellovin、マークBlanchet、スティーブ・ケント、ランディ・ブッシュ、デーヴ・クロッカー、スティーブン・ファレル、ポール・ホフマン、ラスHousley、クリスチャンのHuitema、メリンダShore、アダムShostack、およびカートD.Zeilengaの参加を承諾したがっています。

Schiller                 Best Current Practice                  [Page 6]

RFC 3365            Encryption Security Requirements         August 2002

シラー最も良い現在の習慣[6ページ]RFC3365暗号化セキュリティ要件2002年8月

12.  References

12. 参照

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

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

   [RFC2222] Myers, J., "Simple Authentication and Security Layer
             (SASL)", RFC 2222, October 1997.

[RFC2222] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。

   [RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
             Document Roadmap", RFC 2411, November 1998.

[RFC2411] セイヤーとR.とDoraswamyとN.とR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、1998年11月。

   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
             RFC 2246, January 1999.

[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。

   [RFC2743] Linn, J., "Generic Security Service Application Program
             Interface Version 2, Update 1.", RFC 2743, January 2000.

[RFC2743] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェースバージョン2、アップデート1」、RFC2743、1月2000日

   [RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828,
             May 2000.

[RFC2828]Shirey(R.、「インターネットセキュリティ用語集」、FYI36、RFC2828)は2000がそうするかもしれません。

13.  Author's Address

13. 作者のアドレス

   Jeffrey I. Schiller
   MIT Room W92-190
   77 Massachusetts Avenue
   Cambridge, MA 02139-4307
   USA

ケンブリッジ、ジェフリーI.シラーMIT余地のW92-190 77MA02139-4307米国マサチューセッツ通り

   Phone: +1 (617) 253-8400
   EMail: jis@mit.edu

以下に電話をしてください。 +1 (617) 253-8400 メールしてください: jis@mit.edu

Schiller                 Best Current Practice                  [Page 7]

RFC 3365            Encryption Security Requirements         August 2002

シラー最も良い現在の習慣[7ページ]RFC3365暗号化セキュリティ要件2002年8月

14.  Full Copyright Statement

14. 完全な著作権宣言文

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

Copyright(C)インターネット協会(2002)。 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.

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

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Schiller                 Best Current Practice                  [Page 8]

シラーBest現在の習慣[8ページ]