RFC3552 日本語訳
3552 Guidelines for Writing RFC Text on Security Considerations. E.Rescorla, B. Korver. July 2003. (Format: TXT=110393 bytes) (Also BCP0072) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求めるワーキンググループE.レスコラの要求をネットワークでつないでください: 3552RTFM Inc.BCP: 72B.Korverカテゴリ: 最も良い現在の練習Xythosソフトウェアインターネット・アーキテクチャ委員会IAB2003年7月
Guidelines for Writing RFC Text on Security Considerations
セキュリティ問題に関するテキストをRFCに書くためのガイドライン
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
すべてのRFCsが、Security Considerations部を持つのに必要です。 歴史的に、そのようなセクションは比較的弱いです。 このドキュメントはどう良いSecurity Considerations部に書くかの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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 要件。 . . . . . . . . . . . . . . . . . . . . 3 2. セキュリティの目標。 . . . . . . . . . . . . . . . . . . 3 2.1. コミュニケーションセキュリティ。 . . . . . . . . . . . . . . . 3 2.1.1. 秘密性。 . . . . . . . . . . . . . . . 4 2.1.2. データの保全. . . . . . . . . . . . . . . . 4 2.1.3。 同輩Entity認証. . . . . . . . . . 4 2.2。 非拒否.52.3。 システムセキュリティ。 . . . . . . . . . . . . . . . . . . 5 2.3.1. 権限のない用法. . . . . . . . . . . . . . 6 2.3.2。 不適当な用法。 . . . . . . . . . . . . . 6 2.3.3. サービス妨害。 . . . . . . . . . . . . . . 6 3. インターネット脅威モデル。 . . . . . . . . . . . . . . . . 6 3.1. 株式会社の脅威は.73.2をモデル化します。 受動態は.1に.73.2を攻撃します。 秘密性違反. . . . . . . . . . 8 3.2.2。 パスワードスニフィング。 . . . . . . . . . . . . . . 8 3.2.3. オフライン暗号の攻撃。 . . . . . . . . 9
Rescorla & Korver Best Current Practice [Page 1] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[1ページ]。
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
3.3. 活発な攻撃。 . . . . . . . . . . . . . . . . . . . 9 3.3.1. 反射攻撃. . . . . . . . . . . . . . . . 10 3.3.2。 メッセージ挿入。 . . . . . . . . . . . . . . 10 3.3.3. メッセージ削除. . . . . . . . . . . . . . . 11 3.3.4。 メッセージ変更. . . . . . . . . . . . . 11 3.3.5。 マン・イン・ザ・ミドル。 . . . . . . . . . . . . . . 12 3.4. 位相的な問題。 . . . . . . . . . . . . . . . . . 12 3.5. 経路である対オフ経路.133.6 リンク地方です。 . . . . . . . . . . . . . . . . . . . . . 13 4. 共通の課題。 . . . . . . . . . . . . . . . . . . . . . . 13 4.1. ユーザー認証. . . . . . . . . . . . . . . . . 14 4.1.1。 ユーザ名/パスワード。 . . . . . . . . . . . . . . 14 4.1.2. チャレンジレスポンスと使い捨てパスワード。 . . 14 4.1.3. 共有されたキー。 . . . . . . . . . . . . . . . . . 15 4.1.4. 主要な配送センター. . . . . . . . . . . 15 4.1.5。 証明書. . . . . . . . . . . . . . . . . 15 4.1.6。 いくつかの珍しいシステム… 15 4.1 .7。 認証を主催してください。 . . . . . . . . . . . . . 16 4.2. ジェネリックセキュリティフレームワーク. . . . . . . . . . . . . 16 4.3。 非拒否.174.4。 承認対認証 . . . . . . . . . . 18 4.4.1. アクセスコントロールリスト. . . . . . . . . . . . . 18 4.4.2。 4.5にベースのシステム………18を証明してください。 トラヒック保全を提供します。 . . . . . . . . . . . . . 19 4.5.1. IPsec。 . . . . . . . . . . . . . . . . . . . . 19 4.5.2. SSL/TLS。 . . . . . . . . . . . . . . . . . . . 20 4.5.3. リモート・ログイン. . . . . . . . . . . . . . . . . 22 4.6。 サービス不能攻撃と対策. . . . 22 4.6.1。 盲目のサービス妨害。 . . . . . . . . . . . 23 4.6.2. 分散型サービス妨害。 . . . . . . . . 23 4.6.3. サービス妨害. . . . . . . . . . 24 4.6.4を避けます。 例: TCP SYNは浸水します。 . . . . . . . . . . . 24 4.6.5. 例: Photuris。 . . . . . . . . . . . . . . 25 4.7. チャンネルセキュリティ. . . . . . . . . . . . . 25 4.8に対して反対してください。 ファイアウォールとネットワーク形態。 . . . . . . . . . . . 26 5. セキュリティ問題にセクション. . . . . . . . . 26 6を書きます。 例. . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1。 SMTP。 . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1.1. セキュリティ問題。 . . . . . . . . . . . 29 6.1.2. コミュニケーション安全保障問題. . . . . . . . 34 6.1.3。 サービス妨害。 . . . . . . . . . . . . . . 36 6.2. VRRP。 . . . . . . . . . . . . . . . . . . . . . . . . .36 6.2.1. セキュリティ問題。 . . . . . . . . . . . 36 7. 承認。 . . . . . . . . . . . . . . . . . . . . . 38 8. 引用規格. . . . . . . . . . . . . . . . . . . 39 9。 有益な参照. . . . . . . . . . . . . . . . . . 41 10.Security問題。 . . . . . . . . . . . . . . . . . 42 付録A.. . . . . . . . . . . . . . . . . . . . . . . . . 43
Rescorla & Korver Best Current Practice [Page 2] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[2ページ]。
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 43 Full Copyright Statement. . . . . . . . . . . . . . . . . . . 44
作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . 43 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 44
1. Introduction
1. 序論
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.
すべてのRFCsが、Security Considerations部を含むようにRFC2223によって必要とされます。 この目的はドキュメント作者が彼らのデザインにおけるセキュリティを考えて、関連安全保障問題について読者に知らせるようともに奨励することです。 このメモが両端で使用中の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番目はSecurity Considerationsに書くための一連のガイドラインです。 3番目は一連の例です。
1.1. Requirements
1.1. 要件
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[キーワード]で説明されるように本書では解釈されることであるべきです。
2. The Goals of Security
2. セキュリティの目標
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として知られているCOMMUNICATION SECURITY)と保護システムに関連するもの(ADMINISTRATIVE SECURITYかSYSTEM SECURITY)に分割できます。 コミュニケーションがシステムによって行われて、システムへのアクセスがコミュニケーションチャンネルであるので、これらの目標は明らかに連動しますが、また、独自にそれらを提供できます。
2.1. Communication Security
2.1. コミュニケーションセキュリティ
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つの大範疇に分割することです: 秘密性、データ保全、および同輩実体認証。
Rescorla & Korver Best Current Practice [Page 3] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[3ページ]。
2.1.1. Confidentiality
2.1.1. 秘密性
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.
ほとんどの人々がセキュリティを考えるとき、彼らは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.
明らかに、秘密がありましたら、あなたはたぶん彼らを発見する他のものに関して心配しています。 したがって、少なくとも、あなたは秘密性を維持したがっています。 あなたが、映画のスパイが浴室に入って、急いで去ることにはくを敷くためにすべての水をつけるのを見るとき、彼らが探している特性は秘密性です。
2.1.2. Data Integrity
2.1.2. データの保全
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.
他方では、電子世界では、すべてのビットが同じく見るので、トランジットにおけるメッセージをいじるのが些細です。 あなたは、ワイヤからメッセージを単に取り除いて、あなたが好きである部品を全部写して、あなたが欲しいどんなデータも加えて、あなたが選ぶ新しいメッセージを生成します、そして、受取人は、より賢明ではありません。 これはあなたが書いた手紙を取る攻撃者の道徳的な同等物です、いくらかの新しい紙を買って、メッセージを再コピーして、彼がそれをするときそれを変えて。 それはただすべてのビットが同じく見るので電子的によりしやすいいろいろな事です。
2.1.3. Peer Entity authentication
2.1.3. 同輩Entity認証
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番目の特性はPEER ENTITY AUTHENTICATIONです。 私たちがこれで言っていることは私たちが、コミュニケーションの終点の1つが意図したものであることを知っているということです。 同輩実体認証がなければ、秘密性かデータ保全のどちらかを提供するのは非常に難しいです。 例えば、私たちがアリスからメッセージを受け取って、事実上、それが攻撃者ではなく、アリスによって送られたのを知らないなら、データ保全の特性は私たちをあまり良くしません。 同様に、秘密のメッセージをボブに送りたいと思うなら、それには、私たちが実際に秘密のメッセージを攻撃者に送るなら、私たちには価値があまりありません。
Rescorla & Korver Best Current Practice [Page 4] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[4ページ]。
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.
メッセージング状況で、あなたは、あるメッセージの送付者のアイデンティティを証明するのに同輩実体認証をしばしば使用したがっています。 そのような文脈では、この特性はDATA ORIGIN AUTHENTICATIONと呼ばれます。
2.2. Non-Repudiation
2.2. 非拒否
A system that provides endpoint authentication allows one party to be certain of the identity of someone with whom he is communicating. When the system provides data integrity a receiver can be sure of both the sender's identity and that he is receiving the data that that sender meant to send. However, he cannot necessarily demonstrate this fact to a third party. The ability to make this demonstration is called NON-REPUDIATION.
終点認証を提供するシステムは、1回のパーティーが彼と交信する予定であるだれかのアイデンティティを確信しているのを許容します。 システムが受信機をデータ保全に提供すると、確実に、送付者のアイデンティティとその両方では、彼がその送付者が送るのを意図したデータを受け取っているということであることができます。 しかしながら、彼は必ずこの事実を第三者に示すことができるというわけではありません。 このデモンストレーションをする能力は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回のパーティーがパーティーが一方的に廃棄したがっている契約に署名した状況を考えてください。 彼は、第一にそれに一度も署名したことがなかったと単に主張するかもしれません。 彼は非拒否によってそうすることができないで、その結果、カウンターパーティを保護します。
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は困難のいくつかについて説明します--1回のパーティーが相手が否定したがっていることを立証したがっています。一般に、困難は2回のパーティーの関心が並べられないという事実によります。
2.3. Systems Security
2.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.
一般に、システムセキュリティは人のマシンとデータを保護するのに関係があります。 意図はマシンが単に認定ユーザと所有者が意図する目的に使用されるべきであるということです。 その上、それらはそれらの目的に利用可能であるべきです。 攻撃者は正統のユーザからリソースを奪うことができないべきです。
Rescorla & Korver Best Current Practice [Page 5] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[5ページ]。
2.3.1. Unauthorized Usage
2.3.1. 権限のない用法
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.
ほとんどのシステムが公衆には完全にアクセスしやすいことを意図しません。 むしろ、彼らは単に確信している認可された個人によって使用されることを意図します。 すべてのインターネットユーザにとって、多くのインターネットのサービスが利用可能ですが、一般に、それらのサーバさえより大きい特定のユーザに対するサービスの部分集合を提供します。 例えば、ウェブServersはしばしばどんなユーザにもデータをサービスするでしょうが、特定のユーザにページを変更する能力を制限してください。 一般によるそのような変更はUNAUTHORIZED USAGEでしょう。
2.3.2. Inappropriate Usage
2.3.2. 不適当な用法
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.
認定ユーザであることは、あなたにはシステムのフリーランがあることを意味しません。 私たちが上で言ったように、いくつかの活動が認定ユーザに制限されます、特定のユーザへのいくつか、そして、一般に、いくつかの活動が管理者を除いた皆に禁じられます。 そのうえ、いくつかの場合、一般に、受入れられる活動さえ禁じられるかもしれません。 例えば、ユーザは、あるサイズ、またはウイルスを含むファイルを超えてメールを送ることが許可されていますが、送付ファイルから禁じられるかもしれません。 これらはINAPPROPRIATE USAGEに関する例です。
2.3.3. Denial of Service
2.3.3. サービス妨害
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番目の目標が正統のユーザにとって、システムが利用可能であるべきであるということであったと思い出してください。 広いバラエティーの攻撃は可能です(そのような用法を脅かします)。 そのような攻撃はサービス妨害攻撃とまとめて呼ばれます。 サービス不能攻撃は、しばしば非常に上がりやすくて止まるのは難しいです。 正統のユーザに役立つのを難しいか不可能にして、そのような多くの攻撃が、マシンリソースを消費するように設計されています。 他の攻撃で、ユーザに対するサービスを完全に否定して、ターゲットマシンはダウンします。
3. The Internet Threat Model
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.
THREAT MODELは攻撃者がリソースに対して配布することができると思われる能力について説明します。 それは攻撃者にとって、情報で利用可能なリソースのような情報を含むべきです、能力、およびシステムのコントロールを計算して。 脅威モデルの目的は二つです。 まず最初に、私たちが関する脅威を特定したいと思います。 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
インターネット環境には、公正によく理解されている脅威モデルがあります。 一般に、私たちは、プロトコル交換に従事しているエンドシステムがそうしていないと自分たちで思います。感染されます。 エンドシステムの1つが感染されたとき攻撃から守るのは、そうです。
Rescorla & Korver Best Current Practice [Page 6] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[6ページ]。
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.
対照的に、私たちは、攻撃者にはエンドシステムが交信するコミュニケーションチャンネルのほとんど完全なコントロールがあると思います。 これは、攻撃者がundetectablyに偽造パケットをワイヤにネットワークでどんなPDU(プロトコル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レベルでは、それは要求か応答を意味するかもしれません。
3.1. Limited Threat Models
3.1. 株式会社脅威モデル
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].
私たちが言ったように、才略にたけてひたむきな攻撃者は全体のコミュニケーションチャンネルを監督することができます。 しかしながら、攻撃者は、より少ないリソースで多くの攻撃を仕掛けることができます。 ネットワークの限られたコントロールに従って、攻撃者は多くの現在知られている攻撃を仕掛けることができます。 例えば、任意のパケットを読むことができるだけである攻撃者はパスワードスニフィング攻撃を仕掛けることができます。 一般に、これはPASSIVE ATTACK[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.
対照的に、書きますが、任意のパケットを読むことができない攻撃者はモリスの一連番号推測攻撃[SEQNUM]を取り付けることができます。 攻撃者がネットワークに書くのを必要とするどんな攻撃もACTIVE ATTACKとして知られています。
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.
したがって、攻撃を組織化する役に立つ方法は攻撃を仕掛けるのに必要である能力に基づいてそれらを分割することです。 このセクションの残りは、これらのカテゴリについて説明して、それぞれのカテゴリに関するいくつかの例を提供します。
3.2. Passive Attacks
3.2. 受け身の攻撃
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
受け身の攻撃には、攻撃者は、ネットワークからパケットを読みますが、それらを書きません。 そのような攻撃を仕掛ける最も簡単な方法は犠牲者と同じLANに単にあることです。 ほとんどの一般的なLAN構成では、イーサネット、802.3、およびFDDIを含んでいて、ワイヤの上のどんなマシンもいかなる他のマシンのためにも運命づけられたすべてのトラフィックを読み続けることができます。
Rescorla & Korver Best Current Practice [Page 7] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[7ページ]。
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。 スイッチング・ハブで実質的にかぐこの種類が、より難しくなることに注意してください、マシンのために運命づけられたトラフィックがそのマシンがあるネットワークセグメントに行くだけであるので。
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].
無線通信チャンネルは特別の配慮に値します、特にワイヤレスベースのLANの最近の、そして、増加している人気で、802.11を使用するものなどのように。 データがよく知られている無線周波数で単に放送されるので、攻撃者は、単にそれらのトランスミッションを受けることができる必要があります。 そのようなチャンネルは受け身の攻撃に特に被害を受け易いです。 そのような多くのチャンネルが暗号の保護を入れますが、それはしばしばそのような劣った品質についてほとんど役に立たないほど[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.
一般に、受け身の攻撃の目標は送付者と受信機が個人的に残っているのを好む情報を得ることです。 この個人情報は電子世界、そして/または、パスワードで役に立つ資格証明書か外の世界で役に立つ資格証明書を含むかもしれません、企業秘密情報などのように。
3.2.1. Confidentiality Violations
3.2.1. 秘密性違反
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の広い有用性にもかかわらず、多くのクレジットカードでの取引が明確でまだインターネットを横断しています。 攻撃者は、そのようなメッセージをかいで、クレジットカード番号を回復できました。(次に、詐欺的なトランザクションを作るのにそれを使用できます)。 そのうえ、企業秘密情報はきまりきってメールによる明確のネットワークの上に伝えられます。
3.2.2. Password Sniffing
3.2.2. パスワードスニフィング
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.
受け身の攻撃に関する別の例はPASSWORD SNIFFINGです。 パスワードスニフィングはリソースの無断使用を得るのに向けられます。 多くのプロトコル、含んでいます[TELNET]、[POP]、および[NNTP]はサーバにクライアントを認証するのに共有されたパスワードを使用します。頻繁に、このパスワードはコミュニケーションチャンネルの上の明確でクライアントからサーバまで伝えられます。 したがって、このトラフィックを読むことができる攻撃者はパスワードとREPLAYを得ることができます。それ。 言い換えれば、攻撃者は、捕らわれているパスワードを使用することでサーバに接続を開始して、クライアントのふりをして、ログインできます。
Rescorla & Korver Best Current Practice [Page 8] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[8ページ]。
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.
攻撃のログインフェーズがアクティブですが、実際のパスワード・キャプチャフェーズが受け身であることに注意してください。 そのうえ、サーバが接続の起因するアドレスをチェックしない場合、ログインフェーズはネットワークの少しの特別なコントロールも必要としません。
3.2.3. Offline Cryptographic Attacks
3.2.3. オフライン暗号の攻撃
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.
多くの暗号のプロトコルがOFFLINE ATTACKSを受けることがあります。 そのようなプロトコルでは、攻撃者は、犠牲者の秘密鍵を使用することで処理されたデータを回復して、次に、そのキーに対するcryptanalytic攻撃を仕掛けます。 それらが通常低いエントロピーであるので、パスワードは特に被害を受け易い目標を作ります。 多くのポピュラーなパスワードベースのチャレンジレスポンスプロトコルがDICTIONARY ATTACKに被害を受け易いです。 攻撃者は、チャレンジレスポンス組をキャプチャして、次に、彼が正しい応答を起こすパスワードを見つけるまで、一般的な語(辞書ファイルなどの)のリストからエントリーを試みかけます。
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パスワードは一方向関数を使用することでcryptedされますが、ツールは、そのようなcryptedパスワード[クライン]を知らせるために存在しています。 NISが使用されているとき、cryptedパスワードが企業内情報通信網の上に伝えられて、攻撃者は、その結果、パスワードをかいで、それを攻撃できます。
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.
また、歴史的に、活発な攻撃を使用することでパスワードファイルを回収するのに小さいオペレーティングシステムセキュリティーホールを利用するのも可能です。 そして、前述のオフラインパスワードリカバリ技術を使用することによって、実際のアカウントにこれらの穴を独力で進むことができます。 したがって、私たちは低レベルである活発な攻撃をオフライン受け身の攻撃に結合します。
3.3. Active Attacks
3.3. 活発な攻撃
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.
攻撃が、ネットワークにデータを書くことを伴うと、私たちはこれについてACTIVE ATTACKに言及します。 IPがIPsecなしで使用されるとき、送付者アドレスのための認証が全くありません。 結果として、攻撃者が彼が選ぶソースアドレスでパケットを作成するのは、簡単です。 私たちはこれについてSPOOFING ATTACKに言及するつもりです。
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.
ある状況で、そのようなパケットはネットワークによって別々にされるかもしれません。 例えば、多くのパケットフィルタリングファイアウォールがEXTERNALインタフェースで到着するINTERNALネットワークに関するソースアドレスがあるすべてのパケットを別々にします。 しかしながら、これがファイアウォールの中にいる攻撃者に対してノー・プロテクションを提供することに注意してください。 一般に、デザイナーは、攻撃者がパケットを鍛造できると仮定するべきです。
Rescorla & Korver Best Current Practice [Page 9] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[9ページ]。
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.
しかしながら、パケットを鍛造する能力は手を携えて任意のパケットを受ける能力を伴いません。 事実上、偽造パケットを送りますが、応答を受けることができないことを伴う活発な攻撃が、あります。 私たちはこれらについて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.
それぞれのプロトコルは特定の活発な攻撃に影響されやすいのですが、経験は、どんな与えられたプロトコルにも攻撃の多くの共通パターンを翻案できるのを示します。 次のセクションは、これらの多くのパターンについて説明して、知られているプロトコルへのそれらの適用されるとしての特定の例を出します。
3.3.1. Replay Attacks
3.3.1. 反射攻撃
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.
REPLAY ATTACKでは、攻撃者は、ワイヤからメッセージの系列を記録して、元々それらを受けたパーティーにそれらを再生します。 攻撃者がメッセージを理解する必要はないことができることに注意してください。 彼は、単にそれらをキャプチャして、再送する必要があります。
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メッセージが使用されているこの件が何らかのサービスを要求すると考えてください、クレジットカード購入や株式取引のように。 犠牲者に迷惑をかけるために唯一なら、攻撃者は二度サービスを実行して頂きたいかもしれません。 彼は、メッセージを得て、それを再演できました、彼はそれを読むことができませんが、トランザクションが二度実行されることを引き起こして。
3.3.2. Message Insertion
3.3.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.
MESSAGE INSERTION攻撃では、攻撃者は、何らかの選ばれたセットの特性でメッセージを作り出して、ネットワークにそれを注ぎます。 このメッセージにはしばしば、偽造ソースアドレスが、攻撃者の身元を変装するためにあるでしょう。
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
例えば、目標ホストに向けられた一連の偽りのTCP SYNパケットを挿入することによって、サービス不能攻撃を仕掛けることができます。 目標ホストは、それ自身のSYNと共に応じて、新しい接続のためにカーネルデータ構造を割り当てます。 攻撃者が3ウェイ握手を決して終了しないので、割り当てられた接続終点はカーネルメモリを取り上げながら、そこにただ座っています。 典型的なTCPは実装だけを積み重ねます。
Rescorla & Korver Best Current Practice [Page 10] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[10ページ]。
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.
この「半開きな」状態の何らかの限られたポートの数を許容してください。そうすれば、この限界に達しているとき、それ以上の接続は全く開始できません、正統のホストからさえ。 攻撃者が犠牲者のSYNsを処理する必要はないので、この攻撃が盲目の攻撃であることに注意してください。
3.3.3. Message Deletion
3.3.3. メッセージ削除
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.
MESSAGE DELETION攻撃では、攻撃者はワイヤからメッセージを取り除きます。 モリスの一連番号推測攻撃[SEQNUM]は、しばしばメッセージ削除攻撃が首尾よく実行されるのを必要とします。 この盲目の攻撃では、アドレスが偽造されているホストは攻撃されているホストから偽りのTCP SYNパケットを受けるでしょう。 このSYNパケットの領収書はRSTを生成します。(RSTは違法な接続を取りこわすでしょう)。 このホストが首尾よく攻撃を行うことができるようにRSTを送るのを防いで、モリスは、SYNパケットに待ち行列オーバーフローを作成しても、失われていて、このようにして決して応じないようにこのホストをあふれさせると説明します。
3.3.4. Message Modification
3.3.4. メッセージ変更
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.
MESSAGE MODIFICATION攻撃では、攻撃者は、ネットワークにワイヤからメッセージを取り除いて、それを変更して、それを再注入します。 攻撃者がメッセージのいくつかのデータを送りたいのですが、それのいくつかをまた変えたいなら、この種類の攻撃は特に役に立ちます。
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.
攻撃者がインターネットの上に置かれた商品の注文を攻撃したがっているケースを考えてください。 犠牲者のクレジットカード番号がなくて、彼は、犠牲者が注文をするのを待つので、次に、品物の配達先(そして、ことによると商品記述)を彼自身のに置き換えます。 攻撃者がオリジナルのメッセージからクレジットカード番号を切り取って、新しいメッセージにそれを貼るのでこの特定の攻撃がCUT AND-PASTE攻撃として知られていることに注意してください。
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であるなら、超能力は少しもMACなしで使用されて、次に、攻撃者が犠牲者のために同じマシンに暗号化されたトラフィックを読むのは、可能です。 攻撃者は彼が暗号化されたIPパケットに制御するポートに対応するIPヘッダーを取り付けます。 ホストがパケットを受け取るとき、自動的に攻撃者のポートにそれを解読して、送るでしょう。 セッションハイジャック攻撃を仕掛けるのに同様のテクニックを使用できます。 あなたが暗号化を使用するといつも通報認証を使用することによって、これらの攻撃の両方を避けることができます。 (1) MACチェックが全く使用されていない場合にだけこの攻撃が働いているというメモ、この攻撃が、破損しているパケット(2)がホストからホストであると生成するので、SAは使用されています、ユーザからユーザへのSAがSAに関連しているポートと目標ポートの間の矛盾をもたらすので。 受信マシンがこれよりシングルユーザーであるなら、攻撃は実行不可能です。
Rescorla & Korver Best Current Practice [Page 11] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[11ページ]。
3.3.5. Man-In-The-Middle
3.3.5. マン・イン・ザ・ミドル
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:
MAN IN MIDDLE攻撃は特別なフォームで上のテクニックを結合します: 攻撃者は受信機への送付者と送付者への受信機のふりをするためにコミュニケーションストリームを打倒します:
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.
プロトコルがPEER ENTITY AUTHENTICATIONを欠いているときはいつも、介入者攻撃は可能です。 例えば、攻撃者がTCP握手(恐らくサーバが応じる前にクライアントのSYNに応じるのによる)の間、クライアントTCP接続をハイジャックできるなら、攻撃者は、別の接続をサーバに開いて、介入者攻撃を始めることができます。 また、ARPスプーフィングで企業内情報通信網に介入者攻撃を仕掛けるのも些細です--攻撃者は犠牲者のIPアドレスと彼自身のMACアドレスでARPを鍛造します。 この種類の攻撃を仕掛けるツールは容易に利用可能です。
Note that it is only necessary to authenticate one side of the transaction in order to prevent man-in-the-middle attacks. In such a situation the the peers can establish an association in which only one peer is authenticated. In such a system, an attacker can initiate an association posing as the unauthenticated peer but cannot transmit or access data being sent on a legitimate connection. This is an acceptable situation in contexts such as Web e-commerce where only the server needs to be authenticated (or the client is independently authenticated via some non-cryptographic mechanism such as a credit card number).
介入者攻撃を防ぐために単にトランザクションの半面を認証するのが必要であることに注意してください。 そのような状況に、同輩は協会を1人の同輩だけが認証される設立できます。 そのようなシステムで、攻撃者は、正統の接続に送られるデータに、非認証された同輩のふりをする協会を開始できますが、伝えることができませんし、アクセスできません。 これはサーバだけが認証される必要がある(クライアントはクレジットカード番号などの何らかの非暗号のメカニズムで独自に認証されます)ウェブ電子商取引などの文脈の許容できる状況です。
3.4. Topological Issues
3.4. 位相的な問題
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つのプライマリ意味があります。
Rescorla & Korver Best Current Practice [Page 12] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[12ページ]。
3.5. On-path versus off-path
3.5. 経路である対オフ経路
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.
一般に、データグラムが1人のホストから別のホストまで送られるために、それは何らかのセットの中間的リンクとゲートウェイを横断しなければなりません。 そのようなゲートウェイは、その経路に沿って送られたどんなデータグラムも、読むか、変更するか、または自然に取り外すことができます。 これで、あなたが経路であるなら、さまざまな攻撃を仕掛けるのははるかに簡単になります。
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.
アプリケーションプロトコルデザイナーは、すべての攻撃者が経路になると仮定してはいけません。 可能などこプロトコルSHOULD、設計されているか、そして、ネットワークの完全なコントロールを持っている攻撃者から攻撃に抵抗してください。 しかしながら、デザイナーが経路のものと同様にオフ経路攻撃者が仕掛けることができる攻撃をより多く補強すると予想されます。
3.6. Link-local
3.6. リンク地方です。
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.
同じリンクの上にオン経路の1つの専門化しているケースがあります。 いくつかの状況で、企業内情報通信網の一員であるホストとそうしないそれらを見分けるのは望ましいです。 これのための標準のテクニックはIP TTL値[IP]について確かめることです。 TTLが各混載業者によって減少しなければならないので、プロトコルは、TTLが255に用意ができて、すべての受信機がTTLについて確かめるのを要求できます。 そして、受信機には、従うパケットが同じリンクから来ていると信じる何らかの理由があります。 システムにトンネルを堀ることの面前で慎重にこのテクニックを使用しなければならないことに注意してください、そのようなシステムがTTLを減少させないでパケットを通過するかもしれないので。
4. Common Issues
4. 共通の課題
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.
各システムのセキュリティ要件はユニークですが、ある一般的な要件は多くのプロトコルに現れます。 より良いソリューションは利用可能ですが、ナイーブなプロトコルデザイナーはこれらの要件に直面しているとき、しばしば、彼らが明白な、しかし、不安定なソリューションを選びます。 このセクションは多くのプロトコルとそれらを扱う際に役に立つかもしれない一般的なセキュリティー技術で見られた多くの問題について説明します。
Rescorla & Korver Best Current Practice [Page 13] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[13ページ]。
4.1. User Authentication
4.1. ユーザー認証
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.
リソースへのアクセスを制御したがっている本質的にはあらゆるシステムがユーザを認証する何らかの方法を必要とします。 そのようなほとんど数えられない数のメカニズムがこのために設計されています。 次の数人のセクションがこれらのテクニックのいくつかについて説明します。
4.1.1. Username/Password
4.1.1. ユーザ名/パスワード
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.
最も一般的なアクセス管理機構は、ユーザがユーザ名を供給する簡単なUSERNAME/PASSWORDとホストへの彼が使用したがっている再使用可能パスワードです。 攻撃者がワイヤからパスワードをかいで、次に、新しいセッションを開始するところでこのシステムは単純受動態攻撃に害を被りやすいです、パスワードを提示して。 TLSかIPSECなどの暗号化された接続の上でプロトコルをホスティングすることによって、この脅威を緩和できます。 保護のない(平文)ユーザ名/パスワードシステムはIETF規格で許容できません。
4.1.2. Challenge Response and One Time Passwords
4.1.2. チャレンジレスポンスと使い捨てパスワード
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.
USERNAME/PASSWORDよりすばらしいセキュリティを望んでいるシステムがしばしばONE TIME PASSWORD[OTP]体系かCHALLENGE- RESPONSEのどちらかを使います。 使い捨てパスワード体系では、パスワードのリストをユーザに提供します。(連続して、そして、あるとき、それぞれパスワードを使用しなければなりません)。 (ユーザが単に系列の次のパスワードを計算できるように、しばしば、これらのパスワードはいくらかの秘密鍵から生成されます。) 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.
体系の両方のタイプは反射攻撃にもかかわらず、まだOFFLINE KEYSEARCH ATTACK(受け身の攻撃のフォーム)にしばしば被害を受け易いことに対する保護を提供します: 以前に言及されるように、しばしば、ワンタイムパスワードか応答が共有秘密キーから計算されます。 攻撃者が使用される機能を知っているなら、彼は正しい出力を起こすものを見つけるまで単にすべての可能な共有秘密キーを試みることができます。 共有秘密キーがパスワードであるならこれをより簡単にします、その場合、彼がまさしく無作為のストリングよりむしろ一般的な語(または、ストリング)のリストを試みることを意味する場合、彼はDICTIONARY ATTACKを取り付けることができます。
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.
また、これらのシステムもしばしば活発な攻撃に害を被りやすいです。 コミュニケーションセキュリティが全体のセッションのために提供されない場合、攻撃者は、認証が実行されるまで単に待っていて、接続をハイジャックできます。
Rescorla & Korver Best Current Practice [Page 14] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[14ページ]。
4.1.3. Shared Keys
4.1.3. 共有されたキー
CHALLENGE-RESPONSE type systems can be made secure against dictionary attack by using randomly generated shared keys instead of user- generated passwords. If the keys are sufficiently large then keysearch attacks become impractical. This approach works best when the keys are configured into the end nodes rather than memorized and typed in by users, since users have trouble remembering sufficiently long keys.
CHALLENGE-RESPONSEタイプシステムをパスワードであると生成されたユーザの代わりに手当たりしだいに発生している共有されたキーを使用することによって辞書攻撃に対して安全にすることができます。 キーが十分大きいなら、keysearch攻撃は非実用的になります。 キーが暗記されるよりむしろエンドノードに構成されて、ユーザによってタイプされるとき、このアプローチはうまくいきます、ユーザが十分長いキーを覚えているのに苦労するので。
Like password-based systems, shared key systems suffer from management problems. Each pair of communicating parties must have their own agreed-upon key, which leads to there being a lot of keys.
パスワードベースのシステムのように、共有された主要なシステムは管理問題を欠点にさせます。それぞれの組についてパーティーを伝えると、それら自身の同意しているキーは持たれなければなりません。(それは、そこで多くのキーであるのに通じます)。
4.1.4. Key Distribution Centers
4.1.4. 主要な配送センター
One approach to solving the large number of keys problem is to use an online "trusted third party" that mediates between the authenticating parties. The trusted third party (generally called a a KEY DISTRIBUTION CENTER (KDC)) shares a symmetric key or password with each party in the system. It first contacts the KDC which gives it a TICKET containing a randomly generated symmetric key encrypted under both peer's keys. Since only the proper peers can decrypt the symmetric key the ticket can be used to establish a trusted association. By far the most popular KDC system is Kerberos [KERBEROS].
多くの重要問題を解決することへの1つのアプローチは認証パーティーと和解するオンライン「信頼できる第三者機関」を使用することです。 信頼できる第三者機関(一般に、KEY DISTRIBUTION CENTER(KDC)と呼ばれる)はシステムにおける各当事者と対称鍵かパスワードを共有します。 それは最初に、同輩のものが合わせる両方の下で暗号化された手当たりしだいに発生している対称鍵を含むTICKETをそれに与えるKDCに連絡します。 適切な同輩だけが対称鍵を解読することができるので、信じられた協会を証明するのにチケットを使用できます。 断然最もポピュラーなKDCシステムはケルベロス[ケルベロス]です。
4.1.5. Certificates
4.1.5. 証明書
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.
簡潔な解決法はすべてのユーザに次に彼らがプロトコルいくつかで特有の道を認証するのに使用するCERTIFICATES[PKIX]を持たせることです、[TLS]や[S/MIME]のように。 証明書は公開鍵への実体のアイデンティティを縛る署名している資格証明書です。 証明書の署名者がCERTIFICATE AUTHORITY(カリフォルニア)である、証明書がそうするかもしれない、それ自体、いくつかの優れたカリフォルニアによって署名されてください。 このシステムが扱うように、1CAsの信頼をバンドで出ているファッションに確立しなければなりません。 そのようなCAsはTRUSTED ROOTSかROOT CASと呼ばれます。 クライアント/サーバタイプシステムにおけるこのアプローチへのプライマリ障害は展開問題であるかもしれない証明書を持っているのがクライアントを必要とするということです。
4.1.6. Some Uncommon Systems
4.1.6. いくつかの珍しいシステム
There are ways to do a better job than the schemes mentioned above, but they typically don't add much security unless communications security (at least message integrity) will be employed to secure the connection, because otherwise the attacker can merely hijack the connection after authentication has been performed. A number of protocols ([EKE], [SPEKE], [SRP]) allow one to securely bootstrap a
前記のように体系より良い仕事をする方法がありますが、通信秘密保全(少なくともメッセージの保全)が接続を保証するのに使われないなら、多くのセキュリティを通常加えません、さもなければ、認証が実行された後に攻撃者が単に接続をハイジャックできるので。 多くのプロトコル[EKE][スピーク]で、1つはしっかりとaを独力で進むことができます[SRP)。
Rescorla & Korver Best Current Practice [Page 15] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[15ページ]。
user's password into a shared key which can be used as input to a cryptographic protocol. One major obstacle to the deployment of these protocols has been that their Intellectual Property status is extremely unclear. Similarly, the user can authenticate using public key certificates (e.g., S-HTTP client authentication). Typically these methods are used as part of a more complete security protocol.
暗号のプロトコルに入力されるように使用できる共有されたキーへのユーザのパスワード。 これらのプロトコルの展開への1つの重大な障害はそれらのIntellectual Property状態が非常に不明瞭であるということです。 同様に、ユーザは使用している公開鍵証明書(S HTTP例えば、クライアント認証)を認証できます。 通常、これらのメソッドは、より完全なセキュリティプロトコルの一部として使用されます。
4.1.7. Host Authentication
4.1.7. ホスト認証
Host authentication presents a special problem. Quite commonly, the addresses of services are presented using a DNS hostname, for instance as a URL [URL]. When requesting such a service, one has to ensure that the entity that one is talking to not only has a certificate but that that certificate corresponds to the expected identity of the server. The important thing to have is a secure binding between the certificate and the expected hostname.
ホスト認証は特別な問題を提示します。 全く一般的に、サービスのアドレスは、例えば、URL[URL]としてDNSホスト名を使用することで提示されます。 そのようなサービスを要求するとき、1つは、ものが話している実体が証明書を持っているだけではありませんが、その証明書がサーバの予想されたアイデンティティに一致しているのを保証しなければなりません。持っている重要なことは証明書と予想されたホスト名の間の安全な結合です。
For instance, it is usually not acceptable for the certificate to contain an identity in the form of an IP address if the request was for a given hostname. This does not provide end-to-end security because the hostname-IP mapping is not secure unless secure name resolution [DNSSEC] is being used. This is a particular problem when the hostname is presented at the application layer but the authentication is performed at some lower layer.
例えば、通常、証明書がIPアドレスの形にアイデンティティを含むのは、要求が与えられたホスト名のためのものであったなら許容できません。 安全な名前解決[DNSSEC]が使用されていない場合ホスト名IPマッピングが安全でないので、これは終わりから終わりへのセキュリティを提供しません。 ホスト名が応用層に提示されますが、認証が何らかの下層で実行されるとき、これは特定の問題です。
4.2. Generic Security Frameworks
4.2. ジェネリックセキュリティフレームワーク
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に表現される)への1つの応答は、低レベルセキュリティプロトコルを作成して、次に、新しいプロトコルがそのプロトコルの上に実行されると主張することです。 最近ポピュラーになった別のアプローチは一般的適用層のセキュリティフレームワークを設計することです。 考えはあなたがpluggableファッションで様々なセキュリティー対策を交渉できるプロトコルを設計するということです。 そして、アプリケーション・プロトコルデザイナーは、彼らのアプリケーション・プロトコルでセキュリティプロトコルPDUsを運ぶように手配します。 そのようなフレームワークに関する例は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
ジェネリックフレームワークアプローチには、多くの問題があります。最初に、それはDOWNGRADE ATTACKSに非常に影響されやすいです。 ダウングレード攻撃では、パーティーにそうでなければ、彼らがそうするだろうより弱い保護を交渉させるように、活発な攻撃者は交渉をいじります。 交渉と主要な設立が両方を完成させた後に保全チェックを含んでいるのが可能ですが、この保全チェックの強さは必ず最も弱い一般的なアルゴリズムに制限されます。 しかし、この問題はどんな交渉アプローチでも存在しています。
Rescorla & Korver Best Current Practice [Page 16] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[16ページ]。
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はそれら自身のを設計することの代わりに確立したものの1つを選びます。
4.3. Non-repudiation
4.3. 非拒否
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)は問題のメッセージにデジタルに署名します。 1時の署名パーティーが指すという証拠が議論されたメッセージに同意したようにカウンターパーティ(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.
署名パーティーがメッセージを拒否する最も簡単な方法は彼の秘密鍵が感染されて、攻撃者(もっとも、必ず信用パーティーであるというわけではない)が議論されたメッセージに署名したと主張することです。 この攻撃に対して信用を防御するために、パーティーは、署名パーティーのキーが署名時点で感染されていなかったのを示す必要があります。 これはかなりのインフラストラクチャを必要とします、メッセージが署名された時に証明書取消し情報と確立するタイムスタンプサーバのアーカイブ領域を含んでいて。
Rescorla & Korver Best Current Practice [Page 17] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[17ページ]。
Additionally, the relying party might attempt to trick the signing party into signing one message while thinking he's signing another. This problem is particularly severe when the relying party controls the infrastructure that the signing party uses for signing, such as in kiosk situations. In many such situations the signing party's key is kept on a smartcard but the message to be signed is displayed by the relying party.
さらに、信用パーティーは、彼が別のものに署名していると思っている間、署名パーティーが1つのメッセージに署名するようにだますのを試みるかもしれません。 信用パーティーが署名パーティーがキオスク状況などのように署名するのに使用するインフラストラクチャを制御するとき、この問題は特に厳しいです。 そのような多くの状況で、署名パーティーのキーはスマートカードの上に保たれますが、署名するべきメッセージは信用パーティーによって表されます。
All of these complications make non-repudiation a difficult service to deploy in practice.
これらの複雑さのすべてが、実際には展開するために非拒否を難しいサービスにします。
4.4. Authorization vs. Authentication
4.4. 承認対認証
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.
承認は必ず認証に依存しますが、認証だけが承認を含意しません。 むしろ、動作を実行する許可を与える前に、その動作が受入れられるかどうか決定するために承認メカニズムに相談しなければなりません。
4.4.1. Access Control Lists
4.4.1. アクセスコントロールリスト
One common form of authorization mechanism is an access control list (ACL), which lists users that are permitted access to a resource. Since assigning individual authorization permissions to each resource is tedious, resources are often hierarchically arranged so that the parent resource's ACL is inherited by child resources. This allows administrators to set top level policies and override them when necessary.
1つの一般的なフォームの承認メカニズムはアクセスコントロールリスト(ACL)です。(そのアクセスコントロールリストはリソースへのアクセスが受入れられるユーザを記載します)。 個々の承認許容を各リソースに割り当てるのが退屈であるので、リソースが階層的にしばしば配置されるので、親リソースのACLは子供リソースによって引き継がれます。 これで、管理者は、最高平らな方針を設定して、必要であるときに、それらをくつがえします。
4.4.2. Certificate Based Systems
4.4.2. ベースのシステムを証明してください。
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
例えば、証明書で、有効な署名を提示するのは承認を含意しません。 信じられた根を含む証明書チェーンは署名を支持しなければなりません、そして、その根は支持するに違いありません。
Rescorla & Korver Best Current Practice [Page 18] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[18ページ]。
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カリフォルニアによって発行された証明書を持っているユーザはAcme Accountingカリフォルニアによって発行された証明書を持っているユーザと異なったウェブアクセス権を持っているかもしれません、これらのCAsの両方がAcmeウェブサーバーによって「信じられます」が。
Mechanisms for enforcing these more complicated properties have not yet been completely explored. One approach is simply to attach policies to ACLs describing what sorts of certificates are trusted. Another approach is to carry that information with the certificate, either as a certificate extension/attribute [PKIX, SPKI] or as a separate "Attribute Certificate".
これらのより複雑な特性を実施するためのメカニズムはまだ完全に探られるというわけではありませんでした。 1つのアプローチは単にどんな種類の証明書が信じられるかを説明するACLsに方針を付けることです。 別のアプローチは証明書拡大/属性[PKIX、SPKI]として、または、証明書か、別々の「属性証明書」としてその情報を運ぶことです。
4.5. Providing Traffic Security
4.5. トラヒック保全を提供します。
Securely designed protocols should provide some mechanism for securing (meaning integrity protecting, authenticating, and possibly encrypting) all sensitive traffic. One approach is to secure the protocol itself, as in [DNSSEC], [S/MIME] or [S-HTTP]. Although this provides security which is most fitted to the protocol, it also requires considerable effort to get right.
しっかりと設計されたプロトコルは(意味保全保護、認証、およびことによると暗号化)にすべての敏感なトラフィックを保証するのに何らかのメカニズムを提供するべきです。 1つのアプローチは[DNSSEC]、[S/MIME]または[S-HTTP]のようにプロトコル自体を保証することです。 これはプロトコルに最も合われているセキュリティを提供しますが、また、正しくなるのがかなりの取り組みを必要とします。
Many protocols can be adequately secured using one of the available channel security systems. We'll discuss the two most common, IPsec [AH, ESP] and [TLS].
利用可能なチャンネルセキュリティシステムの1つを使用することで多くのプロトコルを適切に保証できます。IPsec[AH、超能力]と[TLS]、私たちは最も一般的に2について議論するつもりです。
4.5.1. IPsec
4.5.1. IPsec
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と超能力)は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か超能力が使用されているとき、使用されるAHか超能力実装によって、アプリケーション・プログラマーは、何もする必要はありませんし(AHか超能力がシステム全体で有効にされたなら)、また特定のソフトウェア変更を行う必要があるかもしれません(例えば、特定のsetsockopt()が呼ぶと言い足します)。 残念ながら、IPsec実装を制御するためのAPIはまだ標準化されていません。
Rescorla & Korver Best Current Practice [Page 19] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[19ページ]。
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を追加するのは、オペレーティングシステムを変えることを伴います、カーネルで変更するか、または新しいドライバーをインストールすることによって。 これは実質的に単に新しいアプリケーションをインストールするより大きい仕事です。 しかしながら、多くの商品オペレーティングシステムの最近のバージョンが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が利用可能になると仮定してはいけません。 SHOULD NOTが単に述べる一般的適用層のプロトコルのためのIPsecがそうであるに違いない安全保障政策が使用されて、信じる何らかの理由がない場合、そのIPsecは意図している展開環境で利用可能になるでしょう。 IPsecが利用可能でないかもしれなく、トラフィックが唯一TCPである環境で、TLSは選択のメソッドです、アプリケーション開発者が彼のパッケージにTLS実装を含んでいることによって容易に存在を確実にすることができるので。
In the special-case of IPv6, both AH and ESP are mandatory to implement. Hence, it is reasonable to assume that AH/ESP are already available for IPv6-only protocols or IPv6-only deployments. However, automatic key management (IKE) is not required to implement so protocol designers SHOULD not assume it will be present. [USEIPSEC] provides quite a bit of guidance on when IPsec is a good choice.
IPv6の特別な場合では、AHと超能力の両方が、実装するために義務的です。 したがって、AH/超能力が既にIPv6だけプロトコルかIPv6だけ展開に利用可能であると仮定するのは妥当です。 しかしながら、プロトコルデザイナーSHOULDがそれを仮定しないで、実装する(IKE)は必要でない自動かぎ管理が存在するでしょう。 [USEIPSEC]はIPsecが良い選択である時かなりの指導を提供します。
4.5.2. SSL/TLS
4.5.2. SSL/TLS
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実装はバークレーのSocketsのようなインタフェースを簡単なプログラミングに通常提供します。 プライマリ問題はTLSの周りでプロトコルソリューションを設計するとき、TLSを使用することで保護された接続とそうしないそれらを区別することです。
Rescorla & Korver Best Current Practice [Page 20] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[20ページ]。
The two primary approaches used have a separate well-known port for TLS connections (e.g., the HTTP over TLS port is 443) [HTTPTLS] or to have a mechanism for negotiating upward from the base protocol to TLS as in [UPGRADE] or [STARTTLS]. When an upward negotiation strategy is used, care must be taken to ensure that an attacker can not force a clear connection when both parties wish to use TLS.
プライマリアプローチが使用した2はTLS接続(例えば、TLSポートの上のHTTPは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などの信頼できるプロトコルによることに注意してください。 これは2つの注目に値する困難を作り出します。 まず最初に、UDPを使用するデータグラムプロトコルを保証するのにそれを使用できません。 2番目に、TLSはIPsecがそうでないIP層の攻撃に影響されやすいです。 通常、これらの攻撃は何らかの形式のサービスか接続暗殺の否定を取ります。 例えば、攻撃者は、SSL接続を止めるためにTCP RSTを鍛造するかもしれません。 TLSにはトランケーション攻撃を検出するメカニズムがありますが、これらは、犠牲者が、彼が攻撃されているのを知っているのを単に許容して、そのような攻撃に直面して接続の生存性を前提としません。 対照的に、IPsecが使用されているなら、TCP接続に影響しないで、そのような偽造RSTを拒絶できるでしょうに。 TCP接続に対する偽造RSTsか他のそのような攻撃が関心であるなら、AH/超能力かTCP MD5オプション[TCPMD5]が都合のよい選択です。
4.5.2.1. Virtual Hosts
4.5.2.1. 事実上のホスト
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]を使用できます、広い展開を見たのが新し過ぎますが。
4.5.2.2. Remote Authentication and TLS
4.5.2.2. リモート認証とTLS
One difficulty with using TLS is that the server is authenticated via a certificate. This can be inconvenient in environments where previously the only form of authentication was a password shared between client and server. It's tempting to use TLS without an authenticated server (i.e., with anonymous DH or a self-signed RSA certificate) and then authenticate via some challenge-response mechanism such as SASL with CRAM-MD5.
TLSを使用する1つの困難はサーバが証明書で認証されるということです。 これは以前に唯一の形式の認証がクライアントとサーバの間で共有されたパスワードであったところで環境で不便である場合があります。それは認証されたサーバ(すなわち、匿名のDHか自己によって署名されたRSA証明書がある)なしでTLSを使用して、次に、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
残念ながら、SASLとTLSのこの構成は人が予想するだろうというほど強くはありません。 活発な攻撃者がこの接続をハイジャックするのは、簡単です。 クライアントは中期にSSL接続を配置します、そして、(私たちが通常、この攻撃を防ぐことであるサーバを認証していないのを覚えていてください)次に、単にプロキシはSASL握手を配置します。 the
Rescorla & Korver Best Current Practice [Page 21] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[21ページ]。
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.
はっきりと、少なくともそんなにまで攻撃者は関係があります。 この攻撃を防ぐために、クライアントは、サーバの証明書について確かめる必要があります。
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クライアントはそれで「私のアイデンティティがないかどうか外側のチャンネルを調べてください」をサーバに言うことができます)。 明らかに、これは上で説明されたレイヤリング攻撃を受けることがありません。
4.5.3. Remote Login
4.5.3. リモート・ログイン
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/超能力があらゆるパケットを認証して、暗号化するので、これは20倍のデータ展開を意味できます。 telnet暗号化オプション[ENCOPT]は、メッセージの保全に先立つことによって、この拡張を防ぎます。
When using remote terminal service, it's often desirable to securely perform other sorts of communications services. In addition to providing remote login, SSH [SSH] also provides secure port forwarding for arbitrary TCP ports, thus allowing users run arbitrary TCP-based applications over the SSH channel. Note that SSH Port Forwarding can be security issue if it is used improperly to circumvent firewall and improperly expose insecure internal applications to the outside world.
遠隔端末サービスを利用するとき、しっかりと他の種類の情報提供サービスを実行するのはしばしば望ましいです。 また、リモート・ログインを提供することに加えて、SSH[SSH]は任意のTCPポートのための安全なポートフォワーディングを提供します、その結果、SSHチャンネルの上の任意のTCPベースのアプリケーションをユーザ走行に許容します。 それがファイアウォールを回避して、不適切に不安定な内部のアプリケーションを外の世界に暴露するのに不適切に使用されるならSSH Port Forwardingが安全保障問題であるかもしれないことに注意してください。
4.6. Denial of Service Attacks and Countermeasures
4.6. サービス不能攻撃と対策
Denial of service attacks are all too frequently viewed as an fact of life. One problem is that an attacker can often choose from one of many denial of service attacks to inflict upon a victim, and because most of these attacks cannot be thwarted, common wisdom frequently assumes that there is no point protecting against one kind of denial of service attack when there are many other denial of service attacks that are possible but that cannot be prevented.
サービス不能攻撃は現実としてすべて頻繁過ぎ見なされます。 1つの問題がこれらの攻撃の大部分を阻まれることができないので攻撃者が犠牲者で加える多くのサービス不能攻撃の1つからしばしば選ぶことができるということである、一般的な知恵は頻繁に可能なサービス攻撃の他の多くの否定がありますが、防ぐことができない1種類のサービス不能攻撃から守るポイントが全くないと仮定します。
Rescorla & Korver Best Current Practice [Page 22] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[22ページ]。
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.
インターネット規格の作者は、それらのプロトコルがどのサービス不能攻撃に影響されやすいかを説明しなければなりません。 この記述は、それが無理であった理由を含まなければならないか、または試みる範囲からこれらのサービス不能攻撃を避けなければなりません。
4.6.1. Blind Denial of Service
4.6.1. 盲目のサービス妨害
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.
BLINDサービス不能攻撃は特に有害です。 盲目の攻撃によって、攻撃者には、重要な利点があります。 攻撃者が犠牲者からトラフィックを受けることができなければならないなら、彼は、ルーティング骨組みを打倒しなければならないか、または彼自身のIPアドレスを使用しなければなりません。 どちらかが犠牲者が攻撃者を追跡する、そして/または、彼のトラフィックを無視する機会を提供します。 ブラインドと共に、攻撃者が使用できる攻撃はIPアドレスを偽造しました、犠牲者が彼のパケットを無視するのを非常に難しくして。 TCP SYNフラッド攻撃は盲目の攻撃に関する例です。 デザイナーは盲目のサービス不能攻撃を防ぐのにおいて可能に最善の努力をするべきです。
4.6.2. Distributed Denial of Service
4.6.2. 分散型サービス妨害
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
さらに危険であるのは、DISTRIBUTEDサービス不能攻撃(DDoS)[DDOS]です。 DDoSでは、攻撃者は、多くのマシンが同時にターゲットマシンを攻撃するように手配します。 通常、これは、攻撃のリモート開始を許容するプログラムで多くのマシンを染めることによって、達成されます。 実際に攻撃を実行するマシンは、ZOMBIEsと呼ばれて、完全に本当の攻撃者と異なった位置で疑わない第三者によっておそらく所有されています。 そしてDDoS攻撃はゾンビが、しばしば正統のプロトコル要求をしているように見えるので反対するのが非常に困難である場合がある。
Rescorla & Korver Best Current Practice [Page 23] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[23ページ]。
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攻撃は邪魔するのが難しい場合がありますが、プロトコルを設計している間、プロトコルデザイナーはこれらの形式の攻撃において認識力があると予想されます。
4.6.3. Avoiding Denial of Service
4.6.3. サービス妨害を避けます。
There are two common approaches to making denial of service attacks more difficult:
サービス不能攻撃をより難しくすることへの2つの一般的なアプローチがあります:
4.6.3.1. Make your attacker do more work than you do
4.6.3.1. 攻撃者にさせるよりさらに多くの仕事をさせてください。
If an attacker consumes more of his resources than yours when launching an attack, attackers with fewer resources than you will be unable to launch effective attacks. One common technique is to require the attacker perform a time-intensive operation, such as a cryptographic operation. Note that an attacker can still mount a denial of service attack if he can muster substantially sufficient CPU power. For instance, this technique would not stop the distributed attacks described in [TCPSYN].
攻撃を開始するとき、攻撃者が彼のリソースをあなたのものよりまだ消費していると、あなたより少ないリソースをもっている攻撃者は有効な攻撃に着手できないでしょう。 1つの一般的なテクニックは攻撃者を必要とするのが暗号の操作などの時間集約型の操作を実行するということです。 彼が実質的に十分なCPUパワーを召集できるなら攻撃者がまだサービス不能攻撃を仕掛けることができることに注意してください。 例えば、このテクニックは[TCPSYN]で説明された分配された攻撃を止めないでしょう。
4.6.3.2. Make your attacker prove they can receive data from you
4.6.3.2. 攻撃者に彼らがデータを受け取ることができると立証させてください。
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.
その結果、攻撃者(少なくともスプーフィング攻撃の文脈の)にとって、小さいサブネットのホストは、反攻撃測定を場所に入れることができる(例えば、そのサブネットからすべてのトラフィックを下げるために境界ルータを構成できる)ようにサブネット(攻撃者の居場所を見つけるのに十分であるべきである)に攻撃をたどって戻すことができるので、役に立ちません。 一般的なテクニックは攻撃者が前に交換処理で獲得された情報を使用することで返答するのが必要であることです。
4.6.4. Example: TCP SYN Floods
4.6.4. 例: TCP SYN洪水
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で説明される)に被害を受け易いです。 まず最初に、攻撃者は、犠牲者に単一のパケットを送ることによって、重要なリソース(この場合メモリ)を強制的に、消費させることができます。 2番目に、攻撃者が今までに犠牲者からデータを受け取ったことがなくてこの動作を実行できるので、匿名で攻撃を実行できます(したがって、多くの偽造ソースアドレスを使用して)。
Rescorla & Korver Best Current Practice [Page 24] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[24ページ]。
4.6.5. Example: Photuris
4.6.5. 例: Photuris
[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は、攻撃者に返される「クッキー」を生成するのに時間異形秘密を使います。 交換が進歩をするその後のメッセージでこのクッキーを返さなければなりません。 おもしろい特徴は犠牲者が後で交換でこのクッキーを作り直すことができて、その結果、攻撃者が、彼が犠牲者からパケットを受けることができると立証した後まで状態が全く犠牲者が保有される必要はないということです。
4.7. Object vs. Channel Security
4.7. チャンネルセキュリティに対して反対してください。
It's useful to make the conceptual distinction between object security and channel security. Object security refers to security measures which apply to entire data objects. Channel security measures provide a secure channel over which objects may be carried transparently but the channel has no special knowledge about object boundaries.
オブジェクトセキュリティとチャンネルセキュリティの間で概念的な区別をするのは役に立ちます。 オブジェクトセキュリティは全体のデータ・オブジェクトに適用される安全策を示します。 チャンネル安全策はオブジェクトが透過的に運ばれるかもしれませんが、チャンネルがオブジェクト境界に関するどんな特別な知識も持っていない安全なチャンネルを提供します。
Consider the case of an email message. When it's carried over an IPSEC or TLS secured connection, the message is protected during transmission. However, it is unprotected in the receiver's mailbox, and in intermediate spool files along the way. Moreover, since mail servers generally run as a daemon, not a user, authentication of messages generally merely means authentication of the daemon not the user. Finally, since mail transport is hop-by-hop, even if the user authenticates to the first hop relay the authentication can't be safely verified by the receiver.
メールメッセージに関するケースを考えてください。 接続であることが固定されたIPSECかTLSを引き継いだとき、メッセージはトランスミッションの間、保護されます。 しかしながら、それは受信機のメールボックス、および道に沿った中間的スプール・ファイルにおいて保護がありません。 そのうえ、メールサーバがユーザではなく、デーモンとして一般に稼働しているので、一般に、メッセージの認証は単にユーザではなく、デーモンの認証を意味します。 最終的に、メール輸送がホップであることごとに、ユーザが最初のホップリレーに認証を認証しても、受信機は安全に確かめることができません。
By contrast, when an email message is protected with S/MIME or OpenPGP, the entire message is encrypted and integrity protected until it is examined and decrypted by the recipient. It also provides strong authentication of the actual sender, as opposed to the machine the message came from. This is object security. Moreover, the receiver can prove the signed message's authenticity to a third party.
メールメッセージがS/MIMEかOpenPGPと共に保護されるとき、対照的に、全体のメッセージは暗号化されていて、それが受取人によって調べられて、解読されるまで、保全は保護されました。 また、それはメッセージが来たマシンと対照的に実際の送付者の強い認証を提供します。 これはオブジェクトセキュリティです。 そのうえ、受信機は署名しているメッセージの第三者の信憑性となることができます。
Note that the difference between object and channel security is a matter of perspective. Object security at one layer of the protocol stack often looks like channel security at the next layer up. So, from the perspective of the IP layer, each packet looks like an individually secured object. But from the perspective of a web client, IPSEC just provides a secure channel.
オブジェクトとチャンネルセキュリティの違いが見解の問題であることに注意してください。 プロトコル・スタックの1つの層のオブジェクトセキュリティはしばしば次の層で上がっているチャンネルセキュリティに似ています。 それで、IP層の見解から、各パケットは個別に機密保護しているオブジェクトに似ています。 しかし、ウェブクライアントの見解から、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
区別はいつも明快であるというわけではありません。 そして例えば、S-HTTPがただ一つのHTTPトランザクションのために平らなセキュリティをオブジェクトに供給しますが、ウェブページが複数のHTTPトランザクションから通常成る、(ベースのページ。
Rescorla & Korver Best Current Practice [Page 25] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[25ページ]。
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.
多数のインライン画像) したがって、総ウェブページの見解から、これはチャンネルセキュリティにむしろさらに似ています。 ウェブページのためのオブジェクトセキュリティは単一の単位としてページの遷移的な閉鎖とそのすべての埋め込まれた内容のためのセキュリティから成るでしょう。
4.8. Firewalls and Network Topology
4.8. ファイアウォールとネットワーク形態
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.
ファイアウォールを使用する外部の、そして、内部のネットワークにネットワークを仕切るのは、現代のネットワークの共通の安全保障習慣です。 次に、内部のネットワークが安全であると思われて、限られた安全策だけがそこで使用されます。 そのようなネットワークの内部の部分はしばしば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.
2番目に、位相的に切断されるように見えるネットワークはそうではありません。 1つの理由はネットワークが外の世界でアクセスを許すために再構成されたということであるかもしれません。 そのうえ、ファイアウォールはますます[SOAP]か[HTTP]などの一般的適用層のプロトコルを通過しています。 一般に、これらのジェネリックプロトコルに基づいているネットワーク・プロトコルは、ファイアウォールがそれらを保護すると仮定できません。 最終的に、システムへの最も重大な軍事的脅威の1つは部外者ではなく、インサイダーから来ています。 インサイダーが定義上内部のネットワークに近づく手段を持っているので、ファイアウォールなどの位相的な保護はそれらを保護しないでしょう。
5. Writing Security Considerations Sections
5. セキュリティ問題部に書きます。
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
それはどんな与えられたプロトコルやシステムもすべての形式の攻撃に免疫であるという要件ではありませんが、作者が可能であるとしての多くのフォームをみなすのがまだ必要です。 Security Considerations部の目的の一部は範囲の外にどんな攻撃があるか、そして、それらに対して防御するためにどんな対策は適用できるかを説明することです。 コネ
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.
脅威の種類の明確な記述が説明されたプロトコルか技術にあるべきです。 これは、すべての知られているか予見できる危険について説明して、潜在的implementersへの脅威とユーザで「適切な注意」を実行するために取り組みとしてアプローチされるべきです。
Rescorla & Korver Best Current Practice [Page 26] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[26ページ]。
Authors MUST describe
作者は説明しなければなりません。
1. which attacks are out of scope (and why!)
2. which attacks are in-scope
2.1 and the protocol is susceptible to
2.2 and the protocol protects against
1. 範囲の外にどの攻撃がありますか?(なぜです) 2. どれに攻撃は範囲の2.1であり、プロトコルは2.2に影響されやすく、プロトコルは保護されますか。
At least the following forms of attack MUST be considered: eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle. Potential denial of service attacks MUST be identified as well. If the protocol incorporates cryptographic protection mechanisms, it should be clearly indicated which portions of the data are protected and what the protections are (i.e., integrity only, confidentiality, and/or endpoint authentication, etc.). Some indication should also be given to what sorts of attacks the cryptographic protection is susceptible. Data which should be held secret (keying material, random seeds, etc.) should be clearly labeled.
少なくとも以下の形式の攻撃を考えなければなりません: 盗聴、再生、メッセージ挿入、削除、変更、および中央の男性。 また、潜在的サービス不能攻撃を特定しなければなりません。 プロトコルが暗号の保護メカニズムを組み込むなら、データのどの部分が保護されるか、そして、保護がなにか(すなわち、保全だけ、秘密性、そして/または、終点認証など)であるかが明確に示されるべきです。 また、何らかの指示はどんな種類の攻撃に考えて、暗号の保護が影響されやすいということであるべきです。 秘密であるとして(材料、無作為の種子などを合わせます)保持されるべきであるデータは明確にラベルされるべきです。
If the technology involves authentication, particularly user-host authentication, the security of the authentication method MUST be clearly specified. That is, authors MUST document the assumptions that the security of this authentication method is predicated upon. For instance, in the case of the UNIX username/password login method, a statement to the effect of:
技術が認証、特にユーザー・ホスト認証を伴うなら、明確に認証方法のセキュリティを指定しなければなりません。 すなわち、作者は仮定をこの認証方法のセキュリティが叙述される記録しなければなりません。 例えば、以下の効果へのUNIXユーザ名/パスワードログインメソッドの場合における声明
Authentication in the system is secure only to the extent that it
is difficult to guess or obtain a ASCII password that is a maximum
of 8 characters long. These passwords can be obtained by sniffing
telnet sessions or by running the 'crack' program using the
contents of the /etc/passwd file. Attempts to protect against
on-line password guessing by (1) disconnecting after several
unsuccessful login attempts and (2) waiting between successive
password prompts is effective only to the extent that attackers
are impatient.
システムにおける認証は長い間最大8つのキャラクタであるASCIIパスワードを推測するか、または得るのが難しいという範囲だけに安全です。 /etc/passwdファイルのコンテンツを使用しながら、telnetセッションをかぐか、または'ひび'プログラムを動かすことによって、これらのパスワードを得ることができます。 (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ファイルがユーザ名を写像するので、ユーザイド、グループなどに、それは世界読み込み可能であるに違いありません。 実行しているひびをより難しくするのを除いて、この用法を可能にするために、ファイルはしばしば/etc/passwdと'影'パスワードファイルに分けられます。 影のファイルは、世界読み込み可能でなく、暗号化されたパスワードを含んでいます。 通常の/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
人のプロトコルが何らかの下層セキュリティプロトコルの上の走行であるべきであると単に述べるのは不十分です。 システムが下層を当てにされるなら、セキュリティはセキュリティ、保護のためにそれらを修理します。
Rescorla & Korver Best Current Practice [Page 27] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[27ページ]。
services are expected to provide MUST be clearly specified. In addition, the resultant properties of the combined system need to be specified.
サービスは予想されて、明確に提供するのを指定しなければならないということです。 さらに、混合構造の結果の特性は、指定される必要があります。
Note: In general, the IESG will not approve standards track protocols which do not provide for strong authentication, either internal to the protocol or through tight binding to a lower layer security protocol.
以下に注意してください。 一般に、IESGは強い認証に備えない標準化過程プロトコルを承認しないでしょう、プロトコルか強力結合を通して下層セキュリティプロトコルに内部です。
The threat environment addressed by the Security Considerations section MUST at a minimum include deployment across the global Internet across multiple administrative boundaries without assuming that firewalls are in place, even if only to provide justification for why such consideration is out of scope for the protocol. It is not acceptable to only discuss threats applicable to LANs and ignore the broader threat environment. All IETF standards-track protocols are considered likely to have deployment in the global Internet. In some cases, there might be an Applicability Statement discouraging use of a technology or protocol in a particular environment. Nonetheless, the security issues of broader deployment should be discussed in the document.
ファイアウォールが適所にあると仮定しない、Security Considerations部によって扱われた脅威環境は複数の管理境界の向こう側に世界的なインターネットの向こう側に最小限で展開を含まなければなりません、範囲の外にそのような考慮がある理由の正当化をプロトコルに提供するために唯一であっても。 LANに適切な脅威について議論するだけであり、より広い脅威環境を無視するのは許容できません。 すべてのIETF標準化過程プロトコルが世界的なインターネットに展開を持っていそうであると考えられます。 いくつかの場合、特定の環境における技術かプロトコルのApplicability Statementのがっかりしている使用があるかもしれません。 それにもかかわらず、ドキュメントで、より広い展開の安全保障問題について議論するべきです。
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のためにApplicability Statementに結びつけられるかもしれません。
6. Examples
6. 例
This section consists of some example security considerations sections, intended to give the reader a flavor of what's intended by this document.
このセクションはこのドキュメントで意図することに関する風味を読者に与えることを意図するいくつかの例のセキュリティ問題部から成ります。
Rescorla & Korver Best Current Practice [Page 28] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[28ページ]。
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番目の例は現在のプロトコルから切り取られた優れた警備体制問題部です。
6.1. SMTP
6.1. SMTP
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.
RFC821が書かれたとき、Security Considerations部はRFCsで必要ではありませんでした、そして、なにもそのドキュメントに含まれていません。 [RFC2821]は、RFC821をアップデートして、詳細なセキュリティ問題部を加えました。 私たちはここでそのドキュメント(新しいセクション番号がある)からSecurity Considerations部を再生させます。 私たちのコメントは、'注意で字下がりにされて、前書きされます:、' また、私たちは、私たちが重要であると考える話題をカバーするために多くの新しいセクションを加えます。 それらのセクションは[NEW]と共に節の見出しでマークされます。
6.1.1. Security Considerations
6.1.1. セキュリティ問題
6.1.1.1. Mail Security and Spoofing
6.1.1.1. セキュリティとスプーフィングを郵送してください。
SMTP mail is inherently insecure in that it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else. Constructing such a message so that the "spoofed" behavior cannot be detected by an expert is somewhat more difficult, but not sufficiently so as to be a deterrent to someone who is determined and knowledgeable. Consequently, as knowledge of Internet mail increases, so does the knowledge that SMTP mail inherently cannot be authenticated, or integrity checks provided, at the transport level. Real mail security lies only in end-to-end methods involving the message bodies, such as those which use digital signatures (see [14] and, e.g., PGP [4] or S/MIME [31]).
かなりカジュアルなユーザさえ直接、SMTPサーバーを受け取って、リレーすると交渉して、ナイーブな受取人が、他のどこかから来たと信じているようにだますメッセージを作成するのが、可能であるので、SMTPメールは本来不安定です。 そのようなメッセージを構成するのは、いくらか難しいのですが、専門家が「偽造している」振舞いを検出できないくらい断固としてだれか博識な人への抑止力になるように十分難しいというわけではありません。 その結果、インターネット・メールに関する知識が増加するのに従って、本来SMTPメールを認証できなかったか、または保全チェックが提供されたという知識もそうします、輸送レベルで。 そして、本当のメールセキュリティが単に終わりから終わりへのメッセージ本体を伴うメソッドであります、デジタル署名を使用するものなどのように([14]を見てください、例えば、PGP[4]かS/MIME[31])。
NOTE: One bad approach to sender authentication is [IDENT] in
which the receiving mail server contacts the alleged sender and
asks for the username of the sender. This is a bad idea for a
number of reasons, including but not limited to relaying, TCP
connection hijacking, and simple lying by the origin server.
Aside from the fact that IDENT is of low security value, use of
IDENT by receiving sites can lead to operational problems. Many
sending sites blackhole IDENT requests, thus causing mail to be
held until the receiving server's IDENT request times out.
以下に注意してください。 送付者認証への1つの悪いアプローチが、受信が申し立てられた送付者をサーバ接触に郵送する[IDENT]であり、送付者のユーザ名を求めます。 これは様々な意味で悪い考えです、他のリレー、TCP接続ハイジャック、発生源サーバによる簡単なおよび嘘をつくことを含んでいて。IDENTには低セキュリティ価値があるという事実は別として、サイトを受け取るのによるIDENTの使用は運転上の問題多くの送付サイトblackhole IDENT要求につながることができます、その結果、受信サーバのIDENTが外で回を要求するまで、メールが保持されることを引き起こします。
Various protocol extensions and configuration options that provide authentication at the transport level (e.g., from an SMTP client to an SMTP server) improve somewhat on the traditional situation described above. However, unless they are accompanied by careful
輸送レベル(例えば、SMTPクライアントからSMTPサーバーまでの)で認証を提供する様々なプロトコル拡大と設定オプションが上で説明された伝統的な状況をいくらか改良します。 しかしながら、それらは慎重によって伴われません。
Rescorla & Korver Best Current Practice [Page 29] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[29ページ]。
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.
入念に設計された信頼環境における責任のhandoffs、それらは本来輸送システムの保全によるより終わりから終わりへのむしろデジタルに署名しているメッセージを使用するメカニズムより弱いままで残っています。
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"分野にそれら自身のを除いた有効なアドレスを示すように設定するのをより難しくする取り組みは主に指導を誤られます: 彼らはメールが別のものを代表して1人のユーザによって送られるか、または誤り(または、標準)回答が特別なアドレスに向けられるべきである正統のアプリケーションをだめにします。 (ユーザが1メッセージあたり1個のベースでこれらの分野を変更する便利な方法を提供するシステムは、分別よくメッセージデータの中の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.2Inの上のテキストがそうするコミュニケーションのセキュリティとSMTPの追加材料がその事実を反映するためにいくらか編集されると言い足しました。
6.1.1.2. Blind Copies
6.1.1.2. 盲目のコピー
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.
メッセージヘッダーに現れないアドレスはRCPTコマンドにSMTPサーバーにおいて様々な意味で現れるかもしれません。 2、ほとんどのコモンが「リスト発破器」(複数のアドレスに変えるただ一つのアドレス)としての郵送先住所の使用と「盲目のコピー」の外観にかかわります。 特に1つ以上のRCPTコマンドが存在しているとき、これらのメカニズムの目的のいくつかをくつがえすのを避けるために、SMTPクライアントとサーバSHOULD NOTは跡のヘッダーの一部とした、または、ヘッダーか、情報としたRCPTコマンド議論か個人的な拡張ヘッダーのフルセットをコピーします。 この規則に実際にはしばしば違反して、励行できないので、"bcc"使用を意識している送付SMTPシステムは、ただ一つのRCPTコマンドだけを含む別々のメッセージトランザクションとしてそれぞれの盲目のコピーを送るのに役立っているのがわかるかもしれません。
There is no inherent relationship between either "reverse" (from
MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
transaction ("envelope") and the addresses in the headers. Receiving
systems SHOULD NOT attempt to deduce such relationships and use them
SMTPトランザクション(「封筒」)の「逆(メール、SAMLなどからのコマンド)」の、または、「前進」の(RCPT)アドレスとアドレスとのどんな固有の関係もヘッダーにありません。 受電方式SHOULD NOTはそのような関係を推論して、それらを使用するのを試みます。
Rescorla & Korver Best Current Practice [Page 30] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[30ページ]。
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.
配送へのメッセージのヘッダーを変更するために。 」 ヘッダーは故意でない情報公開とSHOULD NOTの共通ソースと同様にこの原則の違反です。ポピュラーである、「明らかである、-、使用されます。
6.1.1.3. VRFY, EXPN, and Security
6.1.1.3. VRFY、EXPN、およびセキュリティ
As discussed in section 3.5, individual sites may want to disable either or both of VRFY or EXPN for security reasons. As a corollary to the above, implementations that permit this MUST NOT appear to have verified addresses that are not, in fact, verified. If a site disables these commands for security reasons, the SMTP server MUST return a 252 response, rather than a code that could be confused with successful or unsuccessful verification.
セクション3.5で議論するように、個々のサイトは安全保障上の理由でVRFYかEXPNのどちらかか両方を無効にしたがっているかもしれません。 上記での推論として、これを可能にする実装は事実上、確かめられないアドレスについて確かめたように見えてはいけません。 サイトが安全保障上の理由でこれらのコマンドを無効にするなら、SMTPサーバーはうまくいっているか失敗の検証に混乱できたコードよりむしろ252応答を返さなければなりません。
Returning a 250 reply code with the address listed in the VRFY command after having checked it only for syntax violates this rule. Of course, an implementation that "supports" VRFY by always returning 550 whether or not the address is valid is equally not in conformance.
構文だけがないかどうかそれをチェックした後にアドレスがVRFYコマンドで記載されている状態で250回答コードを返すと、この規則は違反されます。 もちろん、アドレスが有効であるか否かに関係なく、VRFYをいつも戻っている550「サポートする」実装は順応で等しくそうしていません。
Within the last few years, the contents of mailing lists have become popular as an address information source for so-called "spammers." The use of EXPN to "harvest" addresses has increased as list administrators have installed protections against inappropriate uses of the lists themselves. Implementations SHOULD still provide support for EXPN, but sites SHOULD carefully evaluate the tradeoffs. As authentication mechanisms are introduced into SMTP, some sites may choose to make EXPN available only to authenticated requesters.
ここ数年以内に、メーリングリストの内容はいわゆる「スパマー」のためのアドレスの情報源としてポピュラーになりました。 リスト管理者がリスト自体の不適当な用途に対する保護をインストールするのに従って、「収穫」アドレスへのEXPNの使用は増加しました。 実装SHOULDはまだEXPNのサポートを提供していますが、サイト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を使用することで有効であるかどうか発見するのがしばしば可能であるので。
6.1.1.4. Information Disclosure in Announcements
6.1.1.4. 発表における情報公開
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
挨拶応答かHELPコマンドに対応してサーバタイプとバージョン(そして、時々同等のサーバドメイン名)を発表するデバッグ有利な立場の間には、見返りの進行中の討論がありました、そして、情報がそれであると暴露する損失は潜在的敵対的な攻撃で役に立つかもしれません。 デバッグ情報に関するユーティリティは疑問を超えています。 それを利用可能にするように論争する人は、サーバの正確なアイデンティティを隠すことによって知られている脆弱性を隠そうとするなら、より多くの保護が提供されることを望んでいるより実際にむしろSMTPサーバーを保証するのがはるかに良いと指摘します。 サイトが評価するよう奨励されます。
Rescorla & Korver Best Current Practice [Page 31] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[31ページ]。
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.
その問題が念頭にある見返り。 実装が他のネットワークホストへの何らかの方法で手があいている作成タイプとバージョン情報に最少量で備えるよう強く奨励されます。
6.1.1.5. Information Disclosure in Trace Fields
6.1.1.5. 跡の分野での情報公開
In some circumstances, such as when mail originates from within a LAN
whose hosts are not directly on the public Internet, trace
("Received") fields produced in conformance with this specification
may disclose host names and similar information that would not
normally be available. This ordinarily does not pose a problem, but
sites with special concerns about name disclosure should be aware of
it. Also, the optional FOR clause should be supplied with caution or
not at all when multiple recipients are involved lest it
inadvertently disclose the identities of "blind copy" recipients to
others.
メールが中から、ホストが直接公共のインターネットにいないLANを溯源する時などのいくつかの事情では、順応でこの仕様で生産された跡(「受信する」)の分野は通常、利用可能でないホスト名と同様の情報を明らかにするかもしれません。 これは通常問題を設定しませんが、名前公開に関する特別な心配があるサイトはそれを意識しているべきです。 また、うっかり「盲目のコピー」受取人のアイデンティティを他のものに明らかにするといけないので複数の受取人がかかわるとき、任意のFOR節を慎重か全く提供するべきではありません。
6.1.1.6. Information Disclosure in Message Forwarding
6.1.1.6. メッセージ推進における情報公開
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の回答コードの使用はうっかり機密情報を明らかにするかもしれません。 それらの問題に関して心配しているサイトは適切にサーバを選択して、構成するのを確実にするべきです。
6.1.1.7. Scope of Operation of SMTP Servers
6.1.1.7. SMTPサーバの操作の範囲
It is a well-established principle that an SMTP server may refuse to accept mail for any operational or technical reason that makes sense to the site providing the server. However, cooperation among sites and installations makes the Internet possible. If sites take excessive advantage of the right to reject traffic, the ubiquity of email availability (one of the strengths of the Internet) will be threatened; considerable care should be taken and balance maintained if a site decides to be selective about the traffic it will accept and process.
サーバを提供するサイトに理解できるのは、SMTPサーバーが、どんな操作上的、または、技術的な理由でもメールを受け入れるのを拒否するかもしれないという安定している原則です。しかしながら、サイトとインストールの中の協力で、インターネットは可能になります。 サイトが過度の利点を活用すると、トラフィック、メールの有用性の偏在を拒絶する権利では、(インターネットの強さの1つ)は脅かされるでしょう。 かなりの注意が払われるべきであり、バランスはサイトが、トラフィックに関して選択していると決めると、それが受け入れて、処理されると主張しました。
In recent years, use of the relay function through arbitrary sites has been used as part of hostile efforts to hide the actual origins of mail. Some sites have decided to limit the use of the relay function to known or identifiable sources, and implementations SHOULD provide the capability to perform this type of filtering. When mail is rejected for these or other policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL, or RCPT as appropriate.
近年、任意のサイトを通したリレー機能の使用は、メールの実際の発生源を隠すのに敵対的な取り組みの一部として使用されました。 いくつかのサイトが、リレー機能の使用を知られているか身元保証可能なソースに制限すると決めました、そして、実装SHOULDはこのタイプのフィルタリングを実行する能力を前提とします。 メールがいつこれらのために拒絶されるか、そして、他の方針が推論します、550コードSHOULD。EHLO、メール、またはRCPTに対応して、適宜使用されてください。
Rescorla & Korver Best Current Practice [Page 32] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[32ページ]。
6.1.1.8. Inappropriate Usage [NEW]
6.1.1.8. 不適当な用法[新しい]です。
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のアイデンティティを送るか、またはオープンRelayを通して彼らのメールを転送することによって彼らのアイデンティティをあいまいにするのを試みます--どんな送付者のためのメールリレーも実行するSMTPサーバー。 結果として、現在、また、オープンリレーに関するブラックリスト[ORBS]があります。
6.1.1.8.1. Closed Relaying [NEW]
6.1.1.8.1. 閉じているリレー[新しい]です。
To avoid being used for spam forwarding, many SMTP servers operate as closed relays, providing relaying service only for clients who they can identify. Such relays should generally insist that senders advertise a sending address consistent with their known identity. If the relay is providing service for an identifiable network (such as a corporate network or an ISP's network) then it is sufficient to block all other IP addresses). In other cases, explicit authentication must be used. The two standard choices for this are TLS [STARTTLS] and SASL [SASLSMTP].
スパム推進に使用されるのを避けるために、多くのSMTPサーバーが閉じているリレーとして作動します、彼らが特定できるクライアントのためだけにサービスをリレーしながら提供して。 一般に、そのようなリレーは、送付者が彼らの知られているアイデンティティと一致した送付アドレスの広告を出すと主張するはずです。 リレーが身元保証可能なネットワークにサービスを提供しているなら(ISPのネットワーク) 企業ネットワークとしてのそのようなものか次に、それが他のすべてのIPアドレスを妨げることができるくらいの)。 他の場合では、明白な認証を使用しなければなりません。 これのための2つの標準の選択が、TLS[STARTTLS]とSASL[SASLSMTP]です。
6.1.1.8.2. Endpoints [NEW]
6.1.1.8.2. 終点[新しい]です。
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
現実的に、SMTP終点は、非認証された送付者に対するサービスを否定するのを拒否できません。 かなりの大多数の送付者が非認証されるので、これはインターネット・メール相互運用性を壊すでしょう。 これへの例外は終点サーバがそうあるだけであるべきである時です。
Rescorla & Korver Best Current Practice [Page 33] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[33ページ]。
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.
そうすることができるある他のサーバからメールをそれ自体で受け取って、非認証されたメッセージを受け取ってください。 例えば、会社は、公共のゲートウェイを操作しますが、ゲートウェイと話すだけであるために内部のサーバを構成するかもしれません。
6.1.2. Communications security issues [NEW]
6.1.2. コミュニケーション安全保障問題[新しい]です。
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
IPSEC SMTP/TLS S/MIMEとPGP/MIMEの上のSMTP
6.1.2.1. SMTP over IPSEC [NEW]
6.1.2.1. IPSECの上のSMTP[新しい]です。
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ゲートウェイか、どんな組の接続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ヘッダーに単に現れるので、それは送付者で容易に偽造可能です。 また、最終的に、安全保障政策が非常に厳密に設定されない場合、cleartext攻撃へのアクティブなダウングレードがあります。
Rescorla & Korver Best Current Practice [Page 34] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[34ページ]。
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がなければ、これはportablyするのが非常に難しいです。
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.
彼らにそれがなるそうと信じる理由(2台のマシンの間の先在の協会の存在などの)がないと、管理者がそのIPsecであると仮定してはいけないSMTPサーバーかSMTPの作成者は手があくでしょう。 しかしながら、メールが提供されるとき、便宜主義的に同輩サーバにIPsec協会を創設するのを試みるのは、妥当な手順であるかもしれません。 IPsecが2つのサイトの間のVPNトンネルを提供するのに使用される場合には、かなりのセキュリティ価値がこれにあることに特に前記のように警告を条件として秘密性を提供するという範囲に注意してください。 また、IPsecの適用性で一般的な指導に関して[USEIPSEC]を見てください。
6.1.2.2. SMTP/TLS [NEW]
6.1.2.2. SMTP/TLS[新しい]です。
SMTP can be combined with TLS as described in [STARTTLS]. This provides similar protection to that provided when using IPSEC. Since TLS certificates typically contain the server's host name, recipient authentication may be slightly more obvious, but is still susceptible to DNS spoofing attacks. Notably, common implementations of TLS contain a US exportable (and hence low security) mode. Applications desiring high security should ensure that this mode is disabled. Protection is provided against replay attacks, since the data itself is protected and the packets cannot be replayed. [Note: The Security Considerations section of the SMTP over TLS document is quite good and bears reading as an example of how to do things.]
[STARTTLS]で説明されるようにSMTPをTLSに結合できます。 これはIPSECを使用するとき提供されたそれに同様の保護を提供します。 TLS証明書がサーバのホスト名を通常含んでいるので、受取人認証は、わずかに明白であるかもしれませんが、まだDNSスプーフィング攻撃に影響されやすいです。 著しく、TLSの一般的な実装は米国の輸出向き(そして、したがって、低いセキュリティ)のモードを含んでいます。 高いセキュリティを望んでいるアプリケーションは、このモードが障害があるのを確実にするべきです。 データ自体を保護して、パケットを再演できないので、反射攻撃に対して保護を提供します。 [注意: TLSドキュメントの上のSMTPのSecurity Considerations部は、かなり良く、どうことをするかに関する例と読むのを産出します。]
6.1.2.3. S/MIME and PGP/MIME [NEW]
6.1.2.3. S/MIMEとPGP/MIME[新しい]です。
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が送付者と受信機の両方に識別マークを供給することに注意してください。秘密性を提供さえするとき、その結果、トラヒック分析はまだ可能です。
Rescorla & Korver Best Current Practice [Page 35] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[35ページ]。
6.1.3. Denial of Service [NEW]
6.1.3. サービス妨害[新しい]です。
None of these security measures provides any real protection against denial of service. SMTP connections can easily be used to tie up system resources in a number of ways, including excessive port consumption, excessive disk usage (email is typically delivered to disk files), and excessive memory consumption (sendmail, for instance, is fairly large, and typically forks a new process to deal with each message.)
これらの安全策のいずれもサービスの否定に対する少しの本当の保護も提供しません。 多くの方法でシステム資源をタイアップするのに容易にSMTP接続を使用できます、過度のポート消費、過度のディスクの使用状況(メールはディスクファイルに通常提供される)、および過度のメモリ消費を含んでいて(sendmailは例えば、かなり大きく、各メッセージに対処するニュープロセスを通常分岐させます。)
If transport- or application-layer security is used for SMTP connections, it is possible to mount a variety of attacks on individual connections using forged RSTs or other kinds of packet injection.
輸送か応用層セキュリティがSMTP接続に使用されるなら、偽造RSTsを使用している個々の接続に対するさまざまな攻撃か他の種類のパケット注射を仕掛けるのは可能です。
6.2. VRRP
6.2. VRRP
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、Virtual Router Redundanceプロトコル([VRRP])から来ています。 私たちはここでそのドキュメント(新しいセクション番号がある)からSecurity Considerations部を再生させます。 私たちのコメントは、'注意で字下がりにされて、前書きされます:、'
6.2.1. Security Considerations
6.2.1. セキュリティ問題
VRRP is designed for a range of internetworking environments that may employ different security policies. The protocol includes several authentication methods ranging from no authentication, simple clear text passwords, and strong authentication using IP Authentication with MD5 HMAC. The details on each approach including possible attacks and recommended environments follows.
VRRPは異なった安全保障政策を使うかもしれないさまざまなインターネットワーキング環境のために設計されています。 プロトコルは、MD5 HMACとIP Authenticationを使用することで認証がないのから変化するいくつかの認証方法、簡単なクリアテキストパスワード、および強い認証を含んでいます。 可能な攻撃とお勧めの環境を含んでいると続く各アプローチに関する詳細。
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.
以下に注意してください。 以下のセクションで議論した安全策は様々な種類の認証を提供するだけです。 秘密性を全く提供しません。 これは範囲のように明らかに説明されるべきです。
6.2.1.1. No Authentication
6.2.1.1. 認証がありません。
The use of this authentication type means that VRRP protocol exchanges are not authenticated. This type of authentication SHOULD only be used in environments were there is minimal security risk and little chance for configuration errors (e.g., two VRRP routers on a LAN).
この認証タイプの使用は、VRRPプロトコル交換が認証されないことを意味します。 これをタイプします。環境で使用されているのが、最小量のセキュリティリスクと見込みが構成誤り(例えば、LANに関する2つのVRRPルータ)によってほとんどないということであったという認証SHOULDだけでは、ことになってください。
Rescorla & Korver Best Current Practice [Page 36] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[36ページ]。
6.2.1.2. Simple Text Password
6.2.1.2. 簡単なテキストパスワード
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でルータの偶然のmisconfigurationから守るために役に立ちます。 それはうっかり別のルータを支援するルータから守ります。 別のルータでVRRPを実行できる前に最初に、正しいパスワードで新しいルータを構成しなければなりません。 ノードがパスワードについて学習できるところでこのタイプの認証は、LANでVRRPパケットについて詮索しながら、敵対的な攻撃から守りません。 TTLチェックに結合されたSimple Text AuthenticationはVRRP操作を中断するために別のLANから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.
活発にVRRP操作を中断するLANのノードの最小量のリスクがあるとき、このタイプの認証はRECOMMENDEDです。 このタイプの認証が使用されているなら、ユーザは、このクリアテキストパスワードが頻繁に送られるのを意識しているべきであり、したがって、どんなセキュリティの重要なパスワードとも同じであるべきではありません。
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.
以下に注意してください。 このセクションは、より明確であるはずです。 基本的なポイントは認証とどんなSimple Textも非常に限られた脅威モデルの役に立つだけではなくて、すなわち、地方のLANのノードのいずれも敵対的でないということです。 TTLチェックは、敵対的なノードオフLANが有効なノードのふりをするのを防ぎますが、何も認可されたノードをまねるのからのLANの敵対的なノードを止めません。 これは多くの状況で特に現実的な脅威モデルではありません。 特に、それは非常にもろいです: LANがVRRPノードの再構成を許すどんなノードの感染。
6.2.1.3. IP Authentication Header
6.2.1.3. IP認証ヘッダー
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.
この認証タイプの使用は、VRRPプロトコル交換が[HMAC]を使用することでIP Authentication Header[AH]によって定義されたメカニズムを使用することで認証されることを意味します。 これは構成誤り、反射攻撃、およびパケット不正/変更に対する強い保護を提供します。
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のノードの管理の限られたコントロールがあるとき、このタイプの認証はRECOMMENDEDです。 このタイプの認証はVRRPの操作を保護しますが、VRRPから独立している共有されたメディアリンク(例えば、にせのARP回答の世代)の上に使われるかもしれなくて、保護されない他のタイプの攻撃があります。
Rescorla & Korver Best Current Practice [Page 37] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[37ページ]。
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がこのような関係においてはRECOMMENDEDであることを持つのは、誤りです。 AHが攻撃に対して同じLANの他のノードからVRRPを保護する唯一のメカニズムであるので、それはメカニズムであるべきです。信頼されていないノードが同じネットワークにあるaはケースのためにそうしなければなりません。 どのような場合でも、AHによるaが実装しなければならないということであるはずです。
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.
[このセクションの残りはNEWの材料です] 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ネットワークはmisconfigurationに直面して非常にもろくなります。 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の脅威を取り除くなら、この判断を再訪させるべきです。
7. Acknowledgments
7. 承認
This document is heavily based on a note written by Ran Atkinson in 1997. That note was written after the IAB Security Workshop held in early 1997, based on input from everyone at that workshop. Some of the specific text above was taken from Ran's original document, and some of that text was taken from an email message written by Fred Baker. The other primary source for this document is specific comments received from Steve Bellovin. Early review of this document was done by Lisa Dusseault and Mark Schertler. Other useful comments were received from Bill Fenner, Ned Freed, Lawrence Greenfield, Steve Kent, Allison Mankin and Kurt Zeilenga.
このドキュメントはずっしりと1997年にRanアトキンソンによって書かれた注意に基づいています。 IAB Security Workshopが1997年前半に成立した後にその注意は書かれました、そのワークショップの皆からの入力に基づいて。 上の特定のテキストのいくつかがRanの正本から抜粋されました、そして、そのテキストのいくつかがフレッド・ベイカーによって書かれたメールメッセージから抜粋されました。 このドキュメントのためのもう片方の一次資料はスティーブBellovinから受けられた特定のコメントです。 このドキュメントの早めのレビューがリサDusseaultとマークSchertlerによって行われました。 ビル・フェナー、ネッド・フリード、ローレンス・グリーンフィールド、スティーブ・ケント、アリソン・マンキン、およびカートZeilengaから他の役に立つコメントを受けました。
Rescorla & Korver Best Current Practice [Page 38] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[38ページ]。
8. Normative References
8. 引用規格
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[ああ] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[DNSSEC] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
[ENCOPT] Tso, T., "Telnet Data Encryption Option", RFC 2946,
September, 2000.
[ENCOPT] Tso、T.、「telnetデータ暗号化オプション」、RFC2946、2000年9月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[超能力] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[GSS] Linn, J., "Generic Security Services Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[GSS]リン、J.、「RFC2743、ジェネリックセキュリティは適用業務プログラム・インタフェースバージョン2、アップデートを何1インチも修理して、1月は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] フィールディングとR.とGettysとJ.とムガール人とJ.とFrystykとH.とMasinterとL.とリーチとP.とT.バーナーズ・リー、「ハイパーテキスト転送プロトコル」、RFC2616、1999年6月。
[HTTPTLS] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
[HTTPTLS]レスコラ、E.(「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。
[HMAC] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998.
そして、[HMAC] マドソン、C.、およびR.グレン、「超能力の中のHMAC-MD5-96の使用、ああ、」、RFC2403、11月1998日
KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
ケルベロス] コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[OTP] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time
Password System", STD 61, RFC 2289, February 1998.
[OTP] ハラーとN.とメスとC.とNesserとP.とM.わら、「A One-時間パスワードシステム」、STD61、RFC2289、1998年2月。
[PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[PHOTURIS] Karn、P.、およびW.シンプソン、「Photuris:」 「セッションKey Managementプロトコル」、RFC2522、1999年3月。
[PKIX] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 "Public Key Infrastructure Certificate and
Certificate Restoration List (CRL) Profile", RFC 3280,
April 2002.
[PKIX] HousleyとR.とポークとW.とフォードとW.とD.独奏、「インターネットX.509「公開鍵暗号基盤証明書と証明書王政復古リスト(CRL)プロフィール」、RFC3280、2002年4月。」
[RFC-2223] Postel J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[RFC-2223] ポステルJ.とJ.レイノルズ、「指示、RFCが書く、」、RFC2223、10月1997日
[RFC-2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs",
BCP 30, RFC 2505, February 1999.
[RFC-2505] リンドバーグ、G.、「SMTP MTAsのための反スパム推薦」、BCP30、RFC2505、1999年2月。
Rescorla & Korver Best Current Practice [Page 39] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[39ページ]。
[RFC-2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC-2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[SASL] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[SPKI] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas,
B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
September 1999.
[SPKI] エリソン、C.、フランツ、B.、ランプソン、B.、Rivest、R.、トーマス、B.、およびT.Ylonen、「SPKIは理論を証明します」、RFC2693、1999年9月。
[SSH] Ylonen, T., "SSH - Secure Login Connections Over the
Internet", 6th USENIX Security Symposium, p. 37-42, July
1996.
[SSH] Ylonen、T.、「セキュアシェル (SSH)--インターネットの上でログインコネクションズを保証してください」、第6USENIX Security Symposium、p。 37-42と、1996年7月。
[SASLSMTP] Myers, J., "SMTP Service Extension for Authentication",
RFC 2554, March 1999.
[SASLSMTP] マイアーズ、J.、「認証のためのSMTPサービス拡張子」、RFC2554、1999年3月。
[STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[STARTTLS]ホフマン、P.、「トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子」、RFC3207、2002年2月。
[S-HTTP] Rescorla, E. and A. Schiffman, "The Secure HyperText
Transfer Protocol", RFC 2660, August 1999.
[S-HTTP] レスコラとE.とA.シフマン、「安全なハイパーテキスト転送プロトコル」、RFC2660、1999年8月。
[S/MIME] Ramsdell, B., Editor, "S/MIME Version 3 Message
Specification", RFC 2633, June 1999.
[S/MIME] Ramsdell、B.、エディタ、「S/MIMEバージョン3メッセージ仕様」、RFC2633、1999年6月。
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[telnet] ポステル、J.、およびJ.レイノルズ(「telnetプロトコル仕様」、STD8、RFC854)は1983がそうするかもしれません。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[TLS] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D. and J.
Mikkelsen, "Transport Layer Security (TLS) Extensions",
RFC 3546, May 2003.
[TLSEXT]ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood、D.、およびJ.ミッケルセン(「トランスポート層セキュリティ(TLS)拡大」、RFC3546)は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
[TCPSYN] 「TCP SYN氾濫とIPスプーフィング攻撃」、CERT勧告、カリフォルニア-1996-21、本命1996年9月19日、 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.
「HTTP/1.1インチ、RFC2817、2000年5月中にTLSにアップグレードする」[アップグレード]Khare、R.、およびS.ローレンス。
[URL] Berners-Lee, T., Masinter, M. and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[URL]バーナーズ・リー、T.、Masinter、M.、およびM. McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
Rescorla & Korver Best Current Practice [Page 40] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[40ページ]。
[VRRP] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel,
D., Hunt, P., Higginson, P., Shand, M. and A. Lindemn,
"Virtual Router Redundancy Protocol", RFC 2338, April
1998.
[VRRP] ナイトとS.とウィーバーとD.とホイップルとD.とHindenとR.とMitzelとD.と狩りとP.とヒギンソンとP.とシャンドとM.とA.Lindemn、「仮想のルータ冗長プロトコル」、RFC2338、1998年4月。
9. Informative References
9. 有益な参照
[DDOS] "Denial-Of-Service Tools" CERT Advisory CA-1999-17, 28
December 1999, CERT http://www.cert.org/advisories/CA-
1999-17.html
[DDOS]「サービスの否定ツール」、CERT勧告、カリフォルニア-1999-17、1999年12月28日、本命 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.
[補います] Bellovin、S.、メリット、M.、「暗号化されたキーは以下を交換します」。 「辞書攻撃に対して安全なパスワードベースのプロトコル」、SecurityとPrivacy、1992年5月のResearchの上のIEEE SymposiumのProceedings。
[IDENT] St. Johns, M. and M. Rose, "Identification Protocol", RFC
1414, February 1993.
[IDENT] 聖ジョーンズとM.とM.ローズ、「識別プロトコル」、RFC1414、1993年2月。
[INTAUTH] Haller, N. and R. Atkinson, "On Internet Authentication",
RFC 1704, October 1994.
[INTAUTH] ハラーとN.とR.アトキンソン、「インターネット認証」、RFC1704、1994年10月。
[IPSPPROB] Bellovin, S. M., "Problem Areas for the IP Security
Protocols", Proceedings of the Sixth Usenix UNIX Security
Symposium, July 1996.
[IPSPPROB]Bellovin、S.M.、「IPセキュリティー・プロトコルのための問題領域」、第6Usenix UNIXセキュリティシンポジウム(1996年7月)の議事。
[KLEIN] Klein, D.V., "Foiling the Cracker: A Survey of and
Improvements to Password Security", 1990.
[クライン]クライン、D.V.、「クラッカーにはくを敷きます:」 1990の「パスワードセキュリティへの調査と改良」
[NNTP] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986.
[NNTP] カンターとB.とP.ラプスリー、「ネットワークの電子情報を転送するプロトコル」、RFC977、1986年2月。
[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[飛び出します] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」
[SEQNUM] Morris, R.T., "A Weakness in the 4.2 BSD UNIX TCP/IP
Software", AT&T Bell Laboratories, CSTR 117, 1985.
[SEQNUM]モリス、R.T.、「4.2BSD UNIX TCP/IPソフトウェアの弱点」、AT&Tベル研究所、CSTR117、1985。
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
Mendelsoh, N., Nielsen, H., Thatte, S., Winer, D., "Simple
Object Access Protocol (SOAP) 1.1", May 2000.
[SOAP]箱、D.、Ehnebuske、D.、Kakivaya、G.、俗人、A.、Mendelsoh、N.、ニールセン、H.、Thatte、S.、ワイナー、D.、「Simple Object Access Protocol(SOAP)1.1インチと、2000年5月。」
[SPEKE] Jablon, D., "Strong Password-Only Authenticated Key
Exchange", Computer Communication Review, ACM SIGCOMM,
vol. 26, no. 5, pp. 5-26, October 1996.
[スピーク]Jablon、D.、「強いパスワードだけ認証された主要な交換」、コンピュータCommunication Review、ACM SIGCOMM、vol.26、No.5、ページ 5-26と、1996年10月。
[SRP] Wu T., "The Secure Remote Password Protocol", ISOC NDSS
Symposium, 1998.
[SRP]ウーT.、「安全なリモートパスワードプロトコル」、ISOC NDSSシンポジウム、1998。
Rescorla & Korver Best Current Practice [Page 41] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[41ページ]。
[USEIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
Work in Progress.
S.、「IPsecの使用を強制するためのガイドライン」という[USEIPSEC]Bellovinは進行中で働いています。
[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
[WEP]ボリーソフ、N.、ゴールドバーグ、I.、ワグナー、D.、「移動通信を傍受します:」 「802.11の不安定」、 http://www.isaac.cs.berkeley.edu/isaac/wep-draft.pdf
10. Security Considerations
10. セキュリティ問題
This entire document is about security considerations.
この全体のドキュメントはセキュリティ問題に関するものです。
Rescorla & Korver Best Current Practice [Page 42] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[42ページ]。
Appendix A.
付録A。
IAB Members at the time of this writing
この書くこと時点のIABメンバー
Harald Alvestrand Ran Atkinson Rob Austein Fred Baker Leslie Daigle Steve Deering Sally Floyd Ted Hardie Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Mike St. Johns
ハラルドAlvestrandはアトキンソンロブAusteinフレッドベイカーレスリーDaigleスティーブデアリングSallyフロイドテッドハーディージェフヒューストンチャーリー・カウフマンジェームスケンフエリックレスコラマイク通りジョーンズを車で送りました。
Authors' Addresses
作者のアドレス
Eric Rescorla RTFM, Inc. 2439 Alvin Drive Mountain View, CA 94043
エリックレスコラRTFM Inc.2439アルビン・Driveマウンテンビュー、カリフォルニア 94043
Phone: (650)-320-8549 EMail: ekr@rtfm.com
以下に電話をしてください。 (650)-320-8549 メールしてください: ekr@rtfm.com
Brian Korver Xythos Software, Inc. 77 Maiden Lane, 6th Floor San Francisco, CA, 94108
ブライアンKorver XythosソフトウェアInc.77Maidenレイン、サンフランシスコ、第6Floorカリフォルニア 94108
Phone: (415)-248-3800 EMail: briank@xythos.com
以下に電話をしてください。 (415)-248-3800 メールしてください: briank@xythos.com
Internet Architecture Board IAB EMail: iab@iab.org
インターネット・アーキテクチャ委員会IABはメールします: iab@iab.org
Rescorla & Korver Best Current Practice [Page 43] RFC 3552 Security Considerations Guidelines July 2003
レスコラとKorverの最も良い海流はガイドライン2003年7月にRFC3552セキュリティ問題を練習します[43ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rescorla & Korver Best Current Practice [Page 44]
レスコラとKorverの最も良い現在の習慣[44ページ]
一覧
スポンサーリンク
