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.
著作権（C）インターネット協会（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.
セキュリティがしっかりとそのサービスを提供するために、これらのプロトコルのためのインターネットプロトコルに組み込まれている必要があります。多くのセキュリティ上の問題は、不適切な実装にトレースすることができます。基本的なプロトコルは、それ自体で悪用可能である場合しかし、たとえ適切な実装は、セキュリティ上の問題が発生します。正確セキュリティプロトコルに実装する方法ので、プロトコル自体の構造、変化するであろう。しかし、標準のインターネット・セキュリティ・メカニズム、既に開発は、適用される可能性があるため、多くのプロトコルがあります。どのような状況では適切で正確な1は変えることができます。私たちは、それぞれの性質を説明する、さまざまな選択肢の数を確認します。
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サイトなどの低値の目標は、多くの保護に値しないかもしれません。逆に、インターネットインフラストラクチャの重要な部分を公開する可能性が損なわ場合、リソースは、たとえば、主要なバックボーンルータまたはハイレベルのドメイン・ネーム・サーバーは、非常に強力なメカニズムによって保護されなければなりません。攻撃者にターゲットの値は、攻撃の目的に依存します。目的は機密情報にアクセスする場合、この情報を扱うか、それへのアクセスを仲介するすべてのシステムが貴重です。目的は大混乱をもたらすのであれば、インターネットの大部分が依存しているシステムは非常に価値があります。公開情報のみがウェブサイトに掲載されていても、その内容を変更すると、その所有者に困惑を引き起こす可能性がありますし、かなりの損傷につながる可能性があります。プロトコルがいつか持っていることを使用するものを予測するためのプロトコルを設計するとき、それは困難です。
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.
プロトコルを確保するための私たちに利用できる最も重要なツールの一つは、暗号です。暗号化は、ネットワーク自体の任意の特定のセキュリティ特性に依存することなく、それがネットワークを横断するときに、データの保護の様々な種類を適用するために私達を許可します。インターネット、その分散管理と制御により、それ自体の信頼できるメディアを考えることはできないので、これは重要です。そのセキュリティは、我々はプロトコルの中に自分自身を構築するメカニズムに由来し、基礎となるメディアまたはネットワークオペレータの独立しました。
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でのメカニズム「を実装するために義務的」という概念を進化させてきました。この哲学は、プロトコルの異なる実装間の相互運用性を確保するために私たちの主な願望から発展します。プロトコルは、特定のタスクを実行する方法のための多くのオプションを提供していますが、すべては実装しなければならない少なくとも一つを提供するために失敗した場合、複数の、非相互運用可能な実装が生じる可能性があることも可能です。これは、異なる実装に配備されている非重複機構の選択の結果です。
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は、アプリケーションの彼らのドメインはで最初に非常に制限されると考えられている場合でも、* ALL *プロトコルは、適切なセキュリティメカニズムを提供する必要があります。
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つのリンクです。逆に、署名された電子メールメッセージは、多くのストアアンドフォワードメールゲートウェイを介して送信された場合であっても保護され、実際の送信者を識別することができ、メッセージが配信された後、署名が長く確認することができます。ただし、メッセージのみの1種類が保護されていること。機構は、具体的に適合し、次にニュースハンドリングプログラムに実装されていない限り、このようないくつかのネットニュースへの投稿と同様の形式のメッセージは、保護されていません。
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は、古い技術、特に、鍵付きハッシュ関数に優先して使用すべきです。そのようなBGPセッションセキュリティメカニズム[RFC2385]で使用したものとMD5 [RFC1321]に基づいて、単純なキー付きハッシュは、特にMD5の弱点のヒントを与えて、新しいプロトコルでは回避されるべきです。
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ベースのメカニズムは、すべてのプロトコルデータユニット（別名パケット）に採用する必要があることを理解することが重要です。 TCPセッションの開始を認証するために、HMACベースのシステムを使用して、任意の保護なしで残りのすべてのデータを送信するのは間違いです。
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がより簡単に[NATIKE] NATを通過させるための継続的な仕事があります。
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を使用して1以上のアプリケーション固有の証明書ポリシーを主張することができる可能性が高いです。
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は、パスワードなどのより伝統的なクライアント認証技術、（一回またはそれ以外）を使用することが可能になります。強力な組み合わせは、基礎の保護とサーバの認証、およびクライアントを認証するためのSASLベースのシステムのためのTLSです。異なる認証技術が異なる方向に使用されている場合には注意がなman-in-the-middle脆弱性を避けるようにしなければなりません。
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レコードに署名します。これは、[Bell95] DNSキャッシュ汚染攻撃から保護するために不可欠なツールです。これらは、順番に名前ベースの認証を倒すために攻撃者に過去のトラフィックをリダイレクトするために使用することができます。後者は、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を使用するキーのように単純であってもよいです。特定のIPsecに - - DNSの汎用アプリケーション・キーを格納するという概念は廃止[RFC3445]が、特定の用途のための鍵を記憶する標準化されていることに注意してください進んでいます。
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.
セキュリティ/マルチパートは現在、インターネットで利用可能なオブジェクト保護のない一般的な形式が存在しないなどのトランスポートメカニズム、中間貯蔵の独立したエンドユーザーへの関心の対象が保護されている「オブジェクトセキュリティ」、のいずれかの形を表しています。
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.
チャレンジ/レスポンス認証の最強フォームの一つは、デジタル署名に基づいています。どのサーバもクライアントの秘密のコピーを必要としないため、公開鍵暗号を使用すると、秘密鍵暗号に基づくスキームに好適です。むしろ、クライアントは秘密鍵を持っています。サーバーは、対応する公開鍵を持っています。
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]を使用する必要があります。敵が任意の署名に使用する乱数を回復することができた場合は、二つの異なる文書に同じ乱数を使用している場合、または、あなたの秘密鍵を回収することができます。 RSAは署名を検証するためにはるかに優れた性能を有しながら、DSSは、新しい秘密鍵を生成するための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.
これを書いて、二つの異なるセキュアなメールプロトコルでは、OpenPGPの[のOpenPGP]とS / MIME [S / MIME]は、PEM [PEM]を置き換えるために提案されてきました。どちらかの場合、成功れる、明確ではありません。セキュアなメールで使用するように指定しながら、両方のは、他のプロトコルによって運ばれるデータを保護するために適合させることができます。どちらも、ユーザーを識別するための証明書を使用します。両方は、メールメッセージの機密性と認証を提供することができます。ただし、証明書のフォーマットは非常に異なっています。歴史的に、PGPベースのメールおよびS / MIMEベースのメールとの違いは、証明書チェーンのスタイルとなっています。 S / MIMEでは、ユーザーがX.509証明書を持っています。認定グラフは根の非常に少ない数の木です。これとは対照的に、PGPは、すべてのユーザーが他人の証明書に署名することができ、いわゆる「信頼のウェブ」を使用しています。この認定グラフは、実際に任意のグラフやグラフのセットです。
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ルート、既知の信頼できるソースから開始しなければならない、または誰かが非常に多くの場合、検証者が彼または彼女自身を信頼できます。第二に、署名のチェーンが信頼できるものでなければなりません。つまり、証明グラフ内の各ノードが重要です。それが不誠実であるか、改ざんされた場合、それがためにvouchedたすべての証明書を信頼することはできません。等しい他のすべての要因は、（彼らはめったにありません）、より短い鎖が好ましいです。
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対応のソフトウェアを取得し、安全に通信を開始することができないかもしれません。これは、プロトコルの制限はなく、一般的に入手可能なソフトウェアのための典型的な構成の制限はありません。それらの一方または両方が相互に信頼された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「信頼のウェブ」は、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.
この記事の執筆時点でグローバルな証明書インフラストラクチャは、私たちを逃れるために続けています。適したビジネスモデルについての質問だけでなく、プライバシーの配慮、これまで新興国からの1を防ぐことができます。
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、または直接外部接続があるかどうか、保護を弱めます。ファイアウォールは、それらを介してユーザのトンネルプロトコルなどの時間をかけてあまり効果的になる傾向があり、トンネルのエンドポイントに不十分なセキュリティを有することができます。トンネルが暗号化されている場合は、それらを検閲するために、ファイアウォールのための方法はありません。ファイアウォールのOFT-引用の利点は、外部の目から内部ホストの存在を隠すことです。漏れの量を考えると、しかし、成功した隠れマシンの可能性はかなり低いです。
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.
それらが総合的なセキュリティ構造の一つの要素として使用されているとき、ファイアウォールは最適です。例えば、厳密なファイアウォールは2つだけの間の通信チャネルを開くことで、バックエンドデータベースから露出したWebサーバーを分離するために使用されてもよいです。同様に、唯一の暗号化されたトンネルトラフィックを許可ファイアウォールは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.
ケルベロス[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.
ケルベロスプロトコルに単独で使用することができます。しかし、それはまた、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のように動作します。しかし、端末のようなデバイスにリモート接続用のプロトコルとして最適化されます。そのより革新的な特徴の一つは、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のマッピングに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。第五のUsenixセキュリティ会議、1995。
[Bell98] "Cryptography and the Internet", S.M. Bellovin, in Proceedings of CRYPTO '98, August 1998.
[Bell98] "暗号とインターネット"、S.M. CRYPTO '98、1998年8月の議事録でBellovin氏、。
[DSS] "Digital Signature Standard". NIST. May 1994. FIPS 186.
[DSS] "デジタル署名標準"。 NIST。 1994年には186をFIPSことがあります。
[Klein90] "Foiling the Cracker: A Survey of, and Implications to, Password Security". D. Klein. Usenix UNIX Security Workshop, August 1990.
[Klein90]「：パスワードのセキュリティへの調査、および影響クラッカーをFoiling」。 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]「ケルベロスパスワードセキュリティの実世界の分析」。 T.呉。ネットワークと分散システムセキュリティシンポジウム（NDSS '99）。 1999年1月。
[KRBLIM] "Limitations of the Kerberos Authentication System". Proceedings of the 1991 Winter USENIX Conference, 1991.
【KRBLIM「Kerberos認証システムの制限」。 1991冬のUSENIX会議、1991年の議事。
[KRB4WEAK] "Misplaced trust: Kerberos 4 session keys". Proceedings of the Internet Society Network and Distributed Systems Security Symposium, March 1997.
[KRB4WEAK] "見当違いの信頼：ケルベロス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.、ら、 "IKEでのNATトラバーサルの交渉"、進歩、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]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 1510、1993年9月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]イーストレイク、D.、クロッカー、S.とJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、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]ガルビン、J.、マーフィー、S.、クロッカー、S.およびN.フリード、 "MIMEマルチパートのセキュリティ：マルチパート/署名およびマルチパート/暗号化"、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.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC2222]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "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]ハラー、N.、メス、C.、Nesser、P.とM.わら、 "ワンタイムパスワードシステム"、STD 61、RFC 2289、1998年2月。
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.
[RFC2316] Bellovin氏、S.、 "IABセキュリティアーキテクチャワークショップの報告書"、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]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、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]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
"ISAKMPのための解釈のインターネットIPセキュリティー領域" [RFC2407]パイパー、D.、RFC 2407、1998年11月。
[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411]セイヤー、R.、Doraswamy、N.とR.グレン、 "IPセキュリティドキュメントロードマップ"、RFC 2411、1998年11月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
[RFC2744] Wray, J., "Generic Security Service API Version 2: C-bindings", RFC 2744, January 2000.
[RFC2744]レイ、J.、 "ジェネリックセキュリティサービスAPIバージョン2：C-バインディング"、RFC 2744、2000年1月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]ハイン、T.、 "NATの建築的意味"、RFC 2993、2000年11月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]イーストレイク、D.とP.ジョーンズは、 "米国は、ハッシュアルゴリズム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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、R.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
[RFC3445]マッセイ、D.とS.ローズ、RFC 3445 "KEYリソースレコード（RR）の範囲を制限"、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.、シャミル、A.、およびL.エーデルマン、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
バーナードAbobaハラルドAlvestrandロブAusteinとレスリーDaigle氏、議長パトリックFaltstromサリーフロイド6月-イチローいとぢゅん萩野マーク・ハンドリージェフ・ヒューストンチャーリー・カウフマンジェームス・ケンプ、エリックレスコラマイケルStJohns
Internet Architecture Board EMail: iab@iab.org
インターネットアーキテクチャ委員会メールアドレス：iab@iab.org
Steven M. Bellovin, Editor EMail: bellovin@acm.org
スティーブンM. Bellovin氏、編集者のEメール：bellovin@acm.org
Jeffrey I. Schiller, Editor EMail: jis@mit.edu
ジェフリーI.シラー、エディタのEメール：jis@mit.edu
Charlie Kaufman, Editor EMail: charliek@microsoft.com
チャーリー・カウフマン、エディタのEメール：charliek@microsoft.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。