[要約] RFC 3552は、RFC文書におけるセキュリティ考慮事項の記述ガイドラインを提供します。この文書の目的は、インターネット標準の開発においてセキュリティが適切に考慮されることを確実にすることです。利用場面としては、プロトコルやアプリケーションの設計者がセキュリティ脅威を評価し、対策を文書化する際に参照されます。関連するRFCにはRFC 2119（キーワードによる要件レベルの表現）、RFC 3552自体が更新したRFC 1543（RFCの書き方）、およびセキュリティ関連のRFC 4949（セキュリティ用語集）などがあります。
Network Working Group E. Rescorla
Request for Comments: 3552 RTFM, Inc.
BCP: 72 B. Korver
Category: Best Current Practice Xythos Software
Internet Architecture Board
IAB
July 2003
Guidelines for Writing RFC Text on Security Considerations
セキュリティ上の考慮事項に関するRFCテキストを書くためのガイドライン
Status of this Memo
本文書の状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのためのインターネットの最良の現在の慣行を指定し、改善のための議論と提案を要求します。このメモの分布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット社会（2003）。全著作権所有。
Abstract
概要
All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section.
すべてのRFCはセキュリティ上の考慮事項を持つ必要があります。歴史的に、そのようなセクションは比較的弱いです。この資料は、良いセキュリティ上の考慮事項をどのように書くかについてのRFC著者へのガイドラインを提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements. . . . . . . . . . . . . . . . . . . . . 3
2. The Goals of Security. . . . . . . . . . . . . . . . . . . 3
2.1. Communication Security. . . . . . . . . . . . . . . . 3
2.1.1. Confidentiality. . . . . . . . . . . . . . . . 4
2.1.2. Data Integrity . . . . . . . . . . . . . . . . 4
2.1.3. Peer Entity authentication . . . . . . . . . . 4
2.2. Non-Repudiation . . . . . . . . . . . . . . . . . . . 5
2.3. Systems Security. . . . . . . . . . . . . . . . . . . 5
2.3.1. Unauthorized Usage . . . . . . . . . . . . . . 6
2.3.2. Inappropriate Usage. . . . . . . . . . . . . . 6
2.3.3. Denial of Service. . . . . . . . . . . . . . . 6
3. The Internet Threat Model. . . . . . . . . . . . . . . . . 6
3.1. Limited Threat Models . . . . . . . . . . . . . . . . 7
3.2. Passive Attacks . . . . . . . . . . . . . . . . . . . 7
3.2.1. Confidentiality Violations . . . . . . . . . . 8
3.2.2. Password Sniffing. . . . . . . . . . . . . . . 8
3.2.3. Offline Cryptographic Attacks. . . . . . . . . 9
3.3. Active Attacks. . . . . . . . . . . . . . . . . . . . 9
3.3.1. Replay Attacks . . . . . . . . . . . . . . . . 10
3.3.2. Message Insertion. . . . . . . . . . . . . . . 10
3.3.3. Message Deletion . . . . . . . . . . . . . . . 11
3.3.4. Message Modification . . . . . . . . . . . . . 11
3.3.5. Man-In-The-Middle. . . . . . . . . . . . . . . 12
3.4. Topological Issues. . . . . . . . . . . . . . . . . . 12
3.5. On-path versus off-path . . . . . . . . . . . . . . . 13
3.6. Link-local. . . . . . . . . . . . . . . . . . . . . . 13
4. Common Issues. . . . . . . . . . . . . . . . . . . . . . . 13
4.1. User Authentication . . . . . . . . . . . . . . . . . 14
4.1.1. Username/Password. . . . . . . . . . . . . . . 14
4.1.2. Challenge Response and One Time Passwords. . . 14
4.1.3. Shared Keys. . . . . . . . . . . . . . . . . . 15
4.1.4. Key Distribution Centers . . . . . . . . . . . 15
4.1.5. Certificates . . . . . . . . . . . . . . . . . 15
4.1.6. Some Uncommon Systems. . . . . . . . . . . . . 15
4.1.7. Host Authentication. . . . . . . . . . . . . . 16
4.2. Generic Security Frameworks . . . . . . . . . . . . . 16
4.3. Non-repudiation . . . . . . . . . . . . . . . . . . . 17
4.4. Authorization vs. Authentication. . . . . . . . . . . 18
4.4.1. Access Control Lists . . . . . . . . . . . . . 18
4.4.2. Certificate Based Systems. . . . . . . . . . . 18
4.5. Providing Traffic Security. . . . . . . . . . . . . . 19
4.5.1. IPsec. . . . . . . . . . . . . . . . . . . . . 19
4.5.2. SSL/TLS. . . . . . . . . . . . . . . . . . . . 20
4.5.3. Remote Login . . . . . . . . . . . . . . . . . 22
4.6. Denial of Service Attacks and Countermeasures . . . . 22
4.6.1. Blind Denial of Service. . . . . . . . . . . . 23
4.6.2. Distributed Denial of Service. . . . . . . . . 23
4.6.3. Avoiding Denial of Service . . . . . . . . . . 24
4.6.4. Example: TCP SYN Floods. . . . . . . . . . . . 24
4.6.5. Example: Photuris. . . . . . . . . . . . . . . 25
4.7. Object vs. Channel Security . . . . . . . . . . . . . 25
4.8. Firewalls and Network Topology. . . . . . . . . . . . 26
5. Writing Security Considerations Sections . . . . . . . . . 26
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. SMTP. . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1.1. Security Considerations. . . . . . . . . . . . 29
6.1.2. Communications security issues . . . . . . . . 34
6.1.3. Denial of Service. . . . . . . . . . . . . . . 36
6.2. VRRP. . . . . . . . . . . . . . . . . . . . . . . . . .36
6.2.1. Security Considerations. . . . . . . . . . . . 36
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 38
8. Normative References . . . . . . . . . . . . . . . . . . . 39
9. Informative References . . . . . . . . . . . . . . . . . . 41
10.Security Considerations. . . . . . . . . . . . . . . . . . 42
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 43
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 44
All RFCs are required by RFC 2223 to contain a Security Considerations section. The purpose of this is both to encourage document authors to consider security in their designs and to inform the reader of relevant security issues. This memo is intended to provide guidance to RFC authors in service of both ends.
すべてのRFCは、セキュリティ上の考慮事項セクションを含むようにRFC 2223によって必要です。この目的は、文書著者らの両方が彼らのデザインのセキュリティを検討し、関連するセキュリティ問題の読者に知らせることを奨励することです。このメモは、両端のサービスでRFC著者へのガイダンスを提供することを目的としています。
This document is structured in three parts. The first is a combination security tutorial and definition of common terms; the second is a series of guidelines for writing Security Considerations; the third is a series of examples.
この文書は3つの部分で構成されています。1つ目はセキュリティチュートリアルと共通の用語の定義です。2つ目は、セキュリティ上の考慮事項を書くための一連のガイドラインです。3つ目は一連の例です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [KEYWORDS].
「必須」、「必須」、「必要ではない」、「しない」、「推奨する」、「推奨する」、「5月」、および「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、BCP 14、RFC 2119 [キーワード]に記載されているように解釈されること。
Most people speak of security as if it were a single monolithic property of a protocol or system, however, upon reflection, one realizes that it is clearly not true. Rather, security is a series of related but somewhat independent properties. Not all of these properties are required for every application.
ほとんどの人はそれがプロトコルまたはシステムの単一のモノリシック性であるかのようにセキュリティについて話すが、反映時にはそれが明らかに正しくないことを認識する。むしろ、セキュリティは一連の関連があるがやや独立した特性である。すべてのアプリケーションにこれらすべてのプロパティが必要ではありません。
We can loosely divide security goals into those related to protecting communications (COMMUNICATION SECURITY, also known as COMSEC) and those relating to protecting systems (ADMINISTRATIVE SECURITY or SYSTEM SECURITY). Since communications are carried out by systems and access to systems is through communications channels, these goals obviously interlock, but they can also be independently provided.
セキュリティの目標を緩やかに、コミュニケーションの保護（通信セキュリティ、COMSECとも呼ばれる）、保護システム（管理セキュリティまたはシステムセキュリティ）に関するものに関連するものに緩やかに分割できます。通信はシステムによって実行され、システムへのアクセスは通信チャネルを介して行われるので、これらの目標は明らかにインターロックされていますが、それらは独立して提供され得る。
Different authors partition the goals of communication security differently. The partitioning we've found most useful is to divide them into three major categories: CONFIDENTIALITY, DATA INTEGRITY and PEER ENTITY AUTHENTICATION.
さまざまな作者が通信セキュリティの目標を異なる方法で分割します。最も便利なパーティション化は、それらを3つの主要なカテゴリに分割することです：機密性、データの整合性、およびピアエンティティ認証。
When most people think of security, they think of CONFIDENTIALITY. Confidentiality means that your data is kept secret from unintended listeners. Usually, these listeners are simply eavesdroppers. When an adversary taps your phone, it poses a risk to your confidentiality.
ほとんどの人がセキュリティについて考えるとき、彼らは機密性を考えます。機密性は、データが意図しないリスナーから秘密にされていることを意味します。通常、これらのリスナーは単に盗聴者です。敵対者があなたの携帯電話をタップすると、それはあなたの機密性に危険をもたらします。
Obviously, if you have secrets, then you are probably concerned about others discovering them. Thus, at the very least, you want to maintain confidentiality. When you see spies in the movies go into the bathroom and turn on all the water to foil bugging, the property they're looking for is confidentiality.
明らかに、あなたが秘密を持っているならば、あなたはおそらく彼らを発見する他の人について心配しています。したがって、少なくとも、あなたは機密性を維持したいです。あなたが映画の中でスパイを見ると、浴室に入って燃えるようなすべての水をオンにして、彼らが探している財産は機密性です。
The second primary goal is DATA INTEGRITY. The basic idea here is that we want to make sure that the data we receive is the same data that the sender has sent. In paper-based systems, some data integrity comes automatically. When you receive a letter written in pen you can be fairly certain that no words have been removed by an attacker because pen marks are difficult to remove from paper. However, an attacker could have easily added some marks to the paper and completely changed the meaning of the message. Similarly, it's easy to shorten the page to truncate the message.
2番目の主な目標はデータの整合性です。ここでの基本的な考え方は、私たちが受け取るデータが送信者が送信したのと同じデータであることを確認したいということです。紙ベースのシステムでは、データの整合性が自動的にもたらされます。ペンに書かれた手紙を受け取ると、ペンマークが紙から取り除くのが難しいため、攻撃者によって除去されていないことはかなり確実になることができます。ただし、攻撃者は紙にいくつかのマークを追加し、メッセージの意味を完全に変更することができます。同様に、メッセージを切り捨てるためにページを短縮するのは簡単です。
On the other hand, in the electronic world, since all bits look alike, it's trivial to tamper with messages in transit. You simply remove the message from the wire, copy out the parts you like, add whatever data you want, and generate a new message of your choosing, and the recipient is no wiser. This is the moral equivalent of the attacker taking a letter you wrote, buying some new paper and recopying the message, changing it as he does it. It's just a lot easier to do electronically since all bits look alike.
一方、電子世界では、すべてのビットは似ているので、トランジット内のメッセージで改ざんするのは簡単です。ワイヤからメッセージを削除するには、好きな部分をコピーし、必要なデータを追加して、選択したファイルを選択し、受信者は賢明ではありません。これは、あなたが書いた手紙を取って、いくつかの新しい紙を買ってメッセージを再編成し、それをしているように変更したという道徳的に相当します。すべてのビットが似ているので電子的にやることはたくさん簡単です。
The third property we're concerned with is PEER ENTITY AUTHENTICATION. What we mean by this is that we know that one of the endpoints in the communication is the one we intended. Without peer entity authentication, it's very difficult to provide either confidentiality or data integrity. For instance, if we receive a message from Alice, the property of data integrity doesn't do us much good unless we know that it was in fact sent by Alice and not the attacker. Similarly, if we want to send a confidential message to Bob, it's not of much value to us if we're actually sending a confidential message to the attacker.
私たちが関心のある3番目のプロパティはピアエンティティ認証です。これによって私たちが意味するのは、コミュニケーション内のエンドポイントの1つが意図したものであることを知っていることです。ピアエンティティ認証なしでは、機密性またはデータの整合性を提供することは非常に困難です。たとえば、Aliceからメッセージを受信した場合、データの整合性の財産は、攻撃者ではなくAliceによって送信されたことを知らない限り、私たちがわからない。同様に、Bobに機密メッセージを送信したい場合は、実際に攻撃者に機密メッセージを送信している場合は、弊社にはあまり価値ではありません。
Note that peer entity authentication can be provided asymmetrically. When you call someone on the phone, you can be fairly certain that you have the right person -- or at least that you got a person who's actually at the phone number you called. On the other hand, if they don't have caller ID, then the receiver of a phone call has no idea who's calling them. Calling someone on the phone is an example of recipient authentication, since you know who the recipient of the call is, but they don't know anything about the sender.
ピアエンティティ認証は非対称的に提供され得ることに注意してください。あなたが電話で誰かを呼ぶとき、あなたはあなたが正しい人を持っていることをかなり確かに確かにしています - または少なくともあなたが呼び出された電話番号にある人を持っている人を持っています。一方、発信者IDを持っていない場合、電話の受信者はそれらを呼び出すのはわかりません。電話で誰かを呼び出すことは、電話の受信者が誰であるかを知っているので、受信者認証の例ですが、送信者についてのものは何も知らないためです。
In messaging situations, you often wish to use peer entity authentication to establish the identity of the sender of a certain message. In such contexts, this property is called DATA ORIGIN AUTHENTICATION.
メッセージング状況では、特定のメッセージの送信者の身元を確立するためにピアエンティティ認証を使用することがよくあります。そのようなコンテキストでは、このプロパティはデータオリジナル認証と呼ばれます。
A system that provides endpoint authentication allows one party to be certain of the identity of someone with whom he is communicating. When the system provides data integrity a receiver can be sure of both the sender's identity and that he is receiving the data that that sender meant to send. However, he cannot necessarily demonstrate this fact to a third party. The ability to make this demonstration is called NON-REPUDIATION.
エンドポイント認証を提供するシステムは、1人のパーティが彼がコミュニケーションしている人のアイデンティティの特定のものになることを可能にします。システムがデータの整合性を提供するとき、受信者は送信者の身元の両方を確実であり、彼が送信者が送信することを意味するデータを受信していることを確認することができます。しかし、彼は必ずしもこの事実を第三者に証明することはできません。このデモンストレーションを行う能力は、否認されないと呼ばれます。
There are many situations in which non-repudiation is desirable. Consider the situation in which two parties have signed a contract which one party wishes to unilaterally abrogate. He might simply claim that he had never signed it in the first place. Non-repudiation prevents him from doing so, thus protecting the counterparty.
非否認が望ましいという多くの状況があります。2人の締約国が一人の党が一方的に廃止したい契約に署名した状況を考えてみましょう。彼は単に彼がそもそもそれに署名しなかったと主張するかもしれません。非否認は彼がそうすることを防ぎ、それによって相手方を保護します。
Unfortunately, non-repudiation can be very difficult to achieve in practice and naive approaches are generally inadequate. Section 4.3 describes some of the difficulties, which generally stem from the fact that the interests of the two parties are not aligned -- one party wishes to prove something that the other party wishes to deny.
残念なことに、実際には不十分なアプローチでは、否認を実現することが非常に困難であり得、そしてナイーブアプローチは一般的に不十分である。セクション4.3はいくつかの困難を説明しています。
In general, systems security is concerned with protecting one's machines and data. The intent is that machines should be used only by authorized users and for the purposes that the owners intend. Furthermore, they should be available for those purposes. Attackers should not be able to deprive legitimate users of resources.
一般に、システムセキュリティは自分のマシンとデータを保護することに関係しています。意図は、機械が許可されたユーザーによってのみ、所有者が意図する目的のために使用されるべきであるということです。さらに、それらはそれらの目的のために利用可能であるべきです。攻撃者は、リソースの正当なユーザーを奪うことができないはずです。
Most systems are not intended to be completely accessible to the public. Rather, they are intended to be used only by certain authorized individuals. Although many Internet services are available to all Internet users, even those servers generally offer a larger subset of services to specific users. For instance, Web Servers often will serve data to any user, but restrict the ability to modify pages to specific users. Such modifications by the general public would be UNAUTHORIZED USAGE.
ほとんどのシステムは、一般に完全にアクセス可能であることを意図していません。むしろ、それらは特定の許可された個人によってのみ使用されることを意図しています。すべてのインターネットサービスがすべてのインターネットユーザーに利用可能ですが、それらのサーバーでさえ、一般的に特定のユーザーに大きなサービスのサブセットを提供します。たとえば、Webサーバーはしばしば任意のユーザーにデータを提供しますが、特定のユーザーにページを変更する機能を制限します。一般の人々によるそのような修正は不正な使用法であろう。
Being an authorized user does not mean that you have free run of the system. As we said above, some activities are restricted to authorized users, some to specific users, and some activities are generally forbidden to all but administrators. Moreover, even activities which are in general permitted might be forbidden in some cases. For instance, users may be permitted to send email but forbidden from sending files above a certain size, or files which contain viruses. These are examples of INAPPROPRIATE USAGE.
許可されたユーザーであることは、システムの自由な実行があるという意味ではありません。上記のように、一部の活動は許可されたユーザー、特定のユーザーに制限されており、一部の活動は一般に管理者全員に禁じられています。さらに、一般的に許可されている活動でさえ、場合によっては禁止されるかもしれません。たとえば、ユーザーは電子メールを送信することを許可されているが、特定のサイズより上のファイルの送信、またはウイルスを含むファイルの送信を禁止されることがあります。これらは不適切な使用法の例です。
Recall that our third goal was that the system should be available to legitimate users. A broad variety of attacks are possible which threaten such usage. Such attacks are collectively referred to as DENIAL OF SERVICE attacks. Denial of service attacks are often very easy to mount and difficult to stop. Many such attacks are designed to consume machine resources, making it difficult or impossible to serve legitimate users. Other attacks cause the target machine to crash, completely denying service to users.
私たちの3番目の目標は、システムが正当なユーザーに利用可能であるべきだということでした。そのような使用を脅かす幅広い攻撃が可能です。そのような攻撃はまとめてサービス拒否攻撃と呼ばれます。サービス拒否攻撃は、マウントが非常に簡単で、停止が困難です。多くのそのような攻撃は、機械の資源を消費するように設計されており、正当なユーザーに役立つことが困難または不可能にします。他の攻撃により、ターゲットマシンがクラッシュし、完全にサービスをユーザーに拒否します。
A THREAT MODEL describes the capabilities that an attacker is assumed to be able to deploy against a resource. It should contain such information as the resources available to an attacker in terms of information, computing capability, and control of the system. The purpose of a threat model is twofold. First, we wish to identify the threats we are concerned with. Second, we wish to rule some threats explicitly out of scope. Nearly every security system is vulnerable to a sufficiently dedicated and resourceful attacker.
脅威モデルは、攻撃者がリソースに対して展開できると見なされる機能を記述します。情報、コンピューティング機能、およびシステムの制御に関して、攻撃者が利用できるリソースとしてそのような情報を含める必要があります。脅威モデルの目的は2倍です。まず、私たちが関心のある脅威を特定したいと思います。第二に、私たちは範囲外で明示的に脅威を統治したいと思います。ほとんどすべてのセキュリティシステムは、十分に献身的で機器のある攻撃者に対して脆弱です。
The Internet environment has a fairly well understood threat model. In general, we assume that the end-systems engaging in a protocol exchange have not themselves been compromised. Protecting against an attack when one of the end-systems has been compromised is extraordinarily difficult. It is, however, possible to design protocols which minimize the extent of the damage done under these circumstances.
インターネット環境はかなりよく理解されている脅威モデルを持っています。一般的に、プロトコル交換に従事するエンドシステムが自ら損なわれていないと仮定する。エンドシステムの1つが妥協されたときの攻撃に対して保護することは非常に困難です。しかしながら、これらの状況下で行われた損傷の程度を最小にするプロトコルを設計することは可能である。
By contrast, we assume that the attacker has nearly complete control of the communications channel over which the end-systems communicate. This means that the attacker can read any PDU (Protocol Data Unit) on the network and undetectably remove, change, or inject forged packets onto the wire. This includes being able to generate packets that appear to be from a trusted machine. Thus, even if the end-system with which you wish to communicate is itself secure, the Internet environment provides no assurance that packets which claim to be from that system in fact are.
対照的に、攻撃者がエンドシステムが通信する通信チャネルのほぼ完全な制御を行っていると仮定します。これは、攻撃者がネットワーク上のPDU（プロトコルデータユニット）を読み取り、鍛造されたパケットをワイヤに削除、変更、変更、変更、変更、変更することができることを意味します。これには、信頼できるマシンからのように見えるパケットを生成できることが含まれます。したがって、コミュニケーションを希望するエンドシステムがそれ自体で安全であっても、インターネット環境は、そのシステムからのと主張するパケットが実際にはそうであるという保証を提供しません。
It's important to realize that the meaning of a PDU is different at different levels. At the IP level, a PDU means an IP packet. At the TCP level, it means a TCP segment. At the application layer, it means some kind of application PDU. For instance, at the level of email, it might either mean an RFC-822 message or a single SMTP command. At the HTTP level, it might mean a request or response.
PDUの意味が異なるレベルで異なることを認識することが重要です。IPレベルでは、PDUとはIPパケットを意味します。TCPレベルでは、TCPセグメントを意味します。アプリケーション層では、ある種のアプリケーションPDUを意味します。たとえば、電子メールのレベルでは、RFC-822メッセージまたは単一のSMTPコマンドを意味します。HTTPレベルでは、要求または応答を意味する可能性があります。
As we've said, a resourceful and dedicated attacker can control the entire communications channel. However, a large number of attacks can be mounted by an attacker with fewer resources. A number of currently known attacks can be mounted by an attacker with limited control of the network. For instance, password sniffing attacks can be mounted by an attacker who can only read arbitrary packets. This is generally referred to as a PASSIVE ATTACK [INTAUTH].
私たちが言ったように、機関に満ちて専用の攻撃者は通信チャネル全体を制御することができます。ただし、少ないリソースを持つ攻撃者によって多数の攻撃をマウントできます。現在の既知の攻撃は、ネットワークの制限された制御を備えた攻撃者によってマウントすることができます。たとえば、パスワードのスニッフィング攻撃は、任意のパケットのみを読むことができる攻撃者によってマウントできます。これは一般にパッシブ攻撃と呼ばれます[INTAUTH]。
By contrast, Morris' sequence number guessing attack [SEQNUM] can be mounted by an attacker who can write but not read arbitrary packets. Any attack which requires the attacker to write to the network is known as an ACTIVE ATTACK.
対照的に、Morrisのシーケンス番号推測攻撃[seqnum]は、書くことができるが任意のパケットを読み取ることができない攻撃者によってマウントすることができる。攻撃者がネットワークに書き込むことを要求する攻撃は、アクティブな攻撃として知られています。
Thus, a useful way of organizing attacks is to divide them based on the capabilities required to mount the attack. The rest of this section describes these categories and provides some examples of each category.
したがって、攻撃を整理するための便利な方法は、攻撃をマウントするのに必要な機能に基づいてそれらを分割することです。このセクションの残りの部分では、これらのカテゴリについて説明し、各カテゴリの例をいくつか示します。
In a passive attack, the attacker reads packets off the network but does not write them. The simplest way to mount such an attack is to simply be on the same LAN as the victim. On most common LAN configurations, including Ethernet, 802.3, and FDDI, any machine on the wire can read all traffic destined for any other machine on the same LAN. Note that switching hubs make this sort of sniffing substantially more difficult, since traffic destined for a machine only goes to the network segment which that machine is on.
パッシブ攻撃では、攻撃者はネットワークからパケットを読み込みますが、それらを書きません。そのような攻撃をマウントする最も簡単な方法は、犠牲者と同じLAN上にあることです。イーサネット、802.3、およびFDDIを含むほとんどの一般的なLAN構成については、ワイヤ上の任意のマシンが同じLAN上の他のマシン宛てのすべてのトラフィックを読み取ることができます。スイッチングハブはこの種のスニッフを実質的に困難にしていることに注意してください。マシン宛てのトラフィックは、そのマシンがオンのネットワークセグメントにのみ行われるためです。
Similarly, an attacker who has control of a host in the communications path between two victim machines is able to mount a passive attack on their communications. It is also possible to compromise the routing infrastructure to specifically arrange that traffic passes through a compromised machine. This might involve an active attack on the routing infrastructure to facilitate a passive attack on a victim machine.
同様に、2人の犠牲機械の2つの犠牲者機械間の通信経路でホストを管理する攻撃者は、彼らのコミュニケーションに受動的な攻撃を取り付けることができます。ルーティングインフラストラクチャを妥協することもでき、トラフィックが侵入先のマシンを通過することを特別に配置することも可能です。これは、犠牲マシンへの受動的な攻撃を促進するためにルーティングインフラストラクチャに対する能動的な攻撃を含むかもしれません。
Wireless communications channels deserve special consideration, especially with the recent and growing popularity of wireless-based LANs, such as those using 802.11. Since the data is simply broadcast on well known radio frequencies, an attacker simply needs to be able to receive those transmissions. Such channels are especially vulnerable to passive attacks. Although many such channels include cryptographic protection, it is often of such poor quality as to be nearly useless [WEP].
無線通信チャネルは、特に802.11を使用するものなど、無線ベースのLANの最近および増加する人気を考慮して特別な考慮事項に値する。データはよく知られている無線周波数で簡単にブロードキャストされるので、攻撃者は単にそれらの送信を受信できる必要があります。そのようなチャネルはパッシブ攻撃に対して特に脆弱です。そのようなチャネルの多くは暗号保護を含みますが、それはほとんど無駄なものと同じような質の高い品質の多くです。
In general, the goal of a passive attack is to obtain information which the sender and receiver would prefer to remain private. This private information may include credentials useful in the electronic world and/or passwords or credentials useful in the outside world, such as confidential business information.
一般に、受動的な攻撃の目的は、送信者と受信者が非公開のままであることを好む情報を得ることです。この個人情報は、機密の業務情報など、外部の世界で有用な電子世界やパスワードまたは資格情報に役立つ資格情報を含めることができます。
The classic example of passive attack is sniffing some inherently private data off of the wire. For instance, despite the wide availability of SSL, many credit card transactions still traverse the Internet in the clear. An attacker could sniff such a message and recover the credit card number, which can then be used to make fraudulent transactions. Moreover, confidential business information is routinely transmitted over the network in the clear in email.
パッシブ攻撃の古典的な例は、本質的に無線のデータをワイヤから切り離しています。たとえば、SSLの幅広い可用性にもかかわらず、多くのクレジットカード取引がまだ明確にインターネットを横断します。攻撃者はそのようなメッセージを盗聴し、クレジットカード番号を回復することができ、それは詐欺的な取引をするために使用されます。さらに、機密の業務情報は、電子メールで明確にネットワーク経由で送信されています。
Another example of a passive attack is PASSWORD SNIFFING. Password sniffing is directed towards obtaining unauthorized use of resources. Many protocols, including [TELNET], [POP], and [NNTP] use a shared password to authenticate the client to the server. Frequently, this password is transmitted from the client to the server in the clear over the communications channel. An attacker who can read this traffic can therefore capture the password and REPLAY it. In other words, the attacker can initiate a connection to the server and pose as the client and login using the captured password.
パッシブ攻撃のもう1つの例はパスワードスニッフィングです。パスワードスニッフィングは、資源の不正使用を取得することに向けられています。[Telnet]、[POP]、[NNTP]を含む多くのプロトコルは、共有パスワードを使用してクライアントをサーバーに認証します。多くの場合、このパスワードは通信チャネルを介してクライアントからサーバーに送信されます。したがって、このトラフィックを読むことができる攻撃者はパスワードをキャプチャして再生できます。言い換えれば、攻撃者はサーバーへの接続を開始し、キャプチャされたパスワードを使用してクライアントとしてポーズしてログインすることができます。
Note that although the login phase of the attack is active, the actual password capture phase is passive. Moreover, unless the server checks the originating address of connections, the login phase does not require any special control of the network.
攻撃のログイン段階はアクティブですが、実際のパスワードキャプチャフェーズはパッシブです。さらに、サーバーが接続の発信アドレスをチェックしない限り、ログインフェーズはネットワークの特別な制御を必要としません。
Many cryptographic protocols are subject to OFFLINE ATTACKS. In such a protocol, the attacker recovers data which has been processed using the victim's secret key and then mounts a cryptanalytic attack on that key. Passwords make a particularly vulnerable target because they are typically low entropy. A number of popular password-based challenge response protocols are vulnerable to DICTIONARY ATTACK. The attacker captures a challenge-response pair and then proceeds to try entries from a list of common words (such as a dictionary file) until he finds a password that produces the right response.
多くの暗号化プロトコルはオフライン攻撃の対象となります。そのようなプロトコルでは、攻撃者は被害者の秘密鍵を使用して処理されたデータを回復し、そのキーに暗号分析攻撃をマウントします。パスワードは、通常はエントロピーが低いため、特に脆弱なターゲットを作成します。多数の一般的なパスワードベースのチャレンジ応答プロトコルが辞書攻撃に対して脆弱です。攻撃者はチャレンジレスポンスペアをキャプチャしてから、正しい応答を生成するパスワードを見つけるまで、一般的な単語のリスト（辞書ファイルなど）のリストからのエントリを試してください。
A similar such attack can be mounted on a local network when NIS is used. The Unix password is crypted using a one-way function, but tools exist to break such crypted passwords [KLEIN]. When NIS is used, the crypted password is transmitted over the local network and an attacker can thus sniff the password and attack it.
NISが使用されている場合、そのような攻撃をローカルネットワークにマウントすることができます。UNIXパスワードは一方向の関数を使用して暗号化されていますが、そのような暗号化されたパスワード[klein]を破るためのツールが存在します。NISを使用すると、暗号化されたパスワードはローカルネットワーク経由で送信され、攻撃者はパスワードを盗聴して攻撃することができます。
Historically, it has also been possible to exploit small operating system security holes to recover the password file using an active attack. These holes can then be bootstrapped into an actual account by using the aforementioned offline password recovery techniques. Thus we combine a low-level active attack with an offline passive attack.
歴史的には、アクティブな攻撃を使用してパスワードファイルを回復するために小さなオペレーティングシステムのセキュリティホールを利用することも可能でした。その後、前述のオフラインパスワード回復技術を使用して、これらの穴を実際のアカウントにブートストラップできます。したがって、低レベルのアクティブな攻撃をオフライン受動攻撃と組み合わせる。
When an attack involves writing data to the network, we refer to this as an ACTIVE ATTACK. When IP is used without IPsec, there is no authentication for the sender address. As a consequence, it's straightforward for an attacker to create a packet with a source address of his choosing. We'll refer to this as a SPOOFING ATTACK.
攻撃がネットワークにデータを書き込むことを含む場合は、これをアクティブな攻撃と呼びます。IPSECなしでIPを使用すると、送信側アドレスの認証はありません。結果として、攻撃者が自分の選択の送信元アドレスを持つパケットを作成するのは簡単です。スプーフィング攻撃としてこれを参照します。
Under certain circumstances, such a packet may be screened out by the network. For instance, many packet filtering firewalls screen out all packets with source addresses on the INTERNAL network that arrive on the EXTERNAL interface. Note, however, that this provides no protection against an attacker who is inside the firewall. In general, designers should assume that attackers can forge packets.
特定の状況下では、そのようなパケットはネットワークによってスクリーニングされてもよい。たとえば、多くのパケットフィルタリングファイアウォールは、外部インターフェイスに到着する内部ネットワーク上の送信元アドレスを持つすべてのパケットをスクリーニングします。ただし、これによりファイアウォールの内側にある攻撃者に対する保護はありません。一般に、デザイナーは攻撃者がパケットを偽造できると仮定するべきです。
However, the ability to forge packets does not go hand in hand with the ability to receive arbitrary packets. In fact, there are active attacks that involve being able to send forged packets but not receive the responses. We'll refer to these as BLIND ATTACKS.
ただし、パケットを鍛造する機能は、任意のパケットを受信する機能を手に手にしません。実際、鍛造されたパケットを送信することができるが、応答を受け取らないことを含むアクティブな攻撃があります。これらをブラインド攻撃として参照します。
Note that not all active attacks require forging addresses. For instance, the TCP SYN denial of service attack [TCPSYN] can be mounted successfully without disguising the sender's address. However, it is common practice to disguise one's address in order to conceal one's identity if an attack is discovered.
すべてのアクティブな攻撃に求められているアドレスが必要ではないことに注意してください。たとえば、送信者のアドレスを偽造することなく、サービス攻撃拒否[TCPSYN]のTCP SYN拒否を正常にマウントできます。しかし、攻撃が発見された場合に自分のアイデンティティを隠すために自分のアドレスを偽装することは一般的な慣習です。
Each protocol is susceptible to specific active attacks, but experience shows that a number of common patterns of attack can be adapted to any given protocol. The next sections describe a number of these patterns and give specific examples of them as applied to known protocols.
各プロトコルは特定のアクティブな攻撃の影響を受けやすくなりますが、経験はいくつかの一般的な攻撃パターンを特定のプロトコルに適応させることができることを示しています。次のセクションでは、これらのパターンの多くを説明し、既知のプロトコルに適用されるようにそれらの具体例を示します。
In a REPLAY ATTACK, the attacker records a sequence of messages off of the wire and plays them back to the party which originally received them. Note that the attacker does not need to be able to understand the messages. He merely needs to capture and retransmit them.
リプレイ攻撃では、攻撃者はワイヤからの一連のメッセージを記録し、もともとそれらを受け取ったパーティーに戻ります。攻撃者はメッセージを理解できる必要はないことに注意してください。彼は単にそれらを捉えて再送信する必要があります。
For example, consider the case where an S/MIME message is being used to request some service, such as a credit card purchase or a stock trade. An attacker might wish to have the service executed twice, if only to inconvenience the victim. He could capture the message and replay it, even though he can't read it, causing the transaction to be executed twice.
たとえば、クレジットカードの購入や株式取引などのサービスを要求するためにS / MIMEメッセージが使用されている場合を検討してください。攻撃者は、犠牲者に不便されていれば、サービスを2回実行したいと思うかもしれません。彼はそれを読むことができないにもかかわらず、彼はメッセージをキャプチャして再生することができ、トランザクションを2回実行することができます。
In a MESSAGE INSERTION attack, the attacker forges a message with some chosen set of properties and injects it into the network. Often this message will have a forged source address in order to disguise the identity of the attacker.
メッセージ挿入攻撃では、攻撃者はいくつかの選択された一連のプロパティでメッセージを偽造し、それをネットワークに注入します。多くの場合、このメッセージは攻撃者の身元を偽装するために鍛造された送信元アドレスを持ちます。
For example, a denial-of-service attack can be mounted by inserting a series of spurious TCP SYN packets directed towards the target host. The target host responds with its own SYN and allocates kernel data structures for the new connection. The attacker never completes the 3-way handshake, so the allocated connection endpoints just sit there taking up kernel memory. Typical TCP stack implementations only allow some limited number of connections in this "half-open" state and when this limit is reached, no more connections can be initiated, even from legitimate hosts. Note that this attack is a blind attack, since the attacker does not need to process the victim's SYNs.
たとえば、ターゲットホストに向けられた一連のスプリアスTCP SYNパケットを挿入することで、サービス拒否攻撃をマウントできます。ターゲットホストはそれ自身のSYNで応答し、新しい接続のカーネルデータ構造を割り当てます。攻撃者は3方向ハンドシェイクを完了することはないので、割り当てられた接続エンドポイントはカーネルメモリを登録するだけです。典型的なTCPスタック実装では、この「ハーフオープン」状態では限られた数の接続数だけが許可され、この制限に達すると、正当なホストからでも、もうこれ以上接続を開始できません。攻撃者が被害者の統合を処理する必要がないので、この攻撃は盲目の攻撃であることに注意してください。
In a MESSAGE DELETION attack, the attacker removes a message from the wire. Morris' sequence number guessing attack [SEQNUM] often requires a message deletion attack to be performed successfully. In this blind attack, the host whose address is being forged will receive a spurious TCP SYN packet from the host being attacked. Receipt of this SYN packet generates a RST, which would tear the illegitimate connection down. In order to prevent this host from sending a RST so that the attack can be carried out successfully, Morris describes flooding this host to create queue overflows such that the SYN packet is lost and thus never responded to.
メッセージ削除攻撃では、攻撃者はワイヤからメッセージを削除します。Morrisのシーケンス番号攻撃[SEQNUM]は、メッセージ削除攻撃を正常に実行する必要があることがよくあります。このブラインド攻撃では、アドレスが偽造されているホストは、攻撃されているホストからスプリアスTCP SYNパケットを受け取ります。このSYNパケットの受信はRSTを生成します。これは不正接続を引き下げます。このホストがRSTを送信するのを防ぐために、攻撃を正常に実行できるようにするために、MorRisはこのホストをフラッディングして、SYNパケットが失われるようにキューオーバーフローを作成することを説明します。
In a MESSAGE MODIFICATION attack, the attacker removes a message from the wire, modifies it, and reinjects it into the network. This sort of attack is particularly useful if the attacker wants to send some of the data in the message but also wants to change some of it.
メッセージ修正攻撃では、攻撃者はワイヤからメッセージを削除し、それを変更してネットワークに再投入します。この種の攻撃は、攻撃者がメッセージ内のデータの一部を送信したいだけでなく、そのうちのいくつかを変更したい場合に特に便利です。
Consider the case where the attacker wants to attack an order for goods placed over the Internet. He doesn't have the victim's credit card number so he waits for the victim to place the order and then replaces the delivery address (and possibly the goods description) with his own. Note that this particular attack is known as a CUT-AND-PASTE attack since the attacker cuts the credit card number out of the original message and pastes it into the new message.
攻撃者がインターネット上に置かれた商品の注文を攻撃したい場合を考えてみましょう。彼は被害者のクレジットカード番号を持っていませんので、彼は被害者が注文を出してから配達住所（そして場合によっては商品の説明）を自分のものと交換するのを待っています。攻撃者がオリジナルのメッセージからクレジットカード番号を切り取って新しいメッセージに貼り付けてから、この特定の攻撃はカットアンドペースト攻撃として知られています。
Another interesting example of a cut-and-paste attack is provided by [IPSPPROB]. If IPsec ESP is used without any MAC then it is possible for the attacker to read traffic encrypted for a victim on the same machine. The attacker attaches an IP header corresponding to a port he controls onto the encrypted IP packet. When the packet is received by the host it will automatically be decrypted and forwarded to the attacker's port. Similar techniques can be used to mount a session hijacking attack. Both of these attacks can be avoided by always using message authentication when you use encryption. Note that this attack only works if (1) no MAC check is being used, since this attack generates damaged packets (2) a host-to-host SA is being used, since a user-to-user SA will result in an inconsistency between the port associated with the SA and the target port. If the receiving machine is single-user than this attack is infeasible.
カットアンドペースト攻撃のもう一つの興味深い例は[IPSPProb]によって提供されます。IPsec ESPがMacなしで使用されている場合、攻撃者が同じマシン上の被害者に対して暗号化されたトラフィックを読むことが可能です。攻撃者は、暗号化されたIPパケットにコントロールするポートに対応するIPヘッダーを添付します。パケットがホストによって受信されると、自動的に復号化されて攻撃者のポートに転送されます。セッションハイジャック攻撃をマウントするために同様の技術を使用することができます。暗号化を使用するときは、常にメッセージ認証を使用することで、これらの攻撃の両方を回避できます。この攻撃は、（1）MACチェックが使用されていない場合にのみ機能します。この攻撃は損傷したパケットを生成していない（2）ユーザー間のSAが不一致になるため、ホストからホストSAが使用されています。SAとターゲットポートに関連付けられているポートの間。受信機がこの攻撃よりシングルユーザーの場合は実行不可能です。
A MAN-IN-THE-MIDDLE attack combines the above techniques in a special form: The attacker subverts the communication stream in order to pose as the sender to receiver and the receiver to the sender:
中間攻撃は、上記の手法を特別な形式で組み合わせたものです。攻撃者は、送信者としての送信者と受信者に送信者への受信者としてのコミュニケーションストリームを削除します。
What Alice and Bob think:
Alice <----------------------------------------------> Bob
What's happening:
Alice <----------------> Attacker <----------------> Bob
This differs fundamentally from the above forms of attack because it attacks the identity of the communicating parties, rather than the data stream itself. Consequently, many techniques which provide integrity of the communications stream are insufficient to protect against man-in-the-middle attacks.
これは、データストリーム自体ではなく、通信者の身元を攻撃するため、上記の攻撃の形態から基本的に異なります。その結果、通信ストリームの完全性を提供する多くの技術は、中間攻撃から保護するのに不十分である。
Man-in-the-middle attacks are possible whenever a protocol lacks PEER ENTITY AUTHENTICATION. For instance, if an attacker can hijack the client TCP connection during the TCP handshake (perhaps by responding to the client's SYN before the server does), then the attacker can open another connection to the server and begin a man-in-the-middle attack. It is also trivial to mount man-in-the-middle attacks on local networks via ARP spoofing -- the attacker forges an ARP with the victim's IP address and his own MAC address. Tools to mount this sort of attack are readily available.
プロトコルがピアエンティティ認証を欠いているときはいつでも中間攻撃が可能です。たとえば、攻撃者がTCPハンドシェイク中にクライアントTCP接続をハイジャックできる場合（おそらくは、サーバーの前にクライアントのSYNに応答することで）、攻撃者はサーバーへの別の接続を開き、中間のマンインを開始できます。攻撃。ARPスプーフィングを介してローカルネットワーク上の中間攻撃をマウントするのも些細なことです。この種の攻撃を取り付けるためのツールはすぐに入手できます。
Note that it is only necessary to authenticate one side of the transaction in order to prevent man-in-the-middle attacks. In such a situation the the peers can establish an association in which only one peer is authenticated. In such a system, an attacker can initiate an association posing as the unauthenticated peer but cannot transmit or access data being sent on a legitimate connection. This is an acceptable situation in contexts such as Web e-commerce where only the server needs to be authenticated (or the client is independently authenticated via some non-cryptographic mechanism such as a credit card number).
中間攻撃を防ぐために、トランザクションの片側を認証する必要があるだけであることに注意してください。そのような状況では、ピアは1つのピアだけが認証される関連付けを確立することができる。そのようなシステムでは、攻撃者は、認証されていないピアとしてのアソシエーションを開始することができますが、正規接続で送信されているデータを送信またはアクセスすることはできません。これは、サーバーのみが認証される必要があるWeb電子商取引などのコンテキストの許容可能な状況です（またはクレジットカード番号などのいくつかの非暗号化されていないメカニズムを介してクライアントは独立して認証されています）。
In practice, the assumption that it's equally easy for an attacker to read and generate all packets is false, since the Internet is not fully connected. This has two primary implications.
実際には、インターネットが完全に接続されていないため、攻撃者がすべてのパケットを読み取って生成することが等しく簡単であるという仮定は偽です。これには2つの主な意味があります。
In order for a datagram to be transmitted from one host to another, it generally must traverse some set of intermediate links and gateways. Such gateways are naturally able to read, modify, or remove any datagram transmitted along that path. This makes it much easier to mount a wide variety of attacks if you are on-path.
データグラムがあるホストから別のホストに送信されるためには、一般に中間リンクとゲートウェイの一部を横断する必要があります。そのようなゲートウェイは、そのパスに沿って送信されたデータグラムを読み取り、修正、または削除することができます。これにより、オンパスの場合は、さまざまな攻撃を取り付けることがはるかに簡単になります。
Off-path hosts can, of course, transmit arbitrary datagrams that appear to come from any hosts but cannot necessarily receive datagrams intended for other hosts. Thus, if an attack depends on being able to receive data, off-path hosts must first subvert the topology in order to place themselves on-path. This is by no means impossible but is not necessarily trivial.
オフパスホストは、もちろん、ホストから来るように見える任意のデータグラムを送信することはできますが、必ずしも他のホストを対象としたデータグラムを受信することはできません。したがって、攻撃がデータを受信できることに依存している場合は、OFF-PATHホストは最初にパスをオンパスに配置するためにトポロジをまとめていなければなりません。これは決して不可能ではなく、必ずしも些細なことではありません。
Applications protocol designers MUST NOT assume that all attackers will be off-path. Where possible, protocols SHOULD be designed to resist attacks from attackers who have complete control of the network. However, designers are expected to give more weight to attacks which can be mounted by off-path attackers as well as on-path ones.
アプリケーションプロトコル設計者は、すべての攻撃者がオフパスになると仮定してはいけません。可能であれば、プロトコルは、ネットワークを完全に制御する攻撃者からの攻撃に抵抗するように設計されるべきです。しかし、設計者は、オフパス攻撃者とオンパスの攻撃者によってマウントすることができる攻撃にさらに重量を与えると予想されます。
One specialized case of on-path is being on the same link. In some situations, it's desirable to distinguish between hosts who are on the local network and those who are not. The standard technique for this is verifying the IP TTL value [IP]. Since the TTL must be decremented by each forwarder, a protocol can demand that TTL be set to 255 and that all receivers verify the TTL. A receiver then has some reason to believe that conforming packets are from the same link. Note that this technique must be used with care in the presence of tunneling systems, since such systems may pass packets without decrementing TTL.
On-Pathの1つの特殊なケースが同じリンク上にあります。状況によっては、ローカルネットワーク上にあるホストとそうでない人との間を区別することが望ましいです。これがIP TTL値[IP]を検証しています。TTLは各フォワーダによってデクリメントされなければならないので、プロトコルはTTLが255に設定され、すべての受信機がTTLを検証することを要求することができる。その後、受信者は、適合パケットが同じリンクからのものであると信じる何らかの理由を持っています。このようなシステムはTTLを減らすことなくパケットを通過させる可能性があるため、この手法をトンネリングシステムの存在下で注意して使用する必要があります。
Although each system's security requirements are unique, certain common requirements appear in a number of protocols. Often, when naive protocol designers are faced with these requirements, they choose an obvious but insecure solution even though better solutions are available. This section describes a number of issues seen in many protocols and the common pieces of security technology that may be useful in addressing them.
各システムのセキュリティ要件は一意であるが、特定の共通の要件はいくつかのプロトコルに表示されます。多くの場合、ナイーブプロトコル設計者がこれらの要件に直面している場合、それらはより良い解決策が利用可能であっても明らかだが安全でないソリューションを選択します。このセクションでは、多くのプロトコルで見られるいくつかの問題とそれらに対処するのに役立つ可能性があるセキュリティテクノロジの一般的な部分について説明します。
Essentially every system which wants to control access to its resources needs some way to authenticate users. A nearly uncountable number of such mechanisms have been designed for this purpose. The next several sections describe some of these techniques.
本質的に、そのリソースへのアクセスを制御したいすべてのシステムは、ユーザーを認証するためにいくらかの方法が必要です。この目的のために、そのようなメカニズムのほぼ数えない数が設計されています。次のいくつかのセクションでは、これらの技術のいくつかについて説明しています。
The most common access control mechanism is simple USERNAME/PASSWORD The user provides a username and a reusable password to the host which he wishes to use. This system is vulnerable to a simple passive attack where the attacker sniffs the password off the wire and then initiates a new session, presenting the password. This threat can be mitigated by hosting the protocol over an encrypted connection such as TLS or IPSEC. Unprotected (plaintext) username/password systems are not acceptable in IETF standards.
最も一般的なアクセス制御メカニズムは単純なユーザー名/パスワードで、ユーザーが使用したいホストにユーザー名と再利用可能なパスワードを提供します。このシステムは、攻撃者がパソコンがワイヤから消灯し、パスワードを提示する新しいセッションを開始するシンプルなパッシブ攻撃に対して脆弱です。この脅威は、TLSやIPsecなどの暗号化接続を介してプロトコルをホストすることで軽減できます。保護されていない（平文）ユーザー名/パスワードシステムは、IETF規格では受け入れられません。
Systems which desire greater security than USERNAME/PASSWORD often employ either a ONE TIME PASSWORD [OTP] scheme or a CHALLENGE-RESPONSE. In a one time password scheme, the user is provided with a list of passwords, which must be used in sequence, one time each. (Often these passwords are generated from some secret key so the user can simply compute the next password in the sequence.) SecureID and DES Gold are variants of this scheme. In a challenge-response scheme, the host and the user share some secret (which often is represented as a password). In order to authenticate the user, the host presents the user with a (randomly generated) challenge. The user computes some function based on the challenge and the secret and provides that to the host, which verifies it. Often this computation is performed in a handheld device, such as a DES Gold card.
ユーザー名/パスワードよりも高いセキュリティを望むシステムは、1回限りのパスワード[OTP]スキームまたはチャレンジレスポンスを使用します。ワンタイムパスワード方式では、ユーザはパスワードのリストを備えており、それはそれぞれ1回、順番に使用されなければならない。（多くの場合、これらのパスワードはいくつかの秘密鍵から生成されるため、ユーザーがシーケンス内の次のパスワードを単純に計算できます。）SecureIDとDED GOLDはこの方式の亜種です。チャレンジ応答方式では、ホストとユーザはいくつかの秘密を共有する（これはしばしばパスワードとして表される）。ユーザを認証するために、ホストはユーザに（ランダムに生成された）チャレンジを提示する。ユーザーは、チャレンジと秘密に基づいていくつかの機能を計算し、それを検証するホストに提供します。多くの場合、この計算はDESゴールドカードなどのハンドヘルドデバイスで実行されます。
Both types of scheme provide protection against replay attack, but often still vulnerable to an OFFLINE KEYSEARCH ATTACK (a form of passive attack): As previously mentioned, often the one-time password or response is computed from a shared secret. If the attacker knows the function being used, he can simply try all possible shared secrets until he finds one that produces the right output. This is made easier if the shared secret is a password, in which case he can mount a DICTIONARY ATTACK -- meaning that he tries a list of common words (or strings) rather than just random strings.
両方のタイプのスキームは再生攻撃に対する保護を提供しますが、しばしばオフラインKeysearch攻撃（パッシブ攻撃の形式）に脆弱です。前述のように、しばしばワンタイムパスワードまたは応答は共有秘密から計算されます。攻撃者が使用されている機能を知っている場合、彼は単に正しい出力を生成するものを見つけるまで、すべての可能な共有秘密を試みることができます。共有秘密がパスワードである場合、これは簡単になります。その場合、辞書攻撃をマウントすることができます - 彼がランダムな文字列だけではなく共通の単語（または文字列）のリストを試みることを意味します。
These systems are also often vulnerable to an active attack. Unless communication security is provided for the entire session, the attacker can simply wait until authentication has been performed and hijack the connection.
これらのシステムは能動的な攻撃に対してもしばしば脆弱です。セッション全体に対して通信セキュリティが提供されていない限り、攻撃者は認証が実行され、接続をハイジャックされるまで待機することができます。
CHALLENGE-RESPONSE type systems can be made secure against dictionary attack by using randomly generated shared keys instead of user-generated passwords. If the keys are sufficiently large then keysearch attacks become impractical. This approach works best when the keys are configured into the end nodes rather than memorized and typed in by users, since users have trouble remembering sufficiently long keys.
チャレンジ応答型システムは、ユーザーが生成したパスワードの代わりにランダムに生成された共有キーを使用して、辞書攻撃に対して安全にすることができます。キーが十分に大きい場合、KeySearch攻撃は実用的ではありません。この方法は、ユーザーが十分に長い鍵を覚えていることを把握するのに問題があるため、キーが記憶されて入力されるのではなく、キーがエンドノードに構成されている場合に最適に機能します。
Like password-based systems, shared key systems suffer from management problems. Each pair of communicating parties must have their own agreed-upon key, which leads to there being a lot of keys.
パスワードベースのシステムと同様に、共有キーシステムは管理上の問題を抱えています。コミュニケーションパーティーの各ペアは彼ら自身の合意された鍵を持っていなければなりません、それはたくさんの鍵があることにつながります。
One approach to solving the large number of keys problem is to use an online "trusted third party" that mediates between the authenticating parties. The trusted third party (generally called a a KEY DISTRIBUTION CENTER (KDC)) shares a symmetric key or password with each party in the system. It first contacts the KDC which gives it a TICKET containing a randomly generated symmetric key encrypted under both peer's keys. Since only the proper peers can decrypt the symmetric key the ticket can be used to establish a trusted association. By far the most popular KDC system is Kerberos [KERBEROS].
多数の鍵の問題を解決するための1つのアプローチは、認証当事者間を仲介するオンラインの「信頼できる第三者」を使用することです。信頼できる第三者（一般的には鍵配布センター（KDC）と呼ばれる）は、システム内の各当事者との対称鍵またはパスワードを共有しています。最初にKDCに連絡します。これは、両方のピアのキーの下で暗号化されたランダムに生成された対称鍵を含むチケットを与えます。適切なピアだけが対称キーを復号化することができるので、チケットを使用して信頼できる関連付けを確立することができます。これまでで最も人気のあるKDCシステムはKerberos [Kerberos]です。
A simple approach is to have all users have CERTIFICATES [PKIX] which they then use to authenticate in some protocol-specific way, as in [TLS] or [S/MIME]. A certificate is a signed credential binding an entity's identity to its public key. The signer of a certificate is a CERTIFICATE AUTHORITY (CA), whose certificate may itself be signed by some superior CA. In order for this system to work, trust in one or more CAs must be established in an out-of-band fashion. Such CAs are referred to as TRUSTED ROOTS or ROOT CAS. The primary obstacle to this approach in client-server type systems is that it requires clients to have certificates, which can be a deployment problem.
簡単な方法は、すべてのユーザーが[TLS]または[S / MIME]のように、それらがプロトコル固有の方法で認証するために使用する証明書[PKIX]を持っていることです。証明書は、その公開鍵に対するエンティティのIDを署名する署名付き信任状です。証明書の署名者は証明書局（CA）です。その証明書自体は、一部の優れたCAによって署名されている可能性があります。このシステムが機能するためには、1つ以上のCAを信頼しなければならない。そのようなCAは、信頼された根または根のCASと呼ばれる。クライアント - サーバタイプシステムにおけるこのアプローチへの主な障害は、クライアントが証明書を持つ必要があるため、展開の問題になる可能性があります。
There are ways to do a better job than the schemes mentioned above, but they typically don't add much security unless communications security (at least message integrity) will be employed to secure the connection, because otherwise the attacker can merely hijack the connection after authentication has been performed. A number of protocols ([EKE], [SPEKE], [SRP]) allow one to securely bootstrap a
上記のスキームよりも良い仕事をする方法がありますが、通常のセキュリティ（少なくともメッセージの整合性）が接続を保護するために採用されない限り、多くのセキュリティを追加しません。認証が実行されました。いくつかのプロトコル（[EKE]、[SPEKE]、[SRP]）を確実にブートストラップすることができます。
user's password into a shared key which can be used as input to a cryptographic protocol. One major obstacle to the deployment of these protocols has been that their Intellectual Property status is extremely unclear. Similarly, the user can authenticate using public key certificates (e.g., S-HTTP client authentication). Typically these methods are used as part of a more complete security protocol.
暗号プロトコルへの入力として使用できる共有キーへのユーザーのパスワード。これらのプロトコルの展開に対する1つの大きな障害は、それらの知的財産状況が非常に不明であることです。同様に、ユーザーは公開鍵証明書（例えば、S-HTTPクライアント認証）を使用して認証できます。通常、これらの方法はより完全なセキュリティプロトコルの一部として使用されます。
Host authentication presents a special problem. Quite commonly, the addresses of services are presented using a DNS hostname, for instance as a URL [URL]. When requesting such a service, one has to ensure that the entity that one is talking to not only has a certificate but that that certificate corresponds to the expected identity of the server. The important thing to have is a secure binding between the certificate and the expected hostname.
ホスト認証は特別な問題を提示します。一般に、サービスのアドレスは、例えばURL [URL]としてDNSホスト名を使用して提示されます。そのようなサービスを要求するとき、1つが通話しているエンティティが証明書を持つだけでなく、その証明書がサーバーの予想される識別情報に対応することを保証する必要があります。持つ重要なことは、証明書と予想されるホスト名の間の安全なバインディングです。
For instance, it is usually not acceptable for the certificate to contain an identity in the form of an IP address if the request was for a given hostname. This does not provide end-to-end security because the hostname-IP mapping is not secure unless secure name resolution [DNSSEC] is being used. This is a particular problem when the hostname is presented at the application layer but the authentication is performed at some lower layer.
たとえば、要求が指定されたホスト名の場合、証明書にIPアドレスの形式でIDを含むことは通常は受け入れられません。Secure Name Resolution [DNSSEC]が使用されていない限り、hostname-IPマッピングは安全ではないため、これはエンドツーエンドのセキュリティを提供しません。ホスト名がアプリケーション層に表示されているが、認証はいくつかの下位レイヤで実行されるときに特別な問題です。
Providing security functionality in a protocol can be difficult. In addition to the problem of choosing authentication and key establishment mechanisms, one needs to integrate it into a protocol. One response to this problem (embodied in IPsec and TLS) is to create a lower-level security protocol and then insist that new protocols be run over that protocol. Another approach that has recently become popular is to design generic application layer security frameworks. The idea is that you design a protocol that allows you to negotiate various security mechanisms in a pluggable fashion. Application protocol designers then arrange to carry the security protocol PDUs in their application protocol. Examples of such frameworks include GSS-API [GSS] and SASL [SASL].
プロトコル内のセキュリティ機能を提供することは困難になる可能性があります。認証および重要な確立メカニズムを選択するという問題に加えて、それをプロトコルに統合する必要がある。この問題に対する1つの応答（IPsecおよびTLSで具体化されている）は、低レベルのセキュリティプロトコルを作成してから、そのプロトコルをそのプロトコル上で実行することを主張することです。最近人気になるもう1つのアプローチは、一般的なアプリケーション層のセキュリティフレームワークを設計することです。このアイデアは、プラグ可能な方法でさまざまなセキュリティメカニズムを交渉することを可能にするプロトコルを設計することです。その後、アプリケーションプロトコル設計者は、アプリケーションプロトコルでセキュリティプロトコルPDUを運ぶように配置します。そのようなフレームワークの例には、GSS-API [GSS]およびSASL [SASL]が含まれる。
The generic framework approach has a number of problems. First, it is highly susceptible to DOWNGRADE ATTACKS. In a downgrade attack, an active attacker tampers with the negotiation in order to force the parties to negotiate weaker protection than they otherwise would. It's possible to include an integrity check after the negotiation and key establishment have both completed, but the strength of this integrity check is necessarily limited to the weakest common algorithm. This problem exists with any negotiation approach, but generic frameworks exacerbate it by encouraging the application protocol author to just specify the framework rather than think hard about the appropriate underlying mechanisms, particularly since the mechanisms can very widely in the degree of security offered.
一般的なフレームワークアプローチにはいくつかの問題があります。まず、攻撃を格下げの影響を受けやすいです。ダウングレードの攻撃では、能力が不十分であることよりも弱い保護を交渉するために、能動的な攻撃者が交渉を受けています。ネゴシエーションと主要確立後に完全性チェックを含めることは可能ですが、この完全性検査の強さは必ずしも最も弱い共通アルゴリズムに限定されています。この問題は交渉アプローチに存在しますが、一般的なフレームワークは、特にメカニズムが提供されたセキュリティの程度で非常に広く提供される可能性があるため、適切な基礎となるメカニズムについては、適切な根本的なメカニズムについて激しく考えるのではなくフレームワークを指定するだけでなく、アプリケーションプロトコル作成者が枠組みを指定することを奨励することでそれを悪化させます。
Another problem is that it's not always obvious how the various security features in the framework interact with the application layer protocol. For instance, SASL can be used merely as an authentication framework -- in which case the SASL exchange occurs but the rest of the connection is unprotected, but can also negotiate traffic protection, such as via GSS, as a mechanism. Knowing under what circumstances traffic protection is optional and which it is required requires thinking about the threat model.
もう1つの問題は、フレームワーク内のさまざまなセキュリティ機能がアプリケーション層プロトコルと対話する方法が必ずしも明らかではないということです。たとえば、SASLは単に認証フレームワークとして使用できます。この場合、SASL Exchangeは発生しますが、残りの接続は保護されませんが、Mecumitionとして、GSSを介してトラフィック保護をネゴシエートすることもできます。トラフィック保護がオプションで、必要なのは脅威モデルについて考える必要があるのかを知ることが必要です。
In general, authentication frameworks are most useful in situations where new protocols are being added to systems with pre-existing legacy authentication systems. A framework allows new installations to provide better authentication while not forcing existing sites completely redo their legacy authentication systems. When the security requirements of a system can be clearly identified and only a few forms of authentication are used, choosing a single security mechanism leads to greater simplicity and predictability. In situations where a framework is to be used, designers SHOULD carefully examine the framework's options and specify only the mechanisms that are appropriate for their particular threat model. If a framework is necessary, designers SHOULD choose one of the established ones instead of designing their own.
一般に、認証フレームワークは、既存の従来の認証システムを持つシステムに新しいプロトコルが追加されている状況で最も役立ちます。フレームワークにより、新しいインストールは、既存のサイトを強制しないとともに、従来の認証システムを完全にやり直している間に、より良い認証を提供できます。システムのセキュリティ要件を明確に識別できる場合、単一のセキュリティメカニズムを選択すると、単純さと予測可能性が向上します。フレームワークを使用する状況では、設計者はフレームワークのオプションを慎重に調べ、それらの特定の脅威モデルに適したメカニズムのみを指定する必要があります。フレームワークが必要な場合は、設計者は自分で設計するのではなく、確立されたものの1つを選択する必要があります。
The naive approach to non-repudiation is simply to use public-key digital signatures over the content. The party who wishes to be bound (the SIGNING PARTY) digitally signs the message in question. The counterparty (the RELYING PARTY) can later point to the digital signature as proof that the signing party at one point agreed to the disputed message. Unfortunately, this approach is insufficient.
非否認に対するナイーブアプローチは、単にコンテンツ上で公開鍵のデジタル署名を使用することです。拘束されたいパーティー（署名者）は、問題のメッセージにデジタル的に署名します。相手方（信頼当事者）は後でデジタル署名を指しているため、一点での署名者が論争中のメッセージに合意したことを証明することができます。残念ながら、このアプローチは不十分です。
The easiest way for the signing party to repudiate the message is by claiming that his private key has been compromised and that some attacker (though not necessarily the relying party) signed the disputed message. In order to defend against this attack the relying party needs to demonstrate that the signing party's key had not been compromised at the time of the signature. This requires substantial infrastructure, including archival storage of certificate revocation information and timestamp servers to establish the time that the message was signed.
署名者がメッセージを繰り返しする最も簡単な方法は、彼の秘密鍵が危険にさらされており、その一部の攻撃者が論争中のメッセージに署名したことを主張することです。この攻撃に対して守るために、依拠当事者は、署名者の鍵の鍵が署名の時点で侵害されていないことを証明する必要があります。これには、証明書失効情報のアーカイブストレージやメッセージが署名された時刻を確立するための実質的なインフラストラクチャが必要です。
Additionally, the relying party might attempt to trick the signing party into signing one message while thinking he's signing another. This problem is particularly severe when the relying party controls the infrastructure that the signing party uses for signing, such as in kiosk situations. In many such situations the signing party's key is kept on a smartcard but the message to be signed is displayed by the relying party.
さらに、信頼当事者は、彼が別のメッセージに署名しながら1つのメッセージに署名するために署名者を署名することを試みるかもしれません。この問題は、依頼当事者がキオスク状況などの署名に署名するために使用するインフラストラクチャを制御するとき、この問題は特に深刻です。そのような状況の多くでは、署名者の鍵はスマートカードに保管されていますが、署名されるメッセージは依存パーティーによって表示されます。
All of these complications make non-repudiation a difficult service to deploy in practice.
これらすべての複雑さは、否認防止に困難なサービスを実際に展開しています。
AUTHORIZATION is the process by which one determines whether an authenticated party has permission to access a particular resource or service. Although tightly bound, it is important to realize that authentication and authorization are two separate mechanisms. Perhaps because of this tight coupling, authentication is sometimes mistakenly thought to imply authorization. Authentication simply identifies a party, authorization defines whether they can perform a certain action.
承認は、認証されたパーティーが特定のリソースまたはサービスにアクセスする許可を持っているかどうかを決定するプロセスです。しっかりと束縛されていますが、認証と承認が2つの別々のメカニズムであることを認識することが重要です。おそらくこの緊密な結合のために、認証は誤って許可を意味すると考えられていることがあります。認証は単にパーティーを識別し、許可は、特定のアクションを実行できるかどうかを定義します。
Authorization necessarily relies on authentication, but authentication alone does not imply authorization. Rather, before granting permission to perform an action, the authorization mechanism must be consulted to determine whether that action is permitted.
認証は必ず認証に依存していますが、認証だけでは許可を意味しません。そうではなく、アクションを実行する権限を付与する前に、そのアクションが許可されているかどうかを判断するために認証メカニズムを参照する必要があります。
One common form of authorization mechanism is an access control list (ACL), which lists users that are permitted access to a resource. Since assigning individual authorization permissions to each resource is tedious, resources are often hierarchically arranged so that the parent resource's ACL is inherited by child resources. This allows administrators to set top level policies and override them when necessary.
1つの一般的な形式の許可メカニズムは、リソースへのアクセス許可されているユーザーをリストするアクセス制御リスト（ACL）です。各リソースに個々の許可権限を割り当てることは面倒であるため、親リソースのACLが子リソースによって継承されるように、リソースは階層的に配置されることがよくあります。これにより、管理者は最上位ポリシーを設定し、必要に応じてそれらをオーバーライドできます。
While the distinction between authentication and authorization is intuitive when using simple authentication mechanisms such as username and password (i.e., everyone understands the difference between the administrator account and a user account), with more complex authentication mechanisms the distinction is sometimes lost.
ユーザー名とパスワードなどの単純な認証メカニズムを使用するとき（すなわち、全員が管理者アカウントとユーザアカウントとの間の差異を理解している場合）、認証と承認の違いは直感的であるが、より複雑な認証メカニズムで区別が失われることがあります。
With certificates, for instance, presenting a valid signature does not imply authorization. The signature must be backed by a certificate chain that contains a trusted root, and that root must be trusted in the given context. For instance, users who possess certificates issued by the Acme MIS CA may have different web access privileges than users who possess certificates issued by the Acme Accounting CA, even though both of these CAs are "trusted" by the Acme web server.
たとえば、証明書を使用すると、有効な署名を提示することは許可を意味しません。シグニチャは、信頼されたルートを含む証明書チェーンでバックアップされなければならず、そのルートは与えられたコンテキストで信頼されなければなりません。たとえば、ACME MIS CAによって発行された証明書を所有するユーザーは、ACME Webサーバーによって「信頼できる」になっていても、ACMEアカウンティングCAが発行した証明書を所有するユーザーよりも異なるWebアクセス権限がある場合があります。
Mechanisms for enforcing these more complicated properties have not yet been completely explored. One approach is simply to attach policies to ACLs describing what sorts of certificates are trusted. Another approach is to carry that information with the certificate, either as a certificate extension/attribute [PKIX, SPKI] or as a separate "Attribute Certificate".
これらのより複雑な特性を強制するためのメカニズムはまだ完全に探求されていません。1つのアプローチは、どのような種類の証明書が信頼されているかを説明するACLにポリシーを添付することです。もう1つの方法は、証明書拡張子/属性[PKIX、SPKI]、または別の「属性証明書」として、その情報を証明書と一緒に運ぶことです。
Securely designed protocols should provide some mechanism for securing (meaning integrity protecting, authenticating, and possibly encrypting) all sensitive traffic. One approach is to secure the protocol itself, as in [DNSSEC], [S/MIME] or [S-HTTP]. Although this provides security which is most fitted to the protocol, it also requires considerable effort to get right.
しっかりと設計されたプロトコルは、すべての機密トラフィックを保護するためのメカニズムを提供する必要があります。1つのアプローチは、[DNSSEC]、[S / MIME]または[S-HTTP]のように、プロトコル自体を保護することです。これはプロトコルに最も適しているセキュリティを提供しますが、それはまた権利を得るためにかなりの努力を必要とします。
Many protocols can be adequately secured using one of the available channel security systems. We'll discuss the two most common, IPsec [AH, ESP] and [TLS].
利用可能なチャネルセキュリティシステムの1つを使用して、多くのプロトコルを適切に保護することができます。2つの最も一般的なIPSec [AH、ESP]と[TLS]について説明します。
The IPsec protocols (specifically, AH and ESP) can provide transmission security for all traffic between two hosts. The IPsec protocols support varying granularities of user identification, including for example "IP Subnet", "IP Address", "Fully Qualified Domain Name", and individual user ("Mailbox name"). These varying levels of identification are employed as inputs to access control facilities that are an intrinsic part of IPsec. However, a given IPsec implementation might not support all identity types. In particular, security gateways may not provide user-to-user authentication or have mechanisms to provide that authentication information to applications.
IPSecプロトコル（具体的には、AHとESP）は、2つのホスト間のすべてのトラフィックに対して送信セキュリティを提供できます。IPSecプロトコルは、例えば「IPサブネット」、「IPアドレス」、「完全修飾ドメイン名」、および個々のユーザ（「メールボックス名」）を含む、ユーザ識別の異なる粒度をサポートしている。これらの変化するレベルの識別は、IPsecの固有部分であるアクセス制御施設への入力として採用されています。ただし、特定のIPSec実装はすべてのIDタイプをサポートしていない可能性があります。特に、セキュリティゲートウェイは、ユーザ間認証を提供しないか、またはその認証情報をアプリケーションに提供するためのメカニズムを提供することができない。
When AH or ESP is used, the application programmer might not need to do anything (if AH or ESP has been enabled system-wide) or might need to make specific software changes (e.g., adding specific setsockopt() calls) -- depending on the AH or ESP implementation being used. Unfortunately, APIs for controlling IPsec implementations are not yet standardized.
AHまたはESPが使用されている場合、アプリケーション・プログラマーは何もする必要がないかもしれません（AHまたはESPがシステム全体に有効になっている場合）、または特定のソフトウェアの変更を加える必要がある場合があります（たとえば、特定のSetSockopt（）呼び出し） - AHまたはESPの実装が使用されています。残念ながら、IPSec実装を制御するためのAPIはまだ標準化されていません。
The primary obstacle to using IPsec to secure other protocols is deployment. The major use of IPsec at present is for VPN applications, especially for remote network access. Without extremely tight coordination between security administrators and application developers, VPN usage is not well suited to providing security services for individual applications since it is difficult for such applications to determine what security services have in fact been provided.
他のプロトコルを保護するためにIPSecを使用する主な障害は展開です。現在のIPsecの主な使用は、特にリモートネットワークアクセスのためのVPNアプリケーションのためのものです。セキュリティ管理者とアプリケーション開発者との間に非常に厳密な調整がなければ、VPNの使用法は、実際にどのようなセキュリティサービスが提供されているかを判断するのが困難であるため、個々のアプリケーションのセキュリティサービスを提供するのに適していません。
IPsec deployment in host-to-host environments has been slow. Unlike application security systems such as TLS, adding IPsec to a non-IPsec system generally involves changing the operating system, either by modifying with the kernel or installing new drivers. This is a substantially greater undertaking than simply installing a new application. However, recent versions of a number of commodity operating systems include IPsec stacks, so deployment is becoming easier.
ホスト間環境でのIPsec展開は遅いです。TLSなどのアプリケーションセキュリティシステムとは異なり、IPsec以外のシステムに追加すると、一般に、カーネルを変更するか、新しいドライバをインストールすることによって、オペレーティングシステムの変更が含まれます。これは、単に新しいアプリケーションをインストールすることよりも実質的に大きい事業です。ただし、いくつかの商品オペレーティングシステムの最近のバージョンにはIPsecスタックが含まれているため、展開が簡単になりつつあります。
In environments where IPsec is sure to be available, it represents a viable option for protecting application communications traffic. If the traffic to be protected is UDP, IPsec and application-specific object security are the only options. However, designers MUST NOT assume that IPsec will be available. A security policy for a generic application layer protocol SHOULD NOT simply state that IPsec must be used, unless there is some reason to believe that IPsec will be available in the intended deployment environment. In environments where IPsec may not be available and the traffic is solely TCP, TLS is the method of choice, since the application developer can easily ensure its presence by including a TLS implementation in his package.
IPSecが確実である環境では、アプリケーション通信トラフィックを保護するための実行可能なオプションを表します。保護されるトラフィックがUDP、IPsecとアプリケーション固有のオブジェクトセキュリティが唯一のオプションである場合ただし、設計者はIPsecが利用可能になると仮定してはいけません。Generic Application Layerプロトコルのセキュリティポリシーは、IPsecが意図された展開環境で利用可能になると信じる理由がない限り、単にIPsecを使用する必要はありません。IPSecが利用できない環境で、トラフィックだけがTCPのみである可能性がある環境では、アプリケーション開発者は自分のパッケージ内のTLS実装を含めることによってその存在を容易に確実にすることができるので、TLSは選択方法です。
In the special-case of IPv6, both AH and ESP are mandatory to implement. Hence, it is reasonable to assume that AH/ESP are already available for IPv6-only protocols or IPv6-only deployments. However, automatic key management (IKE) is not required to implement so protocol designers SHOULD not assume it will be present. [USEIPSEC] provides quite a bit of guidance on when IPsec is a good choice.
IPv6の特別なケースでは、AHとESPの両方が実装に必須です。したがって、AH / ESPがIPv6専用プロトコルまたはIPv6専用の展開にすでに利用可能であると仮定することは合理的です。ただし、自動キー管理（IKE）は実装する必要はありません。プロトコル設計者は存在すると仮定しないでください。[ユニプシック] IPsecが良い選択のときにかなりのガイダンスを提供します。
Currently, the most common approach is to use SSL or its successor TLS. They provide channel security for a TCP connection at the application level. That is, they run over TCP. SSL implementations typically provide a Berkeley Sockets-like interface for easy programming. The primary issue when designing a protocol solution around TLS is to differentiate between connections protected using TLS and those which are not.
現在、最も一般的なアプローチは、SSLまたはその後継者TLSを使用することです。それらは、アプリケーションレベルでTCP接続のチャネルセキュリティを提供します。つまり、TCPを介して走ります。SSL実装は通常、簡単なプログラミングのためのBerkeleyソケットのようなインターフェースを提供します。TLS周辺のプロトコルソリューションを設計するときのプライマリの問題は、TLSを使用して保護されている接続を区別することです。
The two primary approaches used have a separate well-known port for TLS connections (e.g., the HTTP over TLS port is 443) [HTTPTLS] or to have a mechanism for negotiating upward from the base protocol to TLS as in [UPGRADE] or [STARTTLS]. When an upward negotiation strategy is used, care must be taken to ensure that an attacker can not force a clear connection when both parties wish to use TLS.
使用される2つの主なアプローチは、TLS接続用の別の有名なポート（例えば、HTTP over TLSポートが443）[HTTPTLS]であるか、[アップグレード]または[アップグレード]または[アップグレード]のようにベースプロトコルからTLSに上向きに交渉するためのメカニズムを持つためのメカニズムを持つかstarttls]。上向きのネゴシエーション戦略を使用する場合、両方の当事者がTLSを使用したい場合に攻撃者がクリア接続を強制できないように注意する必要があります。
Note that TLS depends upon a reliable protocol such as TCP or SCTP. This produces two notable difficulties. First, it cannot be used to secure datagram protocols that use UDP. Second, TLS is susceptible to IP layer attacks that IPsec is not. Typically, these attacks take some form of denial of service or connection assassination. For instance, an attacker might forge a TCP RST to shut down SSL connections. TLS has mechanisms to detect truncation attacks but these merely allow the victim to know he is being attacked and do not provide connection survivability in the face of such attacks. By contrast, if IPsec were being used, such a forged RST could be rejected without affecting the TCP connection. If forged RSTs or other such attacks on the TCP connection are a concern, then AH/ESP or the TCP MD5 option [TCPMD5] are the preferred choices.
TLSは、TCPやSCTPなどの信頼できるプロトコルに依存します。これにより、2つの注目に値する困難が生じる。まず、UDPを使用するデータグラムプロトコルを保護するためには使用できません。第二に、TLSはIPsecがそうでないIP層攻撃の影響を受けやすい。通常、これらの攻撃は何らかの形のサービス拒否または接続暗殺を取ります。たとえば、攻撃者は、SSL接続をシャットダウンするためにTCP RSTを偽造することがあります。TLSは切り捨て攻撃を検出するためのメカニズムを持っていますが、これらは被害者が攻撃されていることを知ることを知るだけで、そのような攻撃に直面しているところで接続の生存可能性を提供しません。対照的に、IPSecが使用されている場合、そのような偽造RSTはTCP接続に影響を与えることなく拒否され得る。TCP接続に対する偽造されたRSTまたは他のそのような攻撃が懸念される場合は、AH / ESPまたはTCP MD5オプション[TCPMD5]が好ましい選択肢です。
If the "separate ports" approach to TLS is used, then TLS will be negotiated before any application-layer traffic is sent. This can cause a problem with protocols that use virtual hosts, such as [HTTP], since the server does not know which certificate to offer the client during the TLS handshake. The TLS hostname extension [TLSEXT] can be used to solve this problem, although it is too new to have seen wide deployment.
「別々のポート」アプローチがTLSに使用されている場合は、アプリケーションレイヤトラフィックが送信される前にTLSがネゴシエートされます。これにより、[HTTP]などの仮想ホストを使用するプロトコルに問題があります。これにより、TLSハンドシェイク中にどの証明書がクライアントに提供するかがわかりません。この問題を解決するには、TLSホスト名拡張子[TLSEXT]を使用できますが、広すぎる展開が見られます。
One difficulty with using TLS is that the server is authenticated via a certificate. This can be inconvenient in environments where previously the only form of authentication was a password shared between client and server. It's tempting to use TLS without an authenticated server (i.e., with anonymous DH or a self-signed RSA certificate) and then authenticate via some challenge-response mechanism such as SASL with CRAM-MD5.
TLSを使用することで1つの問題は、サーバーが証明書を介して認証されていることです。これは以前に唯一の認証の形式がクライアントとサーバー間で共有されたパスワードである環境では不便です。認証されたサーバーなし（すなわち、匿名DHまたは自己署名RSA証明書を使用して）を使用してから、CRAM-MD5を使用してSASLなどのいくつかのチャレンジ応答メカニズムを介して認証するのは魅力的です。
Unfortunately, this composition of SASL and TLS is less strong than one would expect. It's easy for an active attacker to hijack this connection. The client man-in-the-middles the SSL connection (remember we're not authenticating the server, which is what ordinarily prevents this attack) and then simply proxies the SASL handshake. From then on, it's as if the connection were in the clear, at least as far as that attacker is concerned. In order to prevent this attack, the client needs to verify the server's certificate.
残念ながら、SASLおよびTLSのこの構成は、期待されるよりも強い。アクティブな攻撃者がこの接続をハイジャックするのは簡単です。クライアントは、MiddlesのSSL接続（サーバーを認証していないことを忘れないでください。）は、SASLハンドシェイクを単純にプロキシします。その後、それは、少なくともその攻撃者が関係している限り、接続が明確になったかのようです。この攻撃を防ぐために、クライアントはサーバーの証明書を確認する必要があります。
However, if the server is authenticated, challenge-response becomes less desirable. If you already have a hardened channel then simple passwords are fine. In fact, they're arguably superior to challenge-response since they do not require that the password be stored in the clear on the server. Thus, compromise of the key file with challenge-response systems is more serious than if simple passwords were used.
ただし、サーバーが認証されている場合、チャレンジ応答が望ましくありません。あなたがすでに強化されたチャネルを持っているならば、単純なパスワードは大丈夫です。実際、彼らはパスワードがサーバー上でクリアに保存される必要がないので、彼らは挑戦的な反応よりもおそらく優れています。したがって、チャレンジ応答システムを含むキーファイルの妥協は、単純なパスワードが使用されている場合よりも深刻です。
Note that if the client has a certificate than SSL-based client authentication can be used. To make this easier, SASL provides the EXTERNAL mechanism, whereby the SASL client can tell the server "examine the outer channel for my identity". Obviously, this is not subject to the layering attacks described above.
クライアントがSSLベースのクライアント認証より証明書を持っている場合は使用できます。これを簡単にするために、SASLは外部メカニズムを提供します。これにより、SASLクライアントはサーバーに「IDの外側のチャンネルを調べる」と言うことができます。明らかに、これは上記の階層化攻撃の影響を受けない。
In some special cases it may be worth providing channel-level security directly in the application rather than using IPSEC or SSL/TLS. One such case is remote terminal security. Characters are typically delivered from client to server one character at a time. Since SSL/TLS and AH/ESP authenticate and encrypt every packet, this can mean a data expansion of 20-fold. The telnet encryption option [ENCOPT] prevents this expansion by foregoing message integrity.
いくつかの特別な場合には、IPSecまたはSSL / TLSを使用するのではなく、アプリケーションに直接チャネルレベルのセキュリティを提供する価値があるかもしれません。そのような場合の1つは遠隔端末のセキュリティです。文字は通常、一度に1文字の1文字にクライアントからサーバーに配信されます。SSL / TLSおよびAH / ESPはすべてのパケットを認証して暗号化するため、これは20倍のデータ拡張を意味します。Telnet暗号化オプション[Encopt]は、メッセージの整合性を上げることでこの展開を防ぎます。
When using remote terminal service, it's often desirable to securely perform other sorts of communications services. In addition to providing remote login, SSH [SSH] also provides secure port forwarding for arbitrary TCP ports, thus allowing users run arbitrary TCP-based applications over the SSH channel. Note that SSH Port Forwarding can be security issue if it is used improperly to circumvent firewall and improperly expose insecure internal applications to the outside world.
リモート端末サービスを使用する場合、他の種類の通信サービスを安全に実行することがしばしば望ましい。リモートログインの提供に加えて、SSH [SSH]は任意のTCPポートのための安全なポート転送を提供します。したがって、ユーザーがSSHチャネルを介して任意のTCPベースのアプリケーションを実行できるようになります。SSHポート転送は、ファイアウォールを回避し、不適切な内部アプリケーションを外部の世界に不適切に露出させるために不適切に使用されている場合にセキュリティの問題になることがあります。
Denial of service attacks are all too frequently viewed as an fact of life. One problem is that an attacker can often choose from one of many denial of service attacks to inflict upon a victim, and because most of these attacks cannot be thwarted, common wisdom frequently assumes that there is no point protecting against one kind of denial of service attack when there are many other denial of service attacks that are possible but that cannot be prevented.
サービス拒否攻撃はすべて、人生の事実として頻繁に見られます。1つの問題は、攻撃者が犠牲者に影響を与えるために多くの拒否攻撃のうちの1つから選択することができ、そしてこれらの攻撃のほとんどが阻止されることができないので、一般的な知恵は頻繁に一種のサービス拒否に対して保護するという点が頻繁に仮定している。可能な他の多くのサービス攻撃があるがそれが防ぐことができない場合の攻撃。
However, not all denial of service attacks are equal and more importantly, it is possible to design protocols so that denial of service attacks are made more difficult, if not impractical. Recent SYN flood attacks [TCPSYN] demonstrate both of these properties: SYN flood attacks are so easy, anonymous, and effective that they are more attractive to attackers than other attacks; and because the design of TCP enables this attack.
しかしながら、全てのサービス拒否攻撃が等しいわけではないが、実用的ではない場合は、サービス攻撃拒否がより困難になるようにプロトコルを設計することが可能である。最近のSYNフラッド攻撃[TCPSYN]は、これらのプロパティの両方を示しています。シンフラッド攻撃は、他の攻撃よりも攻撃者にとってより魅力的であることが非常に簡単で、匿名、効果的です。そしてTCPの設計がこの攻撃を可能にするからです。
Because complete DoS protection is so difficult, security against DoS must be dealt with pragmatically. In particular, some attacks which would be desirable to defend against cannot be defended against economically. The goal should be to manage risk by defending against attacks with sufficiently high ratios of severity to cost of defense. Both severity of attack and cost of defense change as technology changes and therefore so does the set of attacks which should be defended against.
完全なDOS保護は非常に難しいので、DOSに対するセキュリティは実用的に対処しなければなりません。特に、被害を受けにくい攻撃は経済的に守られないものがある。目標は、防衛コストに対する十分に高い重症度の攻撃に対する防御によってリスクを管理することであるべきです。技術の変化としての攻撃の重大度と防衛のコストの両方が変化し、したがって守られるべき攻撃のセットもあります。
Authors of internet standards MUST describe which denial of service attacks their protocol is susceptible to. This description MUST include the reasons it was either unreasonable or out of scope to attempt to avoid these denial of service attacks.
インターネット規格の著者は、どのサービスの拒否攻撃が自分のプロトコルが影響を受けやすいかを説明しなければなりません。この説明には、これらのサービス拒否攻撃を回避することを試みるために不合理または範囲外のいずれかの理由を含める必要があります。
BLIND denial of service attacks are particularly pernicious. With a blind attack the attacker has a significant advantage. If the attacker must be able to receive traffic from the victim, then he must either subvert the routing fabric or use his own IP address. Either provides an opportunity for the victim to track the attacker and/or filter out his traffic. With a blind attack the attacker can use forged IP addresses, making it extremely difficult for the victim to filter out his packets. The TCP SYN flood attack is an example of a blind attack. Designers should make every attempt possible to prevent blind denial of service attacks.
ブラインドサービス攻撃攻撃は特に厄介です。盲目の攻撃で、攻撃者は大きな利点を持っています。攻撃者が犠牲者からのトラフィックを受信できる必要がある場合は、ルーティングファブリックをまとめたり、自分のIPアドレスを使用する必要があります。被害者が攻撃者を追跡したり、自分の交通を除外する機会を提供します。ブラインドアタックで攻撃者は鍛造IPアドレスを使用することができ、被害者が自分のパケットを除外することは非常に困難です。TCP SYNフラッド攻撃は盲目の攻撃の一例です。デザイナーは、盲目のサービス攻撃を防ぐためにすべての試みを可能にする必要があります。
Even more dangerous are DISTRIBUTED denial of service attacks (DDoS) [DDOS]. In a DDoS the attacker arranges for a number of machines to attack the target machine simultaneously. Usually this is accomplished by infecting a large number of machines with a program that allows remote initiation of attacks. The machines actually performing the attack are called ZOMBIEs and are likely owned by unsuspecting third parties in an entirely different location from the true attacker. DDoS attacks can be very hard to counter because the zombies often appear to be making legitimate protocol requests and simply crowd out the real users. DDoS attacks can be difficult to thwart, but protocol designers are expected to be cognizant of these forms of attack while designing protocols.
さらに危険なサービス拒否攻撃（DDOS）[DDOS]。DDOSでは、攻撃者はターゲットマシンを同時に攻撃するための多数の機械を整理します。通常、これは、攻撃の遠隔起動を可能にするプログラムを使用して多数のマシンに感染することによって達成されます。実際に攻撃を実行する機械はゾンビと呼ばれ、真の攻撃者とはまったく異なる場所にある第三者を疑う余地があることがあります。ゾンビが正当なプロトコル要求を行っているように見えることが多いため、DDOS攻撃は対面にとって非常に困難な場合があります。DDOS攻撃は阻止するのが難しい場合がありますが、プロトコル設計者はプロトコルを設計しながらこれらの攻撃の形式の認識となると予想されます。
There are two common approaches to making denial of service attacks more difficult:
サービス拒否攻撃をより困難にするための2つの一般的なアプローチがあります。
If an attacker consumes more of his resources than yours when launching an attack, attackers with fewer resources than you will be unable to launch effective attacks. One common technique is to require the attacker perform a time-intensive operation, such as a cryptographic operation. Note that an attacker can still mount a denial of service attack if he can muster substantially sufficient CPU power. For instance, this technique would not stop the distributed attacks described in [TCPSYN].
攻撃者が攻撃を開始するときよりも攻撃者が自分のリソースを消費する場合は、リソースの少ない攻撃者が効果的な攻撃を起動できません。1つの一般的な技術は、暗号操作などの時間的な集約的な操作を実行することを攻撃者に要求することです。攻撃者は、実質的に十分なCPU電力を集めることができれば、攻撃者がサービス拒否攻撃をマウントすることができます。たとえば、このテクニックは[TCPSyn]で説明されている分散攻撃を停止しません。
A blind attack can be subverted by forcing the attacker to prove that they can can receive data from the victim. A common technique is to require that the attacker reply using information that was gained earlier in the message exchange. If this countermeasure is used, the attacker must either use his own address (making him easy to track) or to forge an address which will be routed back along a path that traverses the host from which the attack is being launched.
攻撃者が被害者からデータを受信できることを証明することによって、盲目の攻撃を妨げる可能性があります。一般的な手法は、メッセージ交換の前に得られた情報を使用して攻撃者が返信することを要求することです。この対策が使用されている場合、攻撃者は自分の住所を使用する（追跡が簡単な）、または攻撃が開始されているホストを通過するパスに沿って返送される住所を築く必要があります。
Hosts on small subnets are thus useless to the attacker (at least in the context of a spoofing attack) because the attack can be traced back to a subnet (which should be sufficient for locating the attacker) so that anti-attack measures can be put into place (for instance, a boundary router can be configured to drop all traffic from that subnet). A common technique is to require that the attacker reply using information that was gained earlier in the message exchange.
したがって、小さなサブネット上のホストは攻撃者に（少なくともなりすまし攻撃のコンテキストで）攻撃者には役に立ちません（攻撃者を見つけるのに十分であるはずである）ので、アンチアタック対策を講じることができるplane（たとえば、境界ルーターはそのサブネットからすべてのトラフィックを削除するように設定できます）。一般的な手法は、メッセージ交換の前に得られた情報を使用して攻撃者が返信することを要求することです。
TCP/IP is vulnerable to SYN flood attacks (which are described in section 3.3.2) because of the design of the 3-way handshake. First, an attacker can force a victim to consume significant resources (in this case, memory) by sending a single packet. Second, because the attacker can perform this action without ever having received data from the victim, the attack can be performed anonymously (and therefore using a large number of forged source addresses).
TCP / IPは、3方向ハンドシェイクの設計のため、SYNフラッド攻撃（3.3.2項で説明されている）に対して脆弱です。第一に、攻撃者は、単一のパケットを送信することによって、被害者にかなりのリソース（この場合はメモリ）を消費することができます。第二に、攻撃者は被害者からデータを受信したことなくこのアクションを実行できるので、承認を匿名で実行することができます（したがって、多数の鍛造元の送信元アドレスを使用して）攻撃を実行できます。
[PHOTURIS] specifies an anti-clogging mechanism that prevents attacks on Photuris that resemble the SYN flood attack. Photuris employs a time-variant secret to generate a "cookie" which is returned to the attacker. This cookie must be returned in subsequent messages for the exchange to progress. The interesting feature is that this cookie can be regenerated by the victim later in the exchange, and thus no state need be retained by the victim until after the attacker has proven that he can receive packets from the victim.
[PHOTURIS] SYNフラッド攻撃に似たPHORISに対する攻撃を防ぐための目詰まり防止メカニズムを指定します。PHOTURISは、攻撃者に返却された「クッキー」を生成するためのタイムバリアントシークレットを採用しています。このCookieは、進行するためにその後のメッセージで返さなければなりません。興味深い特徴は、このクッキーが犠牲者によって交換の後半によって再生されることができるということであり、したがって攻撃者が被害者からのパケットを受けることができることを証明するまで将来の状態は必要とされないことである。
It's useful to make the conceptual distinction between object security and channel security. Object security refers to security measures which apply to entire data objects. Channel security measures provide a secure channel over which objects may be carried transparently but the channel has no special knowledge about object boundaries.
オブジェクトセキュリティとチャネルセキュリティの概念的な区別を行うのが便利です。オブジェクトセキュリティとは、データオブジェクト全体に適用されるセキュリティ対策を指します。チャネルセキュリティ対策は、オブジェクトが透過的に持ち運ぶことができる安全なチャネルを提供しますが、チャネルはオブジェクトの境界に関する特別な知識はありません。
Consider the case of an email message. When it's carried over an IPSEC or TLS secured connection, the message is protected during transmission. However, it is unprotected in the receiver's mailbox, and in intermediate spool files along the way. Moreover, since mail servers generally run as a daemon, not a user, authentication of messages generally merely means authentication of the daemon not the user. Finally, since mail transport is hop-by-hop, even if the user authenticates to the first hop relay the authentication can't be safely verified by the receiver.
電子メールメッセージの場合を考えてください。それがIPSecまたはTLS保護された接続を介して運ばれるとき、メッセージは送信中に保護されます。ただし、受信側のメールボックス、およびその途中での中間スプールファイルで保護されていません。さらに、メールサーバは一般にユーザではなくデーモンとして実行されるので、メッセージの認証は通常、ユーザではなくデーモンの認証を意味するだけである。最後に、メールトランスポートはホップバイホップであっても、ユーザーが最初のホップリレーに認証されていても、認証は受信者によって安全に検証できません。
By contrast, when an email message is protected with S/MIME or OpenPGP, the entire message is encrypted and integrity protected until it is examined and decrypted by the recipient. It also provides strong authentication of the actual sender, as opposed to the machine the message came from. This is object security. Moreover, the receiver can prove the signed message's authenticity to a third party.
対照的に、電子メールメッセージがS / MIMEまたはOpenPGPで保護されている場合、メッセージ全体は暗号化され、検査され、受信者によって復号化されるまで保護されます。メッセージが出身するマシンとは対照的に、それは実際の送信者の認証を提供します。これはオブジェクトセキュリティです。さらに、受信機は、署名付きメッセージの信頼性を第三者に証明することができる。
Note that the difference between object and channel security is a matter of perspective. Object security at one layer of the protocol stack often looks like channel security at the next layer up. So, from the perspective of the IP layer, each packet looks like an individually secured object. But from the perspective of a web client, IPSEC just provides a secure channel.
オブジェクトとチャネルのセキュリティの違いは視点の問題です。プロトコルスタックの1層でのオブジェクトセキュリティは、次のレイヤーのチャネルセキュリティのように見えます。したがって、IP層の観点からは、各パケットは個別に保護されたオブジェクトのように見えます。しかし、Webクライアントの観点からは、IPsecはセキュアチャンネルを提供するだけです。
The distinction isn't always clear-cut. For example, S-HTTP provides object level security for a single HTTP transaction, but a web page typically consists of multiple HTTP transactions (the base page and numerous inline images). Thus, from the perspective of the total web page, this looks rather more like channel security. Object security for a web page would consist of security for the transitive closure of the page and all its embedded content as a single unit.
区別は必ずしも明確にカットされません。たとえば、S-HTTPは単一のHTTPトランザクションのオブジェクトレベルのセキュリティを提供しますが、Webページは通常、複数のHTTPトランザクション（基本ページと多数のインライン画像）で構成されています。したがって、全ウェブページの観点からは、これはかなりのチャネルセキュリティのように見えます。Webページのオブジェクトセキュリティは、ページの推移的な閉鎖のためのセキュリティと、そのすべての埋め込みコンテンツは単一のユニットとして構成されます。
It's common security practice in modern networks to partition the network into external and internal networks using a firewall. The internal network is then assumed to be secure and only limited security measures are used there. The internal portion of such a network is often called a WALLED GARDEN.
現代のネットワークでは、ネットワークをファイアウォールを使用して外部ネットワークと内部ネットワークに分割するための一般的なセキュリティ実践です。内部ネットワークは安全であると想定され、そこで限られたセキュリティ対策のみが使用されます。そのようなネットワークの内部部分は、しばしば壁の庭と呼ばれます。
Internet protocol designers cannot safely assume that their protocols will be deployed in such an environment, for three reasons. First, protocols which were originally designed to be deployed in closed environments often are later deployed on the Internet, thus creating serious vulnerabilities.
インターネットプロトコル設計者は、3つの理由で、プロトコルがそのような環境で展開されると安全に想定することはできません。まず、最初に、閉じた環境で展開されるように設計されたプロトコルがしばしばインターネット上に展開されているため、深刻な脆弱性が発生します。
Second, networks which appear to be topologically disconnected may not be. One reason may be that the network has been reconfigured to allow access by the outside world. Moreover, firewalls are increasingly passing generic application layer protocols such as [SOAP] or [HTTP]. Network protocols which are based on these generic protocols cannot in general assume that a firewall will protect them. Finally, one of the most serious security threats to systems is from insiders, not outsiders. Since insiders by definition have access to the internal network, topological protections such as firewalls will not protect them.
次に、トポロジ的に切断されているように見えるネットワークはできません。一つの理由は、ネットワークが外部の世界によるアクセスを許可するように再構成されている可能性があります。さらに、ファイアウォールは、[SOAP]または[HTTP]などの一般的なアプリケーション層プロトコルをますます渡されています。これらの一般的なプロトコルに基づくネットワークプロトコルは、一般にファイアウォールがそれらを保護すると仮定することはできません。最後に、システムに対する最も深刻なセキュリティ脅威の1つは、インサイダーからのものです。定義によるインサイダーは内部ネットワークにアクセスできるので、ファイアウォールなどのトポロジー保護はそれらを保護しません。
While it is not a requirement that any given protocol or system be immune to all forms of attack, it is still necessary for authors to consider as many forms as possible. Part of the purpose of the Security Considerations section is to explain what attacks are out of scope and what countermeasures can be applied to defend against them. In
特定のプロトコルまたはシステムがすべての攻撃に耐性があるという要件ではありませんが、作者ができるだけ多くの形を検討する必要があります。セキュリティ上の考慮事項の目的の一部は、どのような攻撃が範囲外であり、それらに対して守るためにどのような対策を適用できるかを説明することです。に
There should be a clear description of the kinds of threats on the described protocol or technology. This should be approached as an effort to perform "due diligence" in describing all known or foreseeable risks and threats to potential implementers and users.
記載されたプロトコルまたは技術に関する脅威の種類の明確な説明があるはずです。これは、潜在的な実装者やユーザーに対するすべての既知のまたは予見可能なリスクと脅威を記述する際に「デューデリジェンス」を実行するための努力として取り組むべきです。
Authors MUST describe
著者は説明しなければなりません
1. which attacks are out of scope (and why!) 2. which attacks are in-scope 2.1 and the protocol is susceptible to 2.2 and the protocol protects against
1. どの攻撃が範囲外（そしてその理由）2。どの攻撃が範囲内2.1であり、プロトコルは2.2の影響を受けやすく、プロトコルは反対に保護します。
At least the following forms of attack MUST be considered: eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle. Potential denial of service attacks MUST be identified as well. If the protocol incorporates cryptographic protection mechanisms, it should be clearly indicated which portions of the data are protected and what the protections are (i.e., integrity only, confidentiality, and/or endpoint authentication, etc.). Some indication should also be given to what sorts of attacks the cryptographic protection is susceptible. Data which should be held secret (keying material, random seeds, etc.) should be clearly labeled.
少なくとも次の形式の攻撃を考慮する必要があります。潜在的なサービス攻撃の拒否も同様に識別されなければなりません。プロトコルが暗号保護メカニズムを組み込んでいる場合、データのどの部分が保護されているか、および保護がどのようなものであるか、および保護が何であるか（すなわち、完全性、機密性、および/またはエンドポイント認証など）を明確に示さなければならない。暗号保護が影響を受けやすい種類の攻撃の種類にもいくつかの指示を与えられるべきです。秘密に保持されるべきデータ（キーイング材料、ランダムな種など）は明確にラベル付けされるべきです。
If the technology involves authentication, particularly user-host authentication, the security of the authentication method MUST be clearly specified. That is, authors MUST document the assumptions that the security of this authentication method is predicated upon. For instance, in the case of the UNIX username/password login method, a statement to the effect of:
テクノロジに認証、特にユーザーホスト認証が含まれる場合は、認証方法のセキュリティを明確に指定する必要があります。つまり、作者は、この認証方法のセキュリティが認められているという仮定を文書化する必要があります。たとえば、UNIXのユーザー名/パスワードのログイン方法の場合は、次の効果を説明します。
Authentication in the system is secure only to the extent that it is difficult to guess or obtain a ASCII password that is a maximum of 8 characters long. These passwords can be obtained by sniffing telnet sessions or by running the 'crack' program using the contents of the /etc/passwd file. Attempts to protect against on-line password guessing by (1) disconnecting after several unsuccessful login attempts and (2) waiting between successive password prompts is effective only to the extent that attackers are impatient.
システム内の認証は、最大8文字のASCIIパスワードを推測または取得することが困難である範囲でのみ安全です。これらのパスワードは、Telnetセッションをスニッフィングすること、または/ etc / passwdファイルの内容を使用して「亀裂」プログラムを実行することによって取得できます。（1）いくつかの失敗したログイン試行後に切断したオンラインパスワード推測から保護しようとすると、（2）連続したパスワードプロンプト間の待機中は、攻撃者が焦点があった範囲でのみ有効です。
Because the /etc/passwd file maps usernames to user ids, groups, etc. it must be world readable. In order to permit this usage but make running crack more difficult, the file is often split into /etc/passwd and a 'shadow' password file. The shadow file is not world readable and contains the encrypted password. The regular /etc/passwd file contains a dummy password in its place.
/ etc / passwdファイルはユーザー名をユーザーID、グループなどにマッピングするため、世界の読みやすい必要があります。この使用法を許可するがランニングクラックをより困難にするために、ファイルは/ etc / passwdおよび 'shadow'パスワードファイルに分割されることがよくあります。シャドウファイルはWorld読み取り可能ではなく、暗号化されたパスワードを含みます。通常/ etc / passwdファイルには、その場所にダミーパスワードがあります。
It is insufficient to simply state that one's protocol should be run over some lower layer security protocol. If a system relies upon lower layer security services for security, the protections those services are expected to provide MUST be clearly specified. In addition, the resultant properties of the combined system need to be specified.
自分のプロトコルをいくつかの下位レイヤセキュリティプロトコルに渡すべきであることを単純に述べるのは不十分です。システムがセキュリティのために低層セキュリティサービスに依存している場合、それらのサービスの保護は明確に指定されなければならないという保護が必要です。また、合わせたシステムの結果として生じる特性を特定する必要があります。
Note: In general, the IESG will not approve standards track protocols which do not provide for strong authentication, either internal to the protocol or through tight binding to a lower layer security protocol.
注：一般に、IESGは、プロトコルの内部または下位レイヤーセキュリティプロトコルへの厳密なバインディングのいずれかで、強力な認証を提供しない標準トラックプロトコルを承認しません。
The threat environment addressed by the Security Considerations section MUST at a minimum include deployment across the global Internet across multiple administrative boundaries without assuming that firewalls are in place, even if only to provide justification for why such consideration is out of scope for the protocol. It is not acceptable to only discuss threats applicable to LANs and ignore the broader threat environment. All IETF standards-track protocols are considered likely to have deployment in the global Internet. In some cases, there might be an Applicability Statement discouraging use of a technology or protocol in a particular environment. Nonetheless, the security issues of broader deployment should be discussed in the document.
セキュリティ上の考慮事項のセクションによって対処される脅威環境は、そのような考慮がプロトコルの範囲外の理由が不足している理由を提供するためだけであっても、ファイアウォールが適切であると仮定しないで、複数の管理境界にわたるグローバルインターネット全体の展開を備えていなければなりません。LANに適用される脅威についてのみ説明し、より広い脅威環境を無視することはできません。すべてのIETF標準トラックプロトコルは、グローバルインターネットに展開がある可能性が高いと見なされます。場合によっては、特定の環境におけるテクノロジやプロトコルの使用を阻止する即応ステートメントがある可能性があります。それにもかかわらず、より広い展開のセキュリティ上の問題は文書内で議論されるべきです。
There should be a clear description of the residual risk to the user or operator of that protocol after threat mitigation has been deployed. Such risks might arise from compromise in a related protocol (e.g., IPsec is useless if key management has been compromised), from incorrect implementation, compromise of the security technology used for risk reduction (e.g., a cipher with a 40-bit key), or there might be risks that are not addressed by the protocol specification (e.g., denial of service attacks on an underlying link protocol). Particular care should be taken in situations where the compromise of a single system would compromise an entire protocol. For instance, in general protocol designers assume that end-systems are inviolate and don't worry about physical attack. However, in cases (such as a certificate authority) where compromise of a single system could lead to widespread compromises, it is appropriate to consider systems and physical security as well.
脅威の軽減が展開された後に、そのプロトコルのユーザーまたはオペレータに残留リスクの明確な説明があるはずです。このようなリスクは、関連するプロトコルでの妥協点から生じる可能性があります（例えば、IPSecは、鍵管理が危険にさらされている場合は無駄になります）、リスク低減に使用されるセキュリティテクノロジの妥協（例：40ビットキーを持つ暗号）、あるいは、プロトコル仕様（例えば、基礎となるリンクプロトコルに対するサービス攻撃の拒否）によって対処されていないリスクがあるかもしれません。単一のシステムの妥協点がプロトコル全体を危うくすることになる状況では、特に注意を払う必要があります。たとえば、一般的なプロトコル設計者は、エンドシステムが非侵害であり、物理的な攻撃を心配しないとします。ただし、単一のシステムの妥協が広くなる可能性がある場合（認証局など）、システムや物理的なセキュリティを考慮することが適切です。
There should also be some discussion of potential security risks arising from potential misapplications of the protocol or technology described in the RFC. This might be coupled with an Applicability Statement for that RFC.
RFCに記載されているプロトコルまたは技術の潜在的な使いやすさから生じる潜在的なセキュリティリスクについてもいくつかの議論があるはずです。これはそのRFCの適用範囲で結合される可能性があります。
This section consists of some example security considerations sections, intended to give the reader a flavor of what's intended by this document.
このセクションは、この文書によって意図されているもののフレーバーを読者に与えることを目的とした、セキュリティ上の考慮事項の一部の例で構成されています。
The first example is a 'retrospective' example, applying the criteria of this document to an existing widely deployed protocol, SMTP. The second example is a good security considerations section clipped from a current protocol.
最初の例は、この文書の基準を既存の広範な展開されたプロトコル、SMTPに適用する例です。2番目の例は、現在のプロトコルから切り取られた優れたセキュリティ上の考慮事項のセクションです。
When RFC 821 was written, Security Considerations sections were not required in RFCs, and none is contained in that document. [RFC 2821] updated RFC 821 and added a detailed security considerations section. We reproduce here the Security Considerations section from that document (with new section numbers). Our comments are indented and prefaced with 'NOTE:'. We also add a number of new sections to cover topics we consider important. Those sections are marked with [NEW] in the section header.
RFC 821が書き込まれたとき、セキュリティに関する考慮事項のセクションはRFCには必要ありませんでしたが、その文書には含まれません。[RFC 2821] RFC 821を更新し、詳細なセキュリティ上の考慮事項を追加しました。ここでは、その文書からセキュリティ上の考慮事項セクションを再現しています（新しいセクション番号付き）。私たちのコメントはインデントされており、「注意：」の前にまた、考慮したトピックをカバーするためにいくつかの新しいセクションを追加します。これらのセクションは、セクションヘッダーの[New]でマークされています。
SMTP mail is inherently insecure in that it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else. Constructing such a message so that the "spoofed" behavior cannot be detected by an expert is somewhat more difficult, but not sufficiently so as to be a deterrent to someone who is determined and knowledgeable. Consequently, as knowledge of Internet mail increases, so does the knowledge that SMTP mail inherently cannot be authenticated, or integrity checks provided, at the transport level. Real mail security lies only in end-to-end methods involving the message bodies, such as those which use digital signatures (see [14] and, e.g., PGP [4] or S/MIME [31]).
SMTPメールは、かなりカジュアルなユーザーでさえも、SMTPサーバーの受信および中継に直接交渉し、彼らが他の場所から来たと信じるメッセージを作成することができるという点で、本質的に不安です。「偽装された」行動が専門家によって検出できないようにそのようなメッセージを構築することはやや困難であるが、決定されている人にとって抑止力があるように十分ではない。したがって、インターネットメールの知識が増えるにつれて、SMTPメールが本質的に認証されない知識、または積載レベルでは、トランスポートレベルで提供されていないこともあります。実際のメールセキュリティは、デジタル署名を使用するものなどのメッセージ本体を含むエンドツーエンドのメソッドでのみあります（[14]、例えばPGP [4]またはS / MIME [31]）。
NOTE: One bad approach to sender authentication is [IDENT] in which the receiving mail server contacts the alleged sender and asks for the username of the sender. This is a bad idea for a number of reasons, including but not limited to relaying, TCP connection hijacking, and simple lying by the origin server. Aside from the fact that IDENT is of low security value, use of IDENT by receiving sites can lead to operational problems. Many sending sites blackhole IDENT requests, thus causing mail to be held until the receiving server's IDENT request times out.
注：送信者認証への1つの悪いアプローチは、受信メールサーバーが送信された送信者に連絡して送信者のユーザー名を要求する[ID]です。これは、中継、TCP接続ハイジャック、および原点サーバーによるシンプルな嘘を含むがこれらに限定されない理由がいくつかの考えである。IDENTがセキュリティ値が低いという事実を除いて、受信サイトによるIDの使用は動作上の問題を引き起こす可能性があります。多くの送信サイトBlackHole IDENTリクエスト、したがって、受信側のサーバーのIDENT要求がタイムアウトするまでメールを保持します。
Various protocol extensions and configuration options that provide authentication at the transport level (e.g., from an SMTP client to an SMTP server) improve somewhat on the traditional situation described above. However, unless they are accompanied by careful handoffs of responsibility in a carefully-designed trust environment, they remain inherently weaker than end-to-end mechanisms which use digitally signed messages rather than depending on the integrity of the transport system.
トランスポートレベル（例えば、SMTPクライアントからSMTPサーバへのSMTPサーバからSMTPサーバへ）で認証を提供するさまざまなプロトコル拡張機能と設定オプションは、上記の伝統的な状況について幾分改善されます。ただし、慎重に設計された信頼環境における責任の慎重なハンドオフを伴わない限り、それらはトランスポートシステムの完全性に依存するのではなく、デジタル署名されたメッセージを使用するエンドツーエンドのメカニズムよりも本質的に弱いままです。
Efforts to make it more difficult for users to set envelope return path and header "From" fields to point to valid addresses other than their own are largely misguided: they frustrate legitimate applications in which mail is sent by one user on behalf of another or in which error (or normal) replies should be directed to a special address. (Systems that provide convenient ways for users to alter these fields on a per-message basis should attempt to establish a primary and permanent mailbox address for the user so that Sender fields within the message data can be generated sensibly.)
封筒の戻りパスとヘッダーを自分のもの以外の有効なアドレスを指すために、ユーザーが自分のフィールドを指すようにするための努力は、主に誤って誤解されています。どのエラー（または通常の）応答を特別なアドレスに向けてください。（メッセージデータ内の送信者フィールドが賢明に生成できるように、ユーザーにこれらのフィールドを変更するための便利な方法を提供するシステムは、ユーザーのプライマリおよび恒久的なメールボックスアドレスを確立しようとする必要があります。）
This specification does not further address the authentication issues associated with SMTP other than to advocate that useful functionality not be disabled in the hope of providing some small margin of protection against an ignorant user who is trying to fake mail.
この仕様では、偽のユーザーに対して保護のある小さなマージンを偽造しようとしていることを希望して、有用な機能が無効にされていないことを参照してください。
NOTE: We have added additional material on communications security and SMTP in Section 6.1.2 In a final specification, the above text would be edited somewhat to reflect that fact.
注：6.1.2項でCommunications SecurityとSMTPに追加の資料を追加しました。最後の仕様では、上記のテキストはその事実を反映するためにやや編集されます。
Addresses that do not appear in the message headers may appear in the RCPT commands to an SMTP server for a number of reasons. The two most common involve the use of a mailing address as a "list exploder" (a single address that resolves into multiple addresses) and the appearance of "blind copies". Especially when more than one RCPT command is present, and in order to avoid defeating some of the purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy the full set of RCPT command arguments into the headers, either as part of trace headers or as informational or private-extension headers. Since this rule is often violated in practice, and cannot be enforced, sending SMTP systems that are aware of "bcc" use MAY find it helpful to send each blind copy as a separate message transaction containing only a single RCPT command.
メッセージヘッダーに表示されないアドレスは、多くの理由で、SMTPサーバーにRCPTコマンドに表示されることがあります。最も一般的な2つの一般的なものは、郵送先住所（複数のアドレスに解決する単一のアドレス）と「ブラインドコピー」の外観としての郵送先住所を使用することを含みます。特に複数のRCPTコマンドが存在する場合、およびこれらのメカニズムの目的の一部を無効にするために、SMTPクライアントとサーバーは、トレースヘッダーの一部として、またはASとしてのRCPTコマンド引数のフルセットをヘッダーにコピーしないでください。情報またはプライベート - 拡張ヘッダ。この規則は実際に違反していることがよくあり、「BCC」を認識しているSMTPシステムを送信することはできませんので、各ブラインドコピーを単一のRCPTコマンドのみを含む別のメッセージトランザクションとして送信すると便利です。
There is no inherent relationship between either "reverse" (from MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP transaction ("envelope") and the addresses in the headers. Receiving systems SHOULD NOT attempt to deduce such relationships and use them to alter the headers of the message for delivery. The popular "Apparently-to" header is a violation of this principle as well as a common source of unintended information disclosure and SHOULD NOT be used.
「逆」（Mail、SAMLなどから）またはSMTPトランザクション（ "envelope"）内の "Forward"（RCPT）アドレスのどちらかとヘッダー内のアドレスのいずれかに固有の関係はありません。受信システムはそのような関係を推測し、それらを使用して配達のためのメッセージのヘッダーを変更することを試みるべきではありません。一般的な「明らかに」ヘッダーは、この原則の違反と意図しない情報開示の一般的な情報源となり、使用しないでください。
As discussed in section 3.5, individual sites may want to disable either or both of VRFY or EXPN for security reasons. As a corollary to the above, implementations that permit this MUST NOT appear to have verified addresses that are not, in fact, verified. If a site disables these commands for security reasons, the SMTP server MUST return a 252 response, rather than a code that could be confused with successful or unsuccessful verification.
セクション3.5で説明したように、個々のサイトは、セキュリティ上の理由からVRFYまたはEXPNのいずれかまたは両方を無効にすることをお勧めします。上記の推論として、これを許可する実装は、実際には検証されていない検証されたアドレスを検証してはいけません。サイトがセキュリティ上の理由からこれらのコマンドを無効にした場合、SMTPサーバーは、成功または失敗した検証と混同される可能性のあるコードではなく、252の応答を返す必要があります。
Returning a 250 reply code with the address listed in the VRFY command after having checked it only for syntax violates this rule. Of course, an implementation that "supports" VRFY by always returning 550 whether or not the address is valid is equally not in conformance.
この規則に違反する構文に違反した後、vrfyコマンドにリストされているアドレスを指定して250回の返信コードを返す。もちろん、アドレスが有効であるかどうかにかかわらず、常に550を返すことによって「サポートする」実装は等しく適合しない。
Within the last few years, the contents of mailing lists have become popular as an address information source for so-called "spammers." The use of EXPN to "harvest" addresses has increased as list administrators have installed protections against inappropriate uses of the lists themselves. Implementations SHOULD still provide support for EXPN, but sites SHOULD carefully evaluate the tradeoffs. As authentication mechanisms are introduced into SMTP, some sites may choose to make EXPN available only to authenticated requesters.
ここ数年以内に、メーリングリストの内容は、いわゆる「スパマー」のアドレス情報源として普及しています。リスト管理者がリスト自体の不適切な用途に対する保護をインストールしたため、「収穫」のアドレスへのEXPNの使用が増加しました。実装はまだEXPNのサポートを提供する必要がありますが、サイトはトレードオフを慎重に評価する必要があります。認証メカニズムがSMTPに導入されるにつれて、いくつかのサイトは認証された要求者にのみ利用可能なEXPNを利用できるようにすることができる。
NOTE: It's not clear that disabling VRFY adds much protection, since it's often possible to discover whether an address is valid using RCPT TO.
注：VRFYを無効にすることは、RCPTを使用してアドレスが有効かどうかを検出することが可能であるため、多くの保護を追加することは明らかではありません。
There has been an ongoing debate about the tradeoffs between the debugging advantages of announcing server type and version (and, sometimes, even server domain name) in the greeting response or in response to the HELP command and the disadvantages of exposing information that might be useful in a potential hostile attack. The utility of the debugging information is beyond doubt. Those who argue for making it available point out that it is far better to actually secure an SMTP server rather than hope that trying to conceal known vulnerabilities by hiding the server's precise identity will provide more protection. Sites are encouraged to evaluate the tradeoff with that issue in mind; implementations are strongly encouraged to minimally provide for making type and version information available in some way to other network hosts.
グリーティングレスポンスのサーバーの種類とバージョン（時には、サーバードメイン名でさえ、ヘルプコマンド）に応答して、または役に立つかもしれない情報を公開することの欠点との間のトレードオフについての継続的な議論がありました。潜在的な敵対的な攻撃で。デバッグ情報の有用性は疑いを超えています。それを利用できるようにする人々は、サーバーの正確なアイデンティティを隠すことによって既知の脆弱性を隠そうとすることを願っていて、実際にSMTPサーバーを確実に保護することを指摘しています。サイトはその問題とのトレードオフを念頭に置いて評価することをお勧めします。実装は、他のネットワークホストに何らかの方法で利用可能な種類とバージョン情報を利用できるようにすることを最小限に推奨されています。
In some circumstances, such as when mail originates from within a LAN whose hosts are not directly on the public Internet, trace ("Received") fields produced in conformance with this specification may disclose host names and similar information that would not normally be available. This ordinarily does not pose a problem, but sites with special concerns about name disclosure should be aware of it. Also, the optional FOR clause should be supplied with caution or not at all when multiple recipients are involved lest it inadvertently disclose the identities of "blind copy" recipients to others.
郵便物が公衆インターネット上で直接公衆インターネット上で直接的ではないLAN内から発信されたときの状況によっては、この仕様に準拠して生成されたトレース（「受信」）フィールドは、ホスト名と通常利用可能ではない類似の情報を開示することがある。これは通常問題を提起しませんが、名前開示に関する特別な懸念を伴うサイトはそれを認識すべきです。また、オプションのFOR句には、複数の受信者が関与している場合はまったく注意してください。
As discussed in section 3.4, use of the 251 or 551 reply codes to identify the replacement address associated with a mailbox may inadvertently disclose sensitive information. Sites that are concerned about those issues should ensure that they select and configure servers appropriately.
セクション3.4で説明したように、メールボックスに関連する置換アドレスを識別するための251または551の応答コードの使用は、誤って機密情報を開示する可能性がある。これらの問題について心配しているサイトは、サーバーを適切に選択して設定することを確認する必要があります。
It is a well-established principle that an SMTP server may refuse to accept mail for any operational or technical reason that makes sense to the site providing the server. However, cooperation among sites and installations makes the Internet possible. If sites take excessive advantage of the right to reject traffic, the ubiquity of email availability (one of the strengths of the Internet) will be threatened; considerable care should be taken and balance maintained if a site decides to be selective about the traffic it will accept and process.
SMTPサーバーが、サーバーを提供するサイトに理にかなっている操作または技術的な理由でメールを受け入れることを拒否することができることは、確立された原則です。ただし、サイトや設置間の協力はインターネットを可能にします。サイトがトラフィックを拒否する権利の過度の利点を持つ場合、電子メールの可用性の普遍性（インターネットの強みの1つ）が脅かされるでしょう。かなりの注意を払って、サイトが受け入れて処理するトラフィックについて選択的になることを決定した場合、維持されるべきバランスが取られるべきです。
In recent years, use of the relay function through arbitrary sites has been used as part of hostile efforts to hide the actual origins of mail. Some sites have decided to limit the use of the relay function to known or identifiable sources, and implementations SHOULD provide the capability to perform this type of filtering. When mail is rejected for these or other policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL, or RCPT as appropriate.
近年、実際のメールの起源を隠すための敵対的な取り組みの一環として、中継機能を任意のサイトに使用しています。いくつかのサイトは、中継関数の使用を既知または識別可能なソースに制限することを決定し、実装はこのタイプのフィルタリングを実行する機能を提供する必要があります。これらのポリシー上の理由からメールが拒否された場合は、必要に応じてEHLO、メール、またはRCPTに応じて550コードを使用する必要があります。
SMTP itself provides no protection is provided against unsolicited commercial mass e-mail (aka spam). It is extremely difficult to tell a priori whether a given message is spam or not. From a protocol perspective, spam is indistinguishable from other e-mail -- the distinction is almost entirely social and often quite subtle. (For instance, is a message from a merchant from whom you've purchased items before advertising similar items spam?) SMTP spam-suppression mechanisms are generally limited to identifying known spam senders and either refusing to service them or target them for punishment/disconnection. [RFC-2505] provides extensive guidance on making SMTP servers spam-resistant. We provide a brief discussion of the topic here.
SMTP自体は、求められていない商業用マスメール（AKA SPAM）に対して保護はありません。与えられたメッセージがスパムかどうかにかかわらず、先験的に言うことは非常に困難です。プロトコルの観点から見ると、スパムは他の電子メールと区別がつかない - 区別はほとんど完全に社会的で、かなり微妙です。（たとえば、類似したアイテムを広告する前に商品を購入した商品からのメッセージは？）SMTPスパム抑制メカニズムは、一般に、既知のスパム送信者の識別に限定され、それらを拒否するか、罰/切断のためにそれらをターゲットにすることを拒否します。。[RFC-2505] SMTPサーバーをスパム抵抗させる上で広範なガイダンスを提供します。ここでトピックについて簡単に説明します。
The primary tool for refusal to service spammers is the blacklist. Some authority such as [MAPS] collects and publishes a list of known spammers. Individual SMTP servers then block the blacklisted offenders (generally by IP address).
サービススパマーを拒否する主なツールはブラックリストです。[地図]などのいくつかの権限は、既知のスパマーのリストを収集して公開します。その後、個々のSMTPサーバーはブラックリストに遭った犯罪者（一般にIPアドレス）をブロックします。
In order to avoid being blacklisted or otherwise identified, spammers often attempt to obscure their identity, either simply by sending a false SMTP identity or by forwarding their mail through an Open Relay -- an SMTP server which will perform mail relaying for any sender. As a consequence, there are now blacklists [ORBS] of open relays as well.
ブラックリストに登録されたり識別されたりするために、スパマーは、誤ったSMTPアイデンティティを送信するか、または任意の送信者のためのメール中継を実行するSMTPサーバを介して誤ったSMTPアイデンティティを送信することによってそれらの身元を不明瞭にしようとします。結果として、オープンリレーのブラックリスト[オーブ）もあります。
To avoid being used for spam forwarding, many SMTP servers operate as closed relays, providing relaying service only for clients who they can identify. Such relays should generally insist that senders advertise a sending address consistent with their known identity. If the relay is providing service for an identifiable network (such as a corporate network or an ISP's network) then it is sufficient to block all other IP addresses). In other cases, explicit authentication must be used. The two standard choices for this are TLS [STARTTLS] and SASL [SASLSMTP].
スパム転送に使用されるのを避けるために、多くのSMTPサーバーはクローズドリレーとして動作し、識別可能なクライアントに対してのみ中継サービスを提供します。そのようなリレーは、一般的に、送信者がそれらの既知の識別情報と一致する送信アドレスをアドバタイズすることを主張するべきである。リレーが識別可能なネットワーク（企業ネットワークやISPネットワークなど）のサービスを提供している場合は、他のすべてのIPアドレスをブロックするのに十分です。それ以外の場合は、明示的認証を使用する必要があります。これに関する2つの標準選択はTLS [STARTTLS]とSASL [SASLSMTP]です。
Realistically, SMTP endpoints cannot refuse to deny service to unauthenticated senders. Since the vast majority of senders are unauthenticated, this would break Internet mail interoperability. The exception to this is when the endpoint server should only be receiving mail from some other server which can itself receive unauthenticated messages. For instance, a company might operate a public gateway but configure its internal servers to only talk to the gateway.
現実的には、SMTPエンドポイントは、認証されていない送信者へのサービスを拒否することを拒否できません。大多数の送信者が認証されていないため、これはインターネットメールの相互運用性を破るでしょう。これに対する例外は、エンドポイントサーバーが他のいくつかのサーバーからのメールを受信している場合、それ自体が認証されていないメッセージを受信できる場合です。たとえば、会社はパブリックゲートウェイを操作することができますが、ゲートウェイと通信するだけで内部サーバーを構成します。
SMTP itself provides no communications security, and therefore a large number of attacks are possible. A passive attack is sufficient to recover the text of messages transmitted with SMTP. No endpoint authentication is provided by the protocol. Sender spoofing is trivial, and therefore forging email messages is trivial. Some implementations do add header lines with hostnames derived through reverse name resolution (which is only secure to the extent that it is difficult to spoof DNS -- not very), although these header lines are normally not displayed to users. Receiver spoofing is also fairly straight-forward, either using TCP connection hijacking or DNS spoofing. Moreover, since email messages often pass through SMTP gateways, all intermediate gateways must be trusted, a condition nearly impossible on the global Internet.
SMTP自体は通信セキュリティを提供しないため、多数の攻撃が可能です。パッシブ攻撃は、SMTPで送信されたメッセージのテキストを回復するのに十分です。プロトコルによってエンドポイント認証は提供されていません。送信者のなりすましは簡単で、したがって鍛造メールメッセージは簡単です。一部の実装では、これらのヘッダー行は通常ユーザーに表示されませんが、リバース名解決を通じて派生したホスト名でヘッダー行を追加します。これは、これらのヘッダー行は通常ユーザーに表示されませんが、これはDNS - を偽装するのが困難です。受信機のなりすましは、TCP接続ハイジャックまたはDNSスプーフィングを使用して、かなり簡単です。さらに、電子メールメッセージはしばしばSMTPゲートウェイを通過するので、すべての中間ゲートウェイを信頼する必要があります。これは、グローバルインターネット上でほぼ不可能です。
Several approaches are available for alleviating these threats. In order of increasingly high level in the protocol stack, we have:
これらの脅威を軽減するためのいくつかのアプローチがあります。プロトコルスタックでますます高レベルの順に、次のとおりです。
SMTP over IPSEC SMTP/TLS S/MIME and PGP/MIME
SMTP over IPsec SMTP / TLS S / MIMEおよびPGP / MIME
An SMTP connection run over IPSEC can provide confidentiality for the message between the sender and the first hop SMTP gateway, or between any pair of connected SMTP gateways. That is to say, it provides channel security for the SMTP connections. In a situation where the message goes directly from the client to the receiver's gateway, this may provide substantial security (though the receiver must still trust the gateway). Protection is provided against replay attacks, since the data itself is protected and the packets cannot be replayed.
SMTP接続がIPSECを介して実行されると、送信者と最初のホップSMTPゲートウェイとの間のメッセージの機密性を提供することができます。つまり、SMTP接続のチャネルセキュリティを提供します。メッセージがクライアントから受信機のゲートウェイに直接アクセスできる状況では、これは実質的なセキュリティを提供する可能性があります（受信者はまだゲートウェイを信頼する必要があります）。データ自体が保護されており、パケットを再生することができないため、再生攻撃に対して保護が提供されます。
Endpoint identification is a problem, however, unless the receiver's address can be directly cryptographically authenticated. Sender identification is not generally available, since generally only the sender's machine is authenticated, not the sender himself. Furthermore, the identity of the sender simply appears in the From header of the message, so it is easily spoofable by the sender. Finally, unless the security policy is set extremely strictly, there is also an active downgrade to cleartext attack.
ただし、受信側のアドレスを直接暗号化認証できる場合を除き、エンドポイント識別は問題です。送信者の識別は一般的に利用可能ではありません。一般的に送信者のマシンだけが認証されているので、送信者自身ではありません。さらに、送信者の識別情報はメッセージのFromヘッダーに表示されるため、送信者によって簡単になりやすいです。最後に、セキュリティポリシーが非常に厳密に設定されていない限り、クリアテキスト攻撃へのアクティブなダウングレードもあります。
Another problem with IPsec as a security solution for SMTP is the lack of a standard IPsec API. In order to take advantage of IPsec, applications in general need to be able to instruct the IPsec implementation about their security policies and discover what protection has been applied to their connections. Without a standard API this is very difficult to do portably.
SMTPのセキュリティソリューションとしてのIPsecに関するもう1つの問題は、標準のIPsec APIの欠如です。IPSecを利用するために、一般に、アプリケーションはセキュリティポリシーについてIPSec実装に指示し、それらの接続にどのような保護が適用されたかを発見する必要があります。標準的なAPIなしでは、これは携帯用に非常に困難です。
Implementors of SMTP servers or SMTP administrators MUST NOT assume that IPsec will be available unless they have reason to believe that it will be (such as the existence of preexisting association between two machines). However, it may be a reasonable procedure to attempt to create an IPsec association opportunistically to a peer server when mail is delivered. Note that in cases where IPsec is used to provide a VPN tunnel between two sites, this is of substantial security value, particularly to the extent that confidentiality is provided, subject to the caveats mentioned above. Also see [USEIPSEC] for general guidance on the applicability of IPsec.
SMTPサーバーまたはSMTP管理者の実装者は、IPSecがそれがあると信じる理由がない限り、（2台のマシン間の既存の関連付けの存在など）をないと仮定してはいけません。ただし、メールが配信されたときにPeer Serverに機会的にIPSec関連の協会を作成しようとする妥当な手順である可能性があります。IPSecが2つのサイト間にVPNトンネルを提供するために使用される場合、これは上記の警告の対象となる、特に機密性が提供される範囲内である。IPsecの適用性に関する一般的なガイダンスのための[都合の使用]を参照してください。
SMTP can be combined with TLS as described in [STARTTLS]. This provides similar protection to that provided when using IPSEC. Since TLS certificates typically contain the server's host name, recipient authentication may be slightly more obvious, but is still susceptible to DNS spoofing attacks. Notably, common implementations of TLS contain a US exportable (and hence low security) mode. Applications desiring high security should ensure that this mode is disabled. Protection is provided against replay attacks, since the data itself is protected and the packets cannot be replayed. [Note: The Security Considerations section of the SMTP over TLS document is quite good and bears reading as an example of how to do things.]
[STARTTLS]に記載されているように、SMTPをTLSと組み合わせることができます。これは、IPsecを使用するときに提供されるものと同様の保護を提供します。TLS証明書には通常、サーバーのホスト名が含まれているため、受信者認証はわずかに明白な場合がありますが、それでもDNSスプーフィング攻撃の影響を受けやすいです。特に、TLSの一般的な実装には、米国のエクスポート可能な（したがって低セキュリティ）モードが含まれています。高いセキュリティを希望するアプリケーションは、このモードが無効になっていることを確認する必要があります。データ自体が保護されており、パケットを再生することができないため、再生攻撃に対して保護が提供されます。[注：TLS文書を介したSMTPのセキュリティに関する考慮事項のセクションは、物事の実行方法の一例として読んで読むことです。]
S/MIME and PGP/MIME are both message oriented security protocols. They provide object security for individual messages. With various settings, sender and recipient authentication and confidentiality may be provided. More importantly, the identification is not of the sending and receiving machines, but rather of the sender and recipient themselves. (Or, at least, of cryptographic keys corresponding to the sender and recipient.) Consequently, end-to-end security may be obtained. Note, however, that no protection is provided against replay attacks. Note also that S/MIME and PGP/MIME generally provide identifying marks for both sender and receiver. Thus even when confidentiality is provided, traffic analysis is still possible.
S / MIMEおよびPGP / MIMEはどちらもメッセージ指向のセキュリティプロトコルです。それらは個々のメッセージのためのオブジェクトセキュリティを提供します。さまざまな設定で、送信者と受信者の認証と機密性を提供することができます。さらに重要なことに、識別は送受信機械ではなく、むしろ送信者と受信者自体のものではありません。その結果、エンドツーエンドセキュリティを得ることができる。ただし、リプレイ攻撃に対して保護されていないことに注意してください。また、S / MIMEおよびPGP / MIMEは一般に、送信者と受信者の両方の識別マークを提供することにも注意してください。したがって、機密性が提供されている場合でも、交通分析は依然として可能です。
None of these security measures provides any real protection against denial of service. SMTP connections can easily be used to tie up system resources in a number of ways, including excessive port consumption, excessive disk usage (email is typically delivered to disk files), and excessive memory consumption (sendmail, for instance, is fairly large, and typically forks a new process to deal with each message.)
これらのセキュリティ対策のどれも、サービス拒否に対する本当の保護を提供しません。SMTP接続を使用して、過度のポート消費量、過度のディスク使用量（電子メールが通常ディスクファイルに配信されている）、過度のメモリ消費量（例えば、Sendmailがかなり大きく、かなり大きく、かなり大きい）を簡単に使用できます。通常、各メッセージに対処するための新しいプロセスをフォークします。）
If transport- or application-layer security is used for SMTP connections, it is possible to mount a variety of attacks on individual connections using forged RSTs or other kinds of packet injection.
トランスポートまたはアプリケーション層のセキュリティがSMTP接続に使用されている場合は、鍛造RSTまたはその他の種類のパケット注入を使用して、さまざまな接続にさまざまな攻撃をマウントすることが可能です。
The second example is from VRRP, the Virtual Router Redundance Protocol ([VRRP]). We reproduce here the Security Considerations section from that document (with new section numbers). Our comments are indented and prefaced with 'NOTE:'.
2番目の例は、VRRP、仮想ルータ冗長プロトコル（[VRRP]）からのものです。ここでは、その文書からセキュリティ上の考慮事項セクションを再現しています（新しいセクション番号付き）。私たちのコメントはインデントされており、「注意：」の前に
VRRP is designed for a range of internetworking environments that may employ different security policies. The protocol includes several authentication methods ranging from no authentication, simple clear text passwords, and strong authentication using IP Authentication with MD5 HMAC. The details on each approach including possible attacks and recommended environments follows.
VRRPは、さまざまなセキュリティポリシーを使用する可能性があるさまざまなインターネットワーキング環境用に設計されています。このプロトコルには、認証なし、単純なクリアテキストパスワード、およびMD5 HMACでIP認証を使用した強力な認証の範囲のいくつかの認証方法が含まれています。可能な攻撃や推奨環境を含む各アプローチの詳細は続きます。
Independent of any authentication type VRRP includes a mechanism (setting TTL=255, checking on receipt) that protects against VRRP packets being injected from another remote network. This limits most vulnerabilities to local attacks.
認証タイプVRRPとは無関係に、別のリモートネットワークから挿入されているVRRPパケットから保護するメカニズム（TTL = 255、受信時の確認）が含まれています。これにより、地元の攻撃に対するほとんどの脆弱性が制限されています。
NOTE: The security measures discussed in the following sections only provide various kinds of authentication. No confidentiality is provided at all. This should be explicitly described as outside the scope.
注：次のセクションで説明したセキュリティ対策は、さまざまな認証のみを提供します。機密性はまったく提供されていません。これは範囲外のものとして明示的に説明する必要があります。
The use of this authentication type means that VRRP protocol exchanges are not authenticated. This type of authentication SHOULD only be used in environments were there is minimal security risk and little chance for configuration errors (e.g., two VRRP routers on a LAN).
この認証タイプの使用は、VRRPプロトコルの交換が認証されていないことを意味します。このタイプの認証は環境でのみ使用されるべきであるため、最小限のセキュリティリスクがあり、設定エラー（例えば、LAN上の2つのVRRPルータ）が最小限に抑えられています。
The use of this authentication type means that VRRP protocol exchanges are authenticated by a simple clear text password.
この認証タイプの使用は、VRRPプロトコル交換が単純なクリアテキストパスワードによって認証されることを意味します。
This type of authentication is useful to protect against accidental misconfiguration of routers on a LAN. It protects against routers inadvertently backing up another router. A new router must first be configured with the correct password before it can run VRRP with another router. This type of authentication does not protect against hostile attacks where the password can be learned by a node snooping VRRP packets on the LAN. The Simple Text Authentication combined with the TTL check makes it difficult for a VRRP packet to be sent from another LAN to disrupt VRRP operation.
このタイプの認証は、LAN上のルータの偶発的な誤構成から保護するのに役立ちます。誤って別のルータをバックアップしているルータから保護します。最初に新しいルータを他のルータでVRRPを実行する前に正しいパスワードで設定する必要があります。このタイプの認証は、パスワードがLAN上のvRRPパケットをスヌーピングするノードによって学習できる敵対的な攻撃に対しては保護されません。TTLチェックと組み合わされた単純なテキスト認証は、VRRPの操作を中断するためにVRRPパケットが他のLANから送信されることを困難にする。
This type of authentication is RECOMMENDED when there is minimal risk of nodes on a LAN actively disrupting VRRP operation. If this type of authentication is used the user should be aware that this clear text password is sent frequently, and therefore should not be the same as any security significant password.
LAN上のノードのリスクが最小限の場合、VRRP操作を復調すると、このタイプの認証が推奨されます。このタイプの認証が使用されている場合、ユーザーはこのクリアテキストパスワードが頻繁に送信されることを認識する必要があります。したがって、セキュリティの重要なパスワードと同じであるべきではありません。
NOTE: This section should be clearer. The basic point is that no authentication and Simple Text are only useful for a very limited threat model, namely that none of the nodes on the local LAN are hostile. The TTL check prevents hostile nodes off-LAN from posing as valid nodes, but nothing stops hostile nodes on-LAN from impersonating authorized nodes. This is not a particularly realistic threat model in many situations. In particular, it's extremely brittle: the compromise of any node the LAN allows reconfiguration of the VRRP nodes.
注：このセクションはより明確になるはずです。基本的な点は、認証と単純なテキストが非常に限られた脅威モデルにのみ有用であり、すなわち、ローカルLAN上のノードは敵対的なものではないことです。TTLチェックは、Off-LANが有効なノードとしてポーズをとるのを防ぎますが、許可されたノードの偽装されたノードから敵対的なノードをオンラインで停止するものはありません。これは多くの状況で特に現実的な脅威モデルではありません。特に、それは非常に脆弱です.LANがVRRPノードの再構成を許可することを可能にします。
The use of this authentication type means the VRRP protocol exchanges are authenticated using the mechanisms defined by the IP Authentication Header [AH] using [HMAC]. This provides strong protection against configuration errors, replay attacks, and packet corruption/modification.
この認証タイプの使用は、[HMAC]を使用してIP認証ヘッダー[AH]で定義されたメカニズムを使用してVRRPプロトコルの交換が認証されています。これにより、構成エラー、リプレイ攻撃、およびパケットの破損/修正に対する強力な保護があります。
This type of authentication is RECOMMENDED when there is limited control over the administration of nodes on a LAN. While this type of authentication does protect the operation of VRRP, there are other types of attacks that may be employed on shared media links (e.g., generation of bogus ARP replies) which are independent from VRRP and are not protected.
このタイプの認証は、LAN上のノードの管理を制限されている場合に推奨されます。この種の認証はVRRPの動作を保護しているが、VRRPから独立しており、保護されていない共有メディアリンク（例えば、Bogus ARP応答の生成）に採用され得る他の種類の攻撃がある。
NOTE: It's a mistake to have AH be a RECOMMENDED in this context. Since AH is the only mechanism that protects VRRP against attack from other nodes on the same LAN, it should be a MUST for cases where there are untrusted nodes on the same network. In any case, AH should be a MUST implement.
注：これは、このコンテキストで推奨されるAHを持っているのは間違いです。AHは、同じLAN上の他のノードからの攻撃に対してVRRPを保護する唯一のメカニズムであるため、同じネットワーク上に信頼できないノードがある場合は必須です。いずれにせよ、ああが実装が必要です。
NOTE: There's an important piece of security analysis that's only hinted at in this document, namely the cost/benefit tradeoff of VRRP authentication.
注意：この文書でのみヒントされているのは、VRRP認証の費用/給付のトレードオフでのみヒントされている重要なセキュリティ分析があります。
[The rest of this section is NEW material] The threat that VRRP authentication is intended to prevent is an attacker arranging to be the VRRP master. This would be done by joining the group (probably multiple times), gagging the master and then electing oneself master. Such a node could then direct traffic in arbitrary undesirable ways.
[このセクションの残りの部分は新しい素材です] VRRP認証を防止することを目的とした脅威は、攻撃者がVRRPマスターになるように配置されています。これは、グループ（おそらく複数回）に参加し、マスターを悩ませてから自分自身を選出することによって行われます。そのようなノードは、任意の望ましくない方法でトラフィックを直接直接直接化することができます。
However, it is not necessary for an attacker to be the VRRP master to do this. An attacker can do similar kinds of damage to the network by forging ARP packets or (on switched networks) fooling the switch VRRP authentication offers no real protection against these attacks.
ただし、攻撃者がこれを行うためにVRRPマスターになる必要はありません。攻撃者は、ARPパケットを鍛造することによってネットワークに類似の種類の損傷を与えることができます（（スイッチドネットワーク上）、スイッチVRRP認証はこれらの攻撃に対して実際の保護はありません。
Unfortunately, authentication makes VRRP networks very brittle in the face of misconfiguration. Consider what happens if two nodes are configured with different passwords. Each will reject messages from the other and therefore both will attempt to be master. This creates substantial network instability.
残念ながら、認証は、誤構成に直面してVRRPネットワークを非常に脆くします。2つのノードがさまざまなパスワードで構成されている場合はどうなるかを検討してください。それぞれが他のものからメッセージを拒否しますので、両方ともマスターになります。これにより、実質的なネットワーク不安定性が生まれます。
This set of cost/benefit tradeoffs suggests that VRRP authentication is a bad idea, since the incremental security benefit is marginal but the incremental risk is high. This judgment should be revisited if the current set of non-VRRP threats are removed.
この一連の費用/給付のトレードオフは、増分セキュリティの利点が限界であるが、増分リスクが高いため、VRRP認証が悪い考えであることを示唆している。現在の非VRRP脅威のセットが削除されている場合、この判断は再検討されるべきです。
This document is heavily based on a note written by Ran Atkinson in 1997. That note was written after the IAB Security Workshop held in early 1997, based on input from everyone at that workshop. Some of the specific text above was taken from Ran's original document, and some of that text was taken from an email message written by Fred Baker. The other primary source for this document is specific comments received from Steve Bellovin. Early review of this document was done by Lisa Dusseault and Mark Schertler. Other useful comments were received from Bill Fenner, Ned Freed, Lawrence Greenfield, Steve Kent, Allison Mankin and Kurt Zeilenga.
この文書は1997年にRAN Atkinsonによって書かれたメモに大きく基づいています。上記の特定のテキストのいくつかはRANのオリジナルの文書から取られ、そのテキストの一部はFred Bakerによって書かれた電子メールメッセージから取得されました。この文書の他の主なソースはSteve Bellovinから受信された特定のコメントです。この文書の初期レビューは、Lisa DusseAllとMark Scherlerによって行われました。その他の有用なコメントは、Bill Fenner、Ned Freed、Lawrence Greenfield、Steve Kent、Allison MankinとKurt Zeilengaから受信されました。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[ああ]ケント、S.およびR. Atkinson、「IP認証ヘッダー」、RFC 2402、1998年11月。
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[DNSSEC]イーストレイク、D.、「ドメインネームシステムセキュリティ拡張」、RFC 2535、1999年3月。
[ENCOPT] Tso, T., "Telnet Data Encryption Option", RFC 2946, September, 2000.
[ENCOPT] TSO、T.、「Telnetデータ暗号化オプション」、RFC 2946、2000年9月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]ケント、S.およびR.Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[GSS] Linn, J., "Generic Security Services Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[GSS] Linn、J.、「Generic Security Services Application Program Interface 2、Update 1」、RFC 2743、2000年1月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "HyperText Transfer Protocol", RFC 2616, June 1999.
[HTTP]フィールド化、R.、GetTys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、L.、Leach、P.およびT.Berners-Lee、「Hypertext Transfer Protocol」、RFC 2616、6月1999年6月。
[HTTPTLS] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
[HTTPTLS] Rescorla、E.、「HTTP over TLS」、RFC 2818、2000年5月。
[HMAC] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[HMAC] Madson、C.およびR.Glenn、「ESPおよびああ内にあるHMAC-MD5-96の使用」、1998年11月、RFC 2403。
KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
Kerberos] Kohl、J.およびC.Neuman、「Kerberos Network認証サービス（V5）」、RFC 1510、1993年9月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S.、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[OTP] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time Password System", STD 61, RFC 2289, February 1998.
[OTP] Haller、N.、Metz、C.、Nesser、P.およびM.ストロー、「ワンタイムパスワードシステム」、STD 61、RFC 2289、1998年2月。
[PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[PHOTURIS] KARN、P.およびW.Simpson、「PHOTURIS：Session-Key Management Protocol」、RFC 2522、1999年3月。
[PKIX] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 "Public Key Infrastructure Certificate and Certificate Restoration List (CRL) Profile", RFC 3280, April 2002.
[PKIX]ハウスリー、R.、Polk、W.、Ford、W.およびD. Solo、「インターネットX.509」2002年4月、RFC 3280。
[RFC-2223] Postel J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC-2223] Postel J.およびJ.レイノルズ、「RFC著者への指示」、RFC 2223、1997年10月。
[RFC-2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.
[RFC-2505] Lindberg、G.、「SMTP MTAのスパム防止推奨」、BCP 30、RFC 2505、1999年2月。
[RFC-2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC-2821]クレンシン、J。、「シンプルメール転送プロトコル」、RFC 2821、2001年4月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]マイヤーズ、J.、「単純認証とセキュリティ層（SASL）」、RFC 2222、1997年10月。
[SPKI] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999.
[Spki]エリソン、C.、Frantz、B.、Luppson、B.、R.、Thomas、B.およびT.Yローネン、「Spki Certificate Theory」、RFC 2693、1999年9月。
[SSH] Ylonen, T., "SSH - Secure Login Connections Over the Internet", 6th USENIX Security Symposium, p. 37-42, July 1996.
[SSH] Ylonen、T.、インターネット上の「SSH - 安全なログイン接続」、6番目のUsenix Security Symposium、p。1996年7月37-42頁。
[SASLSMTP] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SASLSMTP]マイヤーズ、J.、「認証用SMTPサービス拡張」、RFC 2554、1999年3月。
[STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[STARTTLS] HOFFMAN、P.、SMTP SMTPのSMTP SMTPのSMTP SMTPのSMTP SMTP SMTP SECATION用のSMTPサービス拡張機能。
[S-HTTP] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999.
[S-HTTP] Rescorla、E.およびA.Schiffman、「Secure Hypertext Transfer Protocol」、RFC 2660、1999年8月。
[S/MIME] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[S / MIME] Ramsdell、B、Editor、「S / MIMEバージョン3メッセージ仕様」、RFC 2633、1999年6月。
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[Telnet] Postel、J.およびJ. Reynolds、 "Telnet Protocol Specification"、STD 8、RFC 854、1983年5月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T.およびC. Allen、 "Thels Protocol Version 1.0"、RFC 2246、1999年1月。
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D. and J. Mikkelsen, "Transport Layer Security (TLS) Extensions", RFC 3546, May 2003.
[TLSEXT] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.およびJ.Mikkelsen、「トランスポート層セキュリティ（TLS）拡張」、RFC 3546、2003年5月。
[TCPSYN] "TCP SYN Flooding and IP Spoofing Attacks", CERT Advisory
CA-1996-21, 19 September 1996, CERT.
http://www.cert.org/advisories/CA-1996-21.html
[UPGRADE] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[アップグレード] Khare、R.およびS. Lawrence、「HTTP / 1.1内のTLSへのアップグレード」、RFC 2817、2000年5月。
[URL] Berners-Lee, T., Masinter, M. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL] Berners-Lee、T.、M. M.M.Mccahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[VRRP] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., Hunt, P., Higginson, P., Shand, M. and A. Lindemn, "Virtual Router Redundancy Protocol", RFC 2338, April 1998.
[VRRP]ナイト、S.、Weaver、D.、Whipple、D.、Hinden、R.、Mitzel、D.、Hunt、P.、Higginson、P.、Shand、M.およびA. Lindeng冗長性プロトコル「RFC 2338、1998年4月。
[DDOS] "Denial-Of-Service Tools" CERT Advisory CA-1999-17, 28
December 1999, CERT http://www.cert.org/advisories/CA-
1999-17.html
[EKE] Bellovin, S., Merritt, M., "Encrypted Key Exchange: Password-based protocols secure against dictionary attacks", Proceedings of the IEEE Symposium on Research in Security and Privacy, May 1992.
[EKE] Bellovin、S.、Merritt、M.、「辞書攻撃に対して安全なパスワードベースのプロトコル」、セキュリティとプライバシーの研究に関するIEEEシンポジウムの議事録1992年5月。
[IDENT] St. Johns, M. and M. Rose, "Identification Protocol", RFC 1414, February 1993.
[IDENT] St. Johns、M.およびM. Rose、1993年2月、RFC 1414。
[INTAUTH] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[INTAUTH] Haller、N.およびR. Atkinson、「インターネット認証について」、RFC 1704、1994年10月。
[IPSPPROB] Bellovin, S. M., "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix UNIX Security Symposium, July 1996.
[IPSPPROB] Bellovin、S.M.「IPセキュリティプロトコルの問題分野」、第6回USENIX UNIXセキュリティシンポジウム（1996年7月6日）の議事録。
[KLEIN] Klein, D.V., "Foiling the Cracker: A Survey of and Improvements to Password Security", 1990.
[Klein] Klein、D.V.「クラッカーをフォイルリングする：パスワードセキュリティの調査と改善」、1990年。
[NNTP] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[NNTP] Kantor、B.およびP. Lapsley、「ネットワークニュース転送プロトコル」、RFC 977、1986年2月。
[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[ポップ]マイヤーズ、J.およびM.ローズ、「郵便局プロトコル - バージョン3」、STD 53、RFC 1939、1996年5月。
[SEQNUM] Morris, R.T., "A Weakness in the 4.2 BSD UNIX TCP/IP Software", AT&T Bell Laboratories, CSTR 117, 1985.
[Seqnum] Morris、R.T.「4.2 BSD UNIX TCP / IPソフトウェアの弱点」、AT＆T Bell Laboratories、CSTR 117,1985。
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsoh, N., Nielsen, H., Thatte, S., Winer, D., "Simple Object Access Protocol (SOAP) 1.1", May 2000.
[SOAP]ボックス、D.、Ehnebuske、D.、Kakivaya、G.、Layman、A.、Mendelsoh、N.、Nielsen、H.、Totte、S.、Winer、D.、「Simple Object Access Protocol（SOAP）1.1 "、2000年5月。
[SPEKE] Jablon, D., "Strong Password-Only Authenticated Key Exchange", Computer Communication Review, ACM SIGCOMM, vol. 26, no. 5, pp. 5-26, October 1996.
[Speke] Jablon、D.、「強力なパスワード専用キー交換」、コンピュータ通信レビュー、ACM SIGCOMM、VOL。26、いいえ。5、pp.5-26、1996年10月。
[SRP] Wu T., "The Secure Remote Password Protocol", ISOC NDSS Symposium, 1998.
[SRP] WU T.、「安全なリモートパスワードプロトコル」、ISOC NDSSシンポジウム、1998。
[USEIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", Work in Progress.
[usipsec] Bellovin、S。、「IPsecの使用を義務付けるためのガイドライン」、進行中の作業。
[WEP] Borisov, N., Goldberg, I., Wagner, D., "Intercepting
Mobile Communications: The Insecurity of 802.11",
http://www.isaac.cs.berkeley.edu/isaac/wep-draft.pdf
This entire document is about security considerations.
この文書全体はセキュリティ上の考慮事項についてです。
Appendix A.
付録A.
IAB Members at the time of this writing
この書き方のIABメンバー
Harald Alvestrand Ran Atkinson Rob Austein Fred Baker Leslie Daigle Steve Deering Sally Floyd Ted Hardie Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Mike St. Johns
Harald Alvestrand Ran Atkinson Rob Austein Fred Baker Leslie Daigle Steve Ted Sally Floyd Ted Hardie Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Mike St. Johns
Authors' Addresses
著者の住所
Eric Rescorla RTFM, Inc. 2439 Alvin Drive Mountain View, CA 94043
Eric Rescorla RTFM、Inc。2439 Alvin Drive Mountain View、CA 94043
Phone: (650)-320-8549 EMail: ekr@rtfm.com
電話：（650）-320-8549 Eメール：ekr@rtfm.com
Brian Korver Xythos Software, Inc. 77 Maiden Lane, 6th Floor San Francisco, CA, 94108
Brian Korver Xythos Software、Inc。77乙女レーン、6階サンフランシスコ、CA、94108
Phone: (415)-248-3800 EMail: briank@xythos.com
電話：（415）-248-3800 Eメール：briank@xythos.com
Internet Architecture Board IAB EMail: iab@iab.org
インターネットアーキテクチャボードiabメール：iab@iab.org
Full Copyright Statement
完全著作権宣言
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 assigns.
上記の限られた権限は永続的であり、インターネット社会やその後継者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本明細書に含まれる情報は、「現状」ベースで提供されており、インターネット社会とインターネットエンジニアリングのタスクフォースは、本明細書の情報の使用が含まれないことを含むが、これに限定されない、またはこれに限定されないすべての保証を損なう。特定の目的のための商品性または適合性の権利または黙示的な保証を侵害する。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディタ機能のための資金は、現在インターネット社会によって提供されています。