[要約] RFC 3631は、インターネットのセキュリティメカニズムに関する文書で、インターネットのセキュリティアーキテクチャとプロトコルに関する全体的な概観を提供します。このRFCの目的は、インターネット上でのデータの安全性、認証、プライバシー、データの完全性を保証するための既存のセキュリティメカニズムとポリシーを概説することです。利用場面としては、ネットワーク管理者やシステム設計者がセキュリティ対策を計画し、実装する際のガイドラインとして活用されます。関連するRFCには、RFC 2401（IPセキュリティアーキテクチャ）、RFC 2828（インターネットセキュリティ用語集）、RFC 3552（インターネット標準トラックプロトコルのセキュリティに関するガイドライン）などがあります。
Network Working Group S. Bellovin, Ed.
Request for Comments: 3631 J. Schiller, Ed.
Category: Informational C. Kaufman, Ed.
Internet Architecture Board
December 2003
Security Mechanisms for the Internet
インターネットのセキュリティメカニズム
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
Security must be built into Internet Protocols for those protocols to offer their services securely. Many security problems can be traced to improper implementations. However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable. Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself. However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each.
セキュリティは、これらのプロトコルがサービスを安全に提供するために、インターネットプロトコルに組み込む必要があります。多くのセキュリティの問題は、不適切な実装にまでさかのぼることができます。ただし、基本的なプロトコル自体が悪用可能な場合、適切な実装でさえセキュリティの問題が発生します。プロトコル自体の構造により、プロトコルでセキュリティを実装する方法は異なります。ただし、既に開発された標準的なインターネットセキュリティメカニズムが適用される可能性のある多くのプロトコルがあります。特定の状況で適切な正確なものは異なる場合があります。さまざまな選択肢をレビューし、それぞれの特性を説明します。
Internet Security compromises can be divided into several classes, ranging from Denial of Service to Host Compromise. Denial of Service attacks based on sheer volume of traffic are beyond the scope of this document, though they are the subject of much ongoing discussion and research. It is important to note that many such attacks are made more difficult by good security practices. Host Compromise (most commonly caused by undetected Buffer Overflows) represent flaws in individual implementations rather than flaws in protocols. Nevertheless, carefully designed protocols can make such flaws less likely to occur and harder to exploit.
インターネットセキュリティの妥協は、サービスの拒否からホストの妥協まで、いくつかのクラスに分けることができます。膨大な量のトラフィックに基づくサービス拒否攻撃は、このドキュメントの範囲を超えていますが、それらは進行中の議論と研究の対象です。そのような攻撃の多くは、良好なセキュリティ慣行によってより困難になっていることに注意することが重要です。ホストの妥協（最も一般的には検出されないバッファーオーバーフローによって引き起こされる）は、プロトコルの欠陥ではなく、個々の実装の欠陥を表します。それにもかかわらず、慎重に設計されたプロトコルは、そのような欠陥が発生する可能性が低く、悪用するのが難しくなる可能性があります。
However, there are security compromises that are facilitated by the very protocols that are in use on the Internet. If a security problem is inherent in a protocol, no manner of implementation will be able to prevent the problem.
ただし、インターネットで使用されているまさにそのプロトコルによって促進されるセキュリティの妥協があります。セキュリティの問題がプロトコルに固有の場合、実装の方法が問題を防ぐことはできません。
It is therefore vitally important that protocols developed for the Internet provide this fundamental security.
したがって、インターネット用に開発されたプロトコルがこの基本的なセキュリティを提供することが非常に重要です。
Exactly how a protocol should be secured depends on the protocol itself as well as the security needs of the protocol. However, we have developed a number of standard security mechanisms in the IETF. In many cases appropriate application of these mechanisms can provide the necessary security for a protocol.
プロトコルを保護する方法は、プロトコル自体とプロトコルのセキュリティニーズに依存します。ただし、IETFで多くの標準セキュリティメカニズムを開発しました。多くの場合、これらのメカニズムの適切な適用は、プロトコルに必要なセキュリティを提供できます。
A number of possible mechanisms can be used to provide security on the Internet. Which one should be selected depends on many different factors. We attempt here to provide guidance, spelling out the factors and the currently-standardized (or about-to-be-standardized) solutions, as discussed at the IAB Security Architecture Workshop [RFC2316].
多くの可能なメカニズムを使用して、インターネット上のセキュリティを提供できます。選択する必要があるのは、さまざまな要因によって異なります。IABセキュリティアーキテクチャワークショップ[RFC2316]で説明したように、ここでガイダンスを提供し、要因と現在標準化されている（または標準化されている）ソリューションを綴ります。
Security, however, is an art, not a science. Attempting to follow a recipe blindly can lead to disaster. As always, good taste in protocol design should be exercised.
しかし、セキュリティは科学ではなく芸術です。盲目的にレシピに従うことを試みると、災害につながる可能性があります。いつものように、プロトコル設計の優れた味を行使する必要があります。
Finally, security mechanisms are not magic pixie dust that can be sprinkled over completed protocols. It is rare that security can be bolted on later. Good designs -- that is, secure, clean, and efficient designs -- occur when the security mechanisms are crafted along with the protocol. No conceivable exercise in cryptography can secure a protocol with flawed semantic assumptions.
最後に、セキュリティメカニズムは、完成したプロトコルに散らばることができるマジックピクシーダストではありません。セキュリティを後でボルトで固定できることはまれです。優れたデザイン - つまり、安全で、クリーンで効率的なデザイン - は、セキュリティメカニズムがプロトコルとともに作成されたときに発生します。暗号化の考えられる運動は、欠陥のあるセマンティック仮定を備えたプロトコルを確保することはできません。
The most important factor in choosing a security mechanism is the threat model. That is, who may be expected to attack what resource, using what sorts of mechanisms? A low-value target, such as a Web site that offers public information only, may not merit much protection. Conversely, a resource that if compromised could expose significant parts of the Internet infrastructure, say, a major backbone router or high-level Domain Name Server, should be protected by very strong mechanisms. The value of a target to an attacker depends on the purpose of the attack. If the purpose is to access sensitive information, all systems that handle this information or mediate access to it are valuable. If the purpose is to wreak havoc, systems on which large parts of the Internet depend are exceedingly valuable. Even if only public information is posted on a web site, changing its contents can cause embarrassment to its owner and could result in substantial damage. It is difficult when designing a protocol to predict what uses that protocol will someday have.
セキュリティメカニズムを選択する上で最も重要な要素は、脅威モデルです。つまり、どのようなメカニズムを使用して、どのリソースを攻撃することが期待されるか？公開情報のみを提供するWebサイトなど、価値の低いターゲットは、多くの保護に値しない場合があります。逆に、侵害された場合、インターネットインフラストラクチャのかなりの部分、たとえば主要なバックボーンルーターまたは高レベルのドメイン名サーバーを公開できるリソースは、非常に強力なメカニズムによって保護されるべきです。攻撃者に対するターゲットの価値は、攻撃の目的に依存します。機密情報にアクセスすることが目的である場合、この情報を処理するか、アクセスを媒介するすべてのシステムは価値があります。目的が大混乱をもたらすことである場合、インターネットの大部分が依存するシステムは非常に価値があります。公開情報のみがWebサイトに投稿されていても、その内容を変更すると、所有者に恥ずかしさを引き起こし、大きな損害を与える可能性があります。プロトコルを設計して、そのプロトコルがいつか持つかを予測するときは困難です。
All Internet connected systems require a minimum amount of protection. Starting in 2000 and continuing to the present, we have witnessed the advent of a new type of Internet security attack: an Internet "worm" program that seeks out and automatically attacks systems that are vulnerable to compromise via a number of attacks built into the worm program itself. These worm programs can compromise literally thousands of systems within a very short period of time. Note that the first Internet Worm was the "Morris" worm of 1988. However, it was not followed up with similar programs for over 12 years!
すべてのインターネット接続システムには、最小限の保護が必要です。2000年から現在まで続いて、私たちは新しいタイプのインターネットセキュリティ攻撃の出現を目撃しました。ワームに組み込まれた多くの攻撃を介して妥協しやすいシステムを探して自動的に攻撃するインターネット「ワーム」プログラムプログラム自体。これらのワームプログラムは、非常に短い期間内に文字通り何千ものシステムを妥協することができます。最初のインターネットワームは1988年の「モリス」ワームだったことに注意してください。しかし、12年以上も同様のプログラムがフォローアップされていません。
As of the writing of this document, all of these worms have taken advantage of programming errors in the implementation of otherwise reasonably secure protocols. However, it is not hard to envision an attack that targets a fundamental security flaw in a widely deployed protocol. It is therefore imperative that we strive to minimize such flaws in the protocols we design.
このドキュメントの執筆時点で、これらのワームはすべて、それ以外の場合は合理的に安全なプロトコルの実装におけるプログラミングエラーを利用しています。ただし、広く展開されているプロトコルの基本的なセキュリティ欠陥を対象とする攻撃を想像することは難しくありません。したがって、設計するプロトコルのそのような欠陥を最小限に抑えるよう努めていることが不可欠です。
The value of a target to an attacker may depend on where it is located. A network monitoring station that is physically on a backbone cable is a major target, since it could easily be turned into an eavesdropping station. The same machine, if located on a stub net and used for word processing, would be of much less use to a sophisticated attacker, and hence would be at significantly less risk.
攻撃者に対するターゲットの値は、それがどこにあるかによって異なります。バックボーンケーブルに物理的にあるネットワーク監視ステーションは、盗聴ステーションに簡単に変えることができるため、主要なターゲットです。同じマシンは、スタブネットに位置し、ワードプロセッシングに使用されている場合、洗練された攻撃者にとってははるかに少ない使用であるため、リスクが大幅に少なくなります。
One must also consider what sorts of attacks may be expected. At a minimum, eavesdropping must be seen as a serious threat; there have been very many such incidents since at least 1993. Often, active attacks, that is, attacks that involve insertion or deletion of packets by the attacker, are a risk as well. It is worth noting that such attacks can be launched with off-the-shelf tools, and have in fact been observed "in the wild". Of particular interest is a form of attack called "session hijacking", where someone on a link between the two communicating parties wait for authentication to complete and then impersonate one of the parties and continue the connection with the other.
また、どのような攻撃が予想されるかを考慮する必要があります。少なくとも、盗聴は深刻な脅威と見なされなければなりません。少なくとも1993年以来、このような事件は非常に多くありました。多くの場合、攻撃者によるパケットの挿入または削除を伴う攻撃攻撃もリスクです。そのような攻撃は、既製のツールで発売され、実際には「野生で」観察されていることは注目に値します。特に興味深いのは、「セッションハイジャック」と呼ばれる攻撃の形式であり、2つの通信当事者間のリンクの誰かが認証が完了し、その後の当事者になりすまして他の関係を継続するのを待っています。
One of the most important tools available to us for securing protocols is cryptography. Cryptography permits us to apply various kinds of protection to data as it traverses the network, without having to depend on any particular security properties of the network itself. This is important because the Internet, by its distributed management and control, cannot be considered a trustworthy media in and of itself. Its security derives from the mechanisms that we build into the protocols themselves, independent of the underlying media or network operators.
プロトコルを保護するために利用できる最も重要なツールの1つは、暗号化です。暗号化により、ネットワーク自体の特定のセキュリティプロパティに依存することなく、ネットワークを横断する際に、さまざまな種類の保護をデータに適用することができます。インターネットは、その分散した管理と制御によって、それ自体が信頼できるメディアと見なすことができないため、これは重要です。そのセキュリティは、基礎となるメディアまたはネットワークオペレーターとは無関係に、プロトコル自体に構築するメカニズムに由来しています。
Finally, of course, there is the cost to the defender of using cryptography. This cost is dropping rapidly; Moore's Law, plus the easy availability of cryptographic components and toolkits, makes it relatively easy to use strong protective techniques. Although there are exceptions, public key operations are still expensive, perhaps prohibitively so if the cost of each public-key operation is spread over too few transactions, careful engineering design can generally let us spread this cost over many transactions.
最後に、もちろん、暗号化の使用の擁護者にはコストがあります。このコストは急速に減少しています。ムーアの法則に加えて、暗号化コンポーネントとツールキットが簡単に入手できるため、強力な保護技術を使用するのが比較的簡単になります。例外もありますが、公開キー操作は依然として高価であり、おそらく法外に高価なので、各パブリックキー操作のコストが取引が少なすぎる場合、慎重なエンジニアリング設計により、このコストを多くのトランザクションに分散させることができます。
In general, the default today should be to use the strongest cryptography available in any protocol. Strong cryptography often costs no more, and sometimes less, then weaker cryptography. The actual performance cost of an algorithm is often unrelated to the security it provides. Depending on the hardware available, cryptography can be performed at very high rates (1+Gbps), and even in software its performance impact is shrinking over time.
一般に、今日のデフォルトは、あらゆるプロトコルで利用可能な最強の暗号化を使用することです。強い暗号化は、多くの場合、それ以上の費用はかかりませんが、時にはそれより少なく、その後、暗号化が弱くなります。アルゴリズムの実際のパフォーマンスコストは、多くの場合、それが提供するセキュリティとは無関係です。利用可能なハードウェアに応じて、暗号化は非常に高いレート（1 gbps）で実行でき、ソフトウェアでもパフォーマンスの影響は時間とともに縮小しています。
We have evolved in the IETF the notion of "mandatory to implement" mechanisms. This philosophy evolves from our primary desire to ensure interoperability between different implementations of a protocol. If a protocol offers many options for how to perform a particular task, but fails to provide for at least one that all must implement, it may be possible that multiple, non-interoperable implementations may result. This is the consequence of the selection of non-overlapping mechanisms being deployed in the different implementations.
私たちは、IETFで「実装するための必須」メカニズムの概念を進化させました。この哲学は、プロトコルのさまざまな実装間の相互運用性を確保したいという主な欲求から進化します。プロトコルが特定のタスクの実行方法のための多くのオプションを提供しているが、すべてを実装する必要がある少なくとも1つを提供できない場合、複数の挿入不可能な実装が結果として生じる可能性があります。これは、異なる実装で展開されている非重複メカニズムの選択の結果です。
Although a given protocol may make use of only one or a few security mechanisms, these mechanisms themselves often can make use of several cryptographic systems. The various cryptographic systems vary in strength and performance. However, in many protocols we need to specify a "mandatory to implement" to ensure that any two implementations will eventually be able to negotiate a common cryptographic system between them.
特定のプロトコルは1つまたはいくつかのセキュリティメカニズムのみを使用する場合がありますが、これらのメカニズム自体は、いくつかの暗号システムを使用することがよくあります。さまざまな暗号化システムの強度とパフォーマンスは異なります。ただし、多くのプロトコルでは、2つの実装が最終的にそれらの間の共通の暗号システムを交渉できるようにするために、「実装するための必須」を指定する必要があります。
There are some protocols that were originally designed to be run in a very limited domain. It is often argued that the domain of implementation for a particular protocol is sufficiently well defined and secure that the protocol itself need not provide any security mechanisms.
もともと非常に限られたドメインで実行されるように設計されたいくつかのプロトコルがあります。特定のプロトコルの実装ドメインは、プロトコル自体がセキュリティメカニズムを提供する必要がないことが十分に定義され、安全であるとしばしば主張されています。
History has shown this argument to be wrong. Inevitably, successful protocols - even if developed for limited use - wind up used in a broader environment, where the initial security assumptions do not hold.
歴史は、この議論が間違っていることを示しています。必然的に、成功したプロトコルは、限られた使用のために開発されたとしても - 最初のセキュリティの仮定が保持されないより広い環境で使用されます。
To solve this problem, the IETF requires that *ALL* protocols provide appropriate security mechanisms, even when their domain of application is at first believed to be very limited.
この問題を解決するには、IETFでは、 *すべての *プロトコルが適切なセキュリティメカニズムを提供する必要があります。
It is important to understand that mandatory mechanisms are mandatory to *implement*. It is not necessarily mandatory that end-users actually use these mechanisms. If an end-user knows that they are deploying a protocol over a "secure" network, then they may choose to disable security mechanisms that they believe are adding insufficient value as compared to their performance cost. (We are generally skeptical of the wisdom of disabling strong security even then, but that is beyond the scope of this document.)
必須のメカニズムが *実装 *に必須であることを理解することが重要です。エンドユーザーが実際にこれらのメカニズムを使用することは必ずしも必須ではありません。エンドユーザーが「セキュア」ネットワーク上でプロトコルを展開していることを知っている場合、パフォーマンスコストと比較して不十分な値を追加していると思われるセキュリティメカニズムを無効にすることを選択できます。（私たちは一般的に、強力なセキュリティを無効にするという知恵に懐疑的ですが、それはこの文書の範囲を超えています。）
Insisting that certain mechanisms are mandatory to implement means that those end-users who need the protocol provided by the security mechanism have it available when needed. Particularly with security mechanisms, just because a mechanism is mandatory to implement does not imply that it should be the default mechanism or that it may not be disabled by configuration. If a mandatory to implement algorithm is old and weak, it is better to disable it when a stronger algorithm is available.
特定のメカニズムが実装するために必須であると主張することは、セキュリティメカニズムによって提供されるプロトコルを必要とするエンドユーザーが必要に応じて利用できることを意味します。特にセキュリティメカニズムでは、メカニズムが実装することが必須であるからといって、それがデフォルトのメカニズムであるべきであるか、構成によって無効にされない可能性があることを意味するものではありません。実装するための必須アルゴリズムが古くて弱い場合、より強いアルゴリズムが利用可能である場合に無効にする方が良いでしょう。
Some security mechanisms can protect an entire network. While this economizes on hardware, it can leave the interior of such networks open to attacks from the inside. Other mechanisms can provide protection down to the individual user of a timeshared machine, though perhaps at risk of user impersonation if the machine has been compromised.
一部のセキュリティメカニズムは、ネットワーク全体を保護できます。これはハードウェアで節約されますが、そのようなネットワークの内部を内部からの攻撃に開いたままにすることができます。他のメカニズムは、マシンが侵害されている場合、ユーザーのなりすましのリスクがあるかもしれませんが、タイムシェアマシンの個々のユーザーに保護を提供できます。
When assessing the desired granularity of protection, protocol designers should take into account likely usage patterns, implementation layers (see below), and deployability. If a protocol is likely to be used only from within a secure cluster of machines (say, a Network Operations Center), subnet granularity may be appropriate. By contrast, a security mechanism peculiar to a single application is best embedded in that application, rather than inside TCP; otherwise, deployment will be very difficult.
望ましい保護の粒度を評価する場合、プロトコル設計者は、使用パターン、実装レイヤー（以下を参照）、および展開可能性を考慮する必要があります。プロトコルがマシンの安全なクラスター内からのみ使用される可能性が高い場合（たとえば、ネットワークオペレーションセンター）、サブネットの粒度が適切かもしれません。対照的に、単一のアプリケーションに特有のセキュリティメカニズムは、TCP内ではなく、そのアプリケーションに最適に埋め込まれています。それ以外の場合、展開は非常に困難になります。
Security mechanisms can be located at any layer. In general, putting a mechanism at a lower layer protects a wider variety of higher-layer protocols, but may not be able to protect them as well. A link-layer encryptor can protect not just IP, but even ARP packets. However, its reach is just that one link. Conversely, a signed email message is protected even if sent through many store-and-forward mail gateways, can identify the actual sender, and the signature can be verified long after the message is delivered. However, only that one type of message is protected. Messages of similar formats, such as some Netnews postings, are not protected unless the mechanism is specifically adapted and then implemented in the news-handling programs.
セキュリティメカニズムは、任意のレイヤーに配置できます。一般に、メカニズムを下層に置くことで、より広範な高層プロトコルを保護しますが、同様に保護できない場合があります。リンク層の暗号化業者は、IPだけでなくARPパケットさえも保護できます。ただし、そのリーチはその1つのリンクです。逆に、多くのストアアンドフォワードメールゲートウェイを介して送信された場合でも、署名された電子メールメッセージが保護され、実際の送信者を識別でき、メッセージが配信されてから署名を確認できます。ただし、そのタイプのメッセージのみが保護されています。一部のNetNewsの投稿など、同様の形式のメッセージは、メカニズムが特別に適合してからニュース処理プログラムに実装されない限り、保護されていません。
One-time password schemes, such as that described in [RFC2289], are very much stronger than conventional passwords. The host need not store a copy of the user's password, nor is it ever transmitted over the network. However, there are some risks. Since the transmitted string is derived from a user-typed password, guessing attacks may still be feasible. (Indeed, a program to launch just this attack is readily available.) Furthermore, the user's ability to login necessarily expires after a predetermined number of uses. While in many cases this is a feature, an implementation most likely needs to provide a way to reinitialize the authentication database, without requiring that the new password be sent in the clear across the network.
[RFC2289]に記載されているようなワンタイムパスワードスキームは、従来のパスワードよりもはるかに強力です。ホストは、ユーザーのパスワードのコピーを保存する必要はなく、ネットワーク上に送信されることもありません。ただし、いくつかのリスクがあります。送信された文字列はユーザータイプのパスワードから派生しているため、攻撃がまだ実行可能であると推測する可能性があります。（実際、この攻撃を開始するプログラムは容易に入手できます。）さらに、ユーザーのログイン能力は、事前に決められた数の用途の後に必然的に期限切れになります。多くの場合、これは機能ですが、実装は、ネットワーク上のクリアで新しいパスワードを送信することなく、認証データベースを再現する方法を提供する必要がある可能性が最も高いです。
There are commercial hardware authentication tokens. Apart from the session hijacking issue, support for such tokens (especially challenge/response tokens, where the server sends a different random number for each authentication attempt) may require extra protocol messages.
商用ハードウェア認証トークンがあります。セッションのハイジャックの問題とは別に、このようなトークンのサポート（特に、サーバーが認証試行ごとに異なる乱数を送信するチャレンジ/応答トークン）には、追加のプロトコルメッセージが必要になる場合があります。
HMAC [RFC2104] is the preferred shared-secret authentication technique. If both sides know the same secret key, HMAC can be used to authenticate any arbitrary message. This includes random challenges, which means that HMAC can be adapted to prevent replays of old sessions.
HMAC [RFC2104]は、好ましい共有秘密認証手法です。双方が同じ秘密の鍵を知っている場合、HMACを使用して任意のメッセージを認証できます。これには、ランダムな課題が含まれます。つまり、HMACは古いセッションのリプレイを防ぐために適応できます。
An unfortunate disadvantage of using HMAC for connection authentication is that the secret must be known in the clear by both parties, making this undesirable when keys are long-lived.
接続認証にHMACを使用することの不幸な不利な点は、秘密が両当事者によって明確に知られている必要があり、キーが長寿命になったときにこの望ましくないことです。
When suitable, HMAC should be used in preference to older techniques, notably keyed hash functions. Simple keyed hashes based on MD5 [RFC1321], such as that used in the BGP session security mechanism [RFC2385], are especially to be avoided in new protocols, given the hints of weakness in MD5.
適切な場合、HMACは古い手法、特にキー付きハッシュ機能を好むために使用する必要があります。MD5の弱点のヒントを考えると、BGPセッションセキュリティメカニズム[RFC2385]で使用されているようなMD5 [RFC1321]に基づく単純なキー付きハッシュは、特に新しいプロトコルでは回避されます。
HMAC can be implemented using any secure hash function, including MD5 and SHA-1 [RFC3174]. SHA-1 is preferable for new protocols because it is more frequently used for this purpose and may be more secure.
HMACは、MD5やSHA-1 [RFC3174]を含む安全なハッシュ関数を使用して実装できます。SHA-1は、この目的でより頻繁に使用され、より安全になる可能性があるため、新しいプロトコルよりも好ましいです。
It is important to understand that an HMAC-based mechanism needs to be employed on every protocol data unit (aka packet). It is a mistake to use an HMAC-based system to authenticate the beginning of a TCP session and then send all remaining data without any protection.
すべてのプロトコルデータユニット（別名パケット）でHMACベースのメカニズムを使用する必要があることを理解することが重要です。HMACベースのシステムを使用してTCPセッションの開始を認証し、残りのすべてのデータを保護せずに送信することは間違いです。
Attack programs exist that permit a TCP session to be stolen. An attacker merely needs to use such a tool to steal a session after the HMAC step is performed.
TCPセッションを盗むことを許可する攻撃プログラムが存在します。攻撃者は、HMACステップが実行された後、このようなツールを使用してセッションを盗むだけです。
IPsec [RFC2401],[RFC2402],[RFC2406],[RFC2407],[RFC2411] is the generic IP-layer encryption and authentication protocol. As such, it protects all upper layers, including both TCP and UDP. Its normal granularity of protection is host-to-host, host-to-gateway, and gateway-to-gateway. The specification does permit user-granularity protection, but this is comparatively rare. As such, IPsec is currently inappropriate when host-granularity is too coarse.
IPSEC [RFC2401]、[RFC2402]、[RFC2406]、[RFC2407]、[RFC2411]は、一般的なIP層暗号化と認証プロトコルです。そのため、TCPとUDPの両方を含むすべての上層層を保護します。保護の通常の粒度は、ホストからホスト、ホストからゲートウェイ、ゲートウェイからゲートウェイです。この仕様では、ユーザーの粒度保護が可能になりますが、これは比較的まれです。そのため、ホスト粒度が粗すぎる場合、IPSECは現在不適切です。
Because IPsec is installed at the IP layer, it is rather intrusive to the networking code. Implementing it generally requires either new hardware or a new protocol stack. On the other hand, it is fairly transparent to applications. Applications running over IPsec can have improved security without changing their protocols at all. But at least until IPsec is more widely deployed, most applications should not assume they are running atop IPsec as an alternative to specifying their own security mechanisms. Most modern operating systems have IPsec available; most routers do not, at least for the control path. An application using TLS is more likely to be able to assert application-specific to take advantage of its authentication.
IPSECはIPレイヤーにインストールされているため、ネットワークコードに邪魔になります。通常、実装するには、新しいハードウェアまたは新しいプロトコルスタックのいずれかが必要です。一方、アプリケーションに対してかなり透明です。IPSECを介して実行されるアプリケーションは、プロトコルをまったく変更せずにセキュリティを改善する可能性があります。しかし、少なくともIPSECがより広く展開されるまで、ほとんどのアプリケーションは、独自のセキュリティメカニズムを指定する代替としてIPSECの上で実行されていると想定すべきではありません。ほとんどの最新のオペレーティングシステムには、IPSECが利用可能です。ほとんどのルーターは、少なくとも制御パスではそうではありません。TLSを使用したアプリケーションは、その認証を活用するためにアプリケーション固有のものを主張できる可能性が高くなります。
The key management for IPsec can use either certificates or shared secrets. For all the obvious reasons, certificates are preferred; however, they may present more of a headache for the system manager.
IPSECの主要な管理は、証明書または共有秘密のいずれかを使用できます。すべての明らかな理由から、証明書が推奨されます。ただし、システムマネージャーには頭痛の種が増えている場合があります。
There is strong potential for conflict between IPsec and NAT [RFC2993]. NAT does not easily coexist with any protocol containing embedded IP address; with IPsec, every packet, for every protocol, contains such addresses, if only in the headers. The conflict can sometimes be avoided by using tunnel mode, but that is not always an appropriate choice for other reasons. There is ongoing work to make IPsec pass through NAT more easily [NATIKE].
IPSECとNAT [RFC2993]の間には強い矛盾があります。NATは、埋め込まれたIPアドレスを含むプロトコルと簡単に共存しません。IPSECでは、すべてのプロトコルのすべてのパケットには、ヘッダーのみである場合、そのようなアドレスが含まれています。トンネルモードを使用することで競合を回避することもありますが、それは他の理由で常に適切な選択ではありません。IPSECをNATをより簡単に通過させるための継続的な作業があります[Natike]。
Most current IPsec usage is for virtual private networks. Assuming that the other constraints are met, IPsec is the security protocol of choice for VPN-like situations, including the remote access scenario where a single machine tunnels back into its home network over the internet using IPsec.
現在のほとんどのIPSEC使用は、仮想プライベートネットワーク用です。他の制約が満たされていると仮定すると、IPSECは、単一のマシンがIPSECを使用してインターネット上でホームネットワークに戻るリモートアクセスシナリオなど、VPNのような状況に最適なセキュリティプロトコルです。
TLS [RFC2246] provides an encrypted, authenticated channel that runs on top of TCP. While TLS was originally designed for use by Web browsers, it is by no means restricted to such. In general, though, each application that wishes to use TLS will need to be converted individually.
TLS [RFC2246]は、TCPの上で実行される暗号化された認証されたチャネルを提供します。TLSはもともとWebブラウザーで使用するために設計されていましたが、決してそのようなことに限定されていません。ただし、一般に、TLSの使用を希望する各アプリケーションは個別に変換する必要があります。
Generally, the server side is always authenticated by a certificate. Clients may possess certificates, too, providing mutual authentication, though this is rarely deployed. It's an unfortunate reality that even server side authentication it not as secure in practice as the cryptography would imply because most implementations allow users to ignore authentication failures (by clicking OK to a warning) and most users routinely do so [Bell98]. Designers should thus be wary of demanding plaintext passwords, even over TLS-protected connections. (This requirement can be relaxed if it is likely that implementations will be able to verify the authenticity and authorization of the server's certificate.)
通常、サーバー側は常に証明書によって認証されます。クライアントは、相互認証を提供する証明書も所有している場合がありますが、これはめったに展開されません。ほとんどの実装により、ユーザーが認証障害を無視できるため（警告にOKをクリックして）、ほとんどのユーザーが定期的にそうしているため、サーバーサイドの認証で実際には暗示されていないことは不幸な現実です[Bell98]。したがって、設計者は、TLSで保護された接続を超えても、プレーンテキストパスワードを要求することに注意する必要があります。（この要件は、実装がサーバーの証明書の信頼性と承認を検証できる可能性が高い場合に緩和することができます。）
Although application modification is generally required to make use of TLS, there exist toolkits, both free and commercial, that provide implementations. These are designed to be incorporated into the application's code. An application using TLS is more likely to be able to assert application specific certificate policies than one using IPsec.
TLSを使用するには一般にアプリケーションの変更が必要ですが、実装を提供するツールキットが無料で商業的なツールキットが存在します。これらは、アプリケーションのコードに組み込まれるように設計されています。TLSを使用したアプリケーションは、IPSECを使用したものよりもアプリケーション固有の証明書ポリシーをアサートできる可能性が高くなります。
SASL [RFC2222] is a framework for negotiating an authentication and encryption mechanism to be used over a TCP stream. As such, its security properties are those of the negotiated mechanism. Specifically, unless the negotiated mechanism authenticates all of the subsequent messages or underlying protection protocol such as TLS is used, TCP connections are vulnerable to session stealing.
SASL [RFC2222]は、TCPストリームで使用される認証と暗号化メカニズムを交渉するためのフレームワークです。そのため、そのセキュリティプロパティは、交渉されたメカニズムのセキュリティプロパティです。具体的には、交渉されたメカニズムが後続のすべてのメッセージまたはTLSなどの基礎となる保護プロトコルを認証しない限り、TCP接続はセッション盗みに対して脆弱です。
If you need to use TLS (or IPSec) under SASL, why bother with SASL in the first place? Why not simply use the authentication facilities of TLS and be done with it?
SASLでTLS（またはIPSEC）を使用する必要がある場合、そもそもなぜSASLを悩ませるのですか？TLSの認証施設を使用して、それで終了してみませんか？
The answer here is subtle. TLS makes extensive use of certificates for authentication. As commonly deployed, only servers have certificates, whereas clients go unauthenticated (at least by the TLS processing itself).
ここでの答えは微妙です。TLSは、認証のために証明書を広範囲に使用しています。一般的に展開されるように、クライアントは証明書を持っていますが、クライアントは（少なくともTLS処理自体によって）認定されません。
SASL permits the use of more traditional client authentication technologies, such as passwords (one-time or otherwise). A powerful combination is TLS for underlying protection and authentication of the server, and a SASL-based system for authenticating clients. Care must be taken to avoid man-in-the-middle vulnerabilities when different authentication techniques are used in different directions.
SASLは、パスワードなどの従来のクライアント認証テクノロジーの使用を許可しています（1回限り）。強力な組み合わせは、サーバーの根本的な保護と認証のためのTLSと、クライアントを認証するためのSASLベースのシステムです。さまざまな認証手法が異なる方向に使用されている場合、中間の脆弱性を避けるために注意する必要があります。
GSS-API [RFC2744] provides a framework for applications to use when they require authentication, integrity, and/or confidentiality. Unlike SASL, GSS-API can be used easily with UDP-based applications. It provides for the creation of opaque authentication tokens (aka chunks of memory) which may be embedded in a protocol's data units. Note that the security of GSS-API-protected protocols depends on the underlying security mechanism; this must be evaluated independently. Similar considerations apply to interoperability, of course.
GSS-API [RFC2744]は、認証、整合性、および/または機密性が必要な場合に使用するアプリケーションのフレームワークを提供します。SASLとは異なり、GSS-APIはUDPベースのアプリケーションで簡単に使用できます。プロトコルのデータ単位に埋め込まれる可能性のある不透明な認証トークン（別名メモリのチャンク）の作成を提供します。GSS-APIで保護されたプロトコルのセキュリティは、基礎となるセキュリティメカニズムに依存することに注意してください。これは独立して評価する必要があります。もちろん、相互運用性にも同様の考慮事項が適用されます。
DNSSEC [RFC2535] digitally signs DNS records. It is an essential tool for protecting against DNS cache contamination attacks [Bell95]; these in turn can be used to defeat name-based authentication and to redirect traffic to or past an attacker. The latter makes DNSSEC an essential component of some other security mechanisms, notably IPsec.
DNSSEC [RFC2535]デジタルでDNSレコードに署名します。これは、DNSキャッシュ汚染攻撃から保護するための不可欠なツールです[Bell95]。これらは、名前ベースの認証を打ち負かし、攻撃者へのトラフィックをリダイレクトするために使用できます。後者は、DNSSECを他のいくつかのセキュリティメカニズム、特にIPSECの重要なコンポーネントにします。
Although not widely deployed on the Internet at the time of the writing of this document, it offers the potential to provide a secure mechanism for mapping domain names to IP protocol addresses. It may also be used to securely associate other information with a DNS name.
このドキュメントの執筆時点でインターネット上に広く展開されていませんが、IPプロトコルアドレスにドメイン名をマッピングするための安全なメカニズムを提供する可能性を提供します。また、他の情報をDNS名に安全に関連付けるためにも使用できます。
This information may be as simple as a service that is supported on a given node, or a key to be used with IPsec for negotiating a secure session. Note that the concept of storing general purpose application keys in the DNS has been deprecated [RFC3445], but standardization of storing keys for particular applications - in particular IPsec - is proceeding.
この情報は、特定のノードでサポートされているサービスと同じくらい簡単な場合、または安全なセッションを交渉するためにIPSECで使用されるキーです。DNSに汎用アプリケーションキーを保存するという概念は廃止された[RFC3445]が、特定のアプリケーションのためにキーを保存する標準化、特にIPSECでは進行中であることに注意してください。
Security/Multiparts [RFC1847] are the preferred mechanism for protecting email. More precisely, it is the MIME framework within which encryption and/or digital signatures are embedded. Both S/MIME and OpenPGP (see below) use Security/Multipart for their encoding. Conforming mail readers can easily recognize and process the cryptographic portions of the mail.
セキュリティ/マルチパート[RFC1847]は、電子メールを保護するための好ましいメカニズムです。より正確には、それは暗号化やデジタル署名が組み込まれているMIMEフレームワークです。S/MIMEとOpenPGPの両方（以下を参照）エンコードにはセキュリティ/マルチパートを使用します。コンフォームズメールリーダーは、メールの暗号化部分を簡単に認識して処理できます。
Security/Multiparts represents one form of "object security", where the object of interest to the end user is protected, independent of transport mechanism, intermediate storage, etc. Currently, there is no general form of object protection available in the Internet.
セキュリティ/マルチパートは、「オブジェクトセキュリティ」の1つの形式を表します。エンドユーザーにとって関心のあるオブジェクトは、輸送メカニズム、中間ストレージなどとは無関係に保護されています。現在、インターネットでは一般的な形式のオブジェクト保護はありません。
For a good example of using S/MIME outside the context of email, see Session Initiation Protocol [RFC 3261].
電子メールのコンテキストの外でS/MIMEを使用する良い例については、セッション開始プロトコル[RFC 3261]を参照してください。
One of the strongest forms of challenge/response authentication is based on digital signatures. Using public key cryptography is preferable to schemes based on secret key ciphers because no server needs a copy of the client's secret. Rather, the client has a private key; servers have the corresponding public key.
チャレンジ/応答認証の最も強力な形式の1つは、デジタル署名に基づいています。サーバーがクライアントの秘密のコピーを必要としないため、シークレットキー暗号に基づいたスキームよりも公開キーの暗号化を使用することが望ましいです。むしろ、クライアントには秘密鍵があります。サーバーには対応する公開キーがあります。
Using digital signatures properly is tricky. A client should never sign the exact challenge sent to it, since there are several subtle number-theoretic attacks that can be launched in such situations.
デジタル署名を適切に使用するのは難しいです。クライアントは、そのような状況で開始できるいくつかの微妙な数の理論的攻撃があるため、それに送られた正確な課題に決して署名してはなりません。
The Digital Signature Standard [DSS] and RSA [RSA] are both good choices; each has its advantages. Signing with DSA requires the use of good random numbers [RFC1750]. If the enemy can recover the random number used for any given signature, or if you use the same random number for two different documents, your private key can be recovered. DSS has much better performance than RSA for generating new private keys, and somewhat better performance generating signatures, while RSA has much better performance for verifying signatures.
デジタル署名標準[DSS]とRSA [RSA]はどちらも良い選択です。それぞれに利点があります。DSAに署名するには、良好な乱数[RFC1750]を使用する必要があります。敵が特定の署名に使用される乱数を回収できる場合、または2つの異なるドキュメントに同じ乱数を使用する場合、秘密鍵を回復することができます。DSSは、新しいプライベートキーを生成するためのRSAよりもはるかに優れたパフォーマンスを持ち、署名を生成するパフォーマンスを生成しますが、RSAは署名を検証するためのパフォーマンスがはるかに優れています。
Digital signatures can be used to build "object security" applications which can be used to protect data in store and forward protocols such as electronic mail.
デジタル署名は、電子メールなどのストアおよびフォワードプロトコルのデータを保護するために使用できる「オブジェクトセキュリティ」アプリケーションを構築するために使用できます。
At this writing, two different secure mail protocols, OpenPGP [OpenPGP] and S/MIME [S/MIME], have been proposed to replace PEM [PEM]. It is not clear which, if either, will succeed. While specified for use with secure mail, both can be adapted to protect data carried by other protocols. Both use certificates to identify users; both can provide secrecy and authentication of mail messages; however, the certificate formats are very different. Historically, the difference between PGP-based mail and S/MIME-based mail has been the style of certificate chaining. In S/MIME, users possess X.509 certificates; the certification graph is a tree with a very small number of roots. By contrast, PGP uses the so-called "web of trust", where any user can sign anyone else's certificate. This certification graph is really an arbitrary graph or set of graphs.
この執筆では、2つの異なる安全なメールプロトコルであるOpenPGP [OpenPGP]とS/MIME [S/MIME]がPEM [PEM]を置き換えることが提案されています。どちらも成功するのかは明らかではありません。安全なメールで使用するために指定されていますが、どちらも他のプロトコルによって運ばれるデータを保護するために適合させることができます。どちらも証明書を使用してユーザーを識別します。どちらもメールメッセージの秘密と認証を提供できます。ただし、証明書形式は非常に異なります。歴史的に、PGPベースのメールとS/MIMEベースのメールの違いは、証明書チェーンのスタイルでした。S/MIMEでは、ユーザーはX.509証明書を所有しています。認定グラフは、非常に少数の根を持つツリーです。対照的に、PGPはいわゆる「Web of Trust」を使用します。ここでは、ユーザーは他の人の証明書に署名できます。この認証グラフは、実際には任意のグラフまたはグラフのセットです。
With any certificate scheme, trust depends on two primary characteristics. First, it must start from a known-reliable source, either an X.509 root, or someone highly trusted by the verifier, often him or herself. Second, the chain of signatures must be reliable. That is, each node in the certification graph is crucial; if it is dishonest or has been compromised, any certificates it has vouched for cannot be trusted. All other factors being equal (and they rarely are), shorter chains are preferable.
任意の証明書スキームでは、信頼は2つの主要な特性に依存します。まず、X.509ルート、または検証者に非常に信頼されている人、しばしば自分自身に信頼されている人のいずれかで、既知の信頼できるソースから開始する必要があります。第二に、署名のチェーンは信頼できる必要があります。つまり、認定グラフ内の各ノードは非常に重要です。それが不正であるか、妥協されている場合、それが保証した証明書は信頼できません。他のすべての要因は等しい（そしてめったにそうではない）、より短いチェーンが望ましい。
Some of the differences reflect a tension between two philosophical positions represented by these technologies. Others resulted from having separate design teams.
違いのいくつかは、これらの技術に代表される2つの哲学的位置の間の緊張を反映しています。その他は、独立したデザインチームを持つことから生じました。
S/MIME is designed to be "fool proof". That is, very little end-user configuration is required. Specifically, end-users do not need to be aware of trust relationships, etc. The idea is that if an S/MIME client says, "This signature is valid", the user should be able to "trust" that statement at face value without needing to understand the underlying implications.
S/MIMEは「愚か者の証拠」になるように設計されています。つまり、エンドユーザーの構成はほとんど必要ありません。具体的には、エンドユーザーは信頼関係などに注意する必要はありません。アイデアは、S/MIMEクライアントが「この署名が有効」と言う場合、ユーザーはそのステートメントを額面通りに「信頼する」ことができるはずです根本的な意味を理解する必要なく。
To achieve this, S/MIME is typically based on a limited number of "root" Certifying Authorities (CAs). The goal is to build a global trusted certificate infrastructure.
これを達成するために、S/MIMEは通常、限られた数の「ルート」認証当局（CA）に基づいています。目標は、グローバルな信頼できる証明書インフラストラクチャを構築することです。
The down side to this approach is that it requires a deployed public key infrastructure before it will work. Two end-users may not be able to simply obtain S/MIME-capable software and begin communicating securely. This is not a limitation of the protocol, but a typical configuration restriction for commonly available software. One or both of them may need to obtain a certificate from a mutually trusted CA; furthermore, that CA must already be trusted by their mail handling software. This process may involve cost and legal obligations. This ultimately results in the technology being harder to deploy, particularly in an environment where end-users do not necessarily appreciate the value received for the hassle incurred.
このアプローチのダウンサイドは、機能する前に展開された公開キーインフラストラクチャが必要であることです。2人のエンドユーザーは、単にS/MIME対応ソフトウェアを取得して安全に通信し始めることができない場合があります。これはプロトコルの制限ではなく、一般的に利用可能なソフトウェアの典型的な構成制限です。それらの1つまたは両方が、相互に信頼されたCAから証明書を取得する必要がある場合があります。さらに、そのCAは、メール処理ソフトウェアによってすでに信頼されている必要があります。このプロセスには、コストと法的義務が含まれる場合があります。これにより、最終的には、特にエンドユーザーが発生した面倒なものの価値を必ずしも理解していない環境では、技術の展開が困難になります。
The PGP "web of trust" approach has the advantage that two end-users can just obtain PGP software and immediately begin to communicate securely. No infrastructure is required and no fees and legal agreements need to be signed to proceed. As such PGP appeals to people who need to establish ad-hoc security associations.
PGP「Web of Trust」アプローチには、2人のエンドユーザーがPGPソフトウェアを取得し、すぐに安全に通信し始めることができるという利点があります。インフラストラクチャは必要ありませんし、続行するために署名する料金や法的契約に署名する必要はありません。そのように、PGPはアドホックセキュリティ協会を確立する必要がある人々に訴えます。
The down side to PGP is that it requires end-users to have an understanding of the underlying security technology in order to make effective use of it. Specifically it is fairly easy to fool a naive users to accept a "signed" message that is in fact a forgery.
PGPのダウンサイドは、エンドユーザーがそれを効果的に使用するために、基礎となるセキュリティテクノロジーを理解する必要があることです。具体的には、素朴なユーザーが実際に偽造である「署名された」メッセージを受け入れるのはかなり簡単です。
To date PGP has found great acceptance between security-aware individuals who have a need for secure e-mail in an environment devoid of the necessary global infrastructure.
これまで、PGPは、必要なグローバルインフラストラクチャのない環境で安全な電子メールを必要とするセキュリティ認識者の間で大きな受け入れを認めています。
By contrast, S/MIME works well in a corporate setting where a secure internal CA system can be deployed. It does not require a lot of end-user security knowledge. S/MIME can be used between institutions by carefully setting up cross certification, but this is harder to do than it seems.
対照的に、S/MIMEは、安全な内部CAシステムを展開できる企業環境でうまく機能します。エンドユーザーのセキュリティ知識はあまり必要ありません。S/MIMEは、クロス認証を慎重に設定することで機関間で使用できますが、これは見た目よりも難しいです。
As of this writing a global certificate infrastructure continues to elude us. Questions about a suitable business model, as well as privacy considerations, may prevent one from ever emerging.
この時点で、グローバルな証明書インフラストラクチャは私たちを逃れ続けています。適切なビジネスモデルに関する質問、およびプライバシーの考慮事項は、これまで以上に出現することを妨げる可能性があります。
Firewalls are a topological defense mechanism. That is, they rely on a well-defined boundary between the good "inside" and the bad "outside" of some domain, with the firewall mediating the passage of information. While firewalls can be very valuable if employed properly, there are limits to their ability to protect a network.
ファイアウォールはトポロジー的防御メカニズムです。つまり、彼らはいくつかのドメインの「内部」と悪い「外側」の間の明確に定義された境界に依存しており、ファイアウォールは情報の通過を媒介しています。ファイアウォールは適切に採用すると非常に価値がありますが、ネットワークを保護する能力には制限があります。
The first limitation, of course, is that firewalls cannot protect against inside attacks. While the actual incidence rate of such attacks is not known (and is probably unknowable), there is no doubt that it is substantial, and arguably constitutes a majority of security problems. More generally, given that firewalls require a well-delimited boundary, to the extent that such a boundary does not exist, firewalls do not help. Any external connections, whether they are protocols that are deliberately passed through the firewall, links that are tunneled through, unprotected wireless LANs, or direct external connections from nominally-inside hosts, weaken the protection. Firewalls tend to become less effective over time as users tunnel protocols through them and may have inadequate security on the tunnel endpoints. If the tunnels are encrypted, there is no way for the firewall to censor them. An oft-cited advantage of firewalls is that they hide the existence of internal hosts from outside eyes. Given the amount of leakage, however, the likelihood of successfully hiding machines is rather low.
もちろん、最初の制限は、ファイアウォールが内部攻撃から保護できないことです。そのような攻撃の実際の発生率は知られていない（そしておそらく知らない）が、それがかなりのものであることは間違いなく、おそらくセキュリティ問題の大部分を構成することは間違いない。より一般的には、ファイアウォールには、そのような境界が存在しない限り、明確な境界が必要であることを考えると、ファイアウォールは役に立ちません。ファイアウォールを意図的に渡されるプロトコル、トンネルを通過するリンク、保護されていないワイヤレスLAN、または名目上のインサイドホストからの直接的な外部接続が保護を弱めるかどうかにかかわらず、外部接続はすべて、外部接続があります。ユーザーがトンネルプロトコルを通過するため、ファイアウォールは時間の経過とともに効果が低下する傾向があり、トンネルエンドポイントに不十分なセキュリティがある可能性があります。トンネルが暗号化されている場合、ファイアウォールがそれらを検閲する方法はありません。しばしば引用されたファイアウォールの利点は、それらが外側の目から内部ホストの存在を隠すことです。ただし、漏れの量を考えると、マシンを正常に隠す可能性はかなり低いです。
In a more subtle vein, firewalls hurt the end-to-end model of the Internet and its protocols. Indeed, not all protocols can be passed safely or easily through firewalls. Sites that rely on firewalls for security may find themselves cut off from new and useful aspects of the Internet.
より微妙な静脈で、ファイアウォールはインターネットとそのプロトコルのエンドツーエンドモデルを傷つけます。実際、すべてのプロトコルを安全にまたは簡単にファイアウォールで渡すことができるわけではありません。セキュリティのためにファイアウォールに依存しているサイトは、インターネットの新しい有用な側面から自分自身が遮断される可能性があります。
Firewalls work best when they are used as one element of a total security structure. For example, a strict firewall may be used to separate an exposed Web server from a back-end database, with the only opening the communication channel between the two. Similarly, a firewall that permitted only encrypted tunnel traffic could be used to secure a piece of a VPN. On the other hand, in that case the other end of the VPN would need to be equally secured.
ファイアウォールは、セキュリティ構造全体の1つの要素として使用される場合に最適に機能します。たとえば、厳格なファイアウォールを使用して、露出したWebサーバーをバックエンドデータベースから分離することができ、2つの間に通信チャネルを開いているだけです。同様に、暗号化されたトンネルトラフィックのみを許可するファイアウォールを使用して、VPNの一部を確保できます。一方、その場合、VPNのもう一方の端を等しく保護する必要があります。
Kerberos [RFC1510] provides a mechanism for two entities to authenticate each other and exchange keying material. On the client side, an application obtains a Kerberos "ticket" and "authenticator". These items, which should be considered opaque data, are then communicated from client to server. The server can then verify their authenticity. Both sides may then ask the Kerberos software to provide them with a session key which can be used to protect or encrypt data.
Kerberos [RFC1510]は、2つのエンティティがお互いを認証し、キーイング素材を交換するメカニズムを提供します。クライアント側では、アプリケーションがKerberosの「チケット」と「認証者」を取得します。不透明なデータと見なす必要があるこれらのアイテムは、クライアントからサーバーに伝達されます。サーバーは、信頼性を確認できます。その後、双方がKerberosソフトウェアに、データの保護または暗号化に使用できるセッションキーを提供するように依頼する場合があります。
Kerberos may be used by itself in a protocol. However, it is also available as a mechanism under SASL and GSSAPI. It has some known vulnerabilities [KRBATTACK] [KRBLIM] [KRB4WEAK], but it can be used securely.
Kerberosは、プロトコルで単独で使用できます。ただし、SASLおよびGSSAPIの下でのメカニズムとしても利用できます。既知の脆弱性[krbattack] [krblim] [krb4weak]がありますが、安全に使用できます。
SSH provides a secure connection between client and server. It operates very much like TLS; however, it is optimized as a protocol for remote connections on terminal-like devices. One of its more innovative features is its support for "tunneling" other protocols over the SSH-protected TCP connection. This feature has permitted knowledgeable security people to perform such actions as reading and sending e-mail or news via insecure servers over an insecure network. It is not a substitute for a true VPN, but it can often be used in place of one.
SSHは、クライアントとサーバーの間の安全な接続を提供します。TLSと非常によく似ています。ただし、ターミナルのようなデバイス上のリモート接続のプロトコルとして最適化されています。より革新的な機能の1つは、SSHで保護されたTCP接続を介した他のプロトコルを「トンネル化」するためのサポートです。この機能により、知識豊富なセキュリティ人が、安全でないネットワークを介して安全でないサーバーを介して電子メールやニュースを読み取り、送信するなどのアクションを実行することができました。それは真のVPNの代替ではありませんが、多くの場合、1つの代わりに使用できます。
Some common security mechanisms are part of the problem rather than part of the solution.
いくつかの一般的なセキュリティメカニズムは、ソリューションの一部ではなく、問題の一部です。
Plaintext passwords are the most common security mechanism in use today. Unfortunately, they are also the weakest. When not protected by an encryption layer, they are completely unacceptable. Even when used with encryption, plaintext passwords are quite weak, since they must be transmitted to the remote system. If that system has been compromised or if the encryption layer does not include effective authentication of the server to the client, an enemy can collect the passwords and possibly use them against other targets.
平文パスワードは、今日使用されている最も一般的なセキュリティメカニズムです。残念ながら、彼らは最も弱いです。暗号化層によって保護されていない場合、それらは完全に受け入れられません。暗号化で使用する場合でも、プレーンテキストパスワードはリモートシステムに送信する必要があるため、非常に弱いです。そのシステムが侵害された場合、または暗号化レイヤーにクライアントへのサーバーの効果的な認証が含まれていない場合、敵はパスワードを収集し、可能性のあるターゲットに対して使用できます。
Another weakness arises because of common implementation techniques. It is considered good form [MT79] for the host to store a one-way hash of the users' passwords, rather than their plaintext form. However, that may preclude migrating to stronger authentication mechanisms, such as HMAC-based challenge/response.
一般的な実装手法のために別の弱点が生じます。ホストがプレーンテキストフォームではなく、ユーザーのパスワードの一方向のハッシュを保存するための適切なフォーム[MT79]と考えられています。ただし、HMACベースの課題/応答など、より強力な認証メカニズムへの移行を妨げる可能性があります。
The strongest attack against passwords, other than eavesdropping, is password-guessing. With a suitable program and dictionary (and these are widely available), 20-30% of passwords can be guessed in most environments [Klein90].
盗聴以外のパスワードに対する最強の攻撃は、パスワード推測です。適切なプログラムと辞書（およびこれらは広く入手可能）では、ほとんどの環境でパスワードの20〜30％が推測できます[Klein90]。
Another common security mechanism is address-based authentication. At best, it can work in highly constrained environments. If your environment consists of a small number of machines, all tightly administered, secure systems run by trusted users, and if the network is guarded by a router that blocks source-routing and prevents spoofing of your source addresses, and you know there are no wireless bridges, and if you restrict address-based authentication to machines on that network, you are probably safe. But these conditions are rarely met.
別の一般的なセキュリティメカニズムは、アドレスベースの認証です。せいぜい、それは非常に制約された環境で動作する可能性があります。あなたの環境が少数のマシンで構成されている場合、すべてが信頼できるユーザーが実行するすべての緊密に管理されたセキュアシステム、およびネットワークがソースルーティングをブロックし、ソースアドレスのスプーフィングを防ぐルーターによって保護されている場合、ワイヤレスブリッジ、そしてそのネットワーク上のマシンに住所ベースの認証を制限する場合、おそらく安全です。しかし、これらの条件はめったに満たされません。
Among the threats are ARP-spoofing, abuse of local proxies, renumbering, routing table corruption or attacks, DHCP, IP address spoofing (a particular risk for UDP-based protocols), sequence number guessing, and source-routed packets. All of these can be quite potent.
脅威の中には、ARPスプーフィング、ローカルプロキシの乱用、変更、ルーティングテーブルの破損または攻撃、DHCP、IPアドレススプーフィング（UDPベースのプロトコルの特定のリスク）、シーケンス番号推測、およびソースルーティングパケットがあります。これらはすべて非常に強力です。
Name-based authentication has all of the problems of address-based authentication and adds new ones: attacks on the DNS [Bell95] and lack of a one to one mapping between addresses and names. At a minimum, a process that retrieves a host name from the DNS should retrieve the corresponding address records and cross-check. Techniques such as DNS cache contamination can often negate such checks.
名前ベースの認証には、アドレスベースの認証のすべての問題があり、新しいものを追加します。DNS[Bell95]への攻撃と、アドレスと名前の間の1対1のマッピングの欠如です。少なくとも、DNSからホスト名を取得するプロセスでは、対応するアドレスレコードとクロスチェックを取得する必要があります。DNSキャッシュの汚染などの手法は、しばしばそのようなチェックを無効にする可能性があります。
DNSSEC provides protection against this sort of attack. However, it does nothing to enhance the reliability of the underlying address. Further, the technique generates a lot of false alarms. These lookups do not provide reliable information to a machine, though they might be a useful debugging tool for humans and could be useful in logs when trying to reconstruct how and attack took place.
DNSSECは、この種の攻撃に対する保護を提供します。ただし、基礎となる住所の信頼性を高めることはできません。さらに、この手法は多くの誤報を生成します。これらのルックアップはマシンに信頼できる情報を提供しませんが、それらは人間にとって有用なデバッグツールである可能性があり、攻撃の発生方法を再構築しようとする際にログに役立つ可能性があります。
No security mechanisms are perfect. If nothing else, any network-based security mechanism can be thwarted by compromise of the endpoints. That said, each of the mechanisms described here has its own limitations. Any decision to adopt a given mechanism should weigh all of the possible failure modes. These in turn should be weighed against the risks to the endpoint of a security failure.
完璧なセキュリティメカニズムはありません。他に何もなければ、ネットワークベースのセキュリティメカニズムは、エンドポイントの妥協によって阻止できます。とはいえ、ここで説明する各メカニズムには独自の制限があります。特定のメカニズムを採用するという決定は、すべての障害モードの重量を量る必要があります。これらは、セキュリティ障害のエンドポイントに対するリスクに対して比較検討する必要があります。
There are no IANA considerations regarding this document.
このドキュメントに関するIANAの考慮事項はありません。
Brian Carpenter, Tony Hain, and Marcus Leech made a number of useful suggestions. Much of the substance comes from the participants in the IAB Security Architecture Workshop.
ブライアン・カーペンター、トニー・ハイン、マーカス・リーチは、多くの有用な提案をしました。物質の多くは、IABセキュリティアーキテクチャワークショップの参加者から来ています。
[Bell95] "Using the Domain Name System for System Break-Ins". Proc. Fifth Usenix Security Conference, 1995.
[bell95]「システムの侵入にドメイン名システムを使用」。Proc。第5回USENIXセキュリティ会議、1995年。
[Bell98] "Cryptography and the Internet", S.M. Bellovin, in Proceedings of CRYPTO '98, August 1998.
[Bell98]「暗号化とインターネット」、S.M。Bellovin、Crypto '98の議事録、1998年8月。
[DSS] "Digital Signature Standard". NIST. May 1994. FIPS 186.
[DSS]「デジタル署名標準」。nist。1994年5月。FIPS186。
[Klein90] "Foiling the Cracker: A Survey of, and Implications to, Password Security". D. Klein. Usenix UNIX Security Workshop, August 1990.
[klein90]「クラッカーの箔：パスワードセキュリティの調査と影響」。D.クライン。USENIX UNIXセキュリティワークショップ、1990年8月。
[KRBATTACK] "A Real-World Analysis of Kerberos Password Security". T. Wu. Network and Distributed System Security Symposium (NDSS '99). January 1999.
[Krbattack]「Kerberosパスワードセキュリティの実際の分析」。T.ウー。ネットワークおよび分散システムセキュリティシンポジウム（NDSS '99）。1999年1月。
[KRBLIM] "Limitations of the Kerberos Authentication System". Proceedings of the 1991 Winter USENIX Conference, 1991.
[Krblim]「Kerberos認証システムの制限」。1991年冬のユースニックス会議の議事録、1991年。
[KRB4WEAK] "Misplaced trust: Kerberos 4 session keys". Proceedings of the Internet Society Network and Distributed Systems Security Symposium, March 1997.
[krb4weak]「誤った信頼：kerberos 4セッションキー」。インターネットソサエティネットワークおよび分散システムセキュリティシンポジウムの議事録、1997年3月。
[MT79] "UNIX Password Security", R.H. Morris and K. Thompson, Communications of the ACM. November 1979.
[MT79]「UNIXパスワードセキュリティ」、R.H。モリスとK.トンプソン、ACMのコミュニケーション。1979年11月。
[NATIKE] Kivinen, T., et al., "Negotiation of NAT-Traversal in the IKE", Work in Progress, June 2002.
[Natike] Kivinen、T.、et al。、「IKEにおけるNat-Traversalの交渉」、2002年6月、進行中の作業。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジストアルゴリズム」、RFC 1321、1992年4月。
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510] Kohl、J。およびC. Neuman、「The Kerberos Network Authentication Service（V5）」、RFC 1510、1993年9月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] Eastlake、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性推奨」、RFC 1750、1994年12月。
[RFC1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[RFC1847] Galvin、J.、Murphy、S.、Crocker、S。、およびN. Freed、「Mimeのセキュリティマルチパート：MultiPart/Signed and MultiPart/暗号化」、RFC 1847、1995年10月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC2222] Myers、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time Password System", STD 61, RFC 2289, February 1998.
[RFC2289] Haller、N.、Metz、C.、Nesser、P。and M. Straw、「1回限りのパスワードシステム」、STD 61、RFC 2289、1998年2月。
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.
[RFC2316] Bellovin、S。、「IAB Security Architecture Workshopのレポート」、RFC 2316、1998年4月。
[RFC2385] Hefferman, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Hefferman、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S。およびR.アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411] Thayer、R.、Doraswamy、N。およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
[RFC2744] Wray, J., "Generic Security Service API Version 2: C-bindings", RFC 2744, January 2000.
[RFC2744] Wray、J。、「ジェネリックセキュリティサービスAPIバージョン2：C-Bindings」、RFC 2744、2000年1月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、T。、「Natの建築的意味」、RFC 2993、2000年11月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174] Eastlake、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年9月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, R., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、R.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M. and E. Schooler、「SIP：SESSION INTIATION Protocol」、RFC 3261、2002年6月。
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
[RFC3445] Massey、D。およびS. Rose、「主要なリソースレコード（RR）の範囲の制限」、RFC 3445、2002年12月。
[RSA] Rivest, R., Shamir, A. and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, February 1978.
[RSA] Rivest、R.、Shamir、A。、およびL. Adleman、「デジタル署名と公開鍵暗号システムを取得する方法」、ACMの通信、1978年2月。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
This document is a publication of the Internet Architecture Board. Internet Architecture Board Members at the time this document was completed were:
このドキュメントは、インターネットアーキテクチャボードの出版物です。このドキュメントが完成した時点で、インターネットアーキテクチャボードメンバーは次のとおりです。
Bernard Aboba Harald Alvestrand Rob Austein Leslie Daigle, Chair Patrik Faltstrom Sally Floyd Jun-ichiro Itojun Hagino Mark Handley Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Michael StJohns
バーナード・アボバ・ハラルド・アルベストランド・ロブ・オーストイン・レスリー・デイグル、椅子パトリック・ファルトストロム・サリー・フロイド・ジュン・イチーノ・イトジノ・マーク・ハンドリー・ジェフ・ハストン・チャーリー・カウフマン・ジェームズ・ケンプ
Internet Architecture Board EMail: iab@iab.org
インターネットアーキテクチャボードメールメール：iab@iab.org
Steven M. Bellovin, Editor EMail: bellovin@acm.org
Steven M. Bellovin、編集者メール：bellovin@acm.org
Jeffrey I. Schiller, Editor EMail: jis@mit.edu
Jeffrey I. Schiller、編集者メール：jis@mit.edu
Charlie Kaufman, Editor EMail: charliek@microsoft.com
Charlie Kaufman、編集者メール：charliek@microsoft.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
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エディター機能の資金は現在、インターネット協会によって提供されています。