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