RFC3631 日本語訳
3631 Security Mechanisms for the Internet. S. Bellovin, Ed., J.Schiller, Ed., C. Kaufman, Ed.. December 2003. (Format: TXT=47064 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Bellovin, Ed.
Request for Comments: 3631 J. Schiller, Ed.
Category: Informational C. Kaufman, Ed.
Internet Architecture Board
December 2003
ワーキンググループS.Bellovin、エドをネットワークでつないでください。コメントのために以下を要求してください。 3631 エドJ.シラー、カテゴリ: エド情報のC.コーフマン、インターネット・アーキテクチャ委員会2003年12月
Security Mechanisms for the Internet
インターネットへのセキュリティー対策
Status of this Memo
この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.
Copyright(C)インターネット協会(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.
サービス妨害からHost Compromiseまで及んで、インターネットSecurity感染を数人のクラスに分割できます。 全くの交通量に基づくサービス妨害攻撃はこのドキュメントの範囲を超えています、それらが多くの現在行われている議論と研究の対象ですが。 優れた警備体制習慣でそのような多くの攻撃をより難しくすることに注意するのは重要です。 ホストCompromise(undetected Buffer Overflowsによって一般的に最も引き起こされた)はプロトコルの欠点よりむしろ個々の実装における欠点を表します。 それにもかかわらず、入念に設計されたプロトコルは、そのような欠点を利用するのをおそらく起こるように、より少なくより困難にすることができます。
Bellovin, et al. Informational [Page 1] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[1ページ]のRFC3631セキュリティー対策
However, there are security compromises that are facilitated by the very protocols that are in use on the Internet. If a security problem is inherent in a protocol, no manner of implementation will be able to prevent the problem.
しかしながら、インターネットで使用中のまさしくそのプロトコルによって容易にされるセキュリティ感染があります。 警備上の問題はプロトコルが固有であるなら、実装のどんな方法も問題を防ぐことができないでしょう。
It is therefore vitally important that protocols developed for the Internet provide this fundamental security.
したがって、インターネットに開発されたプロトコルがこの基本的なセキュリティを提供するのは、きわめて重要です。
Exactly how a protocol should be secured depends on the protocol itself as well as the security needs of the protocol. However, we have developed a number of standard security mechanisms in the IETF. In many cases appropriate application of these mechanisms can provide the necessary security for a protocol.
ちょうどどうプロトコルを保証するべきであるかはプロトコルの安全要求と同様にプロトコル自体によります。 しかしながら、私たちはIETFの多くの標準のセキュリティー対策を開発しました。 多くの場合、これらのメカニズムの適切な応用は必要なセキュリティをプロトコルに提供できます。
A number of possible mechanisms can be used to provide security on the Internet. Which one should be selected depends on many different factors. We attempt here to provide guidance, spelling out the factors and the currently-standardized (or about-to-be-standardized) solutions, as discussed at the IAB Security Architecture Workshop [RFC2316].
インターネットでセキュリティを提供するのに多くの可能なメカニズムを使用できます。 どれが選択されるべきであるかは多くの異なった要素に依存します。 私たちは、ここで指導を提供するのを試みます、要素と現在標準化された(未来に関して標準化されて)ソリューションについてスペルアウトして、IAB Security Architecture Workshop[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
セキュリティー対策を選ぶ最も重要な要素は脅威モデルです。 すなわち、だれがどんなリソース、何を使用するかを攻撃するために期待しているかもしれないか、メカニズムの種類-- 公開情報だけを提供するウェブサイトなどの低値の目標は多くの保護に値しないかもしれません。 逆に、感染されるならインターネット基盤の重要な部分を暴露するかもしれないリソース(たとえば、主要なバックボーンルータかハイレベルのDomain Name Server)は、非常に強いメカニズムによって保護されるべきです。攻撃者への目標の値は攻撃の目的に依存します。 目的が機密情報にアクセスすることであるなら、この情報を扱うか、またはそれへのアクセスを調停するすべてのシステムが貴重です。 インターネットのかなりの部分がよるシステムが目的が大破壊を加えることであるなら、加える、きわめて。
Bellovin, et al. Informational [Page 2] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[2ページ]のRFC3631セキュリティー対策
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!
すべてのインターネット接続されたシステムが最小の量の保護を必要とします。 2000年に始まって、現在に続いて、私たちは新しいタイプのインターネットセキュリティー攻撃の到来を目撃しました: 多くの攻撃で妥協するために害を被りやすいシステムを捜し出して、自動的に攻撃するインターネット「ワーム」プログラムはワームプログラム自体に建てられました。 これらのワームプログラムは非常に短い期間以内に文字通り何千台ものシステムに感染することができます。 最初のインターネットWormが1988年の「モリス」ワームであったことに注意してください。 しかしながら、それは12年間以上同様のプログラムで追求されませんでした!
As of the writing of this document, all of these worms have taken advantage of programming errors in the implementation of otherwise reasonably secure protocols. However, it is not hard to envision an attack that targets a fundamental security flaw in a widely deployed protocol. It is therefore imperative that we strive to minimize such flaws in the protocols we design.
このドキュメントの書くこと現在、これらのワームのすべてがそうでなければ、合理的に安全なプロトコルの実装におけるプログラミング・エラーを利用しました。 しかしながら、広く配布しているプロトコルの基本的なセキュリティー・フローを狙う攻撃を思い描きにくくはありません。 したがって、私たちが、私たちが設計するプロトコルのそのような欠点を最小にするように努力するのは、必須です。
The value of a target to an attacker may depend on where it is located. A network monitoring station that is physically on a backbone cable is a major target, since it could easily be turned into an eavesdropping station. The same machine, if located on a stub net and used for word processing, would be of much less use to a sophisticated attacker, and hence would be at significantly less risk.
攻撃者への目標の値はそれが位置しているところに依存するかもしれません。 バックボーンケーブルの上で物理的にそうであるステーションをモニターするネットワークは主な対象です、容易にそれを盗聴ステーションに変えることができたので。 同じマシン、スタッブネットに位置していて、文書処理に使用されるなら、洗練された攻撃者にはまして使用があって、したがって、かなり少ないリスクにあるでしょう。
One must also consider what sorts of attacks may be expected. At a minimum, eavesdropping must be seen as a serious threat; there have been very many such incidents since at least 1993. Often, active attacks, that is, attacks that involve insertion or deletion of packets by the attacker, are a risk as well. It is worth noting that such attacks can be launched with off-the-shelf tools, and have in fact been observed "in the wild". Of particular interest is a form of attack called "session hijacking", where someone on a link between the two communicating parties wait for authentication to complete and then impersonate one of the parties and continue the connection with the other.
また、どんな種類の攻撃が予想されるかもしれないかを考えなければなりません。 最小限では、盗聴を重大な脅威と考えなければなりません。 少なくとも1993年以来非常に多くのそのようなインシデントがあります。 しばしば、活発な攻撃(すなわち、攻撃者によるパケットの挿入か削除にかかわる攻撃)はまた、リスクです。 そのような攻撃がすぐ入手できるツールで着手できて、事実上、「荒野」で観測されたことに注意する価値があります。 特別の関心は「セッションハイジャック」と呼ばれる攻撃のフォームです、次に、リンクの上のだれかがもう片方で2回の交信パーティーの間で終了する認証を待っていて、パーティーのひとりをまねて、接続を続けているところで。
One of the most important tools available to us for securing protocols is cryptography. Cryptography permits us to apply various kinds of protection to data as it traverses the network, without having to depend on any particular security properties of the network itself. This is important because the Internet, by its distributed
私たちにとって、プロトコルを保証するのに利用可能な最も重要なツールの1つは暗号です。 ネットワークを横断するとき、暗号は、私たちが様々な種類の保護をデータに適用することを許可します、ネットワーク自体のどんな特定のセキュリティ所有地にもよる必要はなくて。 これが重要である、インターネットであり、それは分配されています。
Bellovin, et al. Informational [Page 3] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[3ページ]のRFC3631セキュリティー対策
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.
管理とコントロールはそういうものの考えられたa信頼できるメディアであるはずがありません。 セキュリティが私たちがプロトコル自体に造るメカニズムに由来しています、基本的なメディアかネットワーク・オペレータの如何にかかわらず。
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. 義務的なメカニズムに関するWord
We have evolved in the IETF the notion of "mandatory to implement" mechanisms. This philosophy evolves from our primary desire to ensure interoperability between different implementations of a protocol. If a protocol offers many options for how to perform a particular task, but fails to provide for at least one that all must implement, it may be possible that multiple, non-interoperable implementations may result. This is the consequence of the selection of non-overlapping mechanisms being deployed in the different implementations.
私たちはIETFで「実装するために義務的」メカニズムの概念を発展しました。この哲学はプロトコルの異なった実装の間の相互運用性を確実にする私たちのプライマリ願望から発展します。 プロトコルがどう特定のタスクを実行するかために多くのオプションを提供しますが、少なくともすべてが実装しなければならないものに備えないなら、複数の、そして、非共同利用できる実装が結果として生じるのは、可能であるかもしれません。 これは異なった実装で配布される非重なっているメカニズムの品揃えの結果です。
Although a given protocol may make use of only one or a few security mechanisms, these mechanisms themselves often can make use of several cryptographic systems. The various cryptographic systems vary in strength and performance. However, in many protocols we need to specify a "mandatory to implement" to ensure that any two implementations will eventually be able to negotiate a common cryptographic system between them.
与えられたプロトコルは1つだけの使用かいくつかのセキュリティー対策を作るかもしれませんが、これらのメカニズム自体はしばしば数個の暗号のシステムを利用できます。様々な暗号のシステムは強さと性能において異なります。 しかしながら、多くのプロトコルでは、私たちは、どんな2つの実装も結局それらの間の一般的な暗号のシステムを交渉できるのを保証するために「実装するためには義務的」を指定する必要があります。
There are some protocols that were originally designed to be run in a very limited domain. It is often argued that the domain of implementation for a particular protocol is sufficiently well defined and secure that the protocol itself need not provide any security mechanisms.
元々非常に限られたドメインに立候補することになるように設計されたいくつかのプロトコルがあります。 しばしば実装のドメインが特定のプロトコルがそれがプロトコル自体であると十分よく定義して、機密保護することであるので少しのセキュリティー対策も提供する必要はないと主張されます。
Bellovin, et al. Informational [Page 4] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[4ページ]のRFC3631セキュリティー対策
History has shown this argument to be wrong. Inevitably, successful protocols - even if developed for limited use - wind up used in a broader environment, where the initial security assumptions do not hold.
歴史は、この議論が間違っているのを示しました。 必然的に、うまくいっているプロトコルは限られた使用のために開発されてもより広い環境で使用されていた状態で終わります。(そこでは、初期のセキュリティ仮定が成立しません)。
To solve this problem, the IETF requires that *ALL* protocols provide appropriate security mechanisms, even when their domain of application is at first believed to be very limited.
この問題を解決するために、IETFは、*すべての*プロトコルが適切なセキュリティー対策を提供するのを必要とします、初めにそれらのアプリケーションのドメインが非常に制限されていると信じられるときさえ。
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.
あるメカニズムが実装するために義務的であると主張するのがセキュリティー対策でプロトコルを提供する必要があるエンドユーザが必要であるとそれを利用可能にすることを意味します。 まさしくメカニズムがそうであるので、道具が、それがデフォルトメカニズムであるべきであることを含意しないか、または含意するかもしれないのが義務的であるのは、構成による特にセキュリティー対策をもっている、身体障害者ではありません。 より強いアルゴリズムが利用可能であるときに、アルゴリズムを実装するために義務的なaが古くて、弱いなら、それを無効にするほうがよいです。
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.
いくつかのセキュリティー対策が全体のネットワークを保護できます。 これがハードウェアを倹約している間、それは内部から攻撃に開かれていた状態でそのようなネットワークの内部を出ることができます。 恐らく危険な状態にユーザものまねについてマシンが感染されたならメカニズムがtimesharedマシンの個々のユーザへの下に保護を提供できるもう一方。
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.
保護の必要な粒状を評価するとき、プロトコルデザイナーはありそうな用法パターン、実装層(以下を見る)、およびdeployabilityを考慮に入れるべきです。 プロトコルが単にマシン(たとえば、ネットワーク運営センター)の安全なクラスタから使用されそうであるなら、サブネット粒状は適切であるかもしれません。 対照的に、TCPの中でというよりむしろそのアプリケーションにただ一つのアプリケーションに独特のセキュリティー対策を埋め込むのは最も良いです。 さもなければ、展開は非常に難しくなるでしょう。
Bellovin, et al. Informational [Page 5] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[5ページ]のRFC3631セキュリティー対策
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.
セキュリティー対策はどんな層にも位置できます。 一般に、下層でメカニズムを置く場合、より広いバラエティーの上位層プロトコルが保護されますが、また、それらは保護できないかもしれません。 リンクレイヤ暗号化する人はIPだけではなく、ARPパケットさえ保護できます。 しかしながら、まさしく、範囲は1つにリンクされるということです。 逆に、多くの店とフォワードメール・ゲートウェイを通して送っても、署名しているメールメッセージを保護します、と実際の送付者は特定できます、そして、メッセージが提供されるずっと後に署名について確かめることができます。 しかしながら、その1つのタイプに関するメッセージだけが保護されます。 いくつかのNetnews任命などの同様の形式に関するメッセージは、メカニズムが明確に適合させられない場合保護されて、次に、ニュース取り扱いプログラムで実装されません。
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
HMAC [RFC2104] is the preferred shared-secret authentication technique. If both sides know the same secret key, HMAC can be used to authenticate any arbitrary message. This includes random challenges, which means that HMAC can be adapted to prevent replays of old sessions.
HMAC[RFC2104]は都合のよい共有秘密キー認証のテクニックです。 両側であるなら、同じ秘密鍵を知ってください、そして、どんな任意のメッセージも認証するのにHMACは使用できます。 これは無作為の挑戦を含んでいます(古いセッションの再生を防ぐためにHMACを適合させることができることを意味します)。
Bellovin, et al. Informational [Page 6] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[6ページ]のRFC3631セキュリティー対策
An unfortunate disadvantage of using HMAC for connection authentication is that the secret must be known in the clear by both parties, making this undesirable when keys are long-lived.
接続認証にHMACを使用する不幸な不都合は双方による明確で秘密を知っていなければならないということです、キーが長命であるときに、これを望ましくなくして。
When suitable, HMAC should be used in preference to older techniques, notably keyed hash functions. Simple keyed hashes based on MD5 [RFC1321], such as that used in the BGP session security mechanism [RFC2385], are especially to be avoided in new protocols, given the hints of weakness in MD5.
適当であるときに、HMACは、より古いテクニック、著しく合わせられたハッシュ関数に優先して使用されるべきです。 BGPセッションセキュリティー対策[RFC2385]で使用されるそれなどのMD5[RFC1321]に基づく簡単な合わせられたハッシュは新しいプロトコルで特に避けられることです、MD5の弱点のヒントを考えて。
HMAC can be implemented using any secure hash function, including MD5 and SHA-1 [RFC3174]. SHA-1 is preferable for new protocols because it is more frequently used for this purpose and may be more secure.
MD5とSHA-1[RFC3174]を含むどんな安全なハッシュ関数も使用するのをHMACに実装することができます。 SHA-1はそれが、より頻繁にこのために使用されるので新しいプロトコルに望ましく、より安全であるかもしれません。
It is important to understand that an HMAC-based mechanism needs to be employed on every protocol data unit (aka packet). It is a mistake to use an HMAC-based system to authenticate the beginning of a TCP session and then send all remaining data without any protection.
HMACベースのメカニズムが、あらゆるプロトコルデータ単位(別名パケット)の上で使われる必要であるのを理解しているのは重要です。 TCPセッションの始まりを認証して、次に、何の保護もなしにすべての残っているデータを送るのにHMACベースのシステムを使用するのは、誤りです。
Attack programs exist that permit a TCP session to be stolen. An attacker merely needs to use such a tool to steal a session after the HMAC step is performed.
TCPセッションが盗まれるのを可能にする攻撃プログラムが存在しています。 攻撃者は、単にHMACステップが実行された後にセッションを横取りするのにそのようなツールを使用する必要があります。
3.3. IPsec
3.3. IPsec
IPsec [RFC2401],[RFC2402],[RFC2406],[RFC2407],[RFC2411] is the generic IP-layer encryption and authentication protocol. As such, it protects all upper layers, including both TCP and UDP. Its normal granularity of protection is host-to-host, host-to-gateway, and gateway-to-gateway. The specification does permit user-granularity protection, but this is comparatively rare. As such, IPsec is currently inappropriate when host-granularity is too coarse.
IPsec[RFC2401][RFC2402]、[RFC2406][RFC2407]はジェネリックIP-層の暗号化と認証プロトコル[RFC2411]です。 そういうものとして、それはTCPとUDPの両方を含むすべての上側の層を保護します。 保護の正常な粒状は、ホストからホストと、ホストからゲートウェイと、ゲートウェイからゲートウェイです。 仕様はユーザ粒状保護を可能にしますが、これは比較的まれです。 ホスト粒状が現在粗過ぎるときに、そういうものとして、IPsecは不適当です。
Because IPsec is installed at the IP layer, it is rather intrusive to the networking code. Implementing it generally requires either new hardware or a new protocol stack. On the other hand, it is fairly transparent to applications. Applications running over IPsec can have improved security without changing their protocols at all. But at least until IPsec is more widely deployed, most applications should not assume they are running atop IPsec as an alternative to specifying their own security mechanisms. Most modern operating systems have IPsec available; most routers do not, at least for the control path. An application using TLS is more likely to be able to assert application-specific to take advantage of its authentication.
IPsecがIP層にインストールされるので、それはネットワークコードにかなり押しつけがましいです。 一般に、それを実装するのは新しいハードウェアか新しいプロトコル・スタックのどちらかを必要とします。 他方では、それはアプリケーションにかなり透明です。 全くそれらのプロトコルを変えないで、IPsecをひくアプリケーションはセキュリティを向上させたはずです。 しかし、IPsecが少なくともより広く配布されるまで、ほとんどのアプリケーションが、それら自身のセキュリティー対策を指定することに代わる手段としてIPsecの上で稼働する予定であると仮定するべきではありません。ほとんどの近代的なオペレーティングシステムには、利用可能なIPsecがあります。 ほとんどのルータは少なくともコントロール経路にそうしません。 TLSを使用するアプリケーションは認証の取るためにアプリケーション特有の利点について、より断言できそうです。
Bellovin, et al. Informational [Page 7] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[7ページ]のRFC3631セキュリティー対策
The key management for IPsec can use either certificates or shared secrets. For all the obvious reasons, certificates are preferred; however, they may present more of a headache for the system manager.
IPsecのためのかぎ管理は証明書か共有秘密キーのどちらかを使用できます。 すべての明白な理由によって、証明書は好まれます。 しかしながら、彼らはシステム・マネージャのために一層の頭痛を提示するかもしれません。
There is strong potential for conflict between IPsec and NAT [RFC2993]. NAT does not easily coexist with any protocol containing embedded IP address; with IPsec, every packet, for every protocol, contains such addresses, if only in the headers. The conflict can sometimes be avoided by using tunnel mode, but that is not always an appropriate choice for other reasons. There is ongoing work to make IPsec pass through NAT more easily [NATIKE].
IPsecとNAT[RFC2993]の間には、強い紛争の潜在性があります。 NATは容易に埋め込まれたIPアドレスを含んでいるどんなプロトコルにも共存していません。 ヘッダーだけであらゆるプロトコルのために、IPsecと共に、あらゆるパケットがそのようなアドレスを含んでいます。 トンネルモードを使用することによって、闘争を時々避けることができますが、それはいつも他の理由のための適当な選択であるというわけではありません。 IPsecにNATをより容易に[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.
最も現在のIPsec用法は仮想私設網のためのものです。 他の規制が迎えられると仮定して、IPsecはVPNのような状況のための選択のセキュリティプロトコルです、IPsecを使用することで単一マシンがインターネットの上でホームネットワークにトンネルを堀って戻る遠隔アクセスのシナリオを含んでいて。
3.4. TLS
3.4. TLS
TLS [RFC2246] provides an encrypted, authenticated channel that runs on top of TCP. While TLS was originally designed for use by Web browsers, it is by no means restricted to such. In general, though, each application that wishes to use TLS will need to be converted individually.
TLS[RFC2246]はTCPの上を走る暗号化されて、認証されたチャンネルを提供します。 TLSは元々使用のためにウェブブラウザによって設計されましたが、それはそのようなものに決して制限されません。 一般に、もっとも、TLSを使用したがっている各アプリケーションは、個別に変換される必要があるでしょう。
Generally, the server side is always authenticated by a certificate. Clients may possess certificates, too, providing mutual authentication, though this is rarely deployed. It's an unfortunate reality that even server side authentication it not as secure in practice as the cryptography would imply because most implementations allow users to ignore authentication failures (by clicking OK to a warning) and most users routinely do so [Bell98]. Designers should thus be wary of demanding plaintext passwords, even over TLS- protected connections. (This requirement can be relaxed if it is likely that implementations will be able to verify the authenticity and authorization of the server's certificate.)
一般に、サーバ側はいつも証明書によって認証されます。 クライアントには、これはめったに配布されませんが、また、証明書が、互いの認証を提供しながら、あるかもしれません。 ユーザがほとんどの実装で、認証失敗(OKを警告とクリックするのによる)を無視できるので暗号と同じくらい安全な習慣ではなく、それが含意するサーバサイド認証とほとんどのユーザさえきまりきってそう[Bell98]をするのは、悲しい現実です。 その結果、デザイナーはTLSの保護された接続の上でさえ平文パスワードを要求するのに用心深いはずです。 (実装がサーバの証明書の信憑性と承認について確かめることができそうであるなら、この要件はリラックスできます。)
Although application modification is generally required to make use of TLS, there exist toolkits, both free and commercial, that provide implementations. These are designed to be incorporated into the application's code. An application using TLS is more likely to be able to assert application specific certificate policies than one using IPsec.
アプリケーション修正がTLSを利用するのに一般に必要ですが、実装を提供する無料の、そして、商業の両方のツールキットが存在しています。 これらは、アプリケーションのコードに組み入れられるように設計されています。 TLSを使用するアプリケーションは、1よりアプリケーションが特定の証明書方針であるとIPsecを使用することで断言できそうです。
Bellovin, et al. Informational [Page 8] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[8ページ]のRFC3631セキュリティー対策
3.5. SASL
3.5. SASL
SASL [RFC2222] is a framework for negotiating an authentication and encryption mechanism to be used over a TCP stream. As such, its security properties are those of the negotiated mechanism. Specifically, unless the negotiated mechanism authenticates all of the subsequent messages or underlying protection protocol such as TLS is used, TCP connections are vulnerable to session stealing.
SASL[RFC2222]は、TCPストリームの上で使用されるために認証と暗号化メカニズムを交渉するためのフレームワークです。 そういうものとして、セキュリティの特性は交渉されたメカニズムのものです。 明確に、交渉されたメカニズムがその後のメッセージのすべてを認証するか、またはTLSなどの基本的な保護プロトコルが使用されていない場合、TCP接続はセッション横取りに被害を受け易いです。
If you need to use TLS (or IPSec) under SASL, why bother with SASL in the first place? Why not simply use the authentication facilities of TLS and be done with it?
あなたが、SASLの下でTLS(または、IPSec)を使用する必要があるなら、なぜ第一に、SASLを苦にしますか? なぜ単にTLSの認証施設を使用して、それでしませんか?
The answer here is subtle. TLS makes extensive use of certificates for authentication. As commonly deployed, only servers have certificates, whereas clients go unauthenticated (at least by the TLS processing itself).
ここでの答えは微妙です。 TLSは証明書の認証の大規模な使用をします。 サーバだけには、一般的に配布されるように、証明書がありますが、クライアントは非認証されているのに行きます(少なくともTLS処理自体で)。
SASL permits the use of more traditional client authentication technologies, such as passwords (one-time or otherwise). A powerful combination is TLS for underlying protection and authentication of the server, and a SASL-based system for authenticating clients. Care must be taken to avoid man-in-the-middle vulnerabilities when different authentication techniques are used in different directions.
SASLはパスワードなどの、より伝統的なクライアント認証技術(1回の、または、そうでない)の使用を可能にします。 強力な組み合わせはサーバの基本的な保護と認証、およびクライアントを認証するSASLベースのシステムのためのTLSです。 異なった認証のテクニックが異なった方向に使用されるとき、中央の男性脆弱性を避けるために注意しなければなりません。
3.6. GSS-API
3.6. GSS-アピ
GSS-API [RFC2744] provides a framework for applications to use when they require authentication, integrity, and/or confidentiality. Unlike SASL, GSS-API can be used easily with UDP-based applications. It provides for the creation of opaque authentication tokens (aka chunks of memory) which may be embedded in a protocol's data units. Note that the security of GSS-API-protected protocols depends on the underlying security mechanism; this must be evaluated independently. Similar considerations apply to interoperability, of course.
彼らが認証、保全、そして/または、秘密性を必要とするとき、GSS-API[RFC2744]はアプリケーションが使用するフレームワークを提供します。 SASLと異なって、UDPベースのアプリケーションと共にGSS-APIを容易に使用できます。 それはプロトコルのデータ単位で埋め込まれるかもしれない不透明な認証トークン(メモリの別名塊)の作成に備えます。 GSS APIが保護されたプロトコルのセキュリティが基本的なセキュリティー対策によることに注意してください。 独自にこれを評価しなければなりません。 同様の問題が相互運用性に適用される、もちろん。
3.7. DNSSEC
3.7. DNSSEC
DNSSEC [RFC2535] digitally signs DNS records. It is an essential tool for protecting against DNS cache contamination attacks [Bell95]; these in turn can be used to defeat name-based authentication and to redirect traffic to or past an attacker. The latter makes DNSSEC an essential component of some other security mechanisms, notably IPsec.
DNSSEC[RFC2535]は、DNSが記録であるとデジタルに署名します。 それはDNSキャッシュ汚染攻撃[Bell95]から守るための不可欠のツールです。 名前ベースの認証を破って、攻撃者か攻撃者の先でトラフィックを向け直すのに順番にこれらを使用できます。 後者はDNSSECをある他のセキュリティー対策、著しくIPsecの必須成分にします。
Although not widely deployed on the Internet at the time of the writing of this document, it offers the potential to provide a secure mechanism for mapping domain names to IP protocol addresses. It may also be used to securely associate other information with a DNS name.
このドキュメントの書くこと時点でインターネットで広く配布されませんが、それはIPプロトコルアドレスにドメイン名を写像するのに安全なメカニズムを提供する可能性を提供します。 また、それは、しっかりと他の情報をDNS名に関連づけるのに使用されるかもしれません。
Bellovin, et al. Informational [Page 9] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[9ページ]のRFC3631セキュリティー対策
This information may be as simple as a service that is supported on a given node, or a key to be used with IPsec for negotiating a secure session. Note that the concept of storing general purpose application keys in the DNS has been deprecated [RFC3445], but standardization of storing keys for particular applications - in particular IPsec - is proceeding.
この情報は安全なセッションを交渉するのにIPsecと共に使用されるために与えられたノード、またはキーの上にサポートされるサービスと同じくらい簡単であるかもしれません。 DNSに汎用のアプリケーションキーを保存する概念が推奨しないのですが[RFC3445]、特定用途のための保存キーの規格化(特にIPsec)が続いていることに注意してください。
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.
セキュリティ/Multiparts[RFC1847]は、メールを保護するための都合のよいメカニズムです。 より正確に、それは暗号化、そして/または、デジタル署名が埋め込まれているMIMEフレームワークです。 S/MIMEとOpenPGP(以下を見る)使用のそれらのコード化における、Security/複合の両方。 メール読者を従わせるのは、容易にメールの暗号の部分を認識して、処理できます。
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.
セキュリティ/Multipartsはエンドユーザにとって、興味深いオブジェクトが保護される1つのフォームの「オブジェクトセキュリティ」を表します、移送機構、中間的ストレージなどの如何にかかわらず 現在、インターネットで利用可能なオブジェクト保護のどんな一般的なフォームもありません。
For a good example of using S/MIME outside the context of email, see Session Initiation Protocol [RFC 3261].
メールの文脈の外にS/MIMEを使用する好例に関しては、Session Initiationプロトコル[RFC3261]を見てください。
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.
挑戦/応答認証の最も強いフォームの1つはデジタル署名に基づいています。 公開鍵暗号を使用するのはどんなサーバもクライアントの秘密のコピーを必要としないので秘密鍵暗号に基づく体系より望ましいです。 むしろ、クライアントには、秘密鍵があります。 サーバには、対応する公開鍵があります。
Using digital signatures properly is tricky. A client should never sign the exact challenge sent to it, since there are several subtle number-theoretic attacks that can be launched in such situations.
適切にデジタル署名を使用するのは扱いにくいです。 クライアントはそれに送られた正確な挑戦に決して署名するべきではありません、そのような状況で着手できるいくつかの微妙な数の理論的な攻撃があるので。
The Digital Signature Standard [DSS] and RSA [RSA] are both good choices; each has its advantages. Signing with DSA requires the use of good random numbers [RFC1750]. If the enemy can recover the random number used for any given signature, or if you use the same random number for two different documents, your private key can be recovered. DSS has much better performance than RSA for generating new private keys, and somewhat better performance generating signatures, while RSA has much better performance for verifying signatures.
デジタル署名基準[DSS]とRSA[RSA]は両方の良い選択です。 それぞれには、利点があります。 DSAと契約するのは良い乱数[RFC1750]の使用を必要とします。 敵がどんな与えられた署名にも使用される乱数を回復できるか、またはあなたが2通の異なったドキュメントに同じ乱数を使用するなら、あなたの秘密鍵を回復できます。 DSSには、新しい秘密鍵を生成するためのRSAよりはるかに良い性能、および署名を生成するいくらか良い性能があります、RSAでは、署名について確かめるためのはるかに良い性能がありますが。
Bellovin, et al. Informational [Page 10] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[10ページ]のRFC3631セキュリティー対策
3.10. OpenPGP and S/MIME
3.10. OpenPGPとS/MIME
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.
この書くこと、2異なった安全なメールプロトコル、OpenPGP[OpenPGP]、およびS/MIME[S/MIME]のときに、提案されて、PEM[PEM]を取り替えてください、そうした。 どれがどちらかなら成功するかは、明確ではありません。 安全なメールで使用に指定されている間、他のプロトコルによって運ばれたデータを保護するために両方を適合させることができます。 両方がユーザを特定するのに証明書を使用します。 両方がメール・メッセージの秘密保持と認証を提供できます。 しかしながら、証明書形式は非常に異なっています。 PGPベースのメールとMIME S/ベースのメールの違いは歴史的に、証明書推論のスタイルです。 S/MIMEでは、ユーザはX.509証明書を持っています。 証明グラフは非常に少ない数のルーツがある木です。 対照的に、PGPはいわゆる「信頼のウェブ」を使用します。そこでは、どんなユーザも他の誰の証明書にも署名することができます。 この証明グラフは本当に任意のグラフか1セットのグラフです。
With any certificate scheme, trust depends on two primary characteristics. First, it must start from a known-reliable source, either an X.509 root, or someone highly trusted by the verifier, often him or herself. Second, the chain of signatures must be reliable. That is, each node in the certification graph is crucial; if it is dishonest or has been compromised, any certificates it has vouched for cannot be trusted. All other factors being equal (and they rarely are), shorter chains are preferable.
どんな証明書体系でも、信頼は2つのプライマリ特性に依存します。 まず最初に、知られている信頼すべき筋から始めなければなりません、とX.509根かだれかのどちらかが高く検証、しばしば彼または自分で信じました。 2番目に、署名のチェーンは高信頼でなければなりません。 証明グラフによるすなわちそれぞれのノードは重要です。 それが不正直であるか、または感染されたなら、それが保証したどんな証明書も信じることができません。 等しさであっ(めったにそれらはそうである)て、より短いチェーンである他のすべての要素が望ましいです。
Some of the differences reflect a tension between two philosophical positions represented by these technologies. Others resulted from having separate design teams.
違いのいくつかがこれらの技術で表された2つの哲学的な位置の間の緊張を反映します。 他のものは別々のデザインが組にする有から生じました。
S/MIME is designed to be "fool proof". That is, very little end-user configuration is required. Specifically, end-users do not need to be aware of trust relationships, etc. The idea is that if an S/MIME client says, "This signature is valid", the user should be able to "trust" that statement at face value without needing to understand the underlying implications.
S/MIMEは、「きわめて簡単に」なるように設計されています。 すなわち、非常に小さいエンドユーザ構成が必要です。 明確に、エンドユーザは信頼関係などを意識している必要はありません。 考えは「この署名は有効です」と、S/MIMEクライアントが言うなら、ユーザが基本的な含意を理解する必要はなくて額面通りのその声明を「信じることができるべきである」ということです。
To achieve this, S/MIME is typically based on a limited number of "root" Certifying Authorities (CAs). The goal is to build a global trusted certificate infrastructure.
これを達成するために、S/MIMEは「根」Certifying Authorities(CAs)の限られた数に通常基づいています。 目標はグローバルな信じられた証明書インフラストラクチャを築き上げることです。
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
このアプローチへの下に側は働く前に配布している公開鍵認証基盤を必要とするということです。 2人のエンドユーザは、単にMIME S/できるソフトウェアを入手して、しっかりと交信し始めることができないかもしれません。 これはプロトコル的にもかかわらず、a典型的の制限ではありません。
Bellovin, et al. Informational [Page 11] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[11ページ]のRFC3631セキュリティー対策
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.
PGP「信頼のウェブ」アプローチは、2人のエンドユーザがまさしくそうすることができる利点がPGPソフトウェアを入手して、すぐにしっかりと交信し始めるのをさせます。 インフラストラクチャは全く必要ではありません、そして、料金がなくて法的な協定は続くように署名される必要があります。 そういうものとして、PGPは臨時のセキュリティ協会を設立する必要がある人々の好みに合います。
The down side to PGP is that it requires end-users to have an understanding of the underlying security technology in order to make effective use of it. Specifically it is fairly easy to fool a naive users to accept a "signed" message that is in fact a forgery.
PGPへの下に側はそれをうまく利用するのにエンドユーザには基本的なセキュリティー技術の理解があるのが必要であるということです。 明確にそれは、事実上偽造である「署名している」メッセージを受け入れるためにナイーブなユーザをかなりだましやすいです。
To date PGP has found great acceptance between security-aware individuals who have a need for secure e-mail in an environment devoid of the necessary global infrastructure.
これまで、PGPは環境における安全なメールの必要性を必要なグローバルなインフラストラクチャに欠けるようにするセキュリティ意識している個人の間のかなりの承認を見つけました。
By contrast, S/MIME works well in a corporate setting where a secure internal CA system can be deployed. It does not require a lot of end-user security knowledge. S/MIME can be used between institutions by carefully setting up cross certification, but this is harder to do than it seems.
対照的に、S/MIMEは安全な内部のカリフォルニアシステムを配布することができる法人の設定でうまくいきます。 それは多くのエンドユーザセキュリティ知識を必要としません。 団体の間で慎重に相互認証をセットアップすることによってS/MIMEを使用できますが、これは見えるよりしにくいです。
As of this writing a global certificate infrastructure continues to elude us. Questions about a suitable business model, as well as privacy considerations, may prevent one from ever emerging.
この書くこと現在、グローバル証書インフラストラクチャは、私たちを避け続けています。 適当なビジネスモデル、およびプライバシー問題に関する質問によって、1つは現れることができないかもしれません。
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.
ファイアウォールは位相的な防衛機構です。 すなわち、彼らは何らかのドメインの良い“inside"と悪い「外部」の間の明確な境界を当てにします、ファイアウォールが情報の通路を調停していて。 適切に使われるなら、ファイアウォールは非常に貴重である場合がありますが、ネットワークを保護する彼らの能力への限界があります。
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
最初の制限はもちろんファイアウォールが内面の攻撃から守ることができないということです。 実際の罹患率のそのような攻撃は知られていませんが(そして、たぶん不可知です)、実質的であり、論証上警備上の問題の大部分を構成するという疑問が全くありません。より一般に、ファイアウォールがそのような境界が存在していないという範囲によく区切られた境界を必要とするなら、ファイアウォールは役に立ちません。 どんな外部の接続、も彼ら
Bellovin, et al. Informational [Page 12] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[12ページ]のRFC3631セキュリティー対策
are protocols that are deliberately passed through the firewall, links that are tunneled through, unprotected wireless LANs, or direct external connections from nominally-inside hosts, weaken the protection. Firewalls tend to become less effective over time as users tunnel protocols through them and may have inadequate security on the tunnel endpoints. If the tunnels are encrypted, there is no way for the firewall to censor them. An oft-cited advantage of firewalls is that they hide the existence of internal hosts from outside eyes. Given the amount of leakage, however, the likelihood of successfully hiding machines is rather low.
故意にファイアウォールを通り抜けるプロトコル、トンネルを堀られるリンクは保護のない無線LANであるか名目上は内面のホストから外部の接続を指示してください、そして、保護を弱めてください。 ファイアウォールは、ユーザがそれらを通してプロトコルにトンネルを堀って、トンネル終点に不十分なセキュリティを持っているとき時間がたつにつれてより有効でなくなる傾向があります。 トンネルが暗号化されているなら、ファイアウォールがそれらについて検閲する方法が全くありません。 ファイアウォールのしばしば引用された利点は目の外から内部のホストの存在を隠すということです。 しかしながら、漏出の量を考えて、首尾よくマシンを隠すという見込みはかなり低いです。
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.
それらが総合セキュリティ構造の1つの要素として使用されるとき、ファイアウォールはうまくいきます。 例えば、厳しいファイアウォールは、バックエンドデータベース(2つの間の唯一の始まりによる通信チャネル)と暴露しているウェブサーバを切り離すのに使用されるかもしれません。 同様に、VPNの1つの断片を保証するのに暗号化されたトンネルトラフィックだけを可能にしたファイアウォールは使用できました。 他方では、その場合、VPNのもう一方の端は、等しく機密保護される必要があるでしょう。
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.
2つの実体が互いを認証するように[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.
ケルベロスはプロトコルにそれ自体で使用されるかもしれません。 しかしながら、また、それもメカニズムとしてSASLとGSSAPIの下で利用可能です。 それには、いくつかの知られている脆弱性[KRBATTACK][KRBLIM][KRB4WEAK]がありますが、しっかりとそれを使用できます。
3.13. SSH
3.13. セキュアシェル (SSH)
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
SSHはクライアントとサーバとの安全な関係を提供します。TLSのように、作動します。 しかしながら、それはリモート接続のためのプロトコルとして端末のようなデバイスで最適化されます。 より革新的な特徴の1つはその他のプロトコルのSSHによって保護されたTCP接続の上で「トンネル」であるサポートです。 この特徴は可能にしました。
Bellovin, et al. Informational [Page 13] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[13ページ]のRFC3631セキュリティー対策
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.
不安定なネットワークの上の不安定なサーバでメールかニュースを読んで、送るような動作を実行する博識なセキュリティの人々。 それは本当のVPNの代用品ではありませんが、しばしば1に代わってそれを使用できます。
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]であると考えられます。 しかしながら、それは、HMACベースの挑戦/応答などの、より強い認証機構にわたるのを排除するかもしれません。
The strongest attack against passwords, other than eavesdropping, is password-guessing. With a suitable program and dictionary (and these are widely available), 20-30% of passwords can be guessed in most environments [Klein90].
盗聴を除いてパスワードに対する最も強い攻撃はパスワード推測です。 20-30 適当なプログラムと辞書(これらは広く利用可能である)で、ほとんどの環境[Klein90]で%のパスワードを推測できます。
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.
別の共通の安全保障メカニズムはアドレスベースの認証です。 せいぜい、それは非常に強制的な環境で働くことができます。 あなたの環境が少ない数のマシンから成るなら、すべてのしっかり管理されて、安全なシステムが信じられたユーザで動きます、そして、ネットワークがソースルーティングを妨げて、だますのを防ぐあなたのソースアドレスのルータによって警備されて、あなたが、どんなワイヤレスのブリッジもないのを知って、そのネットワークでアドレスベースの認証をマシンに制限するなら、あなたはたぶん安全です。 しかし、これらの条件はめったに満たされません。
Bellovin, et al. Informational [Page 14] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[14ページ]のRFC3631セキュリティー対策
Among the threats are ARP-spoofing, abuse of local proxies, renumbering, routing table corruption or attacks, DHCP, IP address spoofing (a particular risk for UDP-based protocols), sequence number guessing, and source-routed packets. All of these can be quite potent.
脅威の中に、ARP-スプーフィング、地元のプロキシか番号を付け替えるか経路指定テーブル不正か攻撃と、DHCPと、(UDPベースのプロトコルのための特定のリスク)を偽造するIPアドレスと、一連番号推測と、ソースによって発送されたパケットの乱用があります。 これらのすべてがかなり強力である場合があります。
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.
名前ベースの認証は、アドレスベースの認証の問題のすべてを持って、新しいものを加えます: アドレスと名前の間の1〜1つのマッピングのDNS[Bell95]と不足に対する攻撃。 最小限では、DNSからホスト名を検索するプロセスは対応するアドレス記録と再チェックを検索するはずです。 DNSキャッシュ汚染などのテクニックはしばしばそのようなチェックを否定できます。
DNSSEC provides protection against this sort of attack. However, it does nothing to enhance the reliability of the underlying address. Further, the technique generates a lot of false alarms. These lookups do not provide reliable information to a machine, though they might be a useful debugging tool for humans and could be useful in logs when trying to reconstruct how and attack took place.
DNSSECはこの種類の攻撃に対する保護を提供します。 しかしながら、それは基本的なアドレスの信頼性を高めるようなことを何もしません。 さらに、テクニックは多くの間違い警報を生成します。これらのルックアップは信頼できる情報をマシンに供給しません、それらが、人間にとって、役に立つデバッグ用ツールであるかもしれなく、どのようにを再建しようとするかとき、ログで役に立つかもしれません、そして、攻撃は行われましたが。
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. IANA問題
There are no IANA considerations regarding this document.
このドキュメントに関するIANA問題が全くありません。
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.
ブライアンCarpenter、トニー・ハイン、およびマーカスLeechは多くの役に立つ提案をしました。 物質の多くがIAB Security Architecture Workshopの関係者から来ます。
Bellovin, et al. Informational [Page 15] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[15ページ]のRFC3631セキュリティー対策
8. Informative References
8. 有益な参照
[Bell95] "Using the Domain Name System for System Break-Ins".
Proc. Fifth Usenix Security Conference, 1995.
[Bell95] 「システム不法侵入にドメインネームシステムを使用します」。 Proc。 第5Usenixセキュリティコンファレンス、1995。
[Bell98] "Cryptography and the Internet", S.M. Bellovin, in
Proceedings of CRYPTO '98, August 1998.
[Bell98]「暗号とインターネット」、暗号98年、8月1998の議事におけるS.M.Bellovin
[DSS] "Digital Signature Standard". NIST. May 1994. FIPS
186.
[DSS]「デジタル署名基準。」 NIST1994年5月。 FIPS186。
[Klein90] "Foiling the Cracker: A Survey of, and Implications to,
Password Security". D. Klein. Usenix UNIX Security
Workshop, August 1990.
[Klein90]、「クラッカーにはくを敷きます:」 「Survey、Implications、Password Security、」 D。 クライン。 1990年8月のUsenix UNIXセキュリティワークショップ。
[KRBATTACK] "A Real-World Analysis of Kerberos Password Security".
T. Wu. Network and Distributed System Security Symposium
(NDSS '99). January 1999.
[KRBATTACK] 「ケルベロスパスワードセキュリティの本当の世界分析。」 T。 ウー。 ネットワークと分散システムセキュリティシンポジウム(NDSS'99)、' 1999年1月。
[KRBLIM] "Limitations of the Kerberos Authentication System".
Proceedings of the 1991 Winter USENIX Conference, 1991.
[KRBLIM] 「ケルベロス認証システムの限界。」 1991年の冬のUSENIXコンファレンス、1991年の議事。
[KRB4WEAK] "Misplaced trust: Kerberos 4 session keys". Proceedings
of the Internet Society Network and Distributed Systems
Security Symposium, March 1997.
[KRB4WEAK] 「置き違えられて、以下を信じてください」 「ケルベロス4セッションキー。」 1997年3月のインターネット協会ネットワークと分散システムセキュリティシンポジウムの議事。
[MT79] "UNIX Password Security", R.H. Morris and K. Thompson,
Communications of the ACM. November 1979.
[MT79] 「UNIXパスワードセキュリティ」とR.H.モリスとK.トンプソン、ACMに関するコミュニケーション。 1979年11月。
[NATIKE] Kivinen, T., et al., "Negotiation of NAT-Traversal in the
IKE", Work in Progress, June 2002.
[NATIKE] Kivinen、T.、他、「IKEでのNAT縦断の交渉」、Progress、2002年6月のWork。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510]コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[RFC1750] イーストレークとD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
[RFC1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[RFC1847] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
Bellovin, et al. Informational [Page 16] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[16ページ]のRFC3631セキュリティー対策
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC2222] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-
Time Password System", STD 61, RFC 2289, February 1998.
[RFC2289] ハラーとN.とメスとC.とNesserとP.とM.わら、「A One時間パスワードシステム」、STD61、RFC2289、1998年2月。
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
[RFC2316] Bellovin、S.、「IABセキュリティー体系ワークショップのレポート」、RFC2316、1998年4月。
[RFC2385] Hefferman, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Hefferman、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[RFC2411] セイヤーとR.とDoraswamyとN.とR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、1998年11月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2535] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
[RFC2744] Wray, J., "Generic Security Service API Version 2: C-
bindings", RFC 2744, January 2000.
[RFC2744] レイ、J.、「ジェネリックセキュリティはAPIバージョン2を供給します」。 「C結合」、RFC2744、2000年1月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC2993] ハイン、T.、「NATの建築含意」、RFC2993、2000年11月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[RFC3174]イーストレークとD.とP.ジョーンズ、「米国安全なハッシュアルゴリズム1(SHA1)」、RFC3174 2001年9月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, R., Johnston,
A., Peterson, J., Sparks, R., Handley, M. and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、R.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
Bellovin, et al. Informational [Page 17] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[17ページ]のRFC3631セキュリティー対策
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[RFC3445] RFC3445、「主要なリソース記録(RR)の範囲を制限し」て、マッシー、D.、およびS.は上昇して、12月は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.
[RSA] RivestとR.とシャミルとA.とL.Adleman、「デジタル署名と公開鍵暗号系を得るためのメソッド」、ACM(1978年2月)に関するコミュニケーション。
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.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
Bellovin, et al. Informational [Page 18] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[18ページ]のRFC3631セキュリティー対策
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
バーナードAbobaハラルドAlvestrandロブAusteinレスリーDaigle、議長パトリクFaltstromはフロイド6月-ichiro Itojun Haginoマークハンドレージェフヒューストンチャーリー・カウフマンジェームスケンフエリックレスコラマイケルStJohnsを出撃させます。
Internet Architecture Board EMail: iab@iab.org
インターネット・アーキテクチャ委員会メール: iab@iab.org
Steven M. Bellovin, Editor EMail: bellovin@acm.org
スティーブンM.Bellovin、エディタメール: bellovin@acm.org
Jeffrey I. Schiller, Editor EMail: jis@mit.edu
ジェフリー・I.シラー、エディタメール: jis@mit.edu
Charlie Kaufman, Editor EMail: charliek@microsoft.com
チャーリー・カウフマン、エディタメール: charliek@microsoft.com
Bellovin, et al. Informational [Page 19] RFC 3631 Security Mechanisms for the Internet December 2003
Bellovin、他 インターネット2003年12月のための情報[19ページ]のRFC3631セキュリティー対策
11. Full Copyright Statement
11. 完全な著作権宣言文
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 assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bellovin, et al. Informational [Page 20]
Bellovin、他 情報[20ページ]
一覧
スポンサーリンク
