RFC2316 日本語訳
2316 Report of the IAB Security Architecture Workshop. S. Bellovin. April 1998. (Format: TXT=19733 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Bellovin Request for Comments: 2316 AT&T Labs Research Category: Informational April 1998
Bellovinがコメントのために要求するワーキンググループS.をネットワークでつないでください: 大西洋標準時2316とT研究室はカテゴリについて研究します: 情報の1998年4月
Report of the IAB Security Architecture Workshop
IABセキュリティー体系ワークショップのレポート
1. Status of this Memo
1. この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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
2. Copyright Notice
2. 版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
3. Abstract
3. 要約
On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. We identified the core security components of the architecture, and specified several documents that need to be written. Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning.
1997年3月3-5日に、IABはマリー・ヒル(ニュージャージー)のベル研究所でセキュリティー体系ワークショップを開きました。 私たちは、アーキテクチャのコアセキュリティ成分を特定して、書かれている必要があるいくつかのドキュメントを指定しました。 最も重要に、私たちは、セキュリティが任意でなく、それが、始めから中に設計される必要だったのに同意しました。
3.1. Specification Language
3.1. 仕様言語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
4. Motivations
4. 動機
On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. The ultimate goal was to design a security architecture for the Internet. More concretely, we wished to understand what security tools and protocols exist or are being developed, where each is useful, and where we are missing adequate security tools. Furthermore, we wanted to provide useful guidance to protocol designers. That is, if we wish to eliminate the phrase "security issues are not discussed in this memo" from future RFCs, we must provide guidance on acceptable analyses.
1997年3月3-5日に、IABはマリー・ヒル(ニュージャージー)のベル研究所でセキュリティー体系ワークショップを開きました。 究極の目標はインターネットにセキュリティー体系を設計することでした。 より具体的に、私たちはどんなセキュリティツールとプロトコルが存在しているか、または開発されているか、そして、それぞれがどこで役に立つか、そして、どこで十分な安全性ツールを逃しているかを理解したかったです。 その上、私たちは、デザイナーについて議定書の中で述べるために役に立つ指導を提供したかったです。 すなわち、句を排除するために、将来のRFCsから「このメモで安全保障問題について議論しないこと」を願うなら、私たちは許容できる分析のときに指導を提供しなければなりません。
Bellovin Informational [Page 1] RFC 2316 Report of the IAB April 1998
IAB1998年4月のBellovinの情報[1ページ]のRFC2316レポート
There were twenty-four attendees (their names are listed in Appendix A). Perhaps not surprisingly for such a group, the overwhelming majority used some form of cryptography when connecting back to their home site from the meeting room. But the situation on the rest of the Internet is not nearly as good; few people use encryption, even when they should.
24人の出席者がいました(彼らの名前はAppendix Aに記載されています)。 会議室からそれらのホームサイトに接続して戻るとき、恐らく当然ながら、そのようなグループのために、圧倒的多数は何らかのフォームに関する暗号を使用しました。 しかし、インターネットの残りの状況は決して同じくらい良くはありません。 彼らが使用さえするべきであるとき、わずかな人々しか暗号化を使用しません。
The problem is that the rate of attacks is increasing. Apart from
the usual few elite hackers -- the ones who find the new holes --
there are many canned exploit scripts around. ("Click here to attack
this system.") Furthermore, the attackers have gotten smarter; rather
than going after random university machines, more and more are
targeting the Internet infrastructure, such as routers, high-level
name servers, and the like.
問題は攻撃の速度が増加しているということです。 わずかな普通のエリートハッカー(新しい穴を見つける人)は別として、多くの缶詰功績スクリプトが周囲にあります。 (「ここでクリックして、このシステムを攻撃してください」。) その上、攻撃者は、より賢くなりました。 無作為の大学マシンを追いかけるよりむしろ、以上とその他はインターネット基盤を狙っています、ルータや、ハイレベルのネームサーバや、同様のものなどのように。
The problem is compounded by organizational laziness. Users and system administrators want "magic security" -- they want whatever they do to be secure, regardless of whether or not it is, or even can be.
問題は組織的な不精によって悪化させられます。 ユーザとシステム管理者は「魔法のセキュリティ」が欲しいです--彼らは、彼らがすることなら何でもに安全であって欲しいです、それがあるか、またはあることさえできるかどうかにかかわらず。
5. General Philosophy
5. 一般哲学
We concluded that in general, end-to-end security is better. Thus, one should use something like PGP or S/MIME for email, rather than relying on an IPsec layer. In general, relying on the security of the infrastructure is a bad idea; it, too, is under attack. Even firewall-protected intranets can be subverted. At best, the infrastructure should provide availability; it is the responsibility of individual protocols not to make unreasonable demands on the infrastructure during an attack.
私たちは、一般に、終わりから終わりへのセキュリティが、より良いと結論を下しました。 したがって、メールにIPsec層を当てにするよりむしろ何かPGPやS/MIMEのようなものを使用するべきです。 一般に、インフラストラクチャのセキュリティを当てにするのは、悪い考えです。 また、それは攻撃されています。 ファイアウォールで保護されたイントラネットさえ打倒できます。 せいぜい、インフラストラクチャは有用性を提供するべきです。 攻撃の間、インフラストラクチャでむり難題をしないのは、個々のプロトコルの責任です。
6. IETF Structure
6. IETF構造
Our security problem is compounded by the IETF's inherent structure (or, in some cases, the lack thereof). By intent, we are a volunteer organization. Who should do the security work? The other protocol designers? Often, they have neither the time nor the interest nor the training to do it. Security area members? What if they are not interested in some subject area, or lack the time themselves? We cannot order them to serve.
IETFの固有の構造(いくつかの場合それの不足)によって私たちの警備上の問題は悪化させられます。 故意に、私たちはボランティア組織です。 だれがセキュリティ仕事をするべきですか? 他のプロトコルデザイナー? 彼らには、しばしば、時間も関心もあるというわけではありません。または、それをするトレーニング。 セキュリティ領域メンバー? 何らかのサブジェクト・エリアに関心がないか、または自分たちで時間を欠いていると、どうなるでしょうか? 私たちは、役立つよう彼らに命令することができません。
To the extent that the IETF does have management, it is embodied in the working group charters. These are in essence contracts between the IESG and a working group, spelling out what is to be done and on what schedule. Can the IESG unilaterally impose new requirements on existing working groups? What if security cannot be added on without substantial changes to the fundamental structure of a protocol that has been reworked over several years?
IETFには管理があるという範囲に、それはワーキンググループ特許に表現されます。 IESGとワーキンググループの間には、本質契約法にこれらがあります、することになっているべきことについて詳しく説明して、どんなスケジュールで。 IESGは一方的に新しい要件を既存のワーキンググループに課すことができますか? 数年間作りなおされているプロトコルの基礎構造への大きな変化なしでセキュリティを加えることができないと、どうなるでしょうか?
Bellovin Informational [Page 2] RFC 2316 Report of the IAB April 1998
IAB1998年4月のBellovinの情報[2ページ]のRFC2316レポート
Finally, there is a perception problem: that IPsec will somehow solve the security problem. It won't; indeed, it can't. IPsec provides excellent protection of packets in transit. But it's hard to deploy on individual hosts, does not protect objects that may be retransmitted (i.e., email messages), does not address authorization issues, cannot block against excess resource consumption, etc.
最終的に、知覚問題があります: そのIPsecはどうにか警備上の問題を解決するでしょう。 それはそうしないでしょう。 本当に、それはそうすることができません。 IPsecはトランジットにおける、パケットの素晴らしい保護を提供します。 しかし、それは、個々のホストの上で配布しにくくて、再送されるかもしれないオブジェクト(すなわち、メールメッセージ)を保護しないで、承認問題を扱わないで、余分なリソース消費に対して立ち塞がることができませんなど。
7. Documents to be Written
7. Writtenであるドキュメント
Collectively, we decided on several documents that need to be written:
私たちは書かれている必要があるいくつかのドキュメントをまとめて、決めました:
Taxonomy of Attacks
In order to defend a protocol against attacks, one must, of
course, know the kinds of attacks that are possible. While the
specifics differ from protocol to protocol, a number of general
categories can be constructed.
攻撃に対してプロトコルを防御するAttacks In命令の分類学、もちろん可能な攻撃の種類を知らなければなりません。 詳細が議定書の中で述べるプロトコルと異なっている間、多くの一般的なカテゴリを構成できます。
Implementation Hints and Pitfalls
Even if a protocol is sound, a host running it can be
vulnerable if the protocol is implemented improperly. A
variety of common errors can and do subvert the best designs.
そして、実装ヒント、プロトコルがあるなら、Pitfalls Evenは鳴って、プロトコルが不適切に実装されるなら、それを実行するホストは被害を受け易い場合があります。 さまざまな一般的な誤りが、打倒して、最も良いデザインを打倒できます。
Firewall Issues
Firewalls are both a common defense and a much-reviled wart on
the Internet. Regardless, they are unlikely to go away any
time soon. They have both strengths and weaknesses that must
be considered when deploying them. Furthermore, some protocols
have characteristics that are unnecessarily firewall-hostile;
such practices should be avoided.
ファイアウォールIssues Firewallsは共同防衛とインターネットにおけるたくさん悪口を言われたいぼの両方です。 不注意に、彼らはすぐ、いつでも立ち去りそうにはありません。 彼らには、それらを配布するとき考えなければならない長所と短所の両方があります。 その上、いくつかのプロトコルには、ファイアウォール不必要に敵対的な特性があります。 そのような習慣は避けられるべきです。
Workshop Report
This document.
ワークショップReport Thisドキュメント。
8. Working Group Charters
8. ワーキンググループ憲章
The actual text in the working group charter is likely to be something fairly simple, like
ワーキンググループにおけるテキストがチャーターする実際は、かなり何かであること簡単なものがありそうであり、好きです。
Protocols developed by this working group will be analyzed for
potential sources of security breach. Identified threats will be
removed from the protocol if possible, and documented and guarded
against in other cases.
このワーキンググループによって開発されたプロトコルは機密保護違反の可能な源に分析されるでしょう。 特定された脅威は、他の場合でできれば、プロトコルから取り除かれて、記録されて、用心されるでしょう。
The actual charter text represents a policy enjoined and enforced by the IESG, and may change from time to time and from charter to
実際の特許テキストは、IESGによって言いつけられて、励行された方針を表して、時々と特許から変化するかもしれません。
Bellovin Informational [Page 3] RFC 2316 Report of the IAB April 1998
IAB1998年4月のBellovinの情報[3ページ]のRFC2316レポート
charter. However, it essentially references and asks for text in documents conforming to the following, which may be very appropriate to include in the RFC.
チャーターします。 しかしながら、それは、本質的には以下に一致しているドキュメントのテキストに参照をつけて、求めます。(ドキュメントはRFCに含んでいるのは非常に適切であるかもしれません)。
9. Guidelines on writing Security Considerations in an RFC
9. RFCにSecurity Considerationsに書くことに関するガイドライン
A "threat" is, by definition, a vulnerability available to a
motivated and capable adversary. CERT advisories are quite
predictable given a knowledge of the target of the threat; they
therefore represent an existence proof, but not a threat analysis.
The point is to determine what attacks are possible ("capabilities"
of a potential attacker) and formulate a defense against the attacks,
or convincingly argue that the attack is not realistic in some
environment and restrict use of the protocol to that environment.
「脅威」は定義上動機づけられて有能な敵にとって、利用可能な脆弱性です。 脅威の目標に関する知識を考えて、CERT勧告はかなり予測できます。 したがって、彼らは脅威分析ではなく、存在証拠を表します。 ポイントは、その環境にどんな攻撃が可能であるかを(潜在的攻撃者の「能力」)決定して、攻撃に対してディフェンスを定式化するか、攻撃が何らかの環境で現実的でないともっともらしく主張して、またはプロトコルの使用を制限することです。
Recommended guidelines:
勧告事項:
All RFCs - MUST meaningfully address security in the protocol or
procedure it specifies. It MUST consider that it is giving its
data to "the enemy" and asking it to be delivered to its friends
and used in the manner it intended. Consideration MUST be given to
the ramifications of the inherent danger of the situation.
すべてのRFCs--意味深長に、それが指定するプロトコルか手順におけるセキュリティを扱わなければなりません。 「敵」にデータを与えて、友人に提供されて、それが意図した方法で使用されるようにそれに頼んでいるのを考えなければなりません。 状況の固有の危険の分岐に対して考慮を払わなければなりません。
- MUST do "due diligence" to list the threats to which the
protocol is vulnerable. Use of legal term does not imply legal
liability, but rather the level of responsibility expected to be
applied to the analysis. This discussion might occur throughout
the document or in the Security Considerations section; if it
occurs throughout, it MUST be summarized and referenced in the
Security Considerations section.
- プロトコルが被害を受け易い脅威を記載するために「適切な注意」をしなければなりません。 法的な用語の使用は法的責任を含意するのではなく、むしろ分析に適用されると予想された責任の度合いを含意します。 この議論はドキュメント中、または、Security Considerations部に起こるかもしれません。 あらゆる点で起こるなら、Security Considerations部でそれをまとめられて、参照をつけなければなりません。
- MUST discuss which of those threats are
* Ameliorated by protocol mechanisms (example: SYN attack is
ameliorated by clever code that drops sessions randomly when
under SYN attack)
- それらの脅威のどれがプロトコルメカニズムによって改善された*であるかと議論しなければなりません。(SYN攻撃で例: SYN攻撃はその低下セッションの巧妙なコードによって手当たりしだいに改善されます)
* Ameliorated by reliance on external mechanisms (example: TCP
data confidentiality provided by IPSEC ESP)
* 外部のメカニズムへの信用で、改善されます。(例: IPSEC ESPによって提供されたTCPデータの機密性)
* Irrelevant ("In most cases, MIBs are not themselves security
risks; If SNMP Security is operating as intended, the use of a
MIB to change the configuration of a system is a tool, not a
threat. For a threat analysis of SNMP Security, see RFC ZZZZ.")
* 無関係(「多くの場合、MIBsは自分たちでセキュリティリスクではありません」。 SNMP Securityが意図されるとして作動しているなら、システムの構成を変えるMIBの使用は脅威ではなく、ツールです。 「SNMP Securityの脅威分析に関して、RFC ZZZZを見てください。」)
* Not addressed by the protocol; results in applicability
statement. ("This protocol should not be used in an
environment subject to this attack")
* プロトコルで、扱われません。 適用性証明の結果。 (「この攻撃を条件として環境でこのプロトコルを使用するべきではありません」)
Bellovin Informational [Page 4] RFC 2316 Report of the IAB April 1998
IAB1998年4月のBellovinの情報[4ページ]のRFC2316レポート
10. Core Security Mechanisms
10. コアセキュリティー対策
A variety of security mechanisms exist today. Not all are well- designed; not all are suitable for all purposes. The members of the workshop designated a number of protocols as "core". Such protocols should be used preferentially, if one of them has properties that match the needs of your protocol. The following were designated as core:
さまざまなセキュリティー対策が今日、存在します。 すべてがよく設計されるというわけではありません。 すべてがすべての目的に適しているというわけではありません。 ワークショップのメンバーは「コア」として多くのプロトコルを指定しました。 彼らのひとりにあなたのプロトコルの必要性に合っている特性があるなら、そのようなプロトコルは優先的に使用されるべきです。 以下はコアとして指定されました:
IPsec [RFC 1825] is the basic host-to-host security mechanism. It
is appropriate for use any time address-based protection would
have been used, including with such programs as rsh and rlogin.
If and when platforms support user-based keying, this scope may
be expanded.
IPsec[RFC1825]はホストからホストへの基本的なセキュリティー対策です。 使用に、アドレスベースの保護が使用されたのは、いつでも適切です、rshとrloginとしてそのようなものでプログラムを含んでいて。 プラットホームがユーザベースの合わせることをサポートするなら、この範囲は広げられるかもしれません。
One particular technique used by IPsec, HMAC [RFC 2104], is
more generally useful. If cryptographic authentication but not
secrecy is needed, and IPsec is not applicable, HMAC should be
used.
一般に、IPsecによって使用された1つの特定のテクニック(HMAC[RFC2104])が、より役に立ちます。 秘密保持ではなく、暗号の認証が必要であり、IPsecが適切でないなら、HMACは使用されるべきです。
ISAKMP/Oakley [ISAKMP drafts] is the basic key negotiation
protocol for IPsec. As such, it should be deployed when IPsec
is used. With the appropriate "domain of interpretation"
document, it should be used to negotiate pairwise keys for
other protocols.
ISAKMP/オークリー[ISAKMP草稿]は基本的なIPsecに、主要な交渉プロトコルです。 IPsecが使用されているとき、そういうものとして、それは配布されるべきです。 「解釈のドメイン」適切なドキュメントと共に、それは、他のプロトコルのために対状キーを交渉するのに使用されるべきです。
DNSsec [RFC 2065] is not only crucial for protecting the DNS --
cache contamination is the easiest way to launch active attacks
-- it's also needed in many situations when IPsec is used.
IPsecが使用されているときキャッシュ汚染が活発な攻撃に着手する最も簡単な方法であるというまたそれが多くの状況で必要としたDNSを保護するのに、DNSsec[RFC2065]は重要であるだけではありません。
Security/Multipart [RFC 1847] is the preferred way to add secured
sections to MIME-encapsulated email.
セキュリティ/複合であることは[RFC1847]、MIMEでカプセル化されたメールに機密保護しているセクションを追加する都合のよい方法です。
Signed keys in the DNS. There is, as noted, widespread agreement
that DNS records themselves must be protected. There was less
agreement that the key records should be signed themselves,
making them in effect certificates. Still, this is one
promising avenue for Internet certificates.
DNSのキーであると署名されます。 注意されるように、DNS記録自体を保護しなければならないという広範囲の協定があります。 そこでは、それらを事実上、証明書にして、主要な記録が署名されるべきであるというより少ない協定が自分たちでしたか? それでも、これはインターネット証明書のための1つの有望な大通りです。
X.509v3 is the other obvious choice for a certificate
infrastructure. Again, though, there was no strong consensus
on this point.
X.509v3は証明書インフラストラクチャのためのもう片方の当然の選択です。 もっとも、再び、このポイントの上にどんな強いコンセンサスもありませんでした。
TLS [TLS draft] was seen by some as the preferred choice for
transport-layer security, though there was no consensus on this
point. TLS is less intrusive to the operating system than
IPsec; additionally, it is easier to provide fine-grained
protection this way.
TLS[TLS草稿]はいくつかによってトランスポート層セキュリティのための都合のよい選択と考えられました、このポイントの上にコンセンサスが全くありませんでしたが。 TLSはIPsecほどオペレーティングシステムに押しつけがましくはありません。 さらに、きめ細かに粒状の保護をこの道に提供するのは、より簡単です。
Bellovin Informational [Page 5] RFC 2316 Report of the IAB April 1998
IAB1998年4月のBellovinの情報[5ページ]のRFC2316レポート
Some protocols were designated as "useful but not core". These were insufficiently general, too new, or were substantially duplicative of core protocols. These include AFT/SOCKS, RADIUS, firewalls, GSS-API, PGP, Kerberos, PGP-MIME, PKIX-3, the various forms of per-hop authentication (OSPF, RSVP, RIPv2), *POP, OTP, S/MIME, SSH, PFKey, IPsec API, SASL, and CRAM/CHAP. Obviously, entries on this list may move in either direction.
いくつかのプロトコルが任じられた、「役に立つ、コアでない、」 これらは、不十分に一般的であって、新し過ぎたか、またはコアプロトコルで実質的に重複していました。 これらはAFT/SOCKS、RADIUS、ファイアウォール、GSS-API、PGP、ケルベロス、PGP-MIME、PKIX-3、様々な形式の1ホップあたりの認証(OSPF、RSVP、RIPv2)、*POP、OTP、S/MIME、SSH、PFKey、IPsecアピ、SASL、およびCRAM/CHAPを含んでいます。 明らかに、このリストの上のエントリーはどちらの方向にも入って来るかもしれません。
A few protocols were considered "not useful". Primarily, these are ones that have failed to catch on, even though they've been available for some time. These include PEM [RFC 1421, 1422, 1423, 1424] and MOSS [RFC 1848]. (The phrase "not useful" does not imply that they are incorrect, or are lacking in important information. However, they do not describe protocols that we are currently encouraging the use of.)
いくつかのプロトコルが「役に立たない」と考えられました。 主として、これらはそれらがしばらく利用可能ですが、引っかかっていないものです。 これらはPEM[RFC1421、1422、1423、1424]とモス[RFC1848]を含んでいます。 (句、「役に立たない」であることは、それらが不正確であることを含意しないか、または重要情報で欠けていることです。 しかしながら、彼らは私たちが現在使用を奨励しているプロトコルについて説明しません。)
One security mechanism was deemed to be unacceptable: plaintext passwords. That is, no protocol that relies on passwords sent over unencrypted channels is acceptable.
1台のセキュリティー対策が容認できないと考えられました: 平文パスワード。 すなわち、非暗号化されたチャンネルの上に送られたパスワードを当てにするどんなプロトコルも許容できません。
11. Missing Pieces
11. なくなった断片
Participants in the workshop identified three significant missing pieces: object security, secure email, and route security.
ワークショップの関係者は3つの重要ななくなった断片を特定しました: オブジェクトセキュリティ、安全なメール、およびルートセキュリティ。
Object security refers to protection for individual data objects, independent of transport. We have one such already -- Secure DNS -- but we need a me general scheme. MIME is a candidate object framework, in part because it is the core of the two most widely used and deployed applications: the web and email. However, securing email has been problematic and the web is not that far in front.
オブジェクトセキュリティは輸送の如何にかかわらず個々のデータ・オブジェクトのための保護について言及します。 あるそのようなものが既にありますが(安全なDNS)、私たちがaを必要とする、私、一般的な体系。 MIMEは候補オブジェクトフレームワークです、それが一部最も広く使用されて、アプリケーションであると配布された2つのもののコアであるので: ウェブとメール。 しかしながら、メールを保証するのは問題が多いです、そして、ウェブがそんなに遠くに前部にありません。
Secure email is a critical need and has been for some time. Two attempts to standardize secure email protocols (PEM and MOSS) have failed to be accepted by the community, while a third protocol (PGP) has become a de facto standard around the world. A fourth protocol, an industry standard (S/MIME), has been gaining popularity. Both of these latter of entered the Internet standards process.
安全なメールは、決定的な必要性であり、しばらく決定的な必要性です。 共同体によって安全なメールプロトコル(PEMとモス)を標準化する2つの試みは受け入れられていません、3番目のプロトコル(PGP)は世界中のデファクトスタンダードになりましたが。 4番目のプロトコル(業界基準(S/MIME))は人気を獲得しています。 ともに、入られることのこれらの後者では、インターネット標準は処理されます。
Route security has recently become a critical need. The sophistication of the attackers is on the rise and the availability of attacking toolkits has increased the number of sophisticated attacks. This task is especially complex because the requirement for maximum performance conflicts with the goal of adding security, which usurps resources that would otherwise enhance the performance of the router.
ルートセキュリティは最近、決定的な必要性になりました。 攻撃者の洗練は上昇中です、そして、攻撃ツールキットの有用性は洗練された攻撃の数を増強しました。 最大性能のための要件がセキュリティを加えるという目標と衝突するので、このタスクは特に複雑です。セキュリティはそうでなければルータの性能を高めるリソースを僣称します。
Bellovin Informational [Page 6] RFC 2316 Report of the IAB April 1998
IAB1998年4月のBellovinの情報[6ページ]のRFC2316レポート
12. Security Considerations
12. セキュリティ問題
Security is not and cannot be a cookie cutter process. There is no magic pixie dust that can be sprinkled over a protocol to make it secure. Each protocol must be analyzed individually to determine what vulnerabilities exist, what risks they may lead to, what palliative measures can be taken, and what the residual risks are.
セキュリティは、なくて、クッキーの抜き型の過程であるはずがありません。 それを安全にするようにプロトコルの上で撒くことができるどんな魔法の魔法の粉もありません。 どんな脆弱性が存在しているか、そして、どんなリスクに通じるかもしれないか、そして、どんな緩和剤の対策を実施されることができるか、そして、残りのリスクが何であるかを決定するために個別に各プロトコルを分析しなければなりません。
13. Acknowledgments
13. 承認
This RFC is largely based on the minutes compiled by Thomas Narten, whose work in turn was partly based on notes by Erik Huizer, John Richardson, and Bob Blakley.
このRFCはエリックHuizer、ジョン・リチャードソン、およびボブ・ブレイクリーの仕事が順番に注意に一部基づいていたトーマスNartenによってコンパイルされた議事録に主に基づいています。
14. References
14. 参照
[RFC 1825] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 1825, August 1995.
[RFC1825] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC1825、1995年8月。
[RFC 2104] Krawcyzk, H., Bellare, M., and R. Canett, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2104] Krawcyzk、H.、Bellare、M.、およびR.Canett、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[ISAKMP drafts] Works in Progress.
[ISAKMP草稿] Progressの作品。
[RFC 2065] Eastlake, D., and C. Kaufman, "Domain Name System
Security Extensions", RFC 2065, January 1997.
[RFC2065] イーストレーク、D.とC.コーフマン、「ドメインネームシステムセキュリティ拡大」、RFC2065、1997年1月。
[RFC 1847] 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月。
[TLS draft] Dierks, T., and C. Allen, "The TLS Protocol Version
1.0", Work in Progress.
[TLS草稿] Dierks、T.とC.アレン、「TLSはバージョン1インチ、処理中の作業について議定書の中で述べます」。
[RFC 1421] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication
Procedures", RFC 1421, February 1993.
リン、[RFC1421]J.、「インターネット電子メールのためのプライバシー増進:」 部分I: 「メッセージ暗号化と認証手順」、RFC1421、2月1993日
[RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management", RFC 1422,
February 1993.
ケント、[RFC1422]S.、「インターネット電子メールのためのプライバシー増進:」 パートII: 「証明書ベースのKey Management」、RFC1422、1993年2月。
[RFC 1423] Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III: Algorithms, Modes, and Identifiers",
RFC 1423, February 1993.
Balenson、[RFC1423]D.、「インターネット電子メールのためのプライバシー増進:」 パートIII: 「アルゴリズム、モード、および識別子」、RFC1423、2月1993日
Bellovin Informational [Page 7] RFC 2316 Report of the IAB April 1998
IAB1998年4月のBellovinの情報[7ページ]のRFC2316レポート
[RFC 1424] Kaliski, B. "Privacy Enhancement for Internet
Electronic Mail: Part IV: Key Certification and Related
Services", RFC 1424, February 1993.
Kaliski、[RFC1424]B.、「インターネット電子メールのためのプライバシー増進:」 パートIV: 「主要な証明の、そして、関連のサービス」、RFC1424、1993年2月。
[RFC 1848] Crocker, S., Freed, N., Galvin, J. and S. Murphy, "MIME
Object Security Services", RFC 1848, October 1995.
クロッカー(S.)が解放した[RFC1848]、N.とガルビンとJ.とS.マーフィー、「MIME物のセキュリティー・サービス」、RFC1848、1995年10月。
Appendix A. Attendees
付録A.出席者
Ran Atkinson rja@inet.org
Fred Baker fred@cisco.com
Steve Bellovin bellovin@acm.org
Bob Blakley blakley@vnet.ibm.com
Matt Blaze mab@research.att.com
Brian Carpenter brian@hursley.ibm.com
Jim Ellis jte@cert.org
James Galvin galvin@commerce.net
Tim Howes howes@netscape.com
Erik Huizer Erik.Huizer@sec.nl
Charlie Kaufman charlie_kaufman@iris.com
Steve Kent kent@bbn.com
Paul Krumviede paul@mci.net
Marcus Leech mleech@nortel.ca
Perry Metzger perry@piermont.com
Keith Moore moore@cs.utk.edu
Robert Moskowitz rgm@htt-consult.com
John Myers jgm@CMU.EDU
Thomas Narten narten@raleigh.ibm.com
Radia Perlman radia.perlman@sun.com
John Richardson jwr@ibeam.jf.intel.com
Allyn Romanow allyn@mci.net
Jeff Schiller jis@mit.edu
Ted T'So tytso@mit.edu
アトキンソン rja@inet.org フレッドベイカー fred@cisco.com スティーブBellovin bellovin@acm.org ボブブレイクリー blakley@vnet.ibm.com マットBlaze mab@research.att.com ブライアンCarpenter brian@hursley.ibm.com ジムエリス jte@cert.org ジェームスガルビン galvin@commerce.net ティムハウズ howes@netscape.com エリックHuizer Erik.Huizer@sec.nl チャーリー・カウフマン charlie_kaufman@iris.com スティーブ・ケント羊飼いの杖@bbnを走らせました; comポールKrumviede paul@mci.net マーカスLeech mleech@nortel.ca ペリーメッツガー perry@piermont.com キースムーア moore@cs.utk.edu ロバートマスコウィッツ rgm@htt-consult.com ジョンマイアーズ jgm@CMU.EDU トーマスNarten narten@raleigh.ibm.com Radiaパールマン radia.perlman@sun.com ジョンリチャードソン jwr@ibeam.jf.intel.com アリンRomanow allyn@mci.net ジェフシラー jis@mit.edu テッドT'So tytso@mit.edu
Appendix B. Author Information
付録B.作者情報
Steven M. Bellovin AT&T Labs Research 180 Park Avenue Florham Park, NJ 07932 USA
研究180パーク・アベニューFlorhamが駐車するスティーブンM.Bellovin AT&T研究室、ニュージャージー07932米国
Phone: (973) 360-8656 EMail: bellovin@acm.org
以下に電話をしてください。 (973) 360-8656 メールしてください: bellovin@acm.org
Bellovin Informational [Page 8] RFC 2316 Report of the IAB April 1998
IAB1998年4月のBellovinの情報[8ページ]のRFC2316レポート
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Bellovin Informational [Page 9]
Bellovin情報です。[9ページ]
一覧
スポンサーリンク
