[要約] RFC 3552は、RFCの「セキュリティに関する考慮事項」節の作成方針を示すBCP 72です。脅威モデル、通信とシステムのセキュリティ目標、代表的な攻撃や対策を説明し、プロトコルの脅威と残留リスクを明確に記述するための指針を示します。
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 におけるセキュリティ検討事項 (Security Considerations) 記述のためのガイドライン
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 2223では、すべてのRFCに「セキュリティに関する考慮事項」節を含めることが求められています。これは、文書の著者に設計時のセキュリティ検討を促すとともに、読者に関連するセキュリティ上の問題を知らせるためです。本メモは、この両方の目的に役立つ指針を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].
この文書で使われている「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は、BCP 14およびRFC 2119 [KEYWORDS]の記述に従って解釈します。
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番目の性質はピアエンティティ認証です。これは、通信の両端のうち一方が、意図した相手であると確認できることを指します。ピアエンティティ認証がなければ、機密性やデータ完全性を実現するのは非常に困難です。たとえば、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.
ピアエンティティ認証は、非対称に実現できる点に注意してください。電話で相手にかけると、正しい相手、少なくとも自分が電話をかけた番号の電話に実際に出た人と話していると、かなり確信できます。一方、相手が発信者番号通知を使っていなければ、電話を受けた側には誰からの電話か分かりません。電話をかけることは受信者認証の例です。発信者は通話相手が誰か分かりますが、相手は発信者について何も分からないためです。
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.
エンドポイント認証を提供するシステムにより、一方の当事者は自身が通信している相手の身元を確信できるようになります。システムがデータの完全性（インテグリティ）を提供する場合、受信者は送信者の身元と、送信者が送ろうとしたデータをそのまま受信していることの両方を確認できます。しかし、受信者は必ずしもこの事実を第三者に証明できるとは限りません。この証明を行う能力を「否認防止（NON-REPUDIATION）」と呼びます。
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者の当事者が契約に署名し、そのうちの一方の当事者がそれを一方的に破棄したいと望んでいる状況を考えてみてください。その当事者は、そもそも署名などしていないと単に主張するかもしれません。否認防止はそうした主張を防ぎ、それによって相手方（取引当事者: counterparty）を保護します。
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.
インターネット環境で想定する脅威モデルは、かなりよく理解されています。一般に、プロトコル通信に参加するエンドシステム自体は侵害されていないと仮定します。エンドシステムの一方が侵害された場合の攻撃から守るのは非常に困難です。ただし、そのような状況で生じる被害を最小限に抑えるプロトコルを設計することは可能です。
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（Protocol Data Unit）を読み取り、検知されないままパケットを削除、変更、または偽造して通信路に挿入できます。信頼できる機器から送られたように見えるパケットを生成することもできます。したがって、通信相手のエンドシステム自体が安全でも、インターネット環境では、そのシステムから来たと主張するパケットが実際にそこから送信されたという保証はありません。
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に接続することです。Ethernet、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台の間の通信経路上にあるホストを制御できる攻撃者は、その通信に対して受動攻撃を実行できます。ルーティング基盤を侵害し、トラフィックが侵害された機器を通るように仕向けることもできます。そのために、被害者の通信を盗聴する準備としてルーティング基盤への能動攻撃を行う場合もあります。
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が広く普及し、利用も増えています。データは既知の無線周波数でそのままブロードキャストされるため、攻撃者は送信を受信できれば足ります。このようなチャネルは受動攻撃に特に弱いものです。暗号による保護を備えるチャネルも多くありますが、その品質が非常に低く、ほとんど役に立たないこともよくあります [WEP]。
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.
受動攻撃の別の例は、パスワード盗聴です。これは、リソースの不正利用に必要な情報を得ることを目的とします。[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.
従来は、能動攻撃によってOSの小さなセキュリティホールを悪用し、パスワードファイルを取得することも可能でした。その後、前述のオフラインパスワード解析技術を使って、その穴を実際のアカウントへの侵入に発展させることができます。このように、低レベルの能動攻撃とオフラインの受動攻撃を組み合わせます。
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.
すべての能動攻撃で送信元アドレスの偽造が必要なわけではありません。たとえば、TCP SYNによるサービス拒否攻撃 [TCPSYN] は、送信者のアドレスを隠さなくても成功します。ただし、攻撃が発覚した場合に身元を隠すため、アドレスを偽装するのが一般的です。
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回実行させたいと考えるかもしれません。メッセージを読めなくても、記録して再送すれば取引を二重に実行させられます。
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スタック実装では、この「ハーフオープン」状態の接続数に上限があります。上限に達すると、正当なホストからも新たな接続を開始できなくなります。攻撃者は被害者からのSYNを処理する必要がないため、これはブラインド攻撃です。
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なりすましを使えば、ローカルネットワーク上で中間者攻撃を仕掛けるのも容易です。攻撃者は被害者のIPアドレスを使った偽のARPメッセージを、自分のMACアドレスとともに送信します。この種の攻撃に使えるツールは広く入手できます。
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).
中間者攻撃を防ぐには、取引の一方だけを認証すればよい場合がある点に注意してください。その場合、ピアの一方だけを認証した状態で、双方が関連付けを確立できます。このようなシステムでは、攻撃者は未認証のピアになりすまして関連付けを開始できますが、正規の接続で送信されているデータを送信したり、アクセスしたりすることはできません。サーバーだけを認証すればよい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.
経路外のホストは、任意のホストから来たように見せかけたデータグラムを送信できますが、他のホスト宛てのデータグラムを受信できるとは限りません。攻撃にデータ受信が必要なら、経路外の攻撃者はまずネットワークのトポロジーを不正に変え、自分を通信経路上に置く必要があります。これは決して不可能ではありませんが、簡単とも限りません。
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.
アプリケーションプロトコルの設計者は、すべての攻撃者が経路外にいると仮定してはなりません (MUST NOT)。可能であれば、ネットワークを完全に制御する攻撃者にも耐えられるようにプロトコルを設計すべきです (SHOULD)。ただし、設計者は、経路外の攻撃者だけでなく経路上の攻撃者も実行できる攻撃を、より重視することが期待されます。
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.
経路上にいる場合の特殊な例として、同じリンク上にいる場合があります。ローカルネットワーク上のホストと、それ以外のホストを区別したい状況があります。そのための標準的な手法は、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.
ユーザー名とパスワードより高い安全性を求めるシステムでは、ワンタイムパスワード [OTP] またはチャレンジレスポンス方式がよく使われます。ワンタイムパスワード方式では、ユーザーは順番に一度ずつ使うパスワードの一覧を受け取ります（多くの場合、パスワードは秘密鍵から生成されるため、ユーザーは次のパスワードを計算できます）。SecureIDやDES Goldはこの方式の派生です。チャレンジレスポンス方式では、ホストとユーザーが秘密情報（多くの場合、パスワードとして表されます）を共有します。ユーザーを認証するため、ホストはランダムに生成したチャレンジを提示します。ユーザーはチャレンジと秘密情報に基づく計算を行い、その結果をホストに返します。ホストはその結果を検証します。この計算は、DES Goldカードなどの携帯型機器で行われることがよくあります。
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.
どちらの方式もリプレイ攻撃を防ぎますが、オフライン鍵探索攻撃（受動攻撃の一種）には依然として弱いことがあります。前述のとおり、ワンタイムパスワードや応答は共有シークレットから計算されることがよくあります。攻撃者が使われている計算方法を知っていれば、正しい結果が得られる共有シークレットが見つかるまで、考えられる秘密をすべて試せます。共有シークレットがパスワードの場合は、ランダムな文字列を試す代わりに一般的な単語や文字列の一覧を試す辞書攻撃が可能となり、さらに容易になります。
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.
これらの方式も能動攻撃に弱いことがあります。セッション全体が通信セキュリティで保護されていなければ、攻撃者は認証が完了するまで待ち、その後で接続を乗っ取れます。
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].
多数の鍵が必要になる問題を解決する方法の一つは、認証する当事者間を仲介するオンラインの「信頼できる第三者」を使うことです。通常、鍵配布センター（KDC）と呼ばれるこの第三者は、システム内の各当事者と対称鍵またはパスワードを共有します。ある当事者が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.
単純な方法は、すべてのユーザーに証明書 [PKIX] を持たせ、[TLS]や[S/MIME]のようにプロトコル固有の方法で認証に使うことです。証明書は、主体の身元と公開鍵を結び付ける署名付きの資格情報です。証明書の署名者は認証局（CA）であり、その証明書自体が上位のCAによって署名されている場合もあります。この方式を機能させるには、1つ以上のCAを帯域外の方法で信頼する必要があります。このようなCAを信頼されたルート、またはルートCAと呼びます。クライアント・サーバー方式でこの方法を導入する際の主な障害は、クライアントにも証明書が必要となり、配備が難しくなることです。
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 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.
前述の方式より優れた方法もありますが、接続を保護する通信セキュリティ（少なくともメッセージ完全性）がなければ、認証後に攻撃者が接続を乗っ取れるため、通常は安全性があまり向上しません。[EKE]、[SPEKE]、[SRP]などのプロトコルでは、ユーザーのパスワードから、暗号プロトコルへの入力に使える共有鍵を安全に生成できます。これらのプロトコルの導入における大きな障害の一つは、知的財産権の状況が極めて不明確なことです。同様に、ユーザーは公開鍵証明書（例：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ホスト名で示されることがよくあります。そのサービスを要求するときは、通信相手が証明書を持つことだけでなく、その証明書が期待するサーバーの身元に対応していることも確認する必要があります。証明書と期待するホスト名を安全に結び付けることが重要です。
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アドレスである場合、通常は受け入れられません。セキュアな名前解決 [DNSSEC] を使わない限り、ホスト名と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].
プロトコルにセキュリティ機能を組み込むのは難しい場合があります。認証方式や鍵確立方式を選ぶだけでなく、それらをプロトコルに統合する必要があるためです。IPsecやTLSが採用する方法の一つは、下位層のセキュリティプロトコルを作り、新しいプロトコルをその上で動作させることです。近年普及している別の方法は、汎用のアプリケーション層セキュリティフレームワークを設計することです。これは、交換可能な形で複数のセキュリティ方式をネゴシエートできるプロトコルを設計する方法です。アプリケーションプロトコルの設計者は、自分たちのプロトコル内でセキュリティプロトコルの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.
もう一つの問題は、フレームワークの各セキュリティ機能がアプリケーション層プロトコルとどう連携するのか、必ずしも明らかでないことです。たとえば、SASLを認証フレームワークとしてだけ使う場合、SASLのやり取りは行われますが、その後の接続は保護されません。一方、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.
一般に、認証フレームワークは、既存の認証システムを備えたシステムに新しいプロトコルを追加するときに最も役立ちます。フレームワークを使えば、既存サイトに従来の認証システムを全面的に作り直させずに、新しい導入環境でより強い認証を提供できます。システムのセキュリティ要件を明確に特定でき、使う認証方式も少数で済む場合は、単一の方式を選ぶほうが単純で予測しやすくなります。フレームワークを使う場合、設計者は選択肢を慎重に検討し、個別の脅威モデルに適した方式だけを指定すべきです (SHOULD)。フレームワークが必要なら、独自のものを設計するのではなく、確立された方式の一つを選ぶべきです (SHOULD)。
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.
否認防止に対する単純なアプローチは、コンテンツに対して公開鍵デジタル署名を使用することです。義務に拘束される側の当事者（署名当事者: SIGNING PARTY）が、当該のメッセージにデジタル署名を行います。相手方（依拠当事者: RELYING PARTY）は、署名当事者がある時点で問題のメッセージに同意したことの証拠として、後からそのデジタル署名を提示できます。残念ながら、このアプローチだけでは不十分です。
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.
さらに、依拠当事者が署名当事者を欺き、別のメッセージに署名していると思い込ませて特定のメッセージに署名させようとする可能性もあります。この問題は、キオスク端末などのように、署名当事者が署名のために使用するインフラを依拠当事者が制御している場合に特に深刻となります。そのような状況の多くでは、署名当事者の鍵はスマートカード内に保持されているものの、署名対象のメッセージは依拠当事者によって表示されます。
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.
認可（AUTHORIZATION）とは、認証された当事者が特定のリソースまたはサービスにアクセスする権限を持っているかどうかを判定するプロセスです。密接に関連しているものの、認証と認可は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.
よく使われる認可方式の一つがアクセス制御リスト（ACL）です。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 Accounting CAが発行した証明書を持つユーザーは、両方のCAがAcmeのWebサーバーから信頼されていても、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".
このような複雑な性質を強制する仕組みは、まだ十分に検討されていません。一つの方法は、どの種類の証明書を信頼するかを記述したポリシーをACLに付けることです。別の方法は、証明書拡張または属性 [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.
安全性を考慮して設計されたプロトコルは、すべての機密トラフィックを保護する仕組みを備えるべきです。ここでいう保護には、完全性の確保、認証、必要に応じた暗号化が含まれます。一つの方法は、[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].
利用可能なチャネルセキュリティ方式を使えば、十分に保護できるプロトコルも多くあります。ここでは、代表的な二つである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実装がすべての識別方式をサポートするとは限りません。特にセキュリティゲートウェイは、ユーザー間認証を提供しない場合や、その認証情報をアプリケーションに渡す仕組みを持たない場合があります。
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を使う場合、システム全体で有効になっていればアプリケーション開発者は何もする必要がないこともあります。一方、使用する実装によっては、特定のsetsockopt()呼び出しを追加するなど、ソフトウェアの変更が必要なこともあります。残念ながら、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を追加するには、通常、カーネルの変更や新しいドライバーの導入など、OSの変更が必要です。これは新しいアプリケーションをインストールするよりはるかに大がかりです。ただし、近年の一般的なOSには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を利用できると想定してはなりません (MUST NOT)。汎用のアプリケーション層プロトコルのセキュリティポリシーでは、予定する導入環境でIPsecが利用可能だと考える根拠がない限り、ポリシーで単にIPsecの使用を必須と定めるべきではありません (SHOULD NOT)。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の両方を実装することが必須です。そのため、IPv6専用のプロトコルや導入環境では、AH/ESPがすでに利用できると想定するのは妥当です。ただし、自動鍵管理（IKE）は実装が必須ではないため、プロトコル設計者は利用できると想定すべきではありません (SHOULD)。IPsecが適切な選択となる状況については[USEIPSEC]に詳しい指針があります。
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 Socketsに似たインターフェースを提供します。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.
主な方法は二つあります。一つはTLS接続専用の既知のポートを用意する方法です（例：HTTPSのポート443）[HTTPTLS]。もう一つは、[UPGRADE]や[STARTTLS]のように、基本プロトコルからTLSへ移行するためのネゴシエーション機構を用意する方法です。後者では、両者が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などの信頼性のあるプロトコルに依存するため、主に二つの問題があります。第一に、UDPを使うデータグラムプロトコルの保護には使えません。第二に、TLSはIPsecでは防げるIP層攻撃の影響を受けます。通常、これらはサービス拒否や接続の強制切断を引き起こします。たとえば攻撃者は偽のTCP RSTを送信し、SSL接続を終了させることがあります。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を使う際の課題の一つは、サーバーを証明書で認証することです。従来、クライアントとサーバーが共有するパスワードだけを認証に使っていた環境では不便な場合があります。サーバーを認証せずにTLSを使い（匿名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をこのように組み合わせても、期待するほど強い保護にはなりません。能動攻撃者は簡単に接続を乗っ取れます。サーバーを認証していないため、通常ならその攻撃を防ぐTLS接続に対して、クライアントとサーバーの間に割り込み、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はEXTERNAL機構を提供しています。これによりSASLクライアントはサーバーに「外側のチャネルから私の身元を確認してください」と伝えられます。当然ながら、これは前述のレイヤー間攻撃を受けません。
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文字ずつクライアントからサーバーへ送られます。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ポートに対する安全なポート転送も提供します。これにより、ユーザーは任意のTCPベースのアプリケーションをSSHチャネル上で実行できます。ただし、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.
サービス拒否攻撃は、避けられないものとして扱われることがあまりにも多くあります。攻撃者は多くの場合、被害者に仕掛ける複数のサービス拒否攻撃から一つを選べます。また、その多くを阻止できないため、ほかにも防げない攻撃が多数あるなら、ある種類の攻撃だけを防いでも意味がないと考えられがちです。
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] は、この両方を示しています。SYNフラッド攻撃は簡単で、匿名性が高く、効果的なため、ほかの攻撃より攻撃者に選ばれやすくなります。そして、その原因は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.
インターネット標準の著者は、自分たちのプロトコルがどのサービス拒否攻撃に弱いかを記述しなければなりません (MUST)。その記述には、そうした攻撃を防ごうとすることが不合理または対象外と判断された理由を含めなければなりません (MUST)。
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攻撃への対処は非常に困難です。阻止するのは難しいものの、プロトコル設計者は設計時にこの種の攻撃を考慮することが求められます。
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].
攻撃者が攻撃を開始する際に、こちらより多くのリソースを消費するようにできれば、こちらより資源の少ない攻撃者は効果的な攻撃を行えなくなります。一般的な手法の一つは、暗号処理など時間のかかる操作を攻撃者に要求することです。ただし、攻撃者が十分な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.
したがって、小さなサブネット上のホストは、少なくともなりすまし攻撃では攻撃者にとって役に立ちません。攻撃をサブネットまで追跡でき（攻撃者の特定に十分な場合があります）、対策を講じられるためです（たとえば、境界ルーターでそのサブネットからの全トラフィックを破棄できます）。一般的な手法の一つは、メッセージ交換の前段で得た情報を使って攻撃者に応答させることです。
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フラッド攻撃に似たPhoturisへの攻撃を防ぐ、リソース枯渇防止機構を規定しています。Photurisは時間とともに変化する秘密情報を使って「クッキー」を生成し、攻撃者に返します。やり取りを続けるには、以降のメッセージでこのクッキーを返さなければなりません。このクッキーはやり取りの後半でも被害者が再生成できます。そのため、攻撃者が被害者からのパケットを受信できると証明するまで、被害者は状態を保持する必要がありません。
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.
オブジェクトセキュリティとチャネルセキュリティの違いは、見る視点によって変わります。プロトコルスタックのある層でのオブジェクトセキュリティは、その上の層から見るとチャネルセキュリティのように見えることがよくあります。たとえば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ページ全体から見ると、チャネルセキュリティに近いものです。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]などの汎用アプリケーション層プロトコルをますます通すようになっています。これらの汎用プロトコルに基づくネットワークプロトコルは、ファイアウォールに守られると一般に想定できません。最後に、システムにとって最も深刻な脅威の一つは、外部ではなく内部の人間からのものです。内部の人間は定義上、内部ネットワークにアクセスできるため、ファイアウォールなどトポロジーに基づく保護では防げません。
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
著者は次の事項を記述しなければなりません (MUST)。
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
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.
少なくとも、盗聴、リプレイ、メッセージの挿入・削除・改変、中間者攻撃を検討しなければなりません (MUST)。サービス拒否攻撃の可能性も特定しなければなりません (MUST)。プロトコルに暗号保護機構が含まれる場合は、データのどの部分がどのように保護されるか（完全性のみ、機密性、エンドポイント認証など）を明確に示すべきです。また、その暗号保護がどのような攻撃に弱いかも示すべきです。秘密にすべきデータ（鍵素材や乱数シードなど）には、明確に印を付けるべきです。
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:
技術に認証、特にユーザー・ホスト認証が含まれる場合は、認証方式の安全性を明確に記述しなければなりません (MUST)。つまり、認証方式の安全性がどのような前提に基づいているかを著者が記録しなければなりません (MUST)。たとえば、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ファイルの内容を使って'crack'プログラムを実行することで取得できます。(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、グループなどを対応付けるため、誰でも読み取れる必要があります。この用途を維持しながらcrackの実行を難しくするため、ファイルを/etc/passwdと「shadow」パスワードファイルに分けることがよくあります。shadowファイルは誰でも読める状態にはせず、暗号化されたパスワードを格納します。通常の/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.
自分のプロトコルを何らかの下位層セキュリティプロトコル上で動かすべきだと述べるだけでは不十分です。システムが下位層のセキュリティサービスに依存する場合、それらのサービスが提供すると想定する保護を明確に記述しなければなりません (MUST)。さらに、組み合わせたシステム全体で得られる性質も記述する必要があります。
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.
「セキュリティに関する考慮事項」節で扱う脅威環境には、少なくとも、ファイアウォールがあると仮定せず、複数の管理境界をまたぐグローバルインターネットへの導入を含めなければなりません (MUST)。これは、そのような脅威への対処がプロトコルの対象外である理由を説明する場合でも同じです。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にもその節はありません。[RFC 2821]はRFC 821を更新し、詳しいセキュリティに関する考慮事項を追加しました。ここでは、その文書の該当節を新しい節番号で再掲します。筆者らのコメントはインデントし、「NOTE:」を付けています。また、重要と考える話題を扱う節をいくつか追加し、節見出しに[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]、例：[4]のPGPや[31]のS/MIME）。
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.
注：送信者認証として適切でない方式の一つが[IDENT]です。受信側のメールサーバーが送信者とされるホストに接続し、そのユーザー名を尋ねます。中継、TCP接続の乗っ取り、送信元サーバーが単に嘘をつくことなど、問題となる理由はほかにもあります。IDENTのセキュリティ上の価値が低いことに加え、受信側サイトがIDENTを使うと運用上の問題も生じます。送信側サイトの多くは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サーバーへの認証）は、従来の状況をある程度改善します。ただし、慎重に設計された信頼環境で責任を適切に引き継ぐ仕組みが伴わなければ、トランスポートの完全性に依存するため、デジタル署名付きメッセージを使うエンドツーエンド方式より本質的に弱いままです。
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.)
ユーザーがエンベロープの戻り先やヘッダーのFrom欄に、自分以外の有効なアドレスを設定できないようにする取り組みは、たいてい見当違いです。別のユーザーに代わってメールを送る用途や、エラー返信（または通常の返信）を特定のアドレスに送る用途を妨げてしまうためです。（メッセージごとにこれらの欄を簡単に変更できるシステムでは、メッセージ内のSender欄を適切に生成できるよう、ユーザーの主たる恒久的なメールボックスアドレスを設定するよう努めるべきです。）
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.
この仕様では、SMTPに伴う認証の問題をこれ以上扱いません。ただし、メールを偽造しようとする知識の乏しいユーザーに対してわずかな保護を与えるためだけに、有用な機能を無効にするべきではないとしています。
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節に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コマンドに現れることがあります。最も一般的なのは、メーリングリストの展開先として一つのアドレスを使う場合（単一アドレスが複数のアドレスに展開されます）と、ブラインドコピーを使う場合です。特に複数のRCPTコマンドがあるとき、これらの仕組みの目的を損なわないよう、SMTPクライアントとサーバーは、トレースヘッダー、情報ヘッダー、またはプライベート拡張ヘッダーのいずれにも、RCPTコマンド引数全体をコピーすべきではありません (SHOULD NOT)。この規則は実運用でしばしば破られ、強制もできないため、bccの使用を認識する送信側SMTPシステムは、各ブラインドコピーをRCPTコマンド一つだけを含む別個のメッセージトランザクションとして送るとよい場合があります (MAY)。
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.
SMTPトランザクション（「エンベロープ」）内の「逆方向」（MAIL、SAMLなどのコマンド）または「順方向」（RCPT）のアドレスと、ヘッダー内のアドレスとの間に本質的な関係はありません。受信側システムは、そのような関係を推測して、配送用にメッセージヘッダーを書き換えるべきではありません (SHOULD NOT)。一般的なApparently-Toヘッダーもこの原則に反し、意図しない情報開示のよくある原因となるため、使うべきではありません (SHOULD NOT)。
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の一方、あるいは両方を無効にする場合があります。これに関連して、無効化を許す実装は、実際には検証していないアドレスを検証済みであるかのように示してはなりません (MUST NOT)。サイトがセキュリティ上の理由からこれらのコマンドを無効にする場合、SMTPサーバーは検証の成功または失敗と誤解される可能性のあるコードではなく、252応答を返さなければなりません (MUST)。
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を返すことでVRFYを「サポート」する実装も、当然ながら適合しません。
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をサポートすべきです (SHOULD) が、サイトは利点とリスクを慎重に評価すべきです (SHOULD)。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 TOを使ってアドレスが有効かどうかを調べられることがよくあるためです。
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サーバーがグリーティング応答やHELPコマンドへの応答で、サーバーの種類やバージョン（場合によってはサーバーのドメイン名まで）を知らせることには、デバッグしやすくなる利点と、攻撃に役立つ情報を公開する欠点があります。この点は継続的に議論されています。デバッグ情報が有用であることに疑いはありません。情報公開を支持する人々は、サーバーの正確な識別情報を隠して既知の脆弱性を隠そうとするより、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内から送信される場合などには、この仕様に従って生成されたトレース（Received）欄から、通常は公開されないホスト名などの情報が漏れることがあります。通常は問題になりませんが、名前の開示を特に懸念するサイトは注意してください。また、複数の受信者がいる場合、ブラインドコピーの受信者を他者に誤って知らせないよう、任意の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サーバーは、運用上または技術上、そのサイトにとって妥当な理由があればメールの受け入れを拒否できるという原則が確立しています。しかし、サイトやシステム同士の協力がインターネットを成り立たせています。サイトがトラフィックを拒否する権利を過度に行使すると、メールをどこでも利用できるというインターネットの強みが損なわれます。受け入れて処理するトラフィックを選別する場合は、十分に注意し、均衡を保つべきです。
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.
近年、メールの本当の送信元を隠す悪意ある行為の一環として、任意のサイトを介した中継機能が使われてきました。中継機能の利用を、既知または識別可能な送信元に制限するサイトもあります。実装は、この種のフィルタリング機能を提供すべきです (SHOULD)。このほかポリシー上の理由でメールを拒否する場合は、状況に応じてEHLO、MAIL、またはRCPTへの応答に550コードを使うべきです (SHOULD)。
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自体は、求められていない商業目的の大量メール（いわゆるスパム）に対する保護を提供しません。あるメッセージがスパムかどうかを事前に判断するのは非常に困難です。プロトコルの観点では、スパムと他のメールを区別できません。その区別はほぼ全面的に社会的なもので、多くの場合、微妙です。（たとえば、以前に商品を購入したことがある販売業者が、似た商品を宣伝するメッセージを送る場合、それはスパムでしょうか。）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).
スパマーへのサービスを拒否する主な手段はブラックリストです。[MAPS]などの組織が既知のスパマーの一覧を収集し、公表します。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上で偽の身元を名乗ったり、任意の送信者のメールを中継するオープンリレーを経由させたりして、身元を隠そうとします。そのため、オープンリレーを対象とするブラックリスト [ORBS] も作られています。
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アドレスを遮断すれば十分です。それ以外の場合は、明示的な認証を使う必要があります。標準的な選択肢は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.
IPsec上でSMTP接続を実行すると、送信者と最初のSMTPゲートウェイとの間、または接続された任意の2つの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を使う際の別の問題は、標準化された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管理者は、利用できると考える理由（例：2台の機器間に既存の関連付けがあること）がない限り、IPsecを利用できると想定してはなりません (MUST NOT)。ただし、メール配送時に相手サーバーとのIPsec関連付けを機会に応じて作成しようとするのは、妥当な手順かもしれません。IPsecを2拠点間のVPNトンネルに使う場合、上述の注意点はありますが、特に機密性を確保できる点で大きなセキュリティ上の価値があります。IPsecの適用性に関する一般的な指針は[USEIPSEC]も参照してください。
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実装には米国への輸出が可能な（したがって安全性の低い）モードがあります。高い安全性を求めるアプリケーションは、このモードが無効であることを確認すべきです。データ自体が保護され、パケットを再送できないため、リプレイ攻撃から保護されます。[注：SMTP over TLS文書の「セキュリティに関する考慮事項」節は、書き方の例として読む価値があります。]
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は比較的大きく、通常はメッセージごとに新しいプロセスをforkします）。
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]から採っています。ここでは、その文書の「セキュリティに関する考慮事項」節を、新しい節番号で再掲します。筆者らのコメントはインデントし、「NOTE:」を付けています。
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は、異なるセキュリティポリシーを採用するさまざまなインターネットワーキング環境向けに設計されています。このプロトコルには、認証なし、単純な平文パスワード、IP認証ヘッダーとMD5 HMACによる強い認証など、複数の認証方式があります。各方式の詳細や、想定される攻撃、推奨される環境について以下で説明します。
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上にVRRPルーターが2台ある場合）でのみ、この方式を使うべきです (SHOULD)。
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検査と組み合わせると、別のLANからVRRPパケットを送り、VRRPの動作を妨害することは難しくなります。
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の動作を積極的に妨害するリスクが小さい場合、この認証方式が推奨されます (SHOULD)。この方式を使う場合、平文パスワードは頻繁に送信されるため、セキュリティ上重要な他のパスワードと同じものを使わないよう利用者に知らせるべきです。
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検査は、LAN外の悪意あるノードが正規ノードになりすますのを防ぎますが、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.
この認証方式では、IP認証ヘッダー [AH] と[HMAC]で定義された仕組みを使って、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上のノードの管理を十分に制御できない場合、この認証方式が推奨されます (SHOULD)。この方式はVRRPの動作を保護しますが、共有媒体リンク上ではVRRPと無関係な攻撃（例：偽の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を保護する唯一の仕組みです。そのため、同じネットワーク上に信頼できないノードが存在する場合、AHを必須とすべきです (MUST)。いずれにしても、AHの実装は必須です (MUST)。
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.
この文書は、Ran Atkinsonが1997年に書いたメモを大幅に基にしています。そのメモは、1997年初頭に開催されたIAB Security Workshopの後、参加者全員の意見を踏まえて書かれました。上記の具体的な記述の一部はRanの原文から、また一部はFred Bakerが書いたメールから採られています。この文書のもう一つの主要な情報源は、Steve Bellovinから寄せられた具体的なコメントです。初期レビューはLisa DusseaultとMark Schertlerが行いました。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.
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[ENCOPT] Tso, T., "Telnet Data Encryption Option", RFC 2946, September, 2000.
[ENCOPT] Tso, T., "Telnet Data Encryption Option", RFC 2946, September, 2000.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[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 Version 2, Update 1", RFC 2743, January 2000.
[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] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "HyperText Transfer Protocol", RFC 2616, June 1999.
[HTTPTLS] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
[HTTPTLS] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
[HMAC] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[HMAC] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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. and M. Straw, "A One-Time Password System", STD 61, RFC 2289, February 1998.
[PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[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] 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.
[RFC-2223] Postel J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC-2223] Postel J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC-2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.
[RFC-2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.
[RFC-2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC-2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SPKI] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999.
[SPKI] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999.
[SSH] Ylonen, T., "SSH - Secure Login Connections Over the Internet", 6th USENIX Security Symposium, p. 37-42, July 1996.
[SSH] Ylonen, T., "SSH - Secure Login Connections Over the Internet", 6th USENIX Security Symposium, p. 37-42, July 1996.
[SASLSMTP] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SASLSMTP] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[S-HTTP] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999.
[S-HTTP] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999.
[S/MIME] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[S/MIME] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[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. and J. Mikkelsen, "Transport Layer Security (TLS) Extensions", RFC 3546, May 2003.
[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.
[UPGRADE] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[URL] Berners-Lee, T., Masinter, M. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL] Berners-Lee, T., Masinter, M. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[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] 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.
[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., "Encrypted Key Exchange: Password-based protocols secure against dictionary attacks", Proceedings of the IEEE Symposium on Research in Security and Privacy, May 1992.
[IDENT] St. Johns, M. and M. Rose, "Identification Protocol", RFC 1414, February 1993.
[IDENT] St. Johns, M. and M. Rose, "Identification Protocol", RFC 1414, February 1993.
[INTAUTH] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[INTAUTH] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[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., "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix UNIX Security Symposium, July 1996.
[KLEIN] Klein, D.V., "Foiling the Cracker: A Survey of and Improvements to Password Security", 1990.
[KLEIN] Klein, D.V., "Foiling the Cracker: A Survey of and Improvements to Password Security", 1990.
[NNTP] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[NNTP] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[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., "A Weakness in the 4.2 BSD UNIX TCP/IP Software", 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] 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.
[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., "Strong Password-Only Authenticated Key Exchange", Computer Communication Review, ACM SIGCOMM, vol. 26, no. 5, pp. 5-26, October 1996.
[SRP] Wu T., "The Secure Remote Password Protocol", ISOC NDSS Symposium, 1998.
[SRP] Wu T., "The Secure Remote Password Protocol", ISOC NDSS Symposium, 1998.
[USEIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", Work in Progress.
[USEIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", Work in Progress.
[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.
この文書全体はセキュリティ上の考慮事項についてです。
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 Deering Sally Floyd Ted Hardie Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Mike St. Johns
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
Phone: (650)-320-8549 EMail: ekr@rtfm.com
Brian Korver Xythos Software, Inc. 77 Maiden Lane, 6th Floor San Francisco, CA, 94108
Brian Korver Xythos Software, Inc. 77 Maiden Lane, 6th Floor San Francisco, CA, 94108
Phone: (415)-248-3800 EMail: briank@xythos.com
Phone: (415)-248-3800 EMail: briank@xythos.com
Internet Architecture Board IAB EMail: iab@iab.org
Internet Architecture Board IAB EMail: iab@iab.org
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本書およびその翻訳は、他者に複製して提供できます。また、本書について論評や説明を加える派生著作物、または本書の実装を支援する派生著作物は、上記の著作権表示とこの段落をすべての複製物および派生著作物に含めることを条件として、全体または一部を問わず、いかなる制限もなく作成、複製、公開、配布できます。ただし、著作権表示やInternet Societyその他のインターネット組織への言及を削除するなど、本書自体を変更してはなりません。例外は、インターネット標準の開発に必要な場合（その場合はInternet Standardsプロセスで定められた著作権手続きに従います）と、英語以外の言語に翻訳する場合です。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で認められた限定的な許可は永続的であり、Internet Society、その後継者または譲受人によって取り消されません。
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.
本書および本書に含まれる情報は「現状有姿」で提供されます。INTERNET SOCIETYおよびINTERNET ENGINEERING TASK FORCEは、明示または黙示を問わず、あらゆる保証を否認します。これには、本情報の利用がいかなる権利も侵害しないことの保証、および商品性または特定目的への適合性に関する黙示の保証が含まれますが、これらに限られません。
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editorの業務に対する資金は、現在Internet Societyが提供しています。