RFC1636 日本語訳
1636 Report of IAB Workshop on Security in the Internet Architecture -February 8-10, 1994. R. Braden, D. Clark, S. Crocker, C. Huitema. June 1994. (Format: TXT=130761 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Braden
Request for Comments: 1636 ISI
Category: Informational D. Clark
MIT Laboratory for Computer Science
S. Crocker
Trusted Information Systems, Inc.
C. Huitema
INRIA, IAB Chair
June 1994
コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 1636年のISIカテゴリ: 情報のD.クラーク・MITコンピュータサイエンス研究所S.クロッカーは情報システムInc.C.Huitema INRIAを信じました、IAB議長1994年6月
Report of IAB Workshop on
IABワークショップについて報告します。
Security in the Internet Architecture
インターネットアーキテクチャにおけるセキュリティ
February 8-10, 1994
1994年2月8日〜10日
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document is a report on an Internet architecture workshop, initiated by the IAB and held at USC Information Sciences Institute on February 8-10, 1994. This workshop generally focused on security issues in the Internet architecture.
このドキュメントは1994年2月8日〜10日にIABによって開始されて、USC情報Sciences Instituteで開かれたインターネットアーキテクチャワークショップに関するレポートです。 一般に、このワークショップはインターネットアーキテクチャの安全保障問題に焦点を合わせました。
This document should be regarded as a set of working notes containing ideas about security that were developed by Internet experts in a broad spectrum of areas, including routing, mobility, realtime service, and provider requirements, as well as security. It contains some significant diversity of opinions on some important issues. This memo is offered as one input in the process of developing viable security mechanisms and procedures for the Internet.
領域の広いスペクトルでインターネットの専門家によって開発されたセキュリティに関する考えを含んでいて、1セットの働きが注意するようにこのドキュメントは見なされるべきです、ルーティング、移動性、リアルタイムでサービス、プロバイダー要件、およびセキュリティを含んでいて。 それは何らかの重要ないくつかの切迫した課題に関する意見の多様性を含んでいます。 実行可能なセキュリティを開発することの途中に1つがメカニズムと手順をインターネットに入力したので、このメモを提供します。
Braden, Clark, Crocker & Huitema [Page 1] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[1ページ]RFC1636IABワークショップレポート1994年6月
Table of Contents
目次
1. INTRODUCTION .................................................. 2
2. OVERVIEW ...................................................... 4
2.1 Strategic and Political Issues ........................... 4
2.2 Security Issues .......................................... 4
2.3 DNS Names for Certificates ............................... 7
3. FIREWALL ARCHITECTURE ......................................... 9
3.1 Introduction ............................................. 9
3.2 Application-Layer Firewalls .............................. 11
3.3 IP-Layer Firewalls ....................................... 12
4. SECURE QOS FORWARDING ......................................... 21
4.1 The Requirement for Setup ................................ 21
4.2 Securing the Setup Process. .............................. 22
4.3 Validating an LLID ....................................... 24
4.4 Dynamics of Setup ........................................ 28
4.5 Receiver-Initiated Setup ................................. 30
4.6 Other Issues ............................................. 30
5. AN AUTHENTICATION SERVICE ..................................... 35
5.1 Names and Credentials .................................... 36
5.2 Identity-Based Authorization ............................. 37
5.3 Choosing Credentials ..................................... 38
6. OTHER ISSUES .................................................. 39
6.1 Privacy and Authentication of Multicast Groups ........... 39
6.2 Secure Plug-and-Play a Must .............................. 41
6.3 A Short-Term Confidentiality Mechanism ................... 42
7. CONCLUSIONS ................................................... 44
7.1 Suggested Short-Term Actions ............................. 44
7.2 Suggested Medium-Term Actions ............................ 46
7.3 Suggested Long-Term Actions .............................. 46
APPENDIX A -- Workshop Organization .............................. 48
Security Considerations .......................................... 52
Authors' Addresses ............................................... 52
1. 序論… 2 2. 概要… 4 2.1 戦略の、そして、政治上の問題… 4 2.2 セキュリティ問題… 4 証明書のための2.3のDNS名… 7 3. ファイアウォールアーキテクチャ… 9 3.1序論… 9 3.2 応用層ファイアウォール… 11 3.3 IP-層のファイアウォール… 12 4. QOSが推進であると機密保護してください… 21 4.1 セットアップのための要件… 21 4.2 セットアッププロセスを機密保護します。 .............................. 22 4.3 LLIDを有効にします… 24 4.4 セットアップの力学… 28 4.5 受信機で開始しているセットアップ… 30 4.6 他の問題… 30 5. 認証サービス… 35 5.1の名前と資格証明書… 36 5.2のアイデンティティベースの承認… 37 5.3 資格証明書を選びます… 38 6. 他の問題… 39 6.1 マルチキャストのプライバシーと認証は分類されます… 39 6.2 Plug and Playが絶対に必要なものであると機密保護してください… 41 6.3 短期的な秘密性メカニズム… 42 7. 結論… 44 7.1は短期的な動作を示しました… 44 7.2は中期動作を示しました… 46 7.3は長期の動作を示しました… 46 付録A--ワークショップ組織… 48 セキュリティ問題… 52人の作者のアドレス… 52
1. INTRODUCTION
1. 序論
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF), under the leadership of the Internet Engineering Steering Group (IESG) and area directorates.
インターネット・アーキテクチャ委員会(IAB)は長期の問題と戦略をインターネットと考えて、インターネットアーキテクチャのために将来の方向を示すように設計された時々のワークショップを開きます。 IABのこの長期計画機能はインターネットEngineering Steering Group(IESG)と領域の管理職のリーダーシップの下でインターネット・エンジニアリング・タスク・フォース(IETF)のワーキンググループによって実行された進行中の技術的努力を補足しています。
An IAB-initiated workshop on the role of security in the Internet Architecture was held on February 8-10, 1994 at the Information Sciences Institute of the University of Southern California, in
インターネットArchitectureにおけるセキュリティの役割に関するIABによって開始されたワークショップは1994年2月8日〜10日に中の南カリフォルニア大学の情報Sciences Instituteで開かれました。
Braden, Clark, Crocker & Huitema [Page 2] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[2ページ]RFC1636IABワークショップレポート1994年6月
Marina del Rey, California. This RFC reports the results of the workshop.
マリナデルレイ、カリフォルニア。 このRFCはワークショップの結果を報告します。
In addition to the IAB members, attendees at this meeting included the IESG Area Directors for the relevant areas (Internet, Transport, Security, and IPng) and a group of 15 other experts in the following areas: IPng, routing, mobility, realtime service, and security (see Appendix for a list of attendees). The IAB explicitly tried to balance the number of attendees from each area of expertise. Logistics limited the attendance to about 30, which unfortunately meant that many highly qualified experts were omitted from the invitation list.
IABメンバーに加えて、このミーティングにおける出席者は関連領域(インターネット、Transport、Security、およびIPng)へのIESG Areaディレクターと以下の領域の他の15人の専門家のグループを入れました: IPng、ルーティング、移動性、リアルタイムでサービス、およびセキュリティ(出席者のリストに関してAppendixを見ます)。 IABは専門的技術の各領域から出席者の数の明らかにバランスをとろうとしました。 ロジスティクスは出席をおよそ30に制限しました。(残念ながら、それは、多くの非常に適任の専門家が招待者名簿から省略されたことを意味しました)。
In summary, the objectives of this workshop were (1) to explore the interconnections between security and the rest of the Internet architecture, and (2) to develop recommendations for the Internet community on future directions with respect to security. These objectives arose from a conviction in the IAB that the two most important problem areas for the Internet architecture are scaling and security. While the scaling problems have led to a flood of activities on IPng, there has been less effort devoted to security.
概要では、このワークショップの目的は、セキュリティとインターネットアーキテクチャの残りの間のインタコネクトについて調査する(1)と、セキュリティに関して将来の方向のインターネットコミュニティのための推薦を開発する(2)でした。 これらの目的はインターネットアーキテクチャのための2つの最も重要な問題領域がスケーリングとセキュリティであるというIABの信念から起こりました。 スケーリング問題はIPngにおける活動の洪水に通じましたが、セキュリティにささげられたより少ない取り組みがありました。
Although some came to the workshop eager to discuss short-term security issues in the Internet, the workshop program was designed to focus more on long-term issues and broad principles. Thus, the meeting began with the following ground rule: valid topics of discussion should involve both security and at least one from the list: (a) routing (unicast and multicast), (b) mobility, and (c) realtime service. As a basis for initial discussion, the invitees met via email to generate a set of scenarios (see Appendix) satisfying this ground rule.
或るものはインターネットで政府短期証券問題について議論することを切望しているワークショップに来ましたが、ワークショッププログラムは、長期の問題と広い原則にさらに焦点を合わせるように設計されました。 したがって、ミーティングは以下の基本規則で始まりました: 議論の有効な話題はリストからのセキュリティと少なくとも1の両方を伴うべきです: (a) ルーティング(ユニキャストとマルチキャスト)、(b)の移動性、および(c)リアルタイムでサービス。 初期の議論の基礎として、招待参加者は、この基本規則を満たしながら1セットのシナリオ(Appendixを見る)を作るためにメールで会いました。
The 30 attendees were divided into three "breakout" groups, with each group including experts in all the areas. The meeting was then structured as plenary meetings alternating with parallel breakout group sessions (see the agenda in Appendix). On the third day, the groups produced text summarizing the results of their discussions. This memo is composed of that text, somewhat rearranged and edited into a single document.
各グループがすべての領域に専門家を含んでいて、30人の出席者が3つの「脱走」グループに分割されました。 そして、ミーティングは平行な脱走グループセッションで交互の全体会議として構造化されました(Appendixの議題を見てください)。 3日目に、グループは、彼らの議論の結果をまとめながら、テキストを製作しました。 このメモは、ただ一つのドキュメントにそのテキストで構成されて、いくらか再配列されて、編集されます。
The meeting process determined the character of this document. It should be regarded as a set of working notes produced by mostly- autonomous groups, containing some diversity of opinions as well as duplication of ideas. It is not the output of the "security community", but instead represents ideas about security developed by a broad spectrum of Internet experts. It is offered as a step in a process of developing viable security mechanisms and procedures for the Internet.
ミーティングプロセスはこのドキュメントのキャラクタを決定しました。 1セットの働く注意がほとんど自治のグループによって作り出されたので、それは見なされるべきです、何らかの考えの複製と同様に意見の多様性を含んでいて。 それは、「安全保障共同体」の出力ではありませんが、代わりにインターネットの専門家の広いスペクトルによって開発されたセキュリティに関して考えを表します。 インターネットのためにステップとして展開している実行可能なセキュリティー対策と手順のプロセスでそれを提供します。
Braden, Clark, Crocker & Huitema [Page 3] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[3ページ]RFC1636IABワークショップレポート1994年6月
2. OVERVIEW
2. 概要
2.1 Strategic and Political Issues
2.1 戦略の、そして、政治上の問題
Despite the workshop emphasis on architectural issues, there was
considerable discussion of the real-politik of security.
構造的な問題へのワークショップ強調にもかかわらず、セキュリティの本当のpolitikのかなりの議論がありました。
For a number of years, the IETF, with IAB backing, has worked on
developing PEM, which provides email security with a great deal of
functionality. A question was repeatedly raised at the workshop:
why has user acceptance of PEM been slow? A number of answers to
this question were suggested.
多年にわたり、IAB支援で、IETFは展開しているPEMに勤めました。(PEMは多くの機能性をメールセキュリティに提供します)。 疑問はワークショップで繰り返して引き起こされました: PEMのユーザ承認はなぜ遅いですか? この質問の多くの答えが示されました。
(a) High-quality implementations have been slow in coming.
(a)高品質な実装はなかなか浮かびませんでした。
(b) The use of a patented technology, the RSA algorithm, violates
social conventions of the Internet.
(b) 特許で保護された技術の使用(RSAアルゴリズム)はインターネットの社会慣習に違反します。
(c) Export restrictions dampen vendor enthusiasm.
(c) 輸出制限はベンダー熱意を湿らせます。
(d) PEM currently depends upon a certificate hierarchy for its
names, and certificates form a new and complex name space.
There is no organizational infrastructure in place for creat-
ing and managing this name space.
(d) PEMは現在名前のために証明書階層構造に依存します、そして、証明書は新しくて複雑な名前スペースを形成します。 どんな組織的なインフラストラクチャも、creat- ingとこの名前スペースを管理するために適所にありません。
(e) There is no directory infrastructure available for looking up
certificates.
(e) 証明書を調べるのに利用可能などんなディレクトリインフラストラクチャもありません。
The decision to use X.500 has been a complete failure, due to
the slow deployment of X.500 in the Internet. Because of UDP
packet size restrictions, it is not currently feasible to
store certificates in the DNS, even if the DNS were expanded
to hold records for individual email users.
インターネットでのX.500の遅い展開でX.500を使用するという決定は完全な失敗です。 UDPパケットサイズ制限のために、DNSの証明書を保存するのは現在可能ではありません、DNSが個々のメールユーザへの記録を保持するために広げられたとしても。
It seems probable that more than one, and possibly all, of these
reasons are at work to discourage PEM adoption.
これらの理由の1以上、およびことによるとすべてがPEM採用に水をさしているために仕事しているのはありえそうに思えます。
The baleful comment about eating: "Everything I enjoy is either
immoral, illegal, or fattening" seems to apply to the cryptography
technology that is required for Internet security.
食べるのに関する有害なコメント: 「私が楽しむすべてが、不道徳であって、不法であるか、または肥満のもとであること」はインターネットセキュリティに必要である暗号化技術に適用するように思えます。
2.2 Security Issues
2.2 セキュリティ問題
Almost everyone agrees that the Internet needs more and better
security. However, that may mean different things to different
people. Four top-level requirements for Internet security were
identified: end-to-end security, end-system security, secure QOS,
and secure network infrastructure.
ほとんどの人は、インターネットが、より多くて、より良いセキュリティを必要とするのに同意します。 しかしながら、それは異なった人々に別物を意味するかもしれません。 インターネットセキュリティのための4つのトップレベル要件が特定されました: 終わりから終わりへのセキュリティ(エンドシステムセキュリティ)はQOS、および安全なネットワークインフラを固定します。
Braden, Clark, Crocker & Huitema [Page 4] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[4ページ]RFC1636IABワークショップレポート1994年6月
A. End-to-End Security
A.終わりから終わりへのセキュリティ
One requirement is to support confidentiality, authentication
and integrity for end-to-end communications. These security
services are best provided on an end-to-end basis, in order
to minimize the number of network components that users must
trust. Here the "end" may be the end system itself, or a
proxy (e.g., a firewall) acting on behalf of an end system.
1つの要件はエンド・ツー・エンド通信のために秘密性、認証、および保全をサポートすることです。 終わりから終わりへのベースでこれらのセキュリティー・サービスを最もよく提供します、ユーザが信じなければならないネットワーク要素の数を最小にするために。 ここで、「終わり」は、エンドシステム自体、またはエンドシステムを代表して行動しているプロキシであるかもしれません(例えば、ファイアウォール)。
For point-to-point applications, the workshop felt that
existing security techniques are well suited to support
confidentiality, authentication and integrity services
efficiently. These existing techniques include symmetric
encryption applied on an end-to-end basis, message digest
functions, and key management algorithms. Current work in
these areas in the IETF include the PEM and Common
Authentication Technologies working groups.
二地点間アプリケーションに関しては、ワークショップは、既存のセキュリティのテクニックがサポート秘密性、認証、および保全サービスによく効率的に合っていると感じました。 これらの既存のテクニックは終わりから終わりへのベースで適用された左右対称の暗号化を含んでいます、メッセージダイジェスト関数、そして、アルゴリズムCurrentがこれらの領域で扱うかぎ管理がIETFにPEMとCommon Authentication Technologiesワーキンググループを含んでいます。
The group favored a strategic direction for coping with
export restrictions: separate authentication from privacy
(i.e., confidentiality). This will allow work to proceed on
authentication for the Internet, despite government
restrictions on export of privacy technology. Conversely, it
will allow easy deployment of privacy without authentication,
where this is appropriate.
グループは輸出制限に対処するための戦略の方向を支持しました: プライバシー(すなわち、秘密性)と認証を切り離してください。 これで、政府制限にもかかわらず、仕事はプライバシー技術の輸出のときにインターネットのための認証のときに続くでしょう。 逆に、これが適切であるところでそれは認証なしでプライバシーの簡単な展開を許すでしょう。
The workshop explored the implications of multicasting for
end-to-end security. Some of the unicast security techniques
can be applied directly to multicast applications, while
others must be modified. Section 6.2 contains the results of
these discussions; in summary, the conclusions were:
ワークショップは終わりから終わりへのセキュリティのためにマルチキャスティングの含意を探りました。 ユニキャストセキュリティのテクニックのいくつかを直接マルチキャストアプリケーションに適用できますが、他のものを変更しなければなりません。 セクション6.2はこれらの議論の結果を含みます。 概要では、結論は以下の通りでした。
a) Existing technology is adequate to support
confidentiality, authentication, and integrity at the
level of an entire multicast group. Supporting
authentication and integrity at the level of an
individual multicast source is performance-limited and
will require technology advances.
a) 既存の技術は、全体のマルチキャストグループのレベルで秘密性、認証、および保全をサポートするために適切です。 個々のマルチキャストソースのレベルで認証と保全をサポートするのは、性能によって制限されていて、技術進歩を必要とするでしょう。
b) End-to-end controls should be based on end system or
user identifiers, not low level identifiers or locator
information. This requirement should spawn engineering
work which consists of applying known key distribution
b) 終わりからエンドへのコントロールは少ない平らな識別子かロケータ情報ではなく、エンドシステムかユーザ識別子に基づくべきです。 この要件は知られている主要な分配を適用するのから成る技術系を生じさせるべきです。
Braden, Clark, Crocker & Huitema [Page 5] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[5ページ]RFC1636IABワークショップレポート1994年6月
and cryptographic techniques.
そして、暗号のテクニック。
B. End-System Security
B.エンドシステムセキュリティ
Every host has its own security defenses, but the strength of
these defenses depends upon the care that is taken in
administering them. Careful host security administration
means plugging security holes in the kernel and applications
as well as enforcing discipline on users to set good (hard to
crack) passwords.
すべてのホストには、それ自身のセキュリティディフェンスがありますが、これらのディフェンスの強さはそれらを管理しながら中に入れられる注意に依存します。 慎重なホストセキュリティ管理は、カーネルとアプリケーションにセキュリティーホールのプラグを差し込んで、良い(割りにくい)パスワードを設定するためにユーザの上で綱紀を粛正することを意味します。
Good security administration is labor-intensive, and
therefore organizations often find it difficult to maintain
the security of a large number of internal machines. To
protect their machines from outside subversion, organizations
often erect an outer security wall or "perimeter". Machines
inside the perimeter communicate with the rest of the
Internet only through a small set of carefully managed
machines called "firewalls". Firewalls may operate at the
application layer, in which case they are application relays,
or at the IP layer, in which case they are firewall routers.
優れた警備体制管理は労働集約的です、そして、したがって、組織によって、しばしば多くの内部のマシンのセキュリティを維持するのが難しいのがわかります。 転覆の外からそれらのマシンを保護するために、組織はしばしば外側のセキュリティ壁か「周辺」を建設します。 周辺の中のマシンは「ファイアウォール」と呼ばれる小さいセットの慎重に管理されたマシンだけを通したインターネットの残りとコミュニケートします。 ファイアウォールは応用層で作動するかもしれませんか、その場合、それらがアプリケーションリレーであるかその場合、それらがIP層では、ファイアウォールルータです。
The workshop spent considerable time on the architecture of
firewall routers. The results are contained in Section 3.
ワークショップはファイアウォールルータのアーキテクチャで、かなりの時間を過ごしました。 結果はセクション3に含まれています。
C. Secure QOS
C.の安全なQOS
The Internet is being extended to provide quality-of-service
capabilities; this is the topic called "realtime service" in
the workshop. These extensions raise a new set of security
issues for the architecture, to assure that users are not
allowed to attach to resources they are not authorized to
use, both to prevent theft of resources and to prevent denial
of service due to unauthorized traffic. The resources to be
protected include link shares, service classes or queues,
multicast trees, and so on. These resources are used as
virtual channels within the network, where each virtual
channel is intended to be used by a particular subset or
"class" of packets.
インターネットはサービスの質能力を提供するために広げられています。 これはワークショップにおける「リアルタイムでサービス」と呼ばれる話題です。 それらは、これらの拡大がアーキテクチャのために新しい安全保障問題を提起して、ユーザがリソースに付くことができないことを保証するために、ともにリソースの窃盗を防いで、権限のないトラフィックによるサービスの否定を防ぐのが使用に認可されません。 保護されるべきリソースはリンクシェアかサービスのクラスか待ち行列、マルチキャスト木などを含んでいます。 これらのリソースは事実上のチャンネルとしてネットワークの中で使用されます。そこでは、それぞれの事実上のチャンネルが特定の部分集合か「クラス」のパケットによって使用されるつもりです。
Secure QOS, i.e., protection against improper virtual channel
usage, is a form of access control mechanism. In general it
will be based on some form of state establishment (setup)
that defines authorized "classes". This setup may be done
via management configuration (typically in advance and for
aggregates of users), or it may be done dynamically via
control information in packets or special messages (typically
at the time of use by the source or receiver(s) of the
安全なQOS(すなわち、不適当な仮想のチャンネル用法に対する保護)はアクセス管理機構のフォームです。 一般に、それは認可された「クラス」を定義する何らかの形式の州の設立(セットアップ)に基づくでしょう。 管理構成(通常早いのとユーザの集合のための)でこのセットアップをするかもしれないか、またはパケットか特別教書における制御情報でダイナミックにそれをするかもしれない、(ソースか受信機による使用通常時点
Braden, Clark, Crocker & Huitema [Page 6] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[6ページ]RFC1636IABワークショップレポート1994年6月
flow/data). In addition to state establishment, some form of
authentication will be needed to assure that successive
packets belong to the established class. The general case to
be solved is the multicast group, since in general the
multicast problem includes the two-party case as a subset.
The workshop developed an approach to the secure QOS problem,
which appears in Section 4 below.
流れ/データ) 州の設立に加えて、何らかの形式の認証が、連続したパケットが設立されたクラスのものを保証するのに必要でしょう。 解決するべき一般的なケースはマルチキャストグループです、マルチキャスト問題が部分集合として一般に2パーティーのケースを含んでいるので。 ワークショップは安全なQOS問題へのアプローチを開発しました。(問題はセクション4に以下に現れます)。
D. Secure Network Infrastructure
D.の安全なネットワークインフラ
Network operation depends upon the management and control
protocols used to configure and operate the network
infrastructure, including routers and DNS servers. An attack
on the network infrastructure may cause denial-of-service
from the user viewpoint, but from the network operators'
viewpoint, security from attack requires authentication and
integrity for network control and management messages.
ネットワーク操作をネットワークインフラを構成して、操作するのに使用される管理と制御プロトコルに頼っています、ルータとDNSサーバを含んでいて。 ネットワークインフラに対する攻撃はユーザ観点からサービスの否定を引き起こすかもしれませんが、ネットワーク・オペレータの観点から、攻撃からのセキュリティはネットワーク制御と管理メッセージのために認証と保全を必要とします。
Securing the routing protocols seems to be a straightforward
engineering task. The workshop concluded the following.
ルーティングがプロトコルであると機密保護するのは簡単な工学タスクであるように思えます。 ワークショップは以下を結論づけました。
a) All routing information exchanges should be
authenticated between neighboring routers.
a) すべてのルーティング情報交換が隣接しているルータの間で認証されるべきです。
b) The sources of all route information should be
authenticated.
b) すべての経由地案内の源は認証されるべきです。
c) Although authenticating the authority of an injector of
route information is feasible, authentication of
operations on that routing information (e.g.,
aggregation) requires further consideration.
c) 経由地案内のインジェクタの権威を認証するのは可能ですが、そのルーティング情報(例えば、集合)における操作の認証はさらなる考慮を必要とします。
Securing router management protocols (e.g., SNMP, Telnet,
TFTP) is urgent, because of the currently active threats.
Fortunately, the design task should be a straightforward
application of existing authentication mechanisms.
ルータ管理プロトコルが(例えば、SNMP、Telnet、TFTP)であると機密保護するのは現在活発な脅威のために緊急です。 幸い、デザインタスクは既存の認証機構の簡単な応用であるべきです。
Securing DNS is an important issue, but it did not receive
much attention at the workshop.
DNSを固定するのは、切迫した課題ですが、それはワークショップで相当な配慮を受けませんでした。
2.3 DNS Names for Certificates
2.3 証明書のためのDNS名
As noted in Section 2.1, work on PEM has assumed the use of X.509
distinguished names as the basis for issuing certificates, with
public-key encryption. The most controversial discussion at the
workshop concerned the possibility of using DNS (i.e., domain)
names instead of X.509 distinguished names as (at least) an
interim basis for Internet security.
セクション2.1に述べられるように、PEMへの作業は証明書を発行する基礎としてX.509分類名の使用を仮定しました、公開鍵暗号化で。 ワークショップでの最も論議を呼んだ議論は、(すなわち、ドメイン)がX.509の代わりに同じくらい(少なくとも)インターネットセキュリティの当座の基礎と分類名を命名するのがDNSを使用する可能性に関係がありました。
Braden, Clark, Crocker & Huitema [Page 7] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[7ページ]RFC1636IABワークショップレポート1994年6月
The argument in favor of DNS names is that they are simple and
well understood in the Internet world. It is easy for a computer
operating in the Internet to be identified this way, and users who
receive email on such machines already have DNS mailbox names. In
contrast, introducing X.509 distinguished names for security will
add a new layer of names. Most importantly, there is an existing
administrative model for assigning DNS names. There is no
administrative infrastructure for assigning X.509 distinguished
names, and generating them may be too complex for early
acceptance. The advocates of DNS names for certificates hope that
using DNS names would encourage the widespread use of security in
the Internet. It is expected that DNS names can be replaced later
by a more capable naming mechanism such as X.509-based
certificates.
DNS名を支持して議論はそれらが簡単であってインターネットの世界でよく理解されているということです。 インターネットで動作するコンピュータに、このように特定されるのが簡単であり、そのようなマシンに関するメールを受け取るユーザが既にDNSメールボックス名を持ちます。 対照的に、セキュリティのためにX.509分類名を導入すると、新しい層の名前は加えるでしょう。 最も重要に、名前をDNSに割り当てるための既存の管理モデルがいます。 分類名をX.509に割り当てるためのどんな管理インフラストラクチャもありません、そして、早めの承認には、それらを生成するのは複雑過ぎるかもしれません。 証明書のためのDNS名の支持者は、DNS名を使用するとインターネットのセキュリティの普及使用が奨励することを望んでいます。 後でDNS名をX.509ベースの証明書などの、よりできる命名メカニズムに取り替えることができると予想されます。
The basic argument against DNS names as a basis for security is
that they are too "weak". Their use may lead to confusion in many
instances, and this confusion can only grow as more organizations
and individuals attach to the Internet. Some commercial email
systems employ numeric mailbox names, and in many organizations
there are uncertainties such as whether "bumber@foo.edu" belongs
to Bill Umber or Tom Bumber. While it is feasible to make DNS
names more descriptive, there is a concern that the existing
infrastructure, with millions of short, non-descriptive names,
will be an impediment to adoption of more descriptive names.
セキュリティの基礎としてのDNS名に対する基本的な議論はそれらが「弱過ぎる」ということです。 彼らの使用は多くのインスタンスにおける混乱につながるかもしれません、そして、より多くの組織と個人がインターネットに付くとき、この混乱は成長できるだけです。 いくつかの市販のメールシステムが数値メールボックス名を使います、そして、多くの組織には、" bumber@foo.edu "がビルUmberかトムBumberに属すかどうかなどの不明確なことがあります。 DNS名をより描写的にするのが可能ですが、既存のインフラストラクチャが何百万もの短くて、不分明な名前をもって、より描写的である名前の採用の障害になるという関心があります。
It was noted that the question of what name space to use for
certificates is independent of the problem of building an
infrastructure for retrieving those names. Because of UDP packet
size restrictions, it would not be feasible to store certificates
in the DNS without significant changes, even if the DNS were
expanded to hold records for individual email users.
証明書にどんな名前スペースを使用したらよいかに関する質問がそれらの名前を検索するために基礎構造を築くという問題から独自であることに注意されました。 UDPパケットサイズ制限のために、DNSの著しい変化のない証明書を保存するのは可能でないでしょう、DNSが個々のメールユーザへの記録を保持するために広げられたとしても。
The group was unable to reach a consensus on the issue of using
DNS names for security; further discussion in the Internet
community is needed.
DNSを使用する問題に関するコンセンサスがセキュリティにちなんで命名する範囲にグループであることができませんでした。 インターネットコミュニティのさらなる議論が必要です。
Braden, Clark, Crocker & Huitema [Page 8] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[8ページ]RFC1636IABワークショップレポート1994年6月
3. FIREWALL ARCHITECTURE
3. ファイアウォールアーキテクチャ
3.1 Introduction
3.1 序論
A firewall may be used to isolate a specific connected segment of
Internet topology. When such a segment has multiple links to the
rest of the Internet, coordinated firewall machines are required
on all the links.
ファイアウォールは、インターネットトポロジーの特定の関連セグメントを隔離するのに使用されるかもしれません。 そのようなセグメントがインターネットの残りに複数のリンクを持っていると、連携ファイアウォールマシンがすべてのリンクの上に必要です。
Firewalls may be implemented at different layers in the protocol
stack. They are most commonly implemented at the application
layer by forwarding (application) gateways, or at the IP
(Internet) layer by filtering routers. Section 3.2 discusses
application gateways. Section 3.3 concerns Internet-layer
firewalls, which filter IP datagrams entering or leaving a
security perimeter.
ファイアウォールはプロトコル・スタックの異なった層で実装されるかもしれません。 それらは推進(アプリケーション)ゲートウェイのそばの応用層において、または、ルータをフィルターにかけるのによるIP(インターネット)層で最も一般的に実装されます。 セクション3.2はアプリケーションゲートウェイについて論じます。 セクション3.3はインターネット層のファイアウォールに関係があります。(ファイアウォールはセキュリティ周辺を入るか、または出るIPデータグラムをフィルターにかけます)。
The general architectural model for a firewall should separate
policy, i.e., determining whether or not the requester of a
service should be granted access to that service, from control,
i.e., limiting access to resources to those who have been granted
access.
すなわち、アクセスをアクセサリーが与えられたそれらへのリソースに制限しながらすなわち、そのサービスへのアクセスがコントロールからサービスのリクエスタに承諾されるべきであるかどうか決定しながら、ファイアウォールへの一般的な建築モデルは方針を切り離すべきです。
3.1.1 The Use for Firewalls
3.1.1 ファイアウォールの使用
Firewalls are a very emotional topic in the Internet community.
Some community members feel the firewall concept is very
powerful because firewalls aggregate security functions in a
single place, simplifying management, installation and
configuration. Others feel that firewalls are damaging for the
same reason: they provide "a hard, crunchy outside with a soft
chewy center", i.e., firewalls foster a false sense of
security, leading to lax security within the firewall
perimeter. They observe that much of the "computer crime" in
corporate environments is perpetrated by insiders, immune to
the perimeter defense strategy. Firewall advocates counter
that firewalls are important as an additional safeguard; they
should not be regarded as a substitute for careful security
management within the perimeter. Firewall detractors are also
concerned about the difficulty of using firewalls, requiring
multiple logins and other out-of-band mechanisms, and their
interference with the usability and vitality of the Internet.
ファイアウォールはインターネットコミュニティの非常に感情的な話題です。 何人かの共同体のメンバーが、ファイアウォールが単一の場所でセキュリティ機能に集められるのでファイアウォール概念が非常に強力であると感じます、管理、インストール、および構成を簡素化して。 他のものは、ファイアウォールが同じ理由からダメージが大きいと感じます: 彼らは「柔らかい噛みにくいセンターがある困難で、ボリボリ音を立てている外部」を提供します、すなわち、ファイアウォールは大丈夫だという誤った感覚を伸ばしています、ファイアウォール周辺の中でゆるい警備に通じて。 彼らは、企業社会における、「コンピュータ犯罪」の多くがインサイダーによって犯されるのを観測します、周辺防衛戦略に、免疫があります。 ファイアウォール支持者は、ファイアウォールが追加安全装置として重要であると反対します。 それらを周辺の中の慎重なセキュリティ管理の代用品と見なすべきではありません。 また、ファイアウォール中傷者はファイアウォールを使用するという困難に関して心配しています、複数のログイン、他のバンドで出ているメカニズム、およびインターネットのユーザビリティとバイタリティーの彼らの干渉を必要として。
However, firewalls are a fact of life in the Internet today.
They have been constructed for pragmatic reasons by
organizations interested in a higher level of security than may
be possible without them. This section will try to outline
some of the advantages and disadvantages of firewalls, and some
しかしながら、今日、ファイアウォールはインターネットの現実です。 それらは実践的な理由でそれらなしで可能であるかもしれないより高いレベルのセキュリティに興味を持っている組織によって組み立てられました。 このセクションは利点のいくつか、ファイアウォールの難点、およびいくつかについて概説しようとするでしょう。
Braden, Clark, Crocker & Huitema [Page 9] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[9ページ]RFC1636IABワークショップレポート1994年6月
instances where they are useful.
それらが役に立つインスタンス。
Consider a large organization of thousands of hosts. If every
host is allowed to communicate directly with the outside world,
attackers will attempt to penetrate the organization by finding
the weakest host in the organization, breaching its defenses,
and then using the resources of that host to extend the
penetration further within the organization. In some sense,
firewalls are not so much a solution to a security problem as
they are a reaction to a more basic software
engineering/administration problem: configuring a large number
of host systems for good security. If this more basic problem
could be solved, firewalls would generally be unnecessary.
何千人ものホストの大きな組織を考えてください。 すべてのホストが外の世界と共に直接伝達できると、攻撃者は、組織の最も弱いホストを見つけることによって組織を理解するのを試みるでしょう、組織の中で、より遠くに侵入を広げるのにディフェンスを破って、次に、そのホストのリソースを使用して。 何らかの意味で、ファイアウォールは警備上の問題へのそれらが、より多くの基本ソフトウェア工学/管理問題への反応であるのと同じくらい多くの解決ではありません: 優れた警備体制の多くのホストシステムを構成します。 このより基本的な問題を解決できるなら、一般に、ファイアウォールは不要でしょうに。
It is interesting to consider the effect that implementing a
firewall has upon various individuals in the organization.
Consider first the effect upon an organization's most secure
host. This host basically receives little or no extra
protection, because its own perimeter defenses are as strong or
stronger than the firewall. In addition, the firewall will
probably reduce the connectivity available to this host, as
well as the reliability of the communications path to the
outside world, resulting in inconvenience to the user(s) of
this host. From this (most secure) user's point of view, the
firewall is a loss.
ファイアウォールを実装すると様々な個人に組織で持たれている効果を考えるのはおもしろいです。 1番目が組織の最も安全なホストへの効果であると考えてください。 このホストは基本的にまず特別な防護措置を受けません、それ自身の規定の防衛線内での防衛が同じくらい強いか、またはファイアウォールより強いので。 さらに、ファイアウォールはたぶんこのホストにとって、利用可能な接続性を減らすでしょう、外の世界へのコミュニケーション経路の信頼性と同様に、このホストのユーザへの不便をもたらして。 この(最も安全)のユーザの観点から、ファイアウォールは損失です。
On the other hand, a host with poor security can "hide" behind
the firewall. In exchange for a more limited ability to
communicate with the outside world, this host can benefit from
the higher level of security provided by the firewall, which is
assumed to be based upon the best security available in the
entire organization. If this host only wants to communicate
with other hosts inside the organization, the outside
communications limitations imposed by the firewall may not even
be noticed. From this host's viewpoint, better security has
been gained at little or no cost.
他方では、手薄な警備体制をもっているホストはファイアウォールの後ろに「隠れることができます」。 外の世界で交信するより限られた能力と引き換えに、このホストは全体の組織で利用可能な最も良いセキュリティに基づくと思われるファイアウォールによって提供されたより高いレベルのセキュリティの利益を得ることができます。 このホストが組織の中で他のホストとコミュニケートするだけでありたいなら、ファイアウォールによって課された外のコミュニケーション制限は気付かれてさえいないかもしれません。 このホストの観点から、より良いセキュリティは費用でまず獲得されていません。
Finally, consider the point of view of the organization as a
whole. A firewall allows the extension of the best security in
the organization across the whole organization. This is a
benefit (except in the case where all host perimeter defenses
in the organization are equal). Centralized access control
also becomes possible, which may be either a benefit or a cost,
depending upon the organization. The "secure" hosts within the
organization may perceive a loss, while the "unsecure" hosts
receive a benefit. The cost/benefit ratio to the organization
as a whole thus depends upon the relative numbers of "secure"
and "unsecure" hosts in the organization.
最終的に、全体で組織の観点を考えてください。 ファイアウォールは全体の組織の向こう側に組織における、最も良いセキュリティの拡大を許します。 これは利益(ケースを除いた中組織におけるすべてのホスト規定の防衛線内での防衛が等しい)です。 また、集結されたアクセスコントロールは可能になります(組織によって、利益か費用のどちらかであるかもしれません)。 組織の中の「安全な」ホストは損失を知覚するかもしれませんが、"unsecure"ホストは利益を受け取ります。 その結果、組織との費用/利益比は全体で組織における、「安全」と"unsecure"ホストの相対数に依存します。
Braden, Clark, Crocker & Huitema [Page 10] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[10ページ]RFC1636IABワークショップレポート1994年6月
Consider some cases where firewalls do not make sense. An
individual can be thought of as an organization of one host.
The security of all the host(s) is thus (trivially) identical,
and by definition the best available to the organization. In
this case the choice of firewall is simple. Does this
individual wish to communicate with the outside or not? If
not, then the "perfect" firewall is implemented (by complete
disconnection). If yes, then the host perimeter will be the
same as the firewall perimeter, so a firewall becomes
unnecessary.
ファイアウォールが理解できないいくつかのケースを考えてください。 1人のホストの組織として個人を思うことができます。 すべてのホストのセキュリティはその結果、(些細なことに)同じで、定義上最も良いこと組織に利用可能な。 この場合、ファイアウォールの選択は簡単です。 この個人は外部で交信したがっていますか? そうでなければ、そして、「完全な」ファイアウォールは実装されます(完全な断線で)。 ホスト周辺がはいならファイアウォール周辺と同じになるので、ファイアウォールは不要になります。
Another interesting case is an organization that consists of
individuals with few shared interests. This might be the case
of a service provider that sells public access to the network.
An unrelated community of subscribers should probably be
considered as individuals, rather than an organization.
Firewalls for the whole organization may make little sense in
this case.
別のおもしろいケースはわずかな共有された関心をもっている個人から成る組織です。 これはパブリックアクセスをネットワークに販売するサービスプロバイダーのそうであるかもしれません。 加入者の関係ない共同体は組織よりむしろ個人であるとたぶんみなされるべきです。 全体の組織のためのファイアウォールはこの場合少ししか理解できないかもしれません。
To summarize, the benefit of a firewall depends upon the nature
of the organization it protects. A firewall can be used to
extend the best available protection within the organization
across the entire organization, and thus be of benefit to large
organizations with large numbers of poorly administered hosts.
A firewall may produce little or no perceived benefit, however,
to the individuals within an organization who have strong host
perimeters already.
まとめるためによる、ファイアウォールの利益はそれが保護する組織の本質によります。 全体の組織の向こう側に組織の中で最も良い利用可能な保護を広げていて、その結果、多くの不十分に管理されたホストにとって大きな組織に有益になるのにファイアウォールを使用できます。 しかしながら、ファイアウォールは既に強いホスト周辺を持っている組織の中でまず知覚されなかった利益を個人に生産するかもしれません。
3.2 Application-Layer Firewalls
3.2 応用層ファイアウォール
An application-layer firewall can be represented by the following
diagram.
以下のダイヤグラムで応用層ファイアウォールを表すことができます。
C <---> F <---> S
C<。--->F<。--->S
Here the requesting client C opens its transport connection to the
firewall F rather than directly to the desired server S. One
mechanism for redirecting C's request to F's IP address rather
than S's could be based on the DNS. When C attempts to resolve
S's name, its DNS lookup would return a "service redirection"
record (analogous to an MX record) for S. The service redirection
record would return the IP address of F.
ここで、要求しているクライアントCは直接SのよりむしろFのIPアドレスに基づくことができたCのものが、要求する向け直す必要なサーバS.OneメカニズムにというよりむしろファイアウォールFとのDNSにおける輸送接続を開きます。 Cが、Sの名前を決議するのを試みるとき、DNSルックアップはサービスリダイレクション記録がFのIPアドレスを返すS.のために「サービスリダイレクション」記録を返すでしょう(MX記録に類似の)。
C enters some authentication conversation to identify itself to F,
and specifies its intention to request a specific service from S.
F then decides if C is authorized to invoke this service. If C is
authorized, F initiates a transport layer connection to S and
begins the operation, passing requests and responses between C and
Cは、それ自体をFまで特定するために何らかの認証の会話に入って、Cがこのサービスを呼び出すのが認可されるなら、次に、S.Fからの特定のサービスが決めるよう要求するという意志を指定します。 そしてCが認可されているなら、Fは、トランスポート層接続をSに開始して、操業を開始します、要求と間の応答にCを通過して。
Braden, Clark, Crocker & Huitema [Page 11] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[11ページ]RFC1636IABワークショップレポート1994年6月
S.
S。
A major advantage of this scenario over an IP-layer firewall is
that raw IP datagrams are never passed through the firewall.
Because the firewall operates at the application layer, it has the
opportunity to handle and verify all data passing through it, and
it may be more secure against illicit rendezvous attacks (see
below).
IP-層のファイアウォールの上のこのシナリオの主要な利点は生のIPデータグラムがファイアウォールを決して通り抜けないということです。 ファイアウォールが応用層で作動するので、それには、それを通り抜けるすべてのデータについて扱って、確かめる機会があります、そして、不法なランデブー攻撃に対して、より安全であるかもしれません(以下を見てください)。
Application layer firewalls also have important disadvantages.
For full benefit, an application level firewall must be coded
specifically for each application. This severely limits the
deployment of new applications. The firewall also represents a
new point of failure; if it ceases to be reachable, the
application fails. Application layer firewalls also may affect
performance more than IP-layer firewalls, depending on specific
mechanisms in use.
また、応用層ファイアウォールには、重要な損失があります。 特に各アプリケーションのために完全給付、アプリケーションレベルファイアウォールをコード化しなければならないので。 これは厳しく新しいアプリケーションの展開を制限します。 また、ファイアウォールは失敗の新しいポイントを表します。 届くのをやめるなら、アプリケーションは失敗します。 使用中の特定のメカニズムによって、応用層ファイアウォールもIP-層のファイアウォールより性能に影響するかもしれません。
3.3 IP-Layer Firewalls
3.3 IP-層のファイアウォール
Our model of an IP-layer firewall is a multi-ported IP router that
applies a set of rules to each incoming IP datagram, to decide
whether it will be forwarded. It is said to "filter" IP
datagrams, based on information available in the packet headers.
私たちのIP-層のファイアウォールのモデルはそれが進められるかどうか決めるためにそれぞれの入って来るIPデータグラムに1セットの規則を適用するマルチ移植されたIPルータです。 それはパケットのヘッダーで利用可能な情報に基づいてIPデータグラムを「フィルターにかける」と言われています。
A firewall router generally has a set of filtering rules, each of
which specifies a "packet profile" and an "action". The packet
profile specifies values for particular header fields, e.g.,
source and destination IP address, protocol number, and other
suitable source and destination identifying information (for
instance, port numbers). The set of possible information that may
be used to match packets is called an "association". The exact
nature of an association is an open issue.
一般に、ファイアウォールルータには、それのそれぞれが「パケットプロフィール」と「動作」を指定する規則をフィルターにかけるセットがあります。 パケットプロフィールは特定のヘッダーフィールド、例えば、ソース、送付先IPアドレス、プロトコル番号、他の適当なソース、および目的地身元が分かる情報に値を指定します(例えば、数を移植してください)。 パケットを合わせるのに使用されるかもしれない可能な情報のセットは「協会」と呼ばれます。 協会の正確な自然は未解決の問題です。
The high-speed datagram forwarding path in the firewall processes
every arriving packet against all the packet profiles of all
active rules, and when a profile matches, it applies the
corresponding action. Typical actions may include forwarding,
dropping, sending a failure response, or logging for exception
tracking. There may be a default rule for use when no other rule
matches, which would probably specify a drop action.
ファイアウォールの高速データグラム推進経路はすべてのアクティブな規則のすべてのパケットプロフィールに対してあらゆる到着パケットを処理します、そして、プロフィールが合っていると、それは対応する動作を適用します。 例外追跡のために失敗応答、または伐採を送って、低下して、典型的な動きは、進めるのを含むかもしれません。 他の規則(たぶん低下動作を指定する)が全く合っていないとき、使用のための省略時の解釈があるかもしれません。
In addition to the packet profile, some firewalls may also use
some cryptographic information to authenticate the packet, as
described below in section 3.3.2.
また、パケットプロフィールに加えて、いくつかのファイアウォールがパケットを認証するのに何らかの暗号の情報を使用するかもしれません、以下でセクション3.3.2で説明されるように。
Braden, Clark, Crocker & Huitema [Page 12] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[12ページ]RFC1636IABワークショップレポート1994年6月
3.3.1 Policy Control Level
3.3.1 方針制御レベル
This section presents a model for the control of a firewall
router, with some examples of specific mechanisms that might be
used.
このセクションはファイアウォールルータのコントロールのためにモデルを提示します、使用されるかもしれない特定のメカニズムに関するいくつかの例で。
1. A client C attempts to access a service S. (Client here
can mean either a person or a process - that also is an
issue to be resolved.)
1. クライアントCは、サービスSにアクセスするのを試みます。(ここのクライアントは、人かプロセスまた、(問題である)のどちらかが決議されるのを意図できます。)
2. The initiation of access to that service may result in an
attempt to cross one or more boundaries of protection via
firewall router(s).
2. そのサービスへのアクセスの開始はファイアウォールルータで保護の1つ以上の境界に交差する試みをもたらすかもしれません。
3. The policy control level sets filters in the firewall
router(s), to permit or deny that attempt.
3. 方針制御レベルは、その試みを可能にするか、または否定するためにファイアウォールルータにフィルタをはめ込みます。
The policy control level consists of two distinct functions,
authentication and authorization. Authentication is the
function of verifying the claimed identity of a user. The
authentication function should be distributed across the
Internet, so that a user in one organization can be
authenticated to another organization. Once a user is
authenticated, it is then the job of the authorization service
local to the resource being requested to determine if that user
is authorized to access that resource. If authorization is
granted, the filter in the firewall can be updated to permit
that access.
方針制御レベルは2つの別個の機能、認証、および承認から成ります。 認証はユーザの要求されたアイデンティティについて確かめる機能です。 認証機能はインターネットの向こう側に分配されるべきです、1つの組織のユーザを別の組織に認証できるように。 かつて、ユーザは認証されます、そして、それがそのユーザがそのリソースにアクセスするのに権限を与えられるかどうか決定するよう要求されているリソースへの地方の承認サービスの仕事です。 承認を与えるなら、そのアクセサリーを可能にするためにファイアウォールのフィルタをアップデートできます。
As an aid to understanding the issues, we introduce a
particular detailed mechanism. We emphasize that this
mechanism is intended only as an illustrative example; actual
engineering of the mechanism will no doubt lead to many
changes. Our mechanism is illustrated by the following sketch.
Here a user wishes to connect from a computer C behind firewall
F1, to a server S behind firewall F2. A1 is a particular
authentication server and Z1 is a particular authorization
server.
問題を理解していることへの援助として、私たちは特定の詳細なメカニズムを紹介します。 私たちは、このメカニズムが単に説明に役立つ実例として意図すると強調します。 メカニズムの実際の工学は間違いなく多くの変化に通じるでしょう。 私たちのメカニズムは以下のスケッチで例証されます。 ここで、ユーザはファイアウォールF1のC後ろのコンピュータからファイアウォールF2の後ろのサーバSまで接続したがっています。 A1は特定の認証サーバです、そして、Z1は特定の承認サーバです。
C <-------> F1 <-------> F2 <-------> S
\ /
\_____ /
\ \ /
A1 Z1
C<。------->F1<。------->F2<。------->S\/\_____ /\\/A1 Z1
C attempts to initiate its conversation by sending an initial
packet to S. C uses a normal DNS lookup to resolve S's name,
and uses normal IP routing mechanisms. C's packet reaches
Cは、Sの名前を決議する正常なDNSルックアップをS.C用途への初期のパケットに送って、正常なIPルーティングメカニズムCのパケット範囲を用途に送ることによって会話を開始するのを試みます。
Braden, Clark, Crocker & Huitema [Page 13] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[13ページ]RFC1636IABワークショップレポート1994年6月
firewall router F1, which rejects the packet because it does
not match any acceptable packet profile. F1 returns an
"Authentication Required" error indication to C, including a
list of authentication/authorization servers that F1 trusts.
This indication might be a new type of ICMP Destination
Unreachable packet, or some other mechanism for communicating
with C.
ファイアウォールルータF1。(どんな許容できるパケットプロフィールも合わせないので、そのF1はパケットを拒絶します)。 F1はF1が信じる認証/承認サーバのリストを含むCに「認証が必要である」という誤り表示を返します。 この指示は、新しいタイプのICMP Destination Unreachableパケット、またはCで交信するためのある他のメカニズムであるかもしれません。
When C receives the error indication, authenticates itself with
A1, one of the authentication servers listed in the error
indication, after validating A1's identity. C then requests
authorization from server Z1 (using a ticket provided by A1),
informs Z1 of the application it wishes to perform, and
provides a profile for the packets it wishes to pass through
F1. Z1 then performs an authorization function to decide
whether to allow C to penetrate F1. If C is to be allowed, Z1
then informs the firewall F1 to allow packets matching the
packet profile to pass through the firewall F1.
Cが誤り表示を受けて、A1と共にそれ自体を認証するとき、A1のアイデンティティを有効にした後に誤り表示で記載された認証サーバの1つです。 Cは、次に、サーバZ1(A1によって供給されたチケットを使用する)から承認を要求して、それが実行したがっているアプリケーションについてZ1に知らせて、それがF1を通り抜けたがっているパケットにプロフィールを提供します。 そして、Z1は、CがF1に入り込むのを許容するかどうか決めるために承認機能を実行します。 Cが許容されるつもりであるなら、Z1は、パケットプロフィールに合っているパケットがファイアウォールF1を通り抜けるのを許容するためにファイアウォールF1を知らせます。
After C's packets penetrate F1, they may again be rejected by a
second firewall F2. C could perform the same procedures with
authentication server A2 and authorization server Z2, which F2
trusts. This is illustrated by the following schematic diagram
of the sequence of events.
CのパケットがF1に入り込んだ後に、それらは再び2番目のファイアウォールF2によって拒絶されるかもしれません。 Cは認証サーバA2と承認サーバZ2で同じ手順を実行できました。(F2はZ2を信じます)。 これはイベントの系列の以下の回路図で例証されます。
Braden, Clark, Crocker & Huitema [Page 14] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[14ページ]RFC1636IABワークショップレポート1994年6月
----------+--------+--------+------------+------------+----
| C | A1 | Z1 | F1 | F2 | S
----------+--------+--------+------------+------------+----
| Sends pkt| | | | |
| to S ----------------------->Intercept;| |
| | | | requires | |
| | | |authenticat'n |
| <------------------------------- | |
|Auth'cate | | | | |
| C to A1 ----> | | | |
| |Provide | | | |
| <------- ticket| | | |
| Request | | | | |
|authoriz'n| | | | |
| -------------------> Is C| | |
| | |allowed?| | |
| | | OK ---------> | |
|Resend | | | Set filter | |
| first pkt| | | | |
| to S -------------------------->(OK)------>Intercept;|
| | | | | requires |
| | | | |authenticat'n
| <------------------------------------------- |
| (Repeat | | | | |
|procedure | | | | |
with A2,Z2)| | | | |
| ... | | | | |
|Resend | | | | |
| first pkt| | | | |
| ------------------------------>(OK)--------(OK)------>
| | | | | |
-----------+--------+--------+------------+------------+----
----------+--------+--------+------------+------------+---- | C| A1| Z1| F1| F2| S----------+--------+--------+------------+------------+---- | pktを送ります。| | | | | | Sに----------------------->インタセプト;、|| | | | | 必要です。| | | | | |authenticat'n| | <------------------------------- | | |Auth'cate| | | | | | A1へのC---->|、|、|、|、| |提供してください。| | | | | <、-、-、-、-、-、-- チケット| | | | | 要求| | | | | |authoriz'n| | | | | | ------------------->はCです。| | | | | |許容されているか、|| | | | | OK--------->|、| |再送します。| | | セットフィルタ| | | 最初に、pkt| | | | | | Sに-------------------------->(OK)------>インタセプト;、|| | | | | 必要です。| | | | | |authenticat'n| <------------------------------------------- | | (反復| | | | | | 手順| | | | | A2と共にZ2)| | | | | | ... | | | | | |再送します。| | | | | | 最初に、pkt| | | | | | ------------------------------>(OK)--------(OK)------>|、|、|、|、|、| -----------+--------+--------+------------+------------+----
Again, we emphasize that this is only intended as a partial
sketch of one possible mechanism. It omits some significant
issues, including the possibility of asymmetric routes (see
3.3.3 below), and the possibility that the profiles may be
different in the two directions between C and S.
一方、私たちは、これが1台の可能なメカニズムの部分的なスケッチとして意図するだけであると強調します。 いくつかの重要な問題を省略します、非対称のルートの可能性を含んでいて(見る、3.3、.3、)、以下にそして、プロフィールがCとSの間の2つの方向に異なるかもしれない可能性。
We could imagine generalizing this to an arbitrary sequence of
firewalls. However, security requires that each of the
firewalls be able to verify that data packets actually come
from C. This packet authentication problem, which is discussed
in the next section, could be extremely difficult if the data
must traverse more than one or possibly two firewalls in
sequence.
私たちは、ファイアウォールの気紛れな順番にこれを一般化すると想像できました。 しかしながら、セキュリティは、それぞれのファイアウォールが、データが連続して1以上かことによると2個のファイアウォールを横断しなければならないならパケットが実際に次のセクションで議論するC.Thisパケット認証問題から来させるデータが非常に難しいかもしれないことを確かめることができるのを必要とします。
Braden, Clark, Crocker & Huitema [Page 15] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[15ページ]RFC1636IABワークショップレポート1994年6月
A firewall router may require re-authentication because:
ファイアウォールルータが再認証を必要とするかもしれない、:
* it has been added to the path by a routing change, or
* またはそれがルーティング変化によって経路に加えられる。
* it has timed out the profile entry, or
* またはそれはプロフィールエントリーから時間がある。
* it has been newly re-activated, perhaps after a crash that
lost its list of acceptable profiles.
* それは恐らく許容できるプロフィールのリストを失ったクラッシュの後に新たに現役に戻されました。
If C contacts authentication and authorization servers that S
trusts, C may utilize tickets given it by these servers when
initiating its use of S, and avoid re-authenticating itself to
S.
CがSが信じる認証と承認サーバに連絡するなら、Cは、Sの使用を開始するとき、それを考えて、これらのサーバでチケットを利用して、それ自体を再認証するのをSとして避けるかもしれません。
Although the authentication server A1 and the authorization
server Z1 are conceptually separate, they may run on the same
computer or router or even be separate aspects of a single
program. The protocol that C speaks to an An, the protocol
that C speaks to a Zn, and the protocol that Zn speaks to Fn
are not specified in these notes. The authentication mechanism
used with An and the packet profile required by a firewall Fn
are considered matters of policy.
認証サーバA1と承認サーバZ1は概念的に別々ですが、それらは、同じコンピュータかルータで動くか、単一のプログラムの別々の局面でさえあるかもしれません。 CがAnに話すプロトコル、CがZnに話すプロトコル、およびZnがFnに話すプロトコルはこれらの注意で指定されません。 Anと共に使用される認証機構とファイアウォールFnによって必要とされたパケットプロフィールは方針の問題であると考えられます。
3.3.2 Source Authentication
3.3.2 ソース認証
We next consider how to protect against spoofing the IP source
address, i.e., injecting packets that are alleged from come
from C but do not. There are three classes of mechanisms to
prevent such spoofing of IP-level firewalls. The mechanisms
outlined here are also discussed in Section 4.3 below.
私たち、次は、すなわち、IPソースアドレスを偽造する注入から守りに、それが申し立てられるパケットがCからどう来るかを考えますが、します。 そのようなものがIP-レベルファイアウォールをだますのを防ぐために、3つのクラスのメカニズムがあります。 また、以下のセクション4.3でここに概説されたメカニズムについて議論します。
o Packet Profile Only
o パケットプロフィール専用
The lowest level of security consists of allowing the IP-
layer firewall to filter packets purely on the basis of
the packet profile. This is essentially the approach used
by filtering routers today, with the addition of (1)
authentication and authorization servers to control the
filtering profiles, and (2) the automatic "Authentication
Required" notification mechanism. This approach provides
almost no security; it does not prevent other computers
from spoofing packets that appear to be transmitted by C,
or from taking over C's transport level connection to S.
IP層のファイアウォールがパケットプロフィールに基づいて純粋にパケットをフィルターにかけるのを許容するのから最も低いレベルのセキュリティは成ります。 これは本質的には今日(2) フィルタリングプロフィール、および「認証が必要である」という自動通知メカニズムを制御するために(1)認証と承認サーバの追加でルータをフィルターにかけることによって使用されるアプローチです。 このアプローチはセキュリティをほとんど全く提供しません。 それは、他のコンピュータがCか、Cの輸送レベルを引き継ぐことから伝えられるように見えるパケットに接続を偽造するのをSに防ぎません。
o Sealed Packets
o 密封されたパケット
In the second level of security, each packet is "sealed"
with a secure hash algorithm. An authentication server Ai
第2レベルのセキュリティでは、各パケットは安全なハッシュアルゴリズムで「封をされます」。 認証サーバAi
Braden, Clark, Crocker & Huitema [Page 16] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[16ページ]RFC1636IABワークショップレポート1994年6月
chooses a secret and shares it with the source host S and
also with the authorization server Zi, which shares the
secret with the firewall Fi. Every packet that C
transmits contains a hash value that depends upon both the
contents of the packet and the secret value. The firewall
Fi can compute the same hash function and verify that the
packet was originated by a computer that knew the shared
secret.
送信元ホストSと承認サーバZiとも秘密を選んで、それを共有します。(ZiはファイアウォールFiと秘密を共有します)。 Cが伝えるあらゆるパケットがパケットのコンテンツと秘密の値の両方に依存するハッシュ値を含んでいます。 ファイアウォールFiは、同じハッシュ関数を計算して、パケットが共有秘密キーを知っていたコンピュータによって溯源されたことを確かめることができます。
This approach does raise issues of how much C trusts Zi
and Fi. Since they know C's secret, Zi or Fi could spoof
C. If C does not trust all Z's and F's in its path, a
stronger mechanism (see below) is needed.
このアプローチはどのくらいのCがZiとFiを信じるかに関する問題を提起します。 彼らが、Cの秘密、ZiまたはFiが経路でIf Cが信じないC.にすべてのZとFのものを偽造することができたのを知っているので、より強いメカニズム(以下を見る)が必要です。
A more difficult problem arises in authenticating C's
packets when more than one firewall lies in the path.
Carrying a separate seal for each firewall that is
penetrated would be costly in terms of packet size. On
the other hand, in order to use a single seal, all the
firewalls would have to cooperate, and this might require
a much more complex mechanism than the one sketched in the
previous section. Morever, it may require mutual trust
among all of the authentication servers Ai and
authorization servers Zi; any of these servers could
undermine all the others. Another possibility to be
investigated is to use hop-by-hop rather than end-to-end
authentication of C's packets. That is, each firewall
would substitute into the packet the hash needed by the
next firewall.
より難しい問題は1個以上のファイアウォールが経路にあるとCのパケットを認証する際に起こります。 理解される各ファイアウォールまで別々のシールを運ぶのはパケットサイズで高価でしょう。 他方では、すべてのファイアウォールが単一のシールを使用するために協力しなければならないでしょう、そして、これは前項でスケッチされたものよりはるかに複雑なメカニズムを必要とするかもしれません。 Morever、認証サーバのAiと承認サーバZiのすべて中で信頼関係を必要とするかもしれません。 これらのサーバのいずれもすべての他のものを弱体化させるかもしれません。 使用には別の調査されるべき可能性がホップごとに終わりから終わりへのCのパケットの認証よりむしろあります。 すなわち各ファイアウォールは隣のファイアウォールによって必要とされたハッシュをパケットに代入するでしょう。
Multi-firewall source authentication is a difficult
problem that needs more investigation.
マルチファイアウォールソース認証は、より多くの調査を必要とする難問です。
o Packet Signatures
o パケット署名
In the third level of security, each packet is "signed"
using a public/private key algorithm. C shares its public
key with Zn, which shares it with Fn. In this scenario, C
can safely use one pair of keys for all authorization
servers and firewalls. No authorization server or
firewall can spoof C because they cannot sign packets
correctly.
第3レベルのセキュリティでは、公衆/秘密鍵アルゴリズムを使用することで各パケットに「署名します」。 CはZnと公開鍵を共有します。(ZnはFnとそれを共有します)。 このシナリオでは、Cはすべての承認サーバとファイアウォールに安全に1組のキーを使用できます。 彼らが正しくパケットに署名することができないので、どんな承認サーバもファイアウォールもCを偽造することができません。
Although packet signing gives a much higher level of
security, it requires public key algorithms that are
patented and currently very expensive to compute; their
time must be added to that for the hash algorithm. Also,
signing the hash generally makes it larger.
パケット署名ははるかに高いレベルのセキュリティを与えますが、計算するのが特許をとられて、現在非常に高価な公開鍵アルゴリズムを必要とします。 ハッシュアルゴリズムのために彼らの時間をそれに加えなければなりません。 また、一般に、ハッシュに署名するのに、それは、より大きくなります。
Braden, Clark, Crocker & Huitema [Page 17] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[17ページ]RFC1636IABワークショップレポート1994年6月
3.3.3 Other Firewall Issues
3.3.3 他のファイアウォール問題
o Performance
o パフォーマンス
An Internet-layer firewall has the advantage of generality
and flexibility. However, filtering introduces a
potential performance problem. Performance may depend
upon the number and position of the packet fields used for
filtering, and upon the number of rules against which a
packet has to be matched.
インターネット層のファイアウォールには、一般性と柔軟性の利点があります。 しかしながら、フィルタリングは潜在的性能問題を紹介します。 パフォーマンスはフィルタリングに使用されるパケット分野の数と位置と、パケットが合わせられなければならない規則の数に依存するかもしれません。
Denial of service attacks require that the per-packet rule
matching and the drop path be able to keep up with the
interface speed.
サービス不能攻撃は、1パケットあたりの規則マッチングと低下経路がインタフェース速度について行くことができるのを必要とします。
o Multicasting
o マルチキャスティング
To allow multicast traffic to penetrate a firewall, the
rule that is needed should be supplied by the receiver
rather than the sender. However, this will not work with
the challenge mechanism outlined in Section 3.3.1, since
"Authentication Required" notifications would be sent to
the sender, not to the receiver(s).
マルチキャストトラフィックがファイアウォールを理解するのを許容するために、送付者よりむしろ受信機は必要である規則を供給するべきです。 しかしながら、挑戦メカニズムがセクション3.3.1に概説されている状態で、これは働かないで、「認証が必要である」ので、受信機ではなく、送付者に通知を送るでしょう。
Multicast conversations may use any of the three levels of
security described in the previous section, but all
firewalls will have to share the same secret with the
originator of the data stream. That secret would have to
be provided to the receivers through other channels and
then passed to the firewalls at the receivers' initiative
(in much the same way that resources are reserved at
receiver's initiative in RSVP).
マルチキャストの会話は前項で説明されたセキュリティの3つのレベルのどれかを使用するかもしれませんが、すべてのファイアウォールがデータ・ストリームの創始者と同じ秘密を共有しなければならないでしょう。 その秘密は、他の方面から受信機に提供されて、次に、受信機のイニシアチブでファイアウォールに通過されなければならないでしょう(大体同じようなやり方でそのリソースはRSVPの受信機のイニシアチブで予約されます)。
o Asymmetric Routing
o 非対称のルート設定
Given a client computer C utilizing a service from another
computer C through a firewall F: if the packets returning
from S to C take a different route than packets from C to
S, they may encounter another firewall F' which has not
been authorized to pass packets from S to C (unlike F,
which has been). F' will challenge S rather than C, but S
may not have credentials to authenticate itself with a
server trusted by F'.
別のコンピュータCからファイアウォールFまでサービスを利用することでクライアントコンピュータCを与えます: 'SからCまで戻るパケットがCからSまでのパケットと異なったルートを取るなら、SからCまでパケットを通過するのは認可されていない別のファイアウォールF'に遭遇するかもしれない、(Fと異なって、どれがいたか、) 'F'はCよりむしろSに挑戦するでしょうが、Sには、サーバがFによって信じられている状態でそれ自体を認証する資格証明書がないかもしれません'。
Fortunately, this asymmetric routing situation is not a
problem for the common case of single homed administrative
domains, where any asymmetric routes converge at the
firewall.
幸い、この非対称のルーティング状況はシングルのよくある例のための問題が家へ帰ったということではありません。どんな非対称のルートもファイアウォールで一点に集まるところの管理ドメイン。
Braden, Clark, Crocker & Huitema [Page 18] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[18ページ]RFC1636IABワークショップレポート1994年6月
o Illicit Rendezvous
o 不法なランデブー
None of these mechanisms prevent two users on opposite
sides of a firewall from rendezvousing with a custom
application written over a protocol that may have been
authorized to run through a firewall.
これらのメカニズムのいずれも、カスタムアプリケーションがファイアウォールをざっと読むのが認可されたかもしれないプロトコルの上に書かれている状態でファイアウォールの反対側の2人のユーザが集合するのを防ぎません。
For example, if an organization has a policy that certain
information is sensitive and must not be allowed outside
its premises, a firewall will not be enough to enforce
this policy if users are able to attach sensitive
information to mail and send it outside to arbitrary
parties. Similarly, a firewall will not prevent all
problems with incoming data. If users import programs and
execute them, the programs may have Trojan horses which
disclose sensitive information or modify or delete
important data. Executable code comes in many, many
forms, including PostScript files, scripts for various
interpreters, and even return addresses for sendmail. A
firewall can detect some of these and scan for some forms
of potentially hazardous code, but it cannot stop users
from transforming things that look like "data" into
programs.
例えば、組織が方針を情報が機密であることをそんなに確信するようにして、構内の外で許されてはいけないと、ユーザが任意のパーティーへの外にそれを郵送して、送るために機密情報を添付できるなら、ファイアウォールは、この方針を実施するために十分にならないでしょう。 同様に、ファイアウォールは受信データに関するすべての問題を防ぐというわけではないでしょう。 ユーザがプログラムをインポートして、それらを実行するなら、プログラムには、重要なデータを機密情報を明らかにするか、変更するか、または削除するトロイの木馬があるかもしれません。 ポストスクリプトファイル、様々なインタプリタのためのスクリプト、およびsendmailのための返送先さえ含んでいて、実行コードは多くのフォームに入ります。 ファイアウォールは、これらのいくつかを検出して、いくつかのフォームの潜在的に危険なコードのためにスキャンされることができますが、それによって、ユーザは「データ」に似ているものをプログラムに変えることができません。
We consider these problems to be somewhat outside the
scope of the firewall router mechanism. It is a matter of
the policies implemented by the organization owning the
firewalls to address these issues.
私たちは、ファイアウォールルータメカニズムの範囲のいくらか外にこれらの問題があると考えます。 これらの問題を扱うのは、ファイアウォールを所有している組織によって実施された政策の問題です。
o Transparency for Security Packets
o セキュリティパケットのための透明
For the mechanisms described above to operate, the
"Authentication Required" notification and the
authentication/authorization protocol that is used between
the client computer and the authentication and
authorization servers trusted by a firewall, must be
passed by all firewalls automatically. This might be on
the basis of the packet profiles involved in security.
Alternatively, firewall routers might serve as
application-layer firewalls for these types of
communications. They could then validate the data they
pass to avoid spoofing or illicit rendezvous.
すべてのファイアウォールで自動的に作動するために上で説明されたメカニズム(「認証が必要である」という通知とファイアウォールによって信じられたクライアントコンピュータと、認証と承認サーバの間で使用される認証/承認プロトコル)を通過しなければならないので。 これは安全にかかわるパケットプロフィールのベースにあるかもしれません。 あるいはまた、ファイアウォールルータはこれらのタイプに関するコミュニケーションのための応用層ファイアウォールとして機能するかもしれません。 そして、彼らはそれらがパロディーの、または、不法なランデブーを避けるために通過するデータを有効にするかもしれません。
3.3.4 Firewall-Friendly Applications
3.3.4 ファイアウォールに優しいアプリケーション
Firewall routers have problems with certain communication
patterns where requests are initiated by the server, including
callbacks and multiple connections (e.g., FTP). It was
ファイアウォールルータには、要求がサーバによって開始されるあるコミュニケーションパターンに関する問題があります、コールバックと複数の接続(例えば、FTP)を含んでいて。 それはそうでした。
Braden, Clark, Crocker & Huitema [Page 19] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[19ページ]RFC1636IABワークショップレポート1994年6月
suggested that it would be useful to have guidelines to
application designers to help them to build 'firewall-friendly
applications'. The following guidelines were suggested:
彼らが'ファイアウォールに優しいアプリケーション'を建てるのを助けるためにアプリケーション設計者にガイドラインを持っているのが役に立つと示唆しました。 以下のガイドラインは示されました:
1) no inbound calls (the xterm problem),
1) 本国行きの要求がありません(xterm問題)。
2) fixed port numbers (no portmapper or tcpmux),
2)はポートナンバー(ポートマッパーでないtcpmuxがない)を固定しました。
3) integral redirection is good (application gateways),
3) 不可欠のリダイレクションは良いです(アプリケーションゲートウェイ)。
4) no redirection in the protocol,
4) プロトコルでリダイレクションがありません。
5) 32 bit sequence numbers that are crypto-strong random #'s,
and
5) 32は暗号強い無作為の#である一連番号に噛み付きました。
6) fixed length and number of header fields.
6)はヘッダーフィールドの長さと数を固定しました。
Type fields are good, but they may not be needed if there are
fixed port numbers.
タイプ分野は良いのですが、固定ポートナンバーがあれば、それらは必要でないかもしれません。
3.3.5 Conclusions
3.3.5 結論
Compared to an application-layer firewall, an IP-layer firewall
scheme could provide a number of benefits:
応用層ファイアウォールと比べて、IP-層のファイアウォール体系は多くの利益を提供するかもしれません:
- No extra authentication is required for end hosts.
- どんな付加的な認証も終わりのホストに必要ではありません。
- A single authentication protocol can be used for all
intended applications.
- すべての意図しているアプリケーションにただ一つの認証プロトコルを使用できます。
- An IP-layer firewall causes less performance degradation.
- IP-層のファイアウォールは、より少ない性能退行を引き起こします。
- An IP-layer firewall may be able to crash and recover
state without disturbing open TCP connections.
- IP-層のファイアウォールは、不穏なオープンなTCP接続なしで状態を墜落して、回復できるかもしれません。
- Routes can shift without disturbing open TCP connections.
- ルートは不穏なオープンなTCP接続なしで移行できます。
- There is no single point of failure.
- 失敗のどんな単一のポイントもありません。
- It is independent of application.
- それはアプリケーションから独立しています。
However, there are substantial difficult design issues to be
solved, particularly in the areas of multiple firewalls,
assymmetric routes, multicasting, and performance.
しかしながら、特に複数のファイアウォール、assymmetricルート、マルチキャスティング、および性能の領域で解決されるために、かなりの難しいデザイン問題があります。
Braden, Clark, Crocker & Huitema [Page 20] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[20ページ]RFC1636IABワークショップレポート1994年6月
4. SECURE QOS FORWARDING
4. 安全なQOS推進
When the Internet supports special qualities-of-service (QOS) for particular packet flows, there will be a new set of security problems. There will be a need to authenticate and authorize users asking for those QOS values that are expensive in network resources, and it will be necessary to prevent theft of these resources and denial-of-service attacks by others. This section contains a conceptual model for these problems, which we may call secure QOS forwarding. The issues here differ from end-to-end security and firewalls, because QOS forwarding security may need to be enforced at every router along a path.
特定のパケットのインターネットサポートの特別なサービスの品質(QOS)が流れるとき、新しい警備上の問題があるでしょう。それらのネットワーク資源で高価なQOS値を求めるユーザを認証して、権限を与える必要があるでしょう、そして、他のものによるこれらのリソースとサービス不能攻撃の窃盗を防ぐのが必要でしょう。 このセクションはこれらの問題によって概念モデルを含みます。(私たちは問題を安全なQOS推進と呼ぶかもしれません)。 ここの問題は終わりから終わりへのセキュリティとファイアウォールと異なっています、QOS推進セキュリティが、経路に沿ったあらゆるルータで実施される必要があるかもしれないので。
It was noted that this is not a new problem; it was stated and solved in a theoretical way in a thesis by Radia Perlman.
これが新しい問題でないことに注意されました。 それは、述べられて、理論上の入口でRadiaパールマンによる論文を解決しました。
4.1 The Requirement for Setup
4.1 セットアップのための要件
Setup is an essential part of any QOS mechanism. However, it may
be argued that there are also good engineering reasons for setup
in any Internet-layer security mechanism, even without QOS
support. In the abstract, one could imagine a pure datagram model
in which each IP packet separately carried the necessary
authorizations for all the stages in the forwarding path.
Realistically, this is not practical, since the security
information may be both unacceptably large and computationally
demanding for inclusion in every packet. This seems to imply the
need for some form of state setup for security.
セットアップはどんなQOSメカニズムの不可欠の部分です。 しかしながら、また、どんなインターネット層のセキュリティー対策にもセットアップの十分な工学理由があると主張されるかもしれません、QOSサポートがなくても。 要約では、人はそれぞれのIPパケットが別々に推進経路のすべての舞台まで必要な承認を運んだ純粋なデータグラムモデルを想像できました。 現実的に、これは実用的ではありません、セキュリティ情報が容認できないほど大きくて、かつあらゆるパケットでの包含には、計算上過酷であるかもしれないので。 これはセキュリティのための何らかの形式の州のセットアップの必要性を含意するように思えます。
Thus, we presume a two stage process that moves somewhat away from
the pure datagram model. In the first stage, the setup stage,
some state is established in the routers (and other network
elements) that describes how a subsequent stream of packets is to
be treated. In the second stage, the classification stage, the
arriving packets are matched with the correct state information
and processed. The terminology in use today calls these different
state descriptions "classes", and the process of sorting
"classification".
したがって、私たちは、移行する2ステージプロセスが純粋なデータグラムモデルからいくらか離れていると推定します。 第一段階、セットアップ段階では、何らかの状態が扱われるパケットの適従川がことである方法を説明するルータ(そして、他のネットワーク要素)に設置されます。 2番目のステージ、分類段階では、到着パケットは、正しい州の情報に合わせられていて、処理されます。 今日の使用中の用語は、これらを異なった州の記述「クラス」、およびソーティング「分類」のプロセスと呼びます。
Setup can take many forms. It could be dynamic, invoked across
the network by an application as described above. The setup
process could also be the manual configuration of a router by
means of a protocol such as SNMP or remote login. For example, a
network link, such as a link across the Atlantic, might be shared
by a number of users who purchase it jointly. They might
implement this sharing by configuring a router with
specifications, or filters, which describe the sorts of packets
that are permitted to use each share. Whether the setup is
セットアップは多くの形を取ることができます。それは、上で説明されるようにネットワークの向こう側にアプリケーションでダイナミックで、呼び出すことができるでしょう。 また、セットアッププロセスはSNMPかリモート・ログインなどのプロトコルによるルータの手動の構成であるかもしれません。 例えば、大西洋中のリンクなどのネットワークリンクは共同でそれを購入する多くのユーザによって共有されるかもしれません。 彼らは、各シェアを使用することが許可されているパケットの種類について説明する仕様、またはフィルタでルータを構成することによって、この共有を実装するかもしれません。 セットアップがそうであり
Braden, Clark, Crocker & Huitema [Page 21] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[21ページ]RFC1636IABワークショップレポート1994年6月
dynamic or manual, short-lived or semi-permanent, it has the same
effect: it creates packet classes in the router and defines how
packets are to be classified as they arrive.
それには、ダイナミックであるか、手動、短命であるかまたは半永久的であることで、同じ効果があります: それは、ルータでパケットのクラスを創設して、到着するときパケットによってどのように分類されていることになっているかを定義します。
Much of the current research on extensions to IP for QOS, such as
realtime service, has assumed an explicit setup phase and a
classification stage. The setup stage is accomplished using
protocols such as RSVP or ST-II, which also specify how the
subsequent classification is to be done. Security at the setup
stage would thus simply be an extension to such a protocol. It
should be noted that there are alternative proposals for realtime
QOS, based on an implicit setup process.
リアルタイムでサービスなどのQOSのためのIPへの拡大の現在の研究の多くが明白なセットアップフェーズと分類ステージを仮定しました。 セットアップステージはRSVPかST-IIなどのプロトコル(また、するその後の分類がことである方法を指定する)を使用するのに優れています。 その結果、セットアップ段階のセキュリティは単にそのようなプロトコルへの拡大でしょう。 内在しているセットアッププロセスに基づいて代案リアルタイム用QOSがあることに注意されるべきです。
4.2 Securing the Setup Process.
4.2 セットアッププロセスを機密保護します。
To secure the setup process, we require that a setup request be
accompanied by user credentials that provide a trustworthy
assurance that the requester is known and is authorized to make
the request in question. We refer to the credentials used in the
setup phase as the high-level identification (HLID).
セットアッププロセスを機密保護するために、私たちは、セットアップ要求がリクエスタが知られていて、要求を問題にするのが認可されるという信頼できる保証を提供するユーザ資格証明書によって伴われるのを必要とします。 私たちはハイレベルの識別(HLID)としてセットアップフェーズに使用される資格証明書について言及します。
A simple version of this authorization would be a password on the
management interface to a router (the limitations of such a
password scheme are well known and not the issue here). In the
case of setup requests made by individual applications, some
user-specific authorization must be assumed.
この承認の簡単なバージョンはルータへの管理インタフェースに関するパスワード(そのようなパスワード体系の制限は、よく知られていてここの問題でない)でしょう。 個々のアプリケーションでされたセットアップ要求の場合では、何らかのユーザ特有の承認を想定しなければなりません。
While there could be any number of ways to organize the HLIDs, the
objective of scaling suggests that a global framework for user
naming and authentication would be useful. The choice of naming
framework is discussed further in Section 5. Note that this
discussion, which concerns controlling access to network resources
and security devices, is distinct from end-to-end authentication
and access control; however, the same authentication
infrastructure could be used for both.
HLIDsを組織化するいろいろな方法があるかもしれませんが、スケーリングの目的は、ユーザ命名と認証のためのグローバルなフレームワークが役に立つと示唆します。 セクション5で、より詳しくフレームワークを命名することの選択について議論します。 この議論(ネットワーク資源とセキュリティデバイスへのアクセスを制御するのに関する)が終わりから終わりへの認証とアクセスコントロールと異なっていることに注意してください。 しかしながら、両方に同じ認証インフラストラクチャを使用できました。
In general, while significant engineering effort will be required
to define a setup architecture for the Internet, there is no need
to develop new security techniques. However, for the security
aspects of the classification process, there are significant
problems related to performance and cost. We thus focus on that
aspect of the overall framework in more detail.
一般に、重要な技術的努力がセットアップアーキテクチャをインターネットと定義するのに必要でしょうが、新しいセキュリティ技術を見いだす必要は全くありません。 しかしながら、分類プロセスのセキュリティ局面には性能と費用に関連する重大な問題があります。 その結果、私たちはさらに詳細に総合的なフレームワークのその局面に焦点を合わせます。
Above, we defined the high-level ID (HLID) as that set of
information presented as part of a setup request. There may also
be a "low-level ID" (LLID), sometimes called a "cookie", carried
in each packet to drive classification. In current proposals for
IP extensions for QOS, packets are classified based on existing
上では、私たちがセットアップ要求の一部として提示されたそのセットの情報とハイレベルのID(HLID)を定義しました。 また、時々「クッキー」と呼ばれる(LLID)が分類を追い立てるために各パケットで運んだ「低地のID」があるかもしれません。 QOSのためのIP拡大のための現在の提案では、存在に基づいてパケットは分類されます。
Braden, Clark, Crocker & Huitema [Page 22] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[22ページ]RFC1636IABワークショップレポート1994年6月
packet fields, e.g., source and destination addresses, ports, and
protocol type.
パケット分野、例えば、ソース、送付先アドレス、ポート、およびプロトコルタイプ。
It is important to note that the LLID is distinct from the address
of the user, at least conceptually. By stressing this distinction
we make the point that the privileges of the user are not
determined by the address in use. If the user's address changes,
the privileges do not.
LLIDがユーザのアドレスと異なっていることに注意するのは少なくとも概念的に重要です。 この区別を強調することによって、私たちはユーザの特権が使用中のアドレスで決定しないというポイントを指摘します。 ユーザのアドレスが変化するなら、特権は変化しません。
The LLID in a packet acts as a form of tag that is used by some or
all routers along a path to make decisions about the sort of QOS
that shall be granted to this packet. An LLID might refer to a
data stream between a single source-destination address pair, or
it might be more general and encompass a range of data streams.
There is no requirement that the LLID embody a syntax that permits
a router to discern the QOS parameters that it represents, but
there also is no prohibition against imposing such a structure.
経路に沿ったいくつかかすべてのルータによって使用される、QOSの種類に関する決定をそれにするタグのフォームをこのパケットに与えるものとするとき、パケットのLLIDは行動します。 LLIDが1ソース目的地アドレス組の間のデータ・ストリームについて言及するかもしれないか、それは、より一般的であり、さまざまなデータ・ストリームを成就するかもしれません。LLIDがルータがそれが表すQOSパラメタについて明察することを許可する構文を具体化しますが、また、そのような構造を課すことに反対して禁止が全くいないという要件が全くありません。
We propose that an IP datagram contain one LLID, which can be used
at various stages of the network to map the packet to a class. We
reject the alternative that the packet should have a variable
number of LLIDs, each one for a different point in the net.
Again, this is not just a security comment, but it has security
implications.
私たちは、IPデータグラムが1LLIDを含むよう提案します。(パケットをクラスに写像するのにネットワークの様々な段階でLLIDを使用できます)。 私たちは代替手段を拒絶します。パケットには、ネットに異なったポイントにはLLIDs、可変数の各々があるはずです。 一方、これはセキュリティコメントであるだけではありませんが、それには、セキュリティ意味があります。
The attributes of the LLID should be picked to match as broad a
range of requirements as possible.
LLIDの属性は、さまざまなできるだけ広い要件を合わせるために選ばれるべきです。
* Its duration (discussed below) must match both the needs of
the security protocol, balancing robustness and efficiency,
and the needs of the application, which will have to deal
with renewal of the setup when the LLID expires. A useful
end-node facility would be a service to renew setup requests
automatically.
* 持続時間(以下では、議論する)がセキュリティプロトコル、バランスをとることの丈夫さ、および効率の必要性とLLIDが期限が切れるときセットアップの更新に対処しなければならないアプリケーションの必要性の両方に合わなければなりません。 役に立つエンドノード施設は、自動的にセットアップ要求を更新するためにはサービスでしょう。
* The degree of trust must be high enough to meet the most
stringent requirement we can reasonably meet.
* 信用の度は私たちが合理的に満たすことができる中で最も厳しい必要条件を満たすことができるくらい高でなければなりません。
* The granularity of the LLID structure must permit packet
classification into classes fine-grained enough for any
resource selection in the network. We should therefore
expect that each separate stream of packets from an
application will have a distinct LLID. There will be little
opportunity for aggregating multiple streams under one LLID
or one authenticator.
* LLID構造の粒状はネットワークにおけるどんなリソース選択のためにもきめ細かに粒状でクラスへのパケット分類を十分可能にしなければなりません。 したがって、私たちは、アプリケーションからのパケットのそれぞれの別々の流れには異なったLLIDがあると予想するべきです。 1LLIDか1つの固有識別文字の下で複数の流れに集める機会がほとんどないでしょう。
Braden, Clark, Crocker & Huitema [Page 23] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[23ページ]RFC1636IABワークショップレポート1994年6月
4.3 Validating an LLID
4.3 LLIDを有効にすること。
At a minimum, it is necessary to validate the use of an LLID in
context, i.e., to ensure that it is being asserted in an
authorized fashion. Unauthorized use of an LLID could result in
theft of service or denial-of-service attacks, where packets not
emitted by an authorized sender are accorded the QOS treatment
reserved for that sender (or for a group of which the sender is a
member). Thus, use of an LLID should be authenticated by routers
that make QOS decisions based on that LLID. (Note that not all
routers may "pay attention" to the LLID.)
最小限では、すなわち、それが認可されたファッションで断言されているのを保証するために状況内においてLLIDの使用を有効にするのが必要です。 LLIDの無断使用はサービスかサービス不能攻撃の窃盗をもたらすかもしれません、その送付者(または、それのグループにおいて送付者がメンバーである)のために控えられたQOS処理が認可された送付者によって放たれなかったパケットに与えられているところで。 したがって、LLIDの使用はQOSをそのLLIDに基づく決定にするルータによって認証されるべきです。 (すべてのルータがLLIDに「注意を向けるかもしれないというわけではない」と述べてください。)
In principle, the validity of an LLID assertion needs to be
checked on every packet, though not necessarily at every router;
it may be possible to restrict the checks to security perimeters.
At those routers that must validate LLIDs, there is an obvious
concern over the performance impact. Therefore, a router may
adopt a less rigorous approach to LLID validation. For example, a
router may elect to sample a data stream and validate some, but
not all, packets. It may also elect to forward packets first and
perform selective validation as a background activity. In the
least stringent approach, a router might log selected packets and
validate them as part of an audit activity much later.
原則として、LLID主張の正当性は、あらゆるパケットの上でチェックされる必要があります、必ずあらゆるルータでどんなそうするというわけではありませんが。 チェックをセキュリティ周辺に制限するのは可能であるかもしれません。 LLIDsを有効にしなければならないそれらのルータには、性能衝撃に関する明白な心配があります。 したがって、ルータはLLID合法化へのそれほど厳しくないアプローチを取るかもしれません。 例えば、ルータは、データ・ストリームを抽出して、パケットではなく、いくつかを有効にするのを選ぶかもしれません。 また、それは、バックグラウンド活動として最初に、パケットを進めて、選択している合法化を実行するのを選ぶかもしれません。 全く厳しいアプローチ、ルータは後で監査活動の一部として非常に選択されたパケットを登録して、それらを有効にするかもしれません。
There are several candidate techniques for validating the use of
LLIDs. We have identified three basic techniques, which differ in
terms of computational performance, bandwidth overhead, and
effectiveness (resistance to various forms of attack).
LLIDsの使用を有効にするためのいくつかの候補のテクニックがあります。 私たちは3つの基本技術を特定しました。(基本技術は計算性能、帯域幅オーバーヘッド、および有効性(様々な形式の攻撃への抵抗)に関して異なります)。
* Digital Signatures
* デジタル署名
The first technique entails the use of public key
cryptography and digital signatures. The sender of each
packet signs the packet (header and payload) by computing a
one-way hash over the packet and transforming the hash value
using a private key associated with the LLID. The resulting
authenticator value is included in the packet header. The
binding between the public key and the LLID is established
through a connection setup procedure that might make use of
public keys that enjoy a much longer lifetime. Using public
key technology yields the advantage that any router can
validate a packet, but no router is entrusted with data that
would enable it to generate a packet with a valid
authenticator (i.e., which would be viewed as valid by other
routers.) This characteristic makes this technique ideal
from the standpoint of the "principle of least privilege."
最初のテクニックは公開鍵暗号とデジタル署名の使用を伴います。 パケットの上で片道細切れ肉料理を計算して、LLIDに関連している秘密鍵を使用することでハッシュ値を変えることによって、それぞれのパケットの送付者はパケット(ヘッダーとペイロード)にサインします。 結果として起こる固有識別文字値はパケットのヘッダーに含まれています。 公開鍵とLLIDの間の結合ははるかに長い生涯を楽しむ公開鍵を利用するかもしれない接続設定手順で確立されます。 公開鍵技術利回りを使用して、どんなルータもパケットを有効にすることができますが、ルータがないのが有効にする利点は有効な固有識別文字でパケットを発生させるのを可能にするデータに預けました(すなわち、どれが他のルータで有効であるとして見なされるでしょうか)。 この特性で、このテクニックは「最少の特権の原則」の見地から理想的になります。
Braden, Clark, Crocker & Huitema [Page 24] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[24ページ]RFC1636IABワークショップレポート1994年6月
Public key cryptosystems such as RSA have the advantage that
validation of a signature is much faster than signing, which
reduces the router processing burden. Nonetheless, this
approach is not likely to be feasible for anything other than
selective checking by routers, given current public key
algorithm performance.
RSAなどの公開鍵暗号方式には、署名の合法化がサインするよりはるかに速い利点があります(ルータ処理負担を減少させます)。 それにもかかわらず、このアプローチはルータによる選択している照合以外の何にも可能である傾向がありません、現在の公開鍵アルゴリズム性能を考えて。
* Sealing
* 封であること
The next technique is based on the use of the same type of
one-way hash function used for digital signatures, but it
does not require signing the hash value. Here the sender
computes a one-way hash with a secret quantity (essentially a
"key") appended to the packet. This process is an example of
what is sometimes referred to more generically as
cryptographic "sealing." The inclusion of this key at the
end of the hash computation results in a hash value that is
not predictable by any entity not possessing the key. The
resulting hash value is the authenticator and is included in
the packet header. A router validates a packet by
recomputing the hash value over the received packet with the
same secret quantity appended. If the transmitted hash value
matches the recomputed hash value, the packet is declared
valid. Unlike the signature technique, sealing implies that
all routers capable of verifying a seal are also capable of
generating (forging) a seal. Thus, this technique requires
that the sender trust the routers not to misuse the key.
次のテクニックはデジタル署名に使用される同じタイプの片道ハッシュ関数の使用に基づいていますが、それは、ハッシュ値にサインするのを必要としません。 ここで、送付者は秘密の量(本質的には「キー」)をパケットに追加している片道細切れ肉料理を計算します。 この過程は時々より一般的に暗号の「封」と呼ばれることに関する例です。 細切れ肉料理計算の終わりのこのキーの包含はキーを所有していないどんな実体でも予測できないハッシュ値をもたらします。 結果として起こるハッシュ値は、固有識別文字であり、パケットのヘッダーに含まれています。 ルータは、容認されたパケットの上で同じ秘密の量を追加している状態でハッシュ値を再計算することによって、パケットを有効にします。 伝えられたハッシュ値が再計算されたハッシュ値に合っているなら、パケットは有効であると宣言されます。 署名のテクニックと異なって、封は、また、シールについて確かめることができるすべてのルータがシールを発生させることができるのを(鍛造します)含意します。 したがって、このテクニックは、送付者がキーを誤用しないようにルータを信じるのを必要とします。
This technique has been described in terms of a single secret
key shared between the sender and all the routers that need
to validate packets associated with an LLID. A related
alternative strategy uses the same authenticator technique,
but shares the secret key on a pairwise basis, e.g., between
the sender and the first router, between the first router and
the next, etc. This avoids the need to distribute the secret
key among a large group of routers, but it requires that the
setup mechanism enable Router A to convince his neighbor
(Router B) that Router A is authorized to represent traffic
on a specific LLID or set of LLIDs. This might best be done
by encapsulating the packet inside a wrapper that both ends
of the link can validate. Once this strategy is in place, it
may even be most efficient for routers to aggregate traffic
between them, providing authentication not on a per-LLID
basis, since the router pairs are prepared to "trust" one
another to accurately represent the data stream LLIDs.
このテクニックは単一の秘密鍵に関してLLIDに関連しているパケットを有効にする必要がある送付者とすべてのルータの間で共有されていた状態で説明されます。 関連する代替の戦略は、同じ固有識別文字のテクニックを使用しますが、対状ベースで秘密鍵を共有します、例えば、送付者と最初のルータと次の間の最初のルータなどの間で これはルータの大きいグループに秘密鍵を分配する必要性を避けますが、Router AがLLIDsの特定のLLIDかセットにおける交通を表すのが認可されると彼の隣人(ルータB)に納得させるのがセットアップメカニズムがRouter Aを有効にするのを必要とします。 リンクの両端が有効にすることができる包装紙にパケットをカプセルに入れることによって、最も上手にこれをするかもしれません。 この戦略が適所にいったんあると、ルータがそれらの間の交通に集められるのは、最も効率的でさえあるかもしれません、どんな1LLIDあたり1個のベースでも認証を提供しないで、ルータ組がお互いが正確にデータ・ストリームLLIDsを表すと「信じてください」用意ができているので。
For a unicast data stream, the use of pairwise keying between
routers does not represent a real change in the trust
ユニキャストデータ・ストリームのために、ルータの間の対状の合わせることの使用は信用における本当の変化を表しません。
Braden, Clark, Crocker & Huitema [Page 25] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[25ページ]RFC1636IABワークショップレポート1994年6月
required of the routers or of the setup mechanism, because of
the symmetric sharing of the secret key. However, for a
multicast connection, this pairwise keying approach is
superior in that it prevents a router at one point in a
multicast tree from being able to generate traffic that could
be inserted at another point in the tree. At worst, a router
can generate spurious, but authenticatable, traffic only for
routers "below" it in the multicast tree.
秘密鍵の左右対称の共有のために、ルータかセットアップメカニズムでは、必要です。 しかしながら、マルチキャスト接続において、マルチキャスト木の1ポイントのルータがもう1ポイントで木に挿入できた交通を発生させることができるのを防ぐので、アプローチを合わせるこの対状は優れています。 最悪、缶が発生させるルータでは、偽りですが、認証可能で、ルータ“below"のためだけにマルチキャスト木でそれを取引してください。
Note that the use of network management fault isolation
techniques, e.g., sampling router traffic statistics at
different points along a data stream, should permit post hoc
detection of packet forgery attacks mounted by rogue routers
along a data stream path. Use of this technique could
provide a deterrent to such activity by routers, further
arguing for the pairwise keying approach.
ネットワークマネージメント欠点分離方法の使用(例えば、データ・ストリームに沿った異なったポイントでの標本抽出ルータ交通統計)がデータ・ストリーム経路に沿って凶暴なルータによって仕掛けられたパケット偽造攻撃のポストhoc検出を可能にするべきであることに注意してください。 さらにアプローチを合わせる対状について賛成の議論をして、このテクニックの使用はルータでそのような活動に抑止力を提供するかもしれません。
The sealing technique is faster than the digital signature
technique, because the incremental hash calculation
(including the appended secret quantity) is much faster than
the cryptographic transformation required to sign a hash.
The processing burden is symmetric here, i.e., the sender and
each router devote the same amount of processing power to
seal a packet and to verify the seal. Also, a sealed hash
may be smaller than a signed hash, even if the same function
is used in both cases. (This is because the modulus size of
the public key signature algorithm and any ancillary
parameters tend to increase the size of the signed hash
value.) Moreover, one could use a hash function with a
"wide" value and truncate that value, if necessary to reduce
overhead; this option is not available when the authenticator
is a signed hash value.
封をするテクニックはデジタル署名のテクニックより速いです、暗号の変化が細切れ肉料理にサインするのが必要であるというよりも増加の細切れ肉料理計算(追加された秘密の量を含んでいる)がはるかに速いので。 処理負担がここで左右対称である、すなわち、送付者と各ルータはパケットの封をして、シールについて確かめるために同じ量の処理能力を注ぎます。 また、密封された細切れ肉料理もサインされた細切れ肉料理より小さいかもしれません、同じ機能がどちらの場合も使用されても。 (これは公開鍵署名アルゴリズムの係数サイズとどんな付属のパラメタも、サインされたハッシュ値のサイズを増加させる傾向があるからです。) そのうえ、1つは、「広い」値があるハッシュ関数を使用して、必要なら、経費を削減するためにその値に先端を切らせるかもしれません。 固有識別文字がサインされたハッシュ値であるときに、このオプションは利用可能ではありません。
As a variant on this technique, one could imagine a
"clearinghouse" that would receive, from the sender, the
secret key used to generate and validate authenticators. A
router needing to validate a packet would send a copy of the
packet to the clearinghouse, which would check the packet and
indicate to the router whether it was a valid packet
associated with the LLID in question. Obviously, this
variant is viable only if the router is performing
infrequent, selective packet validation. However, it does
avoid the need to share the authenticator secret among all
the routers that must validate packets.
このテクニックの異形として、人は受信される「情報センター」を想像できました、送付者から、固有識別文字を発生して、有効にするのに使用される秘密鍵。 パケットを有効にする必要があるルータは、パケットのコピーを情報センターに送って、それが関連しているはっきりしていないLLIDで有効なパケットであったかどうかをルータに示すでしょう。(情報センターはパケットをチェックするでしょう)。 明らかに、ルータが珍しくて、選択しているパケット合法化を実行している場合にだけ、この異形は実行可能です。 しかしながら、それはパケットを有効にしなければならないすべてのルータの中で固有識別文字秘密を共有する必要性を避けます。
For both of these techniques, there is a residual
vulnerability to denial-of-service attacks based on replay of
valid packets during the lifetime of a data stream. Unless
これらのテクニックの両方のために、データ・ストリームの生涯有効なパケットの再生に基づくサービス不能攻撃への残りの脆弱性があります。 unless
Braden, Clark, Crocker & Huitema [Page 26] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[26ページ]RFC1636IABワークショップレポート1994年6月
packets carry sequence numbers and routers track a sequence
number window for each data stream, an (external) attacker
can copy valid packets and replay them. It may be easiest to
protect against this form of attack by aggregating all
traffic between a pair of routers into a single flow and
providing replay protection for the flow as a whole, rather
than on a per data stream basis.
パケットが一連番号を運んで、ルータが各データ・ストリームのために一連番号ウィンドウを追跡して、(外部)の攻撃者は、有効なパケットをコピーして、それらを再演できます。 ただ一つの流れへの1組のルータとa全体としてむしろ反復操作による保護を流れに提供することの間のすべての交通に集めることによってこの形式の攻撃から守るのはデータ・ストリーム基礎あたりのaより最も簡単であるかもしれません。
* Temporary Passwords
* 一時的なパスワード
The final technique explored in the workshop takes a very
different tack to packet validation. The preceding
techniques compute a function of the bits in a packet and
transform that value in a fashion that prevents an intruder
from generating packets with valid authenticators. The
ability to generate packets with valid authenticators for a
given LLID requires access to a secret value that is
available only to the sender, or to the sender and to routers
participating in a given data stream.
ワークショップで探られた最終的なテクニックは非常に異なったびょうをパケット合法化に取ります。 前のテクニックは、パケットでビットの関数を計算して、侵入者が有効な固有識別文字でパケットを発生させることができないファッションでその値を変えます。 与えられたLLIDのために有効な固有識別文字でパケットを発生させる能力は送付者だけに、利用可能な秘密の値、または、送付者と、そして、与えられたデータ・ストリームに参加するルータへのアクセスを必要とします。
In contrast, this third technique calls for the authenticator
to be a short term, secret quantity that is carried in the
packet header, without benefit of further protection. In
essence, this technique incorporates a short term "password"
into each packet header. This approach, like its
predecessor, requires that all of the routers validating the
LLID be privy to this authenticator. Moreover, the
authenticator is visible to any other router or other
equipment along the path, and thus this technique is much
more vulnerable than the previous ones.
対照的に、この3番目のテクニックは、固有識別文字が短期間であるように求めます、パケットのヘッダーで運ばれる秘密の量、さらなる保護の恩恵なしで。 本質では、このテクニックは短期間「パスワード」を各パケットのヘッダーに組み入れます。 前任者のように、このアプローチは、LLIDを有効にするルータのすべてがこの固有識別文字に関与しているのを必要とします。 そのうえ、固有識別文字が経路に沿っていかなる他のルータか他の設備にも目に見えて、その結果、このテクニックは前のものよりはるかに傷つきやすいです。
Here the same authenticator may be applied to all packets
with the same LLID, since the authenticator is not a function
of the packet it authenticates. In fact, this suggests that
it is feasible to use the LLID as the authenticator.
However, adopting this tack would not be consistent with the
two previous techniques, each of which requires an explicit,
separate authenticator, and so we recommend against this
optimization.
ここで、同じ固有識別文字は同じLLIDと共にすべてのパケットに適用されるかもしれません、固有識別文字がそれが認証するパケットの機能でないので。 事実上、これは、固有識別文字としてLLIDを使用するのが可能であると示唆します。 しかしながら、このびょうを採用するのは前の2つのテクニックと一致していないでしょう。それはそれぞれ明白で、別々の固有識別文字、および私たちがこの最適化に対して推薦するそうを必要とします。
Nonetheless, the fact that the authenticator is independent
of the packet context makes it trivial to generate (forge)
apparently authentic packets if the authenticator is
intercepted from any legitimate packet. Also, if the
authenticator can be guessed, an attacker need not even
engage in passive wiretapping to defeat this scheme. This
latter observation suggests that the authenticator must be of
sufficient size to make guessing unlikely, and making the
それにもかかわらず、固有識別文字がパケット文脈から独立しているという事実で、固有識別文字がどんな正統のパケットからも傍受されるなら、明らかに正統のパケットを発生させるのは(鍛造します)些細になります。 また、固有識別文字を推測できるなら、攻撃者は、この計画をくつがえすことを消極的盗聴に約束する必要さえありません。 この後者の観測は、固有識別文字が推測をありそうもなくすることができるくらいのサイズがあって、利かせなければならないと示唆します。
Braden, Clark, Crocker & Huitema [Page 27] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[27ページ]RFC1636IABワークショップレポート1994年6月
LLID and the authenticator separate further supports this
requirement.
LLIDと固有識別文字はさらに分離します。この要件を支持します。
The major advantage of this approach is one of performance.
The authenticator can be validated very quickly through a
simple comparison. Consistent with the need to protect
against guessing attacks, the authenticator need not consume
a significant amount of space in the packet header.
このアプローチの主要な利点は1です。性能について。 簡単な比較で非常にすぐに固有識別文字を有効にすることができます。 攻撃を推測しないように保護する必要性と一致しています、固有識別文字はパケットのヘッダーで重要なスペースの合計を消費する必要はありません。
The use of a sequence number visible to the routers is an
interesting technique to explore to make these somewhat
vulnerable methods more robust. If each stream (each source
of packets) numbers its packets, then an intruder attempting
to use the network resource must delete the legitimate
packets, which in many cases would be difficult. Otherwise,
the router being attacked would notice duplicate sequence
numbers and similar anomalies. The exact details of the
numbering would have to be worked out, since for the
legitimate stream packets might be lost, which would cause
holes in the sequence space.
ルータに目に見える一連番号の使用はこれらのいくらか傷つきやすい方法をより強健にするように探るおもしろいテクニックです。 それぞれが次に、パケット、ネットワーク資源を使用するのを試みる侵入者が流さなければならない数を流すなら(パケットの各源)、正統のパケットを削除してください、多くの場合、難しいどれ。 さもなければ、攻撃されるルータは写し一連番号と同様の例外に気付くでしょう。 付番の詳細が以来正統の流れのパケットのために解決されるために持っている正確(系列スペースの穴を引き起こす)は失われるかもしれません。
We do not consider here the issues of collusion, in which a user
with a given LLID and authenticator deliberately shares this with
another unauthorized user. This possibility should be explored,
to see if there is a practical advantage to this act, and thus a
real threat.
私たちはここで共謀の問題を考えません。(そこでは、与えられたLLIDと固有識別文字をもっているユーザが故意に別の権限のないユーザとこれを共有します)。 この可能性は、この行為の実用的な利点、およびその結果本当の脅威があるかどうか確認するために探られるべきです。
4.4 Dynamics of Setup
4.4 セットアップの力学
o Duration of LLID's
o LLIDの持続時間
A key question in the use of LLIDs is how long they remain
valid. At one extreme, they last only a very short time,
perhaps seconds. This limits the damage that can be done if
the authenticator for the LLID is stolen. At the other
extreme, LLIDs are semi-permanent, like credit card numbers.
The techniques proposed above for securing the LLID traded
strength for efficiency, under the assumption that the peril
was limited by the limited validity of the LLID.
LLIDsの使用における肝心かなめの問題は彼らがどれくらい長い間有効なままで残っているかということです。 1つの極端では、それらは非常に短い間、ほんの恐らく秒続きます。 これはLLIDのための固有識別文字が盗まれるなら与えられることができる損害を制限します。 それとは正反対に、LLIDsはクレジットカード番号のように半永久的です。 LLIDを固定するために上で提案されたテクニックは効率のために強さを取り引きしました、危険がLLIDの限られた正当性によって制限されたという仮定で。
The counterbalancing advantage of long-term or semi-permanent
LLIDs is that it becomes practical to use primitive setup
techniques, such as manual configuration of routers to
establish packet classes. This will be important in the
short run, since deployment of security and dynamic resource
allocation protocols may not exactly track in time.
長期的であるか半永久的なLLIDsの釣り合う利点はパケットのクラスを設立するのがルータの手動の構成などの原始のセットアップのテクニックを使用するために実用的になるということです。 これは短期的には重要になるでしょう、セキュリティとダイナミックな資源配分プロトコルの展開が時間内にまさに追跡されないかもしれないので。
Braden, Clark, Crocker & Huitema [Page 28] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[28ページ]RFC1636IABワークショップレポート1994年6月
We conclude that the correct short-term action is to design
LLIDs under the assumption that they are fairly short lived,
and to tolerate, in the short run, a longer period of
validity. This would imply that we will get an acceptable
long-term mechanism in place, which operationally will have a
lower level of security at first. As we get better tools for
automatic setup, we can shorten the duration of validity on a
individual basis, without replacing mechanism in the packet
forwarding path.
私たちは、正しい短期的な動作が彼らが送られた状態でかなり短いという仮定でLLIDsを設計して、短期的にはより長い期間の正当性を許容することであると結論を下します。 これは、私たちが許容できる長期のメカニズムを適所に手に入れるつもりであるのを含意するでしょう(初めに、セキュリティの下のレベルが操作上あるでしょう)。 自動セットアップのための、より良いツールを手に入れるとき、私たちは個々ベースで正当性の持続時間を短くすることができます、パケット推進経路でメカニズムを置き換えないで。
o Setup Latency
o セットアップ潜在
The tradition of the Internet is not to impose any setup
latency in the communication path between end nodes. This
supports the classic datagram model for quick transactions,
etc., and it is a feature that should be preserved.
インターネットの伝統はエンドノードの間の通信路の少しのセットアップ潜在も課さないことです。 これは迅速な取引などのために古典的なデータグラムモデルをサポートします、そして、それは保存されるべきである特徴です。
For setup that is done "in advance", either through a
management interface or by an end-node in the background, the
issue of latency does not arise. The latency issue occurs
for dynamic reservations made in response to a specific
application request.
「あらかじめ」管理インタフェースを通して、または、バックグラウンドにおけるエンドノードで行われるセットアップのために、潜在の問題は起こりません。 潜在問題は特定のアプリケーション要求に対応してされたダイナミックな予約のために起こります。
We observe that while latency is a key issue, it is not
materially influenced by security concerns. The designers of
resource reservation protocols such as RSVP and ST-II are
debating the latency of these protocols today, absent
security. Adding an authenticator to the request message
will increase the processing needed to validate the request,
and might even imply a message exchange with an
authentication service, but should not substantially change
the real time of the setup stage, which might already take
time on the order of a round-trip delay. But the design of
the high level authentication and authorization methods for
the setup protocol should understand that this process, while
not demanding at the level of the per-packet processing, is
still somewhat time-critical.
私たちは、それが潜在が主要な問題である間安全上の配慮によって物質的に影響を及ぼされないのを観測します。 RSVPやST-IIなどの資源予約プロトコルのデザイナーは今日これらのプロトコルの潜在について討論しています、セキュリティなしで。 実質的に既に往復の遅れの注文の時間がかかるかもしれないセットアップステージのリアルタイムを変えるべきでないのを除いて、要求メッセージへの固有識別文字が処理を増加させると言い足すのが、要求を有効にするのが必要であり、認証サービスで交換処理を含意さえするかもしれません。 しかし、セットアッププロトコルのための高い平らな認証と認可方法のデザインは、この過程が1パケットあたりの処理のレベルで要求していない間時間まだいくらかきわどいのを理解するべきです。
One way of dealing with an expensive setup process is to set
up the request provisionally and perform the validation in
the background. This would limit the damage from one bad
setup request to a short period of time. Note, however, that
the system is still vulnerable to an attack that uses a
sequence of setup requests, each of which allows unauthorized
usage for at least a short period of time.
高価なセットアップの過程に対処する1つの方法は、要求を臨時にセットアップして、バックグラウンドにおける合法化を実行することです。 これは1つの悪いセットアップ要求から短期間までの損害を制限するでしょう。 しかしながら、システムがまだそれのそれぞれが少なくとも短期間の間、権限のない用法を許容するセットアップ要求の系列を使用する攻撃に害を被りやすいことに注意してください。
Note also that a denial-of-service attack can be mounted by
flooding the setup process with invalid setup requests, all
無効のセットアップ要求でセットアップの過程をあふれさせることによってサービス不能攻撃を仕掛けることができるというメモすべて、も
Braden, Clark, Crocker & Huitema [Page 29] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[29ページ]RFC1636IABワークショップレポート1994年6月
of which need to be processed and rejected. This could
prevent a valid user from setting up any state. However,
denial-of-service attacks based upon flooding leave very
large "finger prints"; they should not normally be an
important threat. If it is a problem, it may be possible to
incorporate a mechanism at the level of setup processing that
is equivalent to "fair queueing", to limits the damage from a
flooding attack at the packet level.
どれが処理されて、拒絶される必要があるかについて。 これによって、正規ユーザーはどんな状態も設立できないかもしれません。 しかしながら、氾濫に基づくサービス不能攻撃は非常に大きい「指の印刷」を残します。 通常、それらは重要な脅威であるはずがありません。 それが問題であるなら、「公正な待ち行列」に同等なセットアップ処理のレベルでメカニズムを組み込むのは可能であるかもしれません、パケットのフラッディング攻撃からの損害が平らにする限界に。
4.5 Receiver-Initiated Setup
4.5 受信機で開始しているセットアップ
Recent work on a QOS extension for the Internet, embodied in the
RSVP protocol, uses the model that the receiver will reserve
resources. This scheme is consistent with the current IP
multicast paradigm, which requires the receiver to join the
multicast group. The receiver reserves the resources to insure
that the multicast traffic reaches the receiver with the desired
QOS. In this case, it is the credentials (the HLIDs) of the
receivers that will be presented to the setup phase.
RSVPプロトコルに表現されたインターネットが受信機が使用するモデルを使用するので、QOS拡張子での近作はリソースを予約します。 この計画は現在のIPマルチキャストパラダイムと一致しています。(それは、マルチキャストグループに加わるために受信機を必要とします)。 受信機は、マルチキャスト交通が必要なQOSがある受信機に達するのを保障するためにリソースを予約します。 この場合、それはセットアップフェーズに贈られる受信機の信任状(HLIDs)です。
Note that receiver initiation requires an explicit setup phase.
Suppose setup were implicit, driven by pre-existing fields in the
packet. Then there would be no way to associate a packet with a
particular receiver, since in multicast, the address of the
receiver never appears in the packet.
受信機開始が明白なセットアップフェーズを必要とすることに注意してください。 パケットに分野を先在させることによって運転されて、セットアップが暗黙であるなら。 次に、特定の受信機にパケットを関連づける方法が全くないでしょう、マルチキャストに、受信機のアドレスがパケットに決して現れないので。
Further, it is impossible in this case to perform a setup "in
advance", unless the sender and the receiver are very tightly co-
ordinated; otherwise, the receiver will not know in advance what
LLID will be in the packet. It is certainly impossible, in this
case, for the receiver to set up "semi-permanent" reservations for
multicast traffic coming to it. This, again, is not a security
issue; the problem exists without adding security concerns, but
the security architecture must take it into account.
さらに、「あらかじめ」セットアップを実行するのはこの場合不可能です、送付者と受信機がそれほどしっかり共同ordinatedされない場合。 さもなければ、受信機は、あらかじめ、LLIDがパケットで何になるかを知らないでしょう。 確かに、この場合、受信機がそういうことになるマルチキャスト交通の「半永久的な」予約をセットアップするのは、不可能です。 これは再び安全保障問題ではありません。 安全上の配慮を加えないで、問題は存在していますが、セキュリティー体系はそれを考慮に入れなければなりません。
4.6 Other Issues
4.6 他の問題
4.6.1 Encrypting Firewalls and Bypass
4.6.1 ファイアウォールと迂回をコード化すること。
Our view of security, both end node and network protection,
includes the use of firewalls, which partition the network into
regions of more or less trust. This idea has something in
common with the encrypting-firewall model used in the
military/intelligence community: red (trusted) networks
partitioned from black (untrusted) networks. The very
significant difference is that, in the military model, the
partition uses an encryption unit that encodes as much as
possible of the packet for its trip across the black network to
セキュリティに関する私たちの意見(エンドノードとネットワーク保護の両方)はファイアウォールの使用を含んでいます。(ファイアウォールはだいたい信用の範囲にネットワークを仕切ります)。 この考えは軍/情報機関に使用されるコード化しているファイアウォールモデルと共用して心にわだかまりがあります: 赤い(信じられる)ネットワークは黒(信頼されていない)からネットワークを仕切りました。 パーティションが軍用のモデルでそれが旅行のために黒いネットワークの向こう側にパケットをできるだけコード化する暗号化ユニットを使用する非常に重要な違いがあります。
Braden, Clark, Crocker & Huitema [Page 30] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[30ページ]RFC1636IABワークショップレポート1994年6月
another red network. That is, the purpose of the encryption
unit, among others, is to provide a very high degree of
protection against disclosure for data housed within the red
networks. In contrast, our version of a firewall is more to
protect the trusted (red) region of the network from outside
attacks. It is concerned both with what comes in and with what
goes out. It does permit communication between a node on the
trusted and nodes in the untrusted parts of the network.
別の赤いネットワーク。 すなわち、暗号化ユニットの目的は赤いネットワークの中に収容されたデータのための公開に対する非常に高度の保護を特に提供することです。 対照的に、私たちのファイアウォールのバージョンはさらに攻撃の外からネットワークの信じられた(赤い)領域を保護することです。 それは入ることと出かけることに関係があります。 それは信じるところのノードとネットワークの信頼されていない部分のノードとのコミュニケーションを可能にします。
We would like to be able to adapt our model of secure QOS to
the case of military-style encrypting firewalls. However, this
use of encryption raises a problem with our model of secure
resource management, discussed above, which was based on a
two-stage process of setup and classification. This model is
problematic because it requires information to pass from the
red region to the black region in the clear. This information
includes both the setup packets themselves, if setup is done
dynamically from the end node, and the classification fields
(the LLIDs) in the data packets. Obviously, this information
cannot be encrypted when leaving the red region of the network,
since it would then be meaningless to the black net, so that
the black network would be unable to make resource allocation
decisions based on it.
ファイアウォールをコード化しながら、私たちの安全なQOSのモデルを軍事のスタイルに関するケースに適合させたいと思います。 しかしながら、暗号化のこの使用は私たちのセットアップと分類の2ステージの過程に基づいた上で議論した安全な資源管理のモデルと共に問題を提起します。 明確を赤い領域から黒い領域まで通るのが情報を必要とするので、このモデルは問題が多いです。 この情報は両方のセットアップパケット自体を含んでいます、エンドノード、およびデータ・パケットの分類分野(LLIDs)からダイナミックにセットアップするなら。 ネットワークの赤い領域を出るとき、明らかに、この情報をコード化できません、それはその時黒いネットに無意味でしょう、したがって、黒いネットワークが資源配分をそれに基づく決定にすることができないように。
To make this sort of control scheme work, it is necessary for
the encryption device to be programmed to permit certain
packets and fields in packets to pass through the encryptor in
the clear. This bypass of the encryption is considered highly
undesirable. In a high security situation, the process
generating the bypassing information might be corrupted, with
the result that information that should be controlled is
removed from the secure network by hiding it in the bypassed
fields of the packets.
この種類のコントロール計画仕事をするように、暗号化装置が、パケットのあるパケットと分野が明確を暗号化する人を通り抜けることを許可するようにプログラムされるのが必要です。 暗号化のこの迂回は非常に望ましくないと考えられます。 安全度が高い状況では、迂回情報を発生させる過程は崩壊するかもしれません、その結果、制御されるべきである情報が、安全なネットワークからパケットの迂回している分野にそれを隠すことによって、取り除かれます。
We concluded, however, that this bypass problem is not
insurmountable. The key idea, as in all cases of bypass, is to
limit, rather than wholly outlaw, the information passing in
the clear. To limit the information needed for bypass, one can
either perform the setup as a management function totally
within the black environment, or divide the process into two
stages. The first stage, again totally in the black context,
defines a limited number of setup situations. The second stage
involves sending from the red net a very small message that
selects one request to be instantiated from among the pre-
defined set.
しかしながら、私たちは、この迂回問題が打ち勝ちがたくないと結論を下しました。 主要な考えは迂回に関するすべてのケースのように明確で完全に禁止するよりむしろ情報通過を制限することです。 迂回に必要である情報を制限するために、1つは、管理が黒い環境の中で完全に機能するときセットアップを実行するか、または過程を2つのステージに分割できます。 再び完全に黒い文脈では、第一段階は限られた数のセットアップ状況を定義します。 2番目のステージは、赤いネットからあらかじめ定義されたセットから例示されるという1つの要求を選択する非常に小さいメッセージを送ることを伴います。
Perhaps the more difficult issue is the LLID in the packet
header. If the LLID is an explicit field (as we have discussed
恐らく、より難しい問題はパケットのヘッダーのLLIDです。 LLIDが明白な分野である、(私たちは議論しました。
Braden, Clark, Crocker & Huitema [Page 31] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[31ページ]RFC1636IABワークショップレポート1994年6月
so far, but see below), it represents a new field in each
packet, with perhaps as many as 32 bits. Again, the solution
is to limit the way this field can be used. When the end-node
performs a setup, it will specify the value of the LLID to be
used. This fact can be observed by the red/black encryption
unit, which can then limit the components of this field to the
values currently in use. To further improve the situation, the
encryption unit might be able to aggregate a number of flows
onto one flow for the purpose of crossing the black net, which
would permit a further reduction in the number of distinct
LLIDs that must escape the red region.
今までのところ、以下を見てください、)、それは最大恐らく32ビットで各パケットの新しい分野を表します。 一方、解決策はこの分野を使用できる方法を制限することです。 エンドノードがセットアップを実行するとき、それは、使用されるためにLLIDの値を指定するでしょう。 赤の、または、黒い暗号化ユニットはこの事実を観測できます。(次に、それは、この分野のコンポーネントを現在使用中の値に制限できます)。 さらに状況を改良するために、暗号化ユニットは赤い領域から逃げなければならない異なったLLIDsの数の一層の減少を可能にするだろう黒いネットに交差する目的のために1回の流れへの多くの流れに集めることができるかもしれません。
The details of this proposal, including some important issues
such as the time duration of LLIDs in this case, must be
considered further. However, the initial conclusion that
bypass can be incorporated into a general resource control
framework is very encouraging, since it suggests that both
military and commercial forms of security can be built out of
the same building blocks.
さらにこの場合LLIDsの時間持続時間などのいくつかの切迫した課題を含むこの提案の詳細を考えなければなりません。 しかしながら、一般的な資源管理枠組みに迂回を組み入れることができるという初期の結論は非常に励みになっています、同じブロックから軍事の、そして、商業の両方のフォームのセキュリティを築き上げることができるのを示すので。
4.6.2 The Principle of Consistent Privilege
4.6.2 一貫した特権の原則
A well understood principle of security is the principle of
least privilege, which states that a system is most robust when
it is structured to demand the least privilege from its
components.
セキュリティのよく理解されている原則は最少の特権の原則です。(それは、述べます中でそれがコンポーネントから最少の特権を要求するために構造化されるとき、システムがものである最も強健である)。
A related rule we observe is the principle of consistent
privilege. This can be illustrated simply in the case of
denial of service, where it is particularly relevant. For a
particular route, no assumption of service can be justified
unless we trust the routers to deliver the packets. If a
router is corrupted and will not forward packets, the only
solution is to find another route not involving this router.
We do not concern ourselves here with protocols for finding new
routes in the presence of a corrupted router, since this topic
is properly part of another topic, securing the network
infrastructure. We only observe that either we will get
service from the router or we will not. If the router is
corrupted, it does not matter how it chooses to attack us.
Thus, as long as the router is part of a forwarding path (most
generally a multicast forwarding tree), we should not hesitate
to trust it in other ways, such as by giving it shared resource
keys or LLID verifiers.
私たちが守る関連する規則は一貫した特権の原則です。 単にサービスの否定の場合でこれを例証できます。そこでは、それが特に関連しています。 特定のルートにおいて、私たちがパケットを届けるためにルータを信じないなら、サービスの仮定を全く正当化できません。 ルータが崩壊して、パケットを進めないなら、唯一の解決策は別のルートがこのルータを伴っていないのがわかることです。 私たちはここで崩壊したルータがあるとき新しいルートを見つけるためのプロトコルでタッチしません、この話題が別の話題を適切に離れさせることであるので、ネットワークインフラを保証して。 私たちは、私たちがルータからサービスを得るつもりであるか、または得ないつもりであるのを観測するだけです。 ルータが崩壊するなら、それが、私たちを攻撃するのをどのように選ぶか重要ではありません。 したがって、私たちは、ルータが推進経路(最も一般にマルチキャスト推進木)の一部である限り、他の方法でそれを信じるのをためらうべきではありません、共用資源キーかLLID検証をそれに与えるのなどように。
This illustrates the principle of consistent privilege. This
principle is exploited in the scheme for hop-by-hop or pairwise
use of secrets to validate LLIDs in a multicast tree. If a
これは一貫した特権の原則を例証します。 ホップごとの秘密の対状使用がマルチキャスト木でLLIDsを有効にするのにこの原則は計画で利用されます。 aです。
Braden, Clark, Crocker & Huitema [Page 32] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[32ページ]RFC1636IABワークショップレポート1994年6月
single key is issued for the whole tree, then the privilege is
not consistent. We only need to trust a router with respect to
the nodes "below" it in the tree. If it fails to forward
traffic, it can affect only those nodes. But if we give it the
group key, then it can generate bogus traffic and inject it
into the tree at any point, affecting traffic for other parts
of the tree. If, on the other hand, we use pairwise keys, then
a corrupt node can only generate bogus traffic with the key for
traffic it would directly receive, which is the part of the
tree it could damage anyway.
単一のキーは全体の木のために支給されて、次に、特権は一貫していません。 私たちが、ノード“below"に関してルータを信じる必要があるだけである、それ、木で。 交通を進めないなら、それはそれらのノードしか影響できません。 しかし、私たちがグループキーをそれに与えるなら、任意な点でにせの交通を発生させて、木にそれを注ぐことができます、木の他の部分のための交通に影響して。 他方では、私たちが対状キーを使用するなら、改悪されたノードはそれが直接受けるそれがとにかく破損する場合があった木の部分である交通のためのキーによるにせの交通を発生させることができるだけです。
Another requirement we must place on the network concerns
routing. If a firewall is in place, we must trust the routing
architecture not to bypass that firewall. One way to
accomplish this is to eliminate any physical path between the
regions other than those that go through the firewall.
Operational experience will be required to see if this simple
physical limit is an acceptable constraint.
私たちがネットワークに置かなければならない別の要件は、掘るのが関係があります。 ファイアウォールが適所にあるなら、私たちは、そのファイアウォールは迂回させないようにルーティングアーキテクチャを信じなければなりません。 これを達成する1つの方法はファイアウォールに直面しているもの以外の領域の間のどんな物理的な経路もなくします。 運用経験が、この簡単な物理的な限界が許容できる規制であるかどうか確認するのに必要でしょう。
4.6.3 Implicit LLID's
4.6.3 内在しているLLIDのもの
We stress the importance of a strong conceptual distinction
between the addresses in a packet and the LLID which is used to
classify the packet. The conceptual distinction is important,
but under limited circumstances it may be possible to overload
some of the packet fields and create an LLID from the current
packet header. For example, current packet classifiers for
IPv4, which are not secure but which seem to work for
classifying the packets into service classes, use a number of
the packet fields together as a form of LLID: the source and
destination IP addresses and ports plus the protocol type.
私たちはパケットのアドレスとパケットを分類するのに使用されるLLIDの強い概念的な区別の重要性を強調します。 概念的な区別は重要ですが、限られた状況で、いくつかのパケット野原を積みすぎて、現在のパケットのヘッダーからLLIDを作成するのは可能であるかもしれません。 例えば、安全ではありませんが、パケットをサービスのクラスに分類するために働くように思えるIPv4の現在のパケットクラシファイアはLLIDのフォームとして多くのパケット分野を一緒に使用します: ソース、送付先IPアドレス、ポート、およびプロトコルタイプ。
This sort of "implicit" LLID must be short-lived, especially if
the host can change its IP address as it moves. But if the
LLID is established by some sort of dynamic setup protocol, it
should be possible reestablish the LLID as needed.
特に移行するときホストがIPアドレスを変えることができるなら、「暗黙」のLLIDのこの種類は短命であるに違いありません。 しかし、LLIDがある種の動力によって設立されるなら、セットアップは、議定書を作って、必要に応じてLLIDを復職させますそれが可能であるべきである。
The current IPv4 header has no authenticator field to validate
the LLID. An authenticator field could be optionally carried
in an option; adding it gives robustness to network
reservations. Any of the schemes described above for creating
an authenticator could be used, except that if the simple
password-style authenticator is used, it must be an explicit
separate field, since the LLID cannot be picked randomly.
現在のIPv4ヘッダーには、LLIDを有効にする固有識別文字分野が全くありません。 オプションで固有識別文字野原を任意に運ぶことができました。 それを加えると、丈夫さはネットワークの予約に与えられます。 固有識別文字を作成するために上で説明された体系のどれかを使用できました、簡単なパスワードスタイル固有識別文字が使用されているなら、それが明白な別々の分野であるに違いないのを除いて、手当たりしだいにLLIDを選ぶことができないので。
Braden, Clark, Crocker & Huitema [Page 33] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[33ページ]RFC1636IABワークショップレポート1994年6月
4.6.4 Security without Setup
4.6.4 セットアップのないセキュリティ
As we describe this architecture, the setup phase is an
essential part of the sequence. This suggests that the current
Internet, which has no setup protocols, cannot be secured
against denial-of-service attacks. It is important to explore
the limits of this point. As we stressed above, setup can
occur in many ways. Routers today offer management options to
classify packets based on protocol types and other fields found
in the header, and to use this classification to create a few
fair queueing classes that can prevent one class from
overloading the net to the exclusion of the others.
私たちがこのアーキテクチャについて説明するとき、セットアップフェーズは系列の不可欠の部分です。 これは、サービス不能攻撃に対して現在のインターネット(セットアッププロトコルを全く持っていない)を保証できないのを示します。 このポイントの限界について調査するのは重要です。 私たちが上で圧力を加えたように、セットアップは様々な意味で起こることができます。 ルータは、今日、ヘッダーで見つけられたプロトコルタイプと他の分野に基づくパケットを分類して、1つのクラスが他のものを除外してネットを積みすぎるのを防ぐことができる公正な待ち行列の数クラスを創設するのにこの分類を使用するために管理オプションを提供します。
There are two problem here. The first is that for a setup done
using a management interface, the secret that is shared among
the source and the routers to validate the LLID must remain
valid for a long time, and it must be manually configured. The
second problem is that the granularity of the categories may be
coarse. However, it has been proposed, in a thesis by Radia
Perlman, that a router might create a separate fair queueing
class implicitly for each source address. This approach, which
uses the addresses as an implicit LLID, must have some form of
authenticator for robustness. But if the LLID can be trusted,
this scheme provides classification of traffic based only on an
implicit setup operation. The granularity of classification is
not sufficient to provide any QOS distinction. The only
objective is to prevent the traffic from one source from
flooding the net to the exclusion of another.
2問題がここにあります。 1番目は管理インタフェースを使用し終わっているセットアップのためにLLIDを有効にするためにソースとルータの中で共有される秘密が長い間有効なままで残らなければならなくて、手動でそれを構成しなければならないということです。 2番目の問題はカテゴリの粒状が粗いかもしれないということです。 しかしながら、Radiaパールマンによる論文では、ルータが各ソースアドレスのためにそれとなく別々の公正な待ち行列のクラスを創設するかもしれないよう提案されました。 このアプローチ(内在しているLLIDとしてアドレスを使用する)には、丈夫さのための何らかのフォームの固有識別文字がなければなりません。 しかし、LLIDを信じることができるなら、この体系は暗黙のセットアップ操作だけに基づくトラフィックの分類を提供します。 分類の粒状は、どんなQOS区別も提供するために十分ではありません。 唯一の目的は1つのソースからのトラフィックが別のものを除外してネットをあふれさせるのを防ぐことです。
4.6.5 Validating Addresses
4.6.5 アドレスを有効にすること。
We make a claim here that if the LLID and the addresses in the
packet are conceptually distinct, and if there is a suitable
means to validate the LLID, then there is no reason to validate
the addresses. For example, a packet constructed with a false
source address does not seem to represent any security problem,
if its LLID can be validated.
私たちはパケットのLLIDとアドレスが概念的に異なって、LLIDを有効にする適当な手段があればアドレスを有効にする理由が全くないというここでのクレームをします。 例えば、誤ったソースアドレスで組み立てられたパケットはどんな警備上の問題も表すように思えません、LLIDを有効にすることができるなら。
An exception to this might possibly lie in communication with
mobile hosts, but it will require a complete model of threats
and requirements in the mobile environment to be sure.
However, we make the claim, as a starting point for discussion,
that if LLIDs are distinguished from addresses, many of the
security concerns with mobility are mitigated and perhaps
removed. This point should be validated by more detailed
consideration of the mobility problem.
これへの例外がことによるとモバイルホストとのコミュニケーションにあるかもしれませんが、それはモバイル環境における脅威と要件を完全なモデルにいかにも要求するでしょう。 しかしながら、私たちはアドレスとLLIDsを区別するなら、移動性がある安全上の配慮の多くを緩和して、恐らく取り除くという議論のための出発点としてのクレームをします。 このポイントは移動性問題の、より詳細な考慮で有効にされるべきです。
Braden, Clark, Crocker & Huitema [Page 34] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[34ページ]RFC1636IABワークショップレポート1994年6月
4.6 Conclusions
4.6 結論
a) It is important to conceptually separate a LLID (Low-Level
IDentifier) carried in a packet from addresses in the packet.
a) 概念的にパケットでパケットでアドレスから運ばれたLLID(低レベルIDentifier)を切り離すのは重要です。
b) There will be a single LLID carried in each packet. Although
this might imply some additional state in the routers than if
multiple LLIDs were used, using only one LLID choice is more
scalable.
b) 各パケットで運ばれた独身のLLIDがあるでしょう。 これはそうするかもしれませんが、ルータで何らかの追加状態を含意してください。1つのLLID選択だけを使用するのは複数ならLLIDsが使用されたよりスケーラブルです。
c) Hop-by-hop LLID authentication mechanisms might provide a
highly scalable approach that limits the distribution of
secrets. However, the robustness limitations must be
investigated thoroughly.
c) ホップごとのLLID認証機構は秘密の分配を制限する非常にスケーラブルなアプローチを提供するかもしれません。 しかしながら、丈夫さ制限を徹底的に調査しなければなりません。
d) Statistical sampling or after-the-fact detection mechanisms
may be employed by routers to address performance concerns.
d) 統計調査か事実の後の検出メカニズムがルータによって使われて、性能が関心であると扱うかもしれません。
5. AN AUTHENTICATION SERVICE
5. 認証サービス
The purpose of an authentication service is simply to verify names, or more precisely to verify the origin of "messages". It differs from the authorization service, which determines what services are available to an authenticated name. We expect that authentication will be an Internet-wide service, while authorization will be specific to the resources to which access is being authorized.
認証サービスの目的は、単に名前について確かめるか、または、よりまさに「メッセージ」の発生源について確かめることです。 それは承認サービスと異なっています。(それは、どんなサービスが認証された名前に利用可能であるかを決定します)。 私たちは、認証がインターネット全体のサービスであると予想します、承認はアクセスが認可されているリソースに特定になるでしょうが。
This "identification" function can be used in several contexts, for example:
例えば、いくつかの文脈でこの「識別」機能を使用できます:
* One-time passwords: "it is really <huitema@inria.fr> that is
responding to this challenge".
* ワンタイムパスワード: 「それが really <huitema@inria.fr である、gt;、それがこの挑戦に応じている、」
* Access to a firewall: "it is really <huitema@inria.fr> that is
trying to send data to host-A at port-a".
* ファイアウォールへのアクセス: 「それが really <huitema@inria.fr である、gt;、それがAを接待しているポートaにデータを送ろうとしている、」
There are many Internet objects that we may want to name, e.g.,:
命名するかもしれなくたいと思う多くのインターネットオブジェクトが例えばあります:
domain names: sophia.inria.fr
ドメイン名: sophia.inria.fr
machine names: jupiter.inria.fr
名前を機械加工してください: jupiter.inria.fr
service names: www.sophia.inria.fr
(in fact, a data base)
名前を修理してください: www.sophia.inria.fr(事実上、データベース)
users: huitema@sophia.inria.fr
ユーザ: huitema@sophia.inria.fr
Braden, Clark, Crocker & Huitema [Page 35] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[35ページ]RFC1636IABワークショップレポート1994年6月
processes: p112.huitema@sophia.inria.fr
p112.sophia.inria.fr
プロセス: p112.huitema@sophia.inria.fr p112.sophia.inria.fr
universal resource locators:
http//www.sophia.inria.fr:222/tmp/foobar
普遍的なリソースロケータ: http//www.sophia.inria.fr: 222/tmp/foobar
One could be tempted to believe that the authentication service will only be concerned with naming humans, as only humans are "responsible"; a process obtains some access rights because it is acting on behalf of a person. However, this is too reductive and potentially misleading. We may have to authenticate "machines" or hardware components. For example:
1つが、認証サービスは人間を命名するのに関係があるだけであると信じるように誘惑できました、人間だけが「責任がある」とき。 プロセスは、人を代表して行動しているので、いくつかのアクセス権を得ます。 しかしながら、これは、軽減し過ぎていて潜在的に紛らわしいです。 私たちは「マシン」かハードウェアの部品を認証しなければならないかもしれません。 例えば:
* When a machine boots it needs to access resources for
configuring itself, but it is not yet "used" by a person; there
is no user.
* マシンがいつそれをブートするかがそれ自体を構成するためのリソースにアクセスする必要がありますが、それは人によってまだ「使用されていません」。 ユーザは全くいません。
* On a "distributed processor", component CPUs may need to
authenticate each other.
* 「分配されたプロセッサ」では、コンポーネントCPUは、互いを認証する必要があるかもしれません。
Machines do differ from users; machines cannot keep their "secrets" in the same way that people do. However, there is a big value in having a simple and extensible name space.
マシンはユーザと異なっています。 マシンは人々がするのと同じようにそれらの「秘密」を保つことができません。 しかしながら、簡単で広げることができる名前スペースを持つのにおいて大きい値があります。
5.1 Names and Credentials
5.1 名前と資格証明書
We make the hypothesis that the authorization services will
generally use "access control lists" (ACLs), i.e., some definition
of a set of authorized users. A compact way to represent such a
set would be to allow "wildcard" authorizations, e.g., "anybody at
<Bellcore.com>", or "any machine at <INRIA.FR>". The
authentication service should be designed to facilitate the
realization of the authorization service and should support
"wildcards".
私たちは一般に、承認サービスが「アクセスコントロールリスト」(ACLs)を使用するという仮説、すなわち、1セットの認定ユーザの何らかの定義をします。 そのようなセットを表すコンパクトな方法は「ワイルドカード」承認、例えば、「<Bellcore.com>のだれも」、または「<INRIA.FR>のどんなマシンも」を許容するだろうことです。 認証サービスは、承認サービスの実現を容易にするように設計されるべきであり、「ワイルドカード」をサポートするべきです。
However, wildcards are not general enough. Assuming that we have
a hierarchical name space, a wildcarded entry is limited to the
naming hierarchy. For example, a name like
<huitema@sophia.inria.fr> could be matched by the wildcard
<*@sophia.inria.fr> or <*.inria.fr> or <*.fr>. This is useful as
long as one stays at INRIA, but does not solve the generic
problem. Suppose that an IETF file server at CNRI is to be
accessible by all IAB members: its ACL will explicitly list the
members by name.
しかしながら、ワイルドカードは十分一般的ではありません。 私たちには階層的な名前スペースがあると仮定して、wildcardedエントリーは命名階層構造に制限されます。 または、例えば、名前 like <huitema@sophia.inria.fr 、gt;、 wildcard <*@sophia.inria.fr が合わせることができた、gt;、<*.inria.fr>か<*.fr>。 1つがINRIAに滞在していますが、ジェネリック問題を解決しない限り、これは役に立ちます。 すべてのIABメンバーがアクセスしやすくなるようにCNRIのIETFファイルサーバーがそうであると仮定してください: ACLは明らかに名前のメンバーを記載するでしょう。
The classic approach to naming, as exemplified in the X.500 model,
is to consider that people have "distinguished names". Once one
has discovered such a name through some "white pages" service, can
命名へのX.500モデルで例示される古典的なアプローチは人々には「分類名」があると考えることです。 一度、1つは何らかの「ホワイトページ」サービス、缶を通してそのような名前を発見したことがあります。
Braden, Clark, Crocker & Huitema [Page 36] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[36ページ]RFC1636IABワークショップレポート1994年6月
use it as an access key in a global directory service.
アクセスキーとしてグローバルなディレクトリサービスでそれを使用してください。
An individual may acquire authorizations from a variety of
sources. Using a pure, identity-based access control system, the
user would have to acquire multiple identities (i.e.,
distinguished names), corresponding to the roles in which she is
authorized to access different services. We discuss this approach
in the next section.
個人はさまざまなソースから承認を取得するかもしれません。 純粋で、アイデンティティベースのアクセス制御システムを使用して、ユーザは複数のアイデンティティ(すなわち、分類名)を取得しなければならないでしょう、異なったサービスにアクセスするのに彼女に権限を与える役割に対応しています。 私たちは次のセクションでこのアプローチについて議論します。
An alternative approach is for the user to have a very small
number of identities, and to have the grantors of authorizations
issue (signed) credentials granting permissions to the user,
linked to her ID. These additional signed credentials are known
as "capabilities". The user can then establish her identity
through a generic identity credential, e.g., an X.509 certificate,
and can establish authorization by presenting capabilities as
required. This is somewhat analogous to a person acquiring credit
cards linked to the name on a driver's license, and presenting the
appropriate credit card, plus the license for picture verification
of identity.
代替的アプローチは、非常に少ない数のアイデンティティがあって、承認問題(署名される)資格証明書の授与者にユーザで彼女のIDにリンクされたユーザに許可を与えさせることです。 これらの追加署名している資格証明書は「能力」として知られています。 ユーザは、次に、例えば、ジェネリックアイデンティティ資格証明書、X.509証明書を通して彼女のアイデンティティを確立できて、必要に応じて能力を提示することによって、承認を確立できます。 これは運転免許証で名前にリンクされたクレジットカードを入手して、アイデンティティの画像検証のために適切なクレジットカード、およびライセンスを提示する人にいくらか類似しています。
5.2 Identity-Based Authorization
5.2 アイデンティティベースの承認
Let's open the wallet of an average person: we find several
"credit cards" in it. We all have many "credit cards", e.g.,
company cards, credit cards, airline frequent flyers memberships,
driver licenses. Each of these cards is in fact a token asserting
the existence of a relation: the bank certifies that checks
presented by the bearer will be paid, the traffic authorities
certifies that the bearer has learned how to drive, etc. This is
an example of identity-based authorization, in which an individual
is given different names corresponding to different relations
entered into by that individual.
世間一般の人の財布を開けましょう: 私たちはそれで数個の「クレジットカード」を見つけます。 私たちには皆、多くの「クレジットカード」、会社のカード、クレジットカード、エアラインフリークエントフライヤー会員資格、例えば運転免許証があります。 事実上、それぞれのこれらのカードは関係の存在について断言するトークンです: 銀行は、運搬人によって提示された小切手が支払われるのを公認して、トラフィック当局は、運搬人が、どのように運転するかなどを学んだのを公認します。 これはアイデンティティベースの承認に関する例です。(異なった関係との対応がその個人で入った異なった名前はそれで個人に与えられています)。
If we imagine that the name space is based upon DNS (domain)
names, then for example, the person mentioned above could be
authenticated with the names:
私たちが、名前スペースがDNS(ドメイン)名に基づいていると想像するなら、例えば、前記のように人は名前で認証されるかもしれません:
customer@my-big-bank.com
customer@my-big-bank.com
customer@frequent-flyer.airline.com
customer@frequent-flyer.airline.com
The model we used here is that "the name is an association". This
is consistent with name verification procedures, in which that one
builds a "chain of trust" between the user and the "resource
agent". By following a particular path in the trust graph, one
can both establish the trust and show that the user belongs to an
"authorized group".
私たちがここで使用したモデルは「名前は協会です」ということです。 これは名前検証手続と一致しています。(それはユーザと「リソースエージェント」の間に検証手続で「信頼のチェーン」を建てます)。 信頼グラフで特定の経路に続くことによって、人は、信頼を確立して、ユーザが「認可されたグループ」に属すのを示すことができます。
Braden, Clark, Crocker & Huitema [Page 37] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[37ページ]RFC1636IABワークショップレポート1994年6月
The existence of "multiple names" for a person may or may not
imply the existence of an "equivalence" relation. It may be
useful to know that <huitema@sophia.inria.fr> and
<huitema@iab.isoc.org> are two names for the same person, but
there are many cases where the user does not want to make all his
tokens visible.
人のための「複数の名前」の存在は「等価性」関係の存在を含意するかもしれません。 そして、 that <huitema@sophia.inria.fr を知るのが役に立つかもしれない、gt;、<huitema@iab.isoc.org>は同じ人のための2つの名前ですが、多くのケースがユーザが彼のすべてのトークンを目に見えるようにしたがっているというわけではないところにあります。
5.3 Choosing Credentials
5.3 資格証明書を選ぶこと。
Let's consider again the example of Christian Huitema accessing a
file at CNRI. He will have to interact with INRIA's outgoing
firewall and with CNRI's incoming controls. Regardless of whether
authorization depends upon capabilities or upon multiple
association names, a different credential may be needed in each
firewall on the path. For example, assuming multiple names are
used, he will use an INRIA name, <huitema@sophia.inria.fr>, to be
authorized by INRIA to use network resources, and he will use an
IAB name, <huitema@iab.isoc.org>, to access the file server. Thus
comes an obvious problem: how does he choose the credential
appropriate to a particular firewall? More precisely, how does
the computer program that manages the connection discover that it
should use one credential in response to INRIA's firewall
challenge and another in response to CNRI's request?
再び、CNRIでファイルにアクセスするクリスチャンのHuitemaに関する例を考えましょう。 彼はINRIAの出発しているファイアウォールとCNRIの入って来るコントロールで相互作用しなければならないでしょう。 承認が能力か複数の協会名によるかどうかにかかわらず、異なった資格証明書が経路の各ファイアウォールで必要であるかもしれません。 例えば、複数の名前が使用されていると仮定すると、彼はINRIA名を使用するでしょう、 <huitema@sophia.inria.fr 、gt;、INRIAによって認可されるのに、ネットワーク資源を使用してください。そうすれば、彼はIAB名を使用するでしょう、 <huitema@iab.isoc.org 、gt;、ファイルサーバーにアクセスするためにその結果、来る、明白な問題: 彼はどのように特定のファイアウォールに適切な資格証明書を選びますか? より正確に、接続を管理するコンピュータ・プログラムは、それがどのようにINRIAのファイアウォール挑戦と別のものに対応してCNRIの要求に対応して1つの資格証明書を使用するべきであると発見しますか?
There are many possible answers. The program could simply pass
all the user's credentials and let the remote machine pick one.
This works, but poses some efficiency problems: passing all
possible names is bulky, looking through many names is long.
Advertising many names is also very undesirable for privacy and
security reasons: one does not want remote servers to collect
statistics on all the credentials that a particular user may have.
多くの可能な答えがあります。 プログラムで、リモートマシンは、単にすべてのユーザの資格証明書を通過して、1つを選ぶかもしれません。 これは、いくつかの効率問題を扱いますが、引き起こします: すべての可能な名前を通過するのが厖大である、多くの名前に目を通すのは長いです。 また、多くの名前の広告を出すのもプライバシーとセキュリティ理由で全く望ましくありません: 人は、リモートサーバに統計を特定のユーザが持っているかもしれないすべての資格証明書に集めて欲しくはありません。
Another possibility is to let the agent that requests an
authorization pass the set of credentials that it is willing to
accept, e.g., "I am ready to serve CNRI employees and IAB
members". This poses the same privacy and security problems as
the previous solutions, although to a lesser degree. In fact, the
problem of choosing a name is the same as the generic "trust path"
model. The name to choose is merely a path in the authentication
graph, and network specialists are expected to know how to find
paths in graphs.
別の可能性が承認を要求するエージェントにそれが受け入れても構わないと思っている資格証明書のセットを渡させることであり、例えば、「私はCNRI従業員とIABメンバーに役立つ準備ができています」。 より少ない度合いに引き起こしますが、これは前のソリューションとして同じプライバシーと警備上の問題を引き起こします。 事実上、名前を選ぶという問題はジェネリック「信頼経路」がモデル化されるのと同じです。 認証グラフで選ぶ名前は単に経路です、そして、ネットワークスペシャリストがグラフで経路を見つける方法を知ると予想されます。
In the short term, it is probably possible to use a "default name"
or "principal name", at least for local transactions, and to count
on the user to "guess" the credential that is required by remote
services. To leave the local environment we need only the local
credentials; to contact a remote server we need only the
destination credentials. So we need one or maybe two credentials,
短期で、少なくとも地方のトランザクションに「デフォルト名」か「主要な名前」を使用して、ユーザがリモートサービスで必要である資格証明書を「推測すること」を頼りにするのはたぶん可能です。 地方の環境を残すために、私たちは地方の資格証明書だけを必要とします。 リモートサーバに連絡するために、私たちは目的地資格証明書だけを必要とします。 それで、私たちは1か多分2つの資格証明書を必要とします。
Braden, Clark, Crocker & Huitema [Page 38] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[38ページ]RFC1636IABワークショップレポート1994年6月
which may be derived from the destination. It will be very often
the case that the generic credential is enough; then wildcards;
then "FTP provided" tokens.
目的地から派生するかもしれません。 ジェネリック資格証明書はケースですが、それはあるために頻繁に十分望んでいます。 次に、ワイルドカード。 そして、「FTPは提供した」というトークン。
6. OTHER ISSUES
6. 他の問題
6.1 Privacy and Authentication of Multicast Groups
6.1 マルチキャストグループのプライバシーと認証
Multicast applications are becoming an increasingly important part
of Internet communications. Packet voice, video and shared
whiteboard can be powerful productivity tools for users. For
these applications to have maximum value to their users, a variety
of security services will be required.
マルチキャストアプリケーションはインターネット通信のますます重要な部分になっています。 パケット声、ビデオ、および共有されたホワイトボードはユーザのための強力な生産性ツールであるかもしれません。 これらのアプリケーションが彼らのユーザに最大値を持つように、さまざまなセキュリティー・サービスが必要でしょう。
Existing techniques are directly applicable to providing privacy
for a private teleconference. If each member of the conference
shares a single key for a symmetric encryption algorithm (such as
DES), existing point-to-point security techniques can be extended
to protect communication within the group from outsiders.
既存のテクニックは直接個人的な電子会議にプライバシーを提供するのに適切です。 会議の各メンバーが左右対称の暗号化アルゴリズム(DESなどの)のために単一のキーを共有するなら、グループの中に部外者からコミュニケーションを保護するために既存の二地点間セキュリティのテクニックを広げることができます。
However, slight modifications to existing techniques are required
to accommodate the multicast environment. Each packet will
require independent cryptographic processing to ensure that
packets from multiple sources can be independently decrypted by
the numerous receivers, particularly in the presence of lost
packets. N-party authentication and key management will be
required to establish the shared key among the proper group
members. This can be done by extending existing two-party key
management techniques pairwise. For example, the conference
manager may provide the key to each member following individual
authentication; for example, this could be implemented trivially
using PEM technology. The overhead experienced by each host
computer in the conference will be similar to that of existing
point-to-point encryption applications, This overhead is be low
enough that, today, software encryption can offer adequate
performance to secure whiteboard and voice traffic, while hardware
encryption is adequate for video.
しかしながら、既存のテクニックへのわずかな変更が、マルチキャスト環境を収容するのに必要です。 各パケットは多数の受信機で独自に複数のソースからのパケットを解読することができるのを保証するために独立している暗号の処理を必要とするでしょう、特に無くなっているパケットがあるとき。 N-パーティー認証とかぎ管理は適切なグループのメンバーの中に共有されたキーを設立しなければならないでしょう。 2パーティーの既存のかぎ管理テクニック対状を広げることによって、これができます。 例えば、個々の認証に続いて、会議のマネージャはそれぞれのメンバーのキーを提供するかもしれません。 例えば、PEM技術を些細なことに使用することでこれを実装することができるでしょう。 各ホストコンピュータによって会議で経験されたオーバーヘッドが既存の二地点間暗号化アプリケーションのものと同様になる、Thisオーバーヘッドは今日ソフトウェア暗号化がホワイトボードと音声トラヒックを固定する適切な性能を提供できます、ビデオに、ハードウェア暗号化が適切である、しかし、低いことです。
The nature of multicast communication adds an additional
requirement. Existing multicast conferences provide gradual
degradation in quality as the packet loss rate increases. To be
acceptable, authentication protocols must tolerate lost packets.
Techniques to accomplish this efficiently need to be developed.
One initial sketch is outlined below. Engineering work will be
required to validate the practicality of this approach.
マルチキャストコミュニケーションの本質は追加要件を加えます。 パケット損失率が増加するのに応じて、既存のマルチキャスト会議は漸進的な悪化を品質に供給します。 許容できるために、プロトコルが許容しなければならない認証はパケットを失いました。 効率的にこれを達成するテクニックは、開発される必要があります。 1つの初期のスケッチが以下に概説されています。 技術系が、このアプローチの実用性を有効にするのに必要でしょう。
Braden, Clark, Crocker & Huitema [Page 39] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[39ページ]RFC1636IABワークショップレポート1994年6月
The use of symmetric encryption provides the members of the
conference with effective protection from outsiders. However,
because all members of the conference share a single key, it does
not provide a means of authenticating individual conference
members. In principle, existing techniques, based on one-way hash
functions coupled with digital signatures based on asymmetric
encryption algorithms, can provide individual authentication.
One-way hash functions such as MD5 are comparable in cost to
symmetric encryption. However, digital signatures are
considerably more costly, both in computation and in communication
size. The degree of overhead depends on the quality of
authentication required.
左右対称の暗号化の使用は有効保護を部外者から会議のメンバーに提供します。 しかしながら、会議のすべてのメンバーが単一のキーを共有するので、それは個々の加盟会社を認証する手段を提供しません。 原則として、非対称の暗号化アルゴリズムに基づくデジタル署名に結びつけられた一方向ハッシュ関数に基づく既存のテクニックは個々の認証を提供できます。 MD5などの一方向ハッシュ関数は左右対称の暗号化への費用で匹敵しています。 しかしながら、デジタル署名は計算とコミュニケーションサイズでかなり高価です。 オーバーヘッドの度合いは必要である認証の品質に依存します。
In summary, realtime authentication at the granularity of group
membership is easy and cheap, but individual authentication is
costly in time and space. Over time, the costs of both
communications and processing are expected to decline. It is
possible that this will help make authentication at the level of
individual conference participants. There are two conflicting
trends: (1) increasing CPU speeds to provide symmetric
encryption, and (2) increasing communication data rates. If both
technologies increase proportionally, there will be no net gain,
at least if the grain size is measured in terms of bits, rather
than as a period in seconds.
概要では、グループ会員資格の粒状におけるリアルタイムで認証は、簡単であって、安いのですが、個々の認証は時間と空間で高価です。 時間がたつにつれて、コミュニケーションと処理の両方のコストが減退すると予想されます。 これが、個々の会議の参加者のレベルで認証をするのを助けるのは、可能です。 2つの闘争傾向があります: (1) 左右対称の暗号化、および(2)の増加するコミュニケーションデータ信号速度を提供するためにCPU速度を増強します。 両方の技術が比例して増加すると、純益が全くない、少なくとも、粒径は秒に期間としてというよりむしろビットで測定されるのであるかどうか。
The group felt that the correct approach to end-to-end controls is
the use of encryption, as discussed above. The alternative is to
control the ability of a user to join a multicast group as a
listener, or as a speaker. However, we are not comfortable with
the level of assurance that we can offer if we attempt to ensure
end-to-end semantics using these means. Any passive penetration
of the network, i.e., any wire-tap, can compromise the privacy of
the transmitted information. We must acknowledge, however, that
problems with deployment of encryption code and hardware, and
especially problems of export controls, will create a pressure to
use the tools described in Section 4 to implement a form of end-
to-end control. Such a decision would raise no new issues in
security technology. The shared key now used for encrypting the
data could instead be used as the basis for authenticating a
multicast group join request. This would require modification of
the multicast packet format, but nothing more. Our concern is not
the technical difficulty of this approach, but the level of
assurance we can offer the user.
グループは、上で議論するように終わりからエンドへのコントロールへの正しいアプローチが暗号化の使用であると感じました。 代替手段はユーザがリスナーとして、または、スピーカーとしてマルチキャストグループに加わる能力を制御することです。 しかしながら、これらの手段を使用することで終わりから終わりへの意味論を確実にするのを試みるなら、私たちは私たちが提供できる保証のレベルに満足ではありません。 ネットワークのどんな受け身の侵入(すなわちどんな盗聴も)も伝達情報量のプライバシーに感染することができます。 しかしながら、私たちは、暗号化コードとハードウェアの展開、および特に輸出管理の問題に関する問題が終わりまでのエンドコントロールのフォームを実装するためにセクション4で説明されたツールを使用する圧力を引き起こすと認めなければなりません。 そのような決定はセキュリティー技術で新規発行を全く提起しないでしょう。 マルチキャストグループを認証する基礎が要求に参加するとき、代わりに現在データを暗号化するのに使用されている共有されたキーは使用できました。 これはしかし、マルチキャストパケット・フォーマット、それ以上何もの変更を必要とするでしょう。 私たちの関心はこのアプローチの技術的困難ではなく、私たちがユーザを提供できる保証のレベルです。
Braden, Clark, Crocker & Huitema [Page 40] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[40ページ]RFC1636IABワークショップレポート1994年6月
6.2 Secure Plug-and-Play a Must
6.2 安全なPlug and Play絶対に必要なもの
Plug-and-play is the ability to plug a new device into a network
and have it obtain the information it needs to communicate with
other devices, without requiring any new configuration
information. Secure plug-and-play is an important Internet
requirement, and a central architectural issue is whether it can
be made to scale well.
プラグアンドプレイは新しいデバイスのネットワークにプラグを差し込んで、それが対向機器とコミュニケートする必要がある情報を得させる能力です、新しい設定情報を必要としないで。 安全なプラグアンドプレイは重要なインターネット要件です、そして、主要な構造的な問題はよく比例させられることができるかどうかということです。
For plug-and-play operation, a new machine that is "plugged" into
the network needs to:
プラグアンドプレイ操作のために、ネットワークに「ふさがれる」新しいマシンは、以下のこと必要があります。
(1) Obtain an locator so it can communicate with other devices
(1) 対向機器とコミュニケートできるようにロケータを得てください。
(2) Register or obtain a name to be identified by (e.g., machine
name)
(2) 特定される名前を登録するか、または得てください。(例えば、マシン名)
(3) Discover services available on the network (e.g., printers,
routers, file servers, etc.)
(3) ネットワークで利用可能なサービスを発見してください。(例えば、プリンタ、ルータ、ファイルサーバーなど)
(4) Discover other systems on the network so it can communicate
with them.
(4) それが彼らとコミュニケートできるように、ネットワークで他のシステムを発見してください。
In some environments, no security mechanisms are required because
physical security and local knowledge of the users are sufficient
protection. At the other end of the spectrum is a large network
with many groups of users, different types of outside connections,
and levels of administrative control. In such environments,
similar plug-and-play capabilities are needed, but the new device
must be "authenticated" before it can perform these functions. In
each step in the discovery process the new device must
authenticate itself prior to learning about services.
いくつかの環境で、ユーザに関する物理的なセキュリティと局所的知識が十分な保護であるので、セキュリティー対策は全く必要ではありません。 範囲内で対照的に一方の側に、大きいネットワークがユーザ(異なったタイプの外部の接続、およびレベルの運営管理コントロール)の多くのグループと共にあります。 そのような環境で、同様のプラグアンドプレイ能力が必要ですが、これらの機能を実行できる前に新しいデバイスは「認証されなければなりません」。 発見プロセスの各ステップでは、新しいデバイスはサービスに関して学ぶ前に、それ自体を認証しなければなりません。
The steps might be:
ステップは以下の通りです。
- Obtain a HLID from a smart card, smart disk, or similar
device.
- スマートカード、賢いディスク、または同様のデバイスからHLIDを入手してください。
- Authenticate itself with the first plug-and-play server using
its HLID, to register a name and to find the location of
other services.
- 名前を登録して、他のサービスの位置を見つけるのにHLIDを使用して、最初のプラグアンドプレイサーバでそれ自体を認証してください。
- Discover services available on the network (e.g., printers,
routers, file servers, etc.) based on its HLID.
- HLIDに基づくネットワーク(例えば、プリンタ、ルータ、ファイルサーバーなど)で利用可能なサービスを発見してください。
- Discover other systems on the network so it can communicate
with them.
- それが彼らとコミュニケートできるように、ネットワークで他のシステムを発見してください。
Braden, Clark, Crocker & Huitema [Page 41] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[41ページ]RFC1636IABワークショップレポート1994年6月
The problem of taking a system out of the box and initially
configuring it is similar to the problem of a mobile or portable
machine that a human wants to connect to a local network
temporarily in order to receive services on that network. How can
the local network authenticate the human (and therefore the
human's machine) and know which services this visiting machine is
permitted to use?
創造的にシステムを取って、初めはそれを構成するという問題は人間がそのネットワークでサービスを受けるために一時企業内情報通信網に接続したがっているというモバイルの、または、携帯用のマシンの問題と同様です。 企業内情報通信網は、どうしたら人間(そして、したがって、人間のマシン)を認証して、この訪問マシンがどのサービスを使用することが許可されているかを知ることができますか?
The human must be endowed with a high level identifier (HLID)
which acts as his/her passport and can be verified by the local
network. This high level identifier must be globally unique and
registered/assigned by some recognized authority.
人間をその人のパスポートとして機能する高い平らな識別子(HLID)を寄付しなければならなくて、企業内情報通信網は確かめることができます。 何らかの認識された権威でこの高い平らな識別子をグローバルにユニークであり、登録されなければならないか、または割り当てなければなりません。
When the human plugs the machine onto a local net, the machine
identifies itself to the net with the human's high level
identifier. If local net has a policy of permitting anyone to
plug and play on its network, it will ignore the HLID and assign
an address (locator), permitting the visitor unrestricted access
and privileges. More likely, the local net will authenticate the
HLID prior to granting the visitor an address or any privileges.
人間がローカルのネットにマシンを差し込むとき、マシンは人間の高い平らな識別子でネットにそれ自体を特定します。 ローカルのネットにだれでもネットワークで働いて、プレーすることを許可する方針があると、HLIDを無視して、アドレス(ロケータ)を割り当てるでしょう、訪問者の無制限なアクセスと特権を可能にして。 おそらく、アドレスかどんな特権も訪問者に与える前に、ローカルのネットはHLIDを認証するでしょう。
At this point, the HLID has only authenticated the visitor to the
local network; the issue of which services or resources the
visitor is entitled to use has not been addressed. It is
desirable to develop a low-overhead approach to granting
authentications to new users. This will help in the case of
visitors to a site, as well as new users joining a facility.
ここに、HLIDは企業内情報通信網に訪問者を認証するだけでした。 訪問者がどのサービスかリソースを使用する権利を与えられるかに関する問題は扱われていません。 新しいユーザの認証を承諾することへの低いオーバーヘッドアプローチを開発するのは望ましいです。 これは訪問者の場合でサイト、および施設に加わる新しいユーザに助けるでしょう。
6.3 A Short-Term Confidentiality Mechanism
6.3 短期的な秘密性メカニズム
Authentication has customarily been achieved using passwords. In
the absence of active attacks, the greatest threat to computer
system security may be the ease with which passwords can be
"snooped" by the promiscuous monitoring of shared-media networks.
There are known security techniques for achieving authentication
without exposing passwords to interception, for example the
techniques implemented in the well-known Kerberos system.
However, authentication systems such as Kerberos currently operate
only in isolation within organizational boundaries. Developing
and deploying a global authentication infrastructure is an
important objective, but it will take some years. Another useful
approach in the short term is the use of a challenge-response user
authentication scheme (e.g., S/Key).
認証は、パスワードを使用することで通例に達成されました。 活発な攻撃がないとき、コンピュータ・システムセキュリティへの最大の脅威は共有されたマスメディア網の無差別なモニターでパスワードについて「詮索できる」容易さであるかもしれません。 妨害(例えばよく知られるケルベロスシステムで実装されたテクニック)にパスワードを暴露しないで認証を達成するためのセキュリティのテクニックは知られています。 しかしながら、ケルベロスなどの認証システムは現在、分離して組織境界だけの中で作動します。 グローバルな認証インフラストラクチャを開発して、配布するのは、重要な目的ですが、それは数年かかるでしょう。 別の役に立つアプローチは短期で、チャレンジレスポンスユーザー認証体系(例えば、S/キー)の使用です。
One of the groups explored another interim approach to guarding
passwords: introducing a readily-used confidentiality mechanism
based on an encrypted TCP connection. This would operate at the
IP level to encrypt the IP payload, including the TCP header, to
グループの1つはパスワードを警備することへの別の当座のアプローチについて調査しました: 暗号化されたTCP接続に基づく容易に使用された秘密性メカニズムを紹介します。 これはIPでTCPヘッダーを含むIPペイロードを暗号化するために平らな状態で作動するでしょう。
Braden, Clark, Crocker & Huitema [Page 42] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[42ページ]RFC1636IABワークショップレポート1994年6月
allow the nature as well of the contents of the communication to
be kept private. It could be implemented to provide either
"strict" protection (the connection fails if the other side cannot
decrypt your data stream) or "loose" protection (falling back to
non-private TCP if decryption fails).
また、コミュニケーションのコンテンツの本質は個人的に保たされてください。 「厳しい」保護(反対側があなたのデータ・ストリームを解読することができないなら、接続は失敗する)か「ゆるい」保護のどちらかを提供するためにそれを実装することができました(復号化が失敗するなら非個人的なTCPへ後ろへ下がって)。
Loose protection would allow interoperability with older hosts in
a seamless (non-user-intrusive) manner.
ゆるい保護がシームレスの、より年取ったホストと共に相互運用性を許容するだろう、(非ユーザ押しつけがましい、)、方法。
One-time keys may be exchanged during the SYN handshake that
starts the TCP connection. Using one-time keys avoids a need for
infrastructure support and does not require trust between the
organizations on the two ends of the connection. Tieing the key
exchange to the SYN handshake will avoid the possibility of having
the connection fully open without knowing the state of encryption
on both ends of the connection. Although it may still be
theoretically possible to intercept the SYN exchange and subvert
the connection by an active "man-in-the-middle" attack, in
practice such attacks on TCP connections are quite difficult
unless the routing protocols have been subverted.
TCP接続を始めるSYN握手の間、1回のキーを交換するかもしれません。 1回のキーを使用するのは、インフラ支援の必要性を避けて、接続の2つの終わりで組織の間の信頼を必要としません。 SYN握手への主要な交換をTieingすると、接続の両端で暗号化の状態を知らないで完全にオープンな接続がある可能性は避けられるでしょう。 実際には活発な「中央の男性」攻撃でSYN交換を妨害して、接続を打倒するのがまだ理論的に可能であるかもしれませんが、ルーティング・プロトコルが打倒されていないなら、TCP接続に対するそのような攻撃はかなり難しいです。
The keys could be exchanged using a new option that specifies the
key exchange protocol, the data encryption algorithm, and the key
to be used to decrypt the connection. It could be possible to
include multiple options in the same SYN segment, specifying
different encryption models; the far end would then need to
acknowledge the option that it is willing to use. In this case,
the lack of an acknowledgement would imply disinterest in
decrypting the datastream. If a loose privacy policy were in
force, the connection could continue even without an
acknowledgment. The policy, "strict" or "loose", would be set by
either the user or the default configuration for the machine.
接続を解読するのに使用されるために主要な交換プロトコル、データ暗号化アルゴリズム、およびキーを指定する新しいオプションを使用することでキーを交換できるでしょう。 異なった暗号化モデルを指定して、同じSYNセグメントで複数のオプションを含んでいるのは可能であるかもしれません。 そして、遠端は、それが使用しても構わないと思っているオプションを承諾する必要があるでしょう。 この場合、承認の不足はdatastreamを解読する際に公平無私を含意するでしょう。 ゆるいプライバシーに関する方針が有効であるなら、接続は承認がなくても続くことができるでしょうに。 「厳しい」か「ゆるい」方針は、マシンのためのユーザかデフォルト設定のどちらかによって設定されるでしょう。
One must however observe that a TCP option can carry only a
limited amount of data. Efficient protection against crypto-
analysis of the Diffie-Hellmann scheme may require the use of a
very long modulus, e.g., 1024 bits, which cannot be carried in the
40 bytes available for TCP options. One would thus have either to
define an "extended option" format or to implement encryption in a
separate protocol layered between TCP and IP, perhaps using a
version of "IP security". The detailed engineering of such a
solution would have to be studied by a working group.
しかしながら、TCPオプションが限られた量のデータしか運ぶことができないのを観測しなければなりません。 ディフィー-ヘルマン体系の暗号分析に対する効率的な保護は非常に長い係数、例えばTCPオプションに有効な40バイトで運ぶことができない1024ビットの使用を必要とするかもしれません。 1つには、その結果、「拡張オプション」書式を定義するか、またはTCPとIPの間で層にされた別々のプロトコルにおける暗号化を実装するどちらかがあるでしょう、恐らく「IPセキュリティ」のバージョンを使用して。 そのようなソリューションの詳細な工学はワーキンググループによって研究されなければならないでしょう。
A TCP connection encryption mechanism such as that just outlined
requires no application changes, although it does require kernel
changes. It has important drawbacks, including failure to provide
privacy for privacy for UDP, and the great likelihood of export
control restrictions. If Diffie-Hellman were used, there would
カーネル変化を必要としますが、ただ概説されたそれなどのTCP接続暗号化メカニズムはアプリケーション変化を全く必要としません。 それには、重要な欠点があります、UDPのためにプライバシーをプライバシーに提供しないこと、および輸出管理制限のすばらしい見込みを含んでいて。 ディフィー-ヘルマンはそこで使用されたでしょう。
Braden, Clark, Crocker & Huitema [Page 43] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[43ページ]RFC1636IABワークショップレポート1994年6月
also be patent issues.
また、特許問題になってください。
7. CONCLUSIONS
7. 結論
As a practical matter, security must be added to the Internet incrementally. For example, a scheme that requires, as a precondition for any improvement, changes to application code, the DNS, routers and firewalls all at once will be very hard to deploy. One of the reasons the workshop explored schemes that are local to the IP layer is that we surmise that they might be easier to deploy in practice.
実際問題として、インターネットにセキュリティを増加して加えなければなりません。 例えば、どんな改良のための前提条件としても応用コードへの変化、DNS、ルータ、およびファイアウォールを必要とする体系は一気に非常に配布しにくいようになるでしょう。 ワークショップがIP層に地方であることの体系について調査した理由の1つは私たちが、それらは実際には配布するのが、より簡単であるかもしれないことを推量するということです。
There are two competing observations that must shape planning for Internet security. One is the well known expression: "the best is the enemy of the good." The other is the observation that the attacks are getting better.
インターネットセキュリティのために計画しながら形成されなければならない2つの競争している観測があります。 1つはよく知られている表現です: 「ベストは利益の敵です。」 もう片方は攻撃に改善されているという観測です。
Finally, it should noted that the principle of least privilege, which was mentioned above, may be in contradiction to the principle of least cost.
最終的にそれは注意するべきです。上に言及された最少特権の原則が最小費用の原則に反しているかもしれないことに注意しました。
7.1 Suggested Short-Term Actions
7.1 提案された短期的な動作
The general recommendation for short-term Internet security policy
was that the IETF should make a list of desirable short-term
actions and then reach out to work with other organizations to
carry them out. Other organizations include regionals, which may
be in a good position to provide site security counseling services
to their customers, vendors and other providers, and other
societies. We should also give input to the US government to
influence their posture on security in the direction desired by
the community.
短期的なインターネット安全保障政策のための一般的な推薦はIETFが望ましい短期的な動作のリストを作って、次に、それらを行うために他の組織による仕事と連絡を取ろうと試みるはずであるということでした。 他の組織は地方版と他の社会を含んでいます。(地方版が彼らの顧客、業者、および他のプロバイダーにサイトセキュリティカウンセリング・サービスを提供する良い立場にあるかもしれません)。 また、私たちは、共同体のそばで必要な指示に基づくセキュリティのそれらの姿勢に影響を及ぼすために米国政府に入力を与えるべきです。
A suggested preliminary list of short-term actions was developed.
短期的な動作の提案された予備のリストは開発されました。
o Perform external diagnostic security probes
o 外部の診断セキュリティ探測装置を実行してください。
Organizations should be encouraged to use CRACK and other
tools to check the robustness of their own passwords. It
would also be useful to run a variety of security probes from
outside. Since this is a very sensitive issue, some care
needs to be taken to get the proper auspices for such
probing.
組織がCRACKとそれら自身のパスワードの丈夫さをチェックする他の道具を使用するよう奨励されるべきです。 また、外部からさまざまなセキュリティ探測装置を動かすのも役に立つでしょう。 これが非常に敏感な問題であるので、何らかの注意が、そのような調べのための適切な前兆を得るために取られる必要があります。
Braden, Clark, Crocker & Huitema [Page 44] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[44ページ]RFC1636IABワークショップレポート1994年6月
Useful probe tools include:
役に立つ徹底的調査ツールは:
ISS: Klaus (GA)
SATAN: Farmer Venema
ICEPICK: NRL
ISS: クラウス(ジョージア)魔王: 農業者Venema ICEPICK: NRL
o Determine Security-Risk Publication Channels
o 危険人物公開チャネルを決定してください。
What channels should be used for disseminating information of
security risks?
どんなチャンネルが、セキュリティリスクの情報を広めるのに使用されるべきですか?
o Encourage use of one-time passwords.
o ワンタイムパスワードの使用を奨励してください。
Available packages: S/Key, SecurID, Enigma, Digital Pathways.
利用可能なパッケージ: S/キー、SecurID、謎、デジタル小道。
o Develop and publish guidelines for protocol developers, for
security-friendliness and firewall-friendliness.
o プロトコル開発者、セキュリティ友情とファイアウォール友情のためのガイドラインを開発して、発表してください。
o Control topology to isolate threats
o トポロジーを制御して、脅威を隔離してください。
o Set privacy policy:
o プライバシーに関する方針を設定してください:
* Always
* いつも
* As much as possible
* できるだけ
o Bring Site Security Handbook up to date
o Site Security Handbookを最新の状態にしてください。
o Support use of Kerberos
o ケルベロスのサポート使用
The subject of the "Clipper chip" came up several times, but there
was not sufficient discussion of this very complex issue for this
grouip to reach a recommendation. It has been observed that there
are a number of quite differing viewpoints about Clipper.
「クリッパーチップ」の対象は何度か来ましたが、このgrouipが推薦に達するように、この非常に複雑な問題の十分な議論はありませんでした。 Clipperに関して多くのかなり異なった観点があるのが観測されました。
o Some people accept the government's Clipper proposal,
including key escrow by the US government and the
requirement that encryption be in hardware.
o 何人かの人々が政府のClipper提案を受け入れます、暗号化がハードウェアにある米国政府と要件でキーエスクローを含んでいて。
o Some people don't mind key escrow by the government in
principle, but the object to the hardware requirement.
o 人々の中には原則として政府でキーエスクローを気にするのではなく、物をハードウェア要件に気にする人もいます。
o Some people don't mind key escrow in principle, but
don't want the government to hold the keys. They would
be comfortable with having the organization which owns
the data hold the keys.
o 人々の中には、原則としてキーエスクローを気にしませんが、政府が鍵を握って欲しくない人もいます。 彼らはデータを所有している組織を鍵を握らせるのに快適でしょう。
o Some people don't want key escrow at all.
o 全くキーエスクローが欲しくない人々もいます。
Braden, Clark, Crocker & Huitema [Page 45] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[45ページ]RFC1636IABワークショップレポート1994年6月
o Some people don't mind the hardware or the key escrow,
but they don't think this will be acceptable to other
countries and thus will not work internationally.
o 何人かの人々がハードウェアかキーエスクローを気にしませんが、彼らは、これが他国に許容できるようになると思わないで、またその結果、国際的に働かないでしょう。
This report takes no position on any of these viewpoints.
このレポートはこれらの観点のどれかの立場を全く取りません。
7.2 Suggested Medium-Term Actions
7.2 提案された中期動作
These actions require some protocol design or modification;
however, they use existing security technology and require no
research.
これらの動作は何らかのプロトコルデザインか変更を必要とします。 しかしながら、彼らは、既存のセキュリティー技術を使用して、研究を全く必要としません。
o Authentication Protocol
o 認証プロトコル
There is a problem of the choice of technology. Public key
technology is generally deemed superior, but it is patented
and can also induce relatively long computations. Symmetric
key technology (Needham-Schroeder algorithm, as used in
Kerberos) has some technical drawbacks but it is not
patented. A system based on symmetric keys and used only for
authentication would be freely exportable without being
subject to patents.
技術の選択の問題があります。 一般に、公開鍵技術が優れていると考えられますが、それは、特許をとられて、また、比較的長い計算を引き起こすことができます。 (ニーダム-シュローダーアルゴリズムで、ケルベロスで中古)の対称鍵技術には、いくつかの技術的な欠点がありますが、それは特許をとられません。 対称鍵に基づいていて、認証にだけ使用されるシステムは特許を条件として自由に輸出向きでしょう存在なしで。
o Push Kerberos
o ケルベロスを押してください。
Engineering is needed on Kerberos to allow it to interoperate
with mechanisms that use public key cryptography.
工学が、それが公開鍵暗号を使用するメカニズムで共同利用するのを許容するのにケルベロスで必要です。
o Push PEM/RIPEM/PGP...
o PEM/RIPEM/PGPを押してください…
o Develop an authenticated DNS
o 認証されたDNSを開発してください。
o Develop a key management mechanism
o かぎ管理メカニズムを開発してください。
o Set up a certificate server infrastructure
o 証明書サーバインフラストラクチャをセットアップしてください。
Possible server mechanisms include the DNS, Finger, SNMP,
Email, Web, and FTP.
可能なサーバメカニズムはDNS、Finger、SNMP、メール、ウェブ、およびFTPを含んでいます。
o Engineer authentication for the Web
o ウェブのための技術者認証
7.3 Suggested Long-Term Actions
7.3 提案された長期の動作
In this category, we have situations where a threat has been
identified and solutions are imaginable, but closure has not been
reached on the principles.
このカテゴリでは、私たちは脅威が特定されて、解決策が想像可能ですが、閉鎖に原則で達していない状況を持っています。
Braden, Clark, Crocker & Huitema [Page 46] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[46ページ]RFC1636IABワークショップレポート1994年6月
o Executable Apps
o 実行可能なアプリケーション
o Router sabotage counter-measures
o ルータサボタージュ対応策
o Prevent Byzantine routing.
o 込み入ったルーティングを防いでください。
o Proxy Computing
o プロキシコンピューティング
o Decomposition of computers
o コンピュータの分解
o Are there "good" viruses?
o 「良い」ウイルスがありますか?
Braden, Clark, Crocker & Huitema [Page 47] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[47ページ]RFC1636IABワークショップレポート1994年6月
APPENDIX A -- Workshop Organization
付録A--ワークショップ組織
The following list of attendees indicates also the breakout group to which they were assigned.
また、出席者の以下のリストは彼らが配属された脱走グループを示します。
Breakout Groups
脱走グループ
Group I.1 Leader: 1 Christian Huitema, INRIA (IAB)
I.1リーダーを分類してください: 1 クリスチャンのHuitema、INRIA(IAB)
1 Steve Bellovin, AT&T 1 Bob Braden, ISI (IAB) 1 John Curran, NEARNET 1 Phill Gross, ANS (IETF/IAB) 1 Stev Knowles, FTP Software (Internet AD) 1 Barry Leiner, USRA (IAB) 1 Paul Mockapetris, ISI 1 Yakov Rekhter, IBM (IAB) 1 Dave Sincoskie, Bellcore (IAB)
1 スティーブBellovin、AT&T1のボブ・ブレーデン、ISI(IAB)1ジョン・カラン、NEARNET1フィルGross、ANS(IETF/IAB)1Stevノウルズ、1FTPソフトウェア(インターネットAD)バリトンサックスLeiner、USRA(IAB)1ポールMockapetris、ISI1ヤコフRekhter、IBM(IAB)1デーヴSincoskie、Bellcore(IAB)
Group I.2 Leader: 2 Steve Crocker, TIS (Security AD)
I.2リーダーを分類してください: 2 スティーブ・クロッカー、TIS(セキュリティAD)
2 Jon Crowcroft 2 Steve Deering, PARC 2 Paul Francis, NTT 2 Van Jacobson, LBL 2 Phil Karn, Qualcomm 2 Allison Mankin, NRL (Transport AD, IPng AD) 2 Radia Perlman, Novell 2 John Romkey, ELF (IAB) 2 Mike StJohns, ARPA (IAB)
2 ジョン・クロウクロフト2・スティーブ・デアリング、PARC2ポール・フランシス、NTT2はジェーコブソンをバンに積みます、LBL2フィルKarn、クアルコム2のアリソン・マンキン、NRL(ADを輸送してください、IPng AD)2Radiaパールマン、ノベル2ジョンRomkey、小妖精(IAB)2マイクStJohns、アルパ(IAB)
Group I.3 Leader: 3 Dave Clark, MIT
I.3リーダーを分類してください: 3 デーブ・クラーク、MIT
3 Deborah Estrin, USC 3 Elise Gerich, Merit (IAB) 3 Steve Kent, BBN (IAB) 3 Tony Lauck, DEC (IAB) 3 Tony Li, CISCO 3 Bob Hinden, Sun (IESG->IAB liaison, Routing AD) 3 Jun Murai, WIDE (IAB) 3 Scott Shenker, PARC 3 Abel Weinrib, Bellcore
3デボラEstrin、USC3エリーズGerich、Merit(IAB)3スティーブ・ケント、BBN(IAB)3トニーLauck、12月の(IAB)3トニー・李、シスコ3ボブHinden、Sun、(IESG、-、>IAB連絡、村井、WIDE(IAB)3スコットShenker、PARC3アベルWeinrib、ルート設定AD) 6月3日のBellcore
The following were able to attend only the third day, due to a conflicting ISOC Board of Trustees meeting:
以下は3日目だけにTrusteesミーティングの闘争ISOC Boardのため出席できました:
Braden, Clark, Crocker & Huitema [Page 48] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[48ページ]RFC1636IABワークショップレポート1994年6月
Scott Bradner, Harvard (IPng AD)
Jon Postel, ISI (IAB)
スコット・ブラドナー、ハーバード(IPng AD)のジョン・ポステル、ISI(IAB)
The workshop agenda was as follows.
ワークショップ議題は以下の通りでした。
Tues Feb 8
9:00 - 10:30 Plenary
Discuss facilities, meeting goals, agenda, organization.
Establish some minimal common understandings. Assign
scenarios to Breakout I groups.
2月8日火曜日の9:00--10:30のPlenary Discuss施設、ミーティング目標、議題、組織。 いくつかの最小量の一般的な疎通を確立してください。 私が分類するBreakoutにシナリオを割り当ててください。
10:30 - 13:00 Breakout I meetings
Each breakout group examine one or more scenarios and
formulate a list of design questions. Lunch available on
11th floor.
10:30、--、13:00、脱走IミーティングEach脱走グループは、1つ以上のシナリオを調べて、デザイン質問のリストを定式化します。 11階で利用可能な昼食。
13:00 - 15:00 Plenary
Report, discuss. Collate and shorten list of design
issues. Organize Breakout II groups to work on these
issues.
13:00--15:00の絶対的なReport、議論します。 デザイン問題のリストを照合して、短くしてください。 Breakout IIグループがこれらの問題に働くのを組織化してください。
15:00 - 17:30 Breakout IIa meetings
Work on design issues.
デザイン問題の15:00--17:30脱走IIaミーティングWork。
Wed Feb 9
9:00 - 10:00 Plenary
Report, discuss.
2月9日水曜日の9:00--10:00Plenary Report、議論します。
10:00 - 13:30 Breakout IIb meetings
More work on design questions, develop list of
requirements.
10:00、--、13:30、脱走IIbミーティングMoreはデザイン質問に取り組んで、要件のリストを開発してください。
13:30 - 14:30 Plenary
Report, discuss.
13:30--14:30の絶対的なReport、議論します。
15:30 - 17:30 Breakout III groups
15:30--17:30脱走IIIグループ
Thurs Feb 10
9:00 - 9:30 Plenary
2月10日の9:00木曜日から9:30まで絶対的です。
9:30 - 11:00 Breakout Groups (wrapup)
9:30--11:00の脱走グループ(wrapup)
11:00 - 12:00 Plenary
Discuss possible short-term security recommendations
11:00--12:00の絶対的なDiscuss可能な政府短期証券推薦
13:00 - 14:00 Plenary -- Discuss short-term security issues
13:00(14:00絶対的である)は政府短期証券問題について議論します。
14:00 - 14:30 Plenary -- Presentation by Steve Bellovin
14:00--14:30 絶対的--、スティーブBellovinによるプレゼンテーション
Braden, Clark, Crocker & Huitema [Page 49] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[49ページ]RFC1636IABワークショップレポート1994年6月
14:30 - 16:00 Plenary -- Long- and Medium-term
Recommendations
: 16:00絶対的な30が切望する14と中期推薦
The following scenarios were used as a starting point for discussions. It distinguished security-S (security as a service to the end systems) from security-M, security as a mechanism to support other services. The workshop was intended to be primarily concerned with interactions among the following different *services*:
以下のシナリオは議論に出発点として使用されました。 それはセキュリティM(他のサービスを支持するメカニズムとしてのセキュリティ)からのセキュリティS(エンドシステムに対するサービスとしてのセキュリティ)を区別しました。 ワークショップが主として以下の異なった*サービス*の中の相互作用に関係があることを意図しました:
o Security-S
o セキュリティS
o Routing
o ルート設定
o Multi-destination delivery (mcast-S)
o マルチの目的地配送(mcast-S)
o Realtime Packet scheduling (realtime)
o リアルタイムでPacketスケジューリング(リアルタイムで)
o Mobility
o 移動性
o Accounting
o 会計
(and maybe large-scale?)
(そして、多分大規模ですか?)
These categories were then applied to the following scenarios:
次に、これらのカテゴリは以下のシナリオに適用されました:
S1. Support a private teleconference among mobile hosts connected to
the Internet. [Security-S, mcast-S, realtime, mobility]
S1。 インターネットに接続されたモバイルホストの中で個人的な電子会議を支持してください。 [セキュリティS、mcast-S、リアルタイムで、移動性]
S2. The group in S1 is 1/3 the Internet, i.e., there are VERY severe
scaling problems. [Security-S, mcast-S, realtime, mobility,
large-scale]
S2。 S1のグループは1/3です。インターネットであり、非常に厳しいスケーリング問題があります。[セキュリティS、mcast-S、移動性の、そして、大規模なリアルタイム]
S3. Charge for communication to support a video teleconference.
[Accounting, realtime, mcast-S]
S3。 コミュニケーションに課金して、ビデオ電子会議を支持してください。 [会計、リアルタイムで、mcast-S]
S4. I am travelling with my laptop. I tune in to radio channel IP-
RADIO, pick-up the beacon and start using it. Who gets the
bill? Why do they believe this is me? Is "me" a piece of
hardware (IP address) or a certified user (PEM certificate)?
[Mobility, accounting (, realtime, mcast-S)]
S4。 私はラップトップとともに旅しています。 私は、ラジオチャンネルIP RADIO、ピックアップに標識の波長を合わせて、それを使用し始めます。 だれが請求書を手に入れますか? 彼らは、なぜこれが私であると信じていますか? 1片のハードウェア(IPアドレス)かaがユーザ(PEM証明書)であることを公認した「私」、-- [説明することでの(リアルタイムで、mcast-S)移動性
S5. A Politically Important Person will mcast an Internet
presentation, without danger of interruptions from the audience.
S5。 Politically Important Personは聴衆から中断という危険なしでインターネットプレゼンテーションをmcastするでしょう。
S6. The travel industry wants to use Internet to deliver tickets to
customer premises directly in a secure way, but the customer has
only dial-up capability. [Security-S, mobility]
S6。 観光業は直接安全な方法で顧客構内にチケットを届けるのにインターネットを使用したがっていますが、顧客には、ダイヤルアップ能力しかありません。 [セキュリティS、移動性]
Braden, Clark, Crocker & Huitema [Page 50] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[50ページ]RFC1636IABワークショップレポート1994年6月
S7. I am traveling with my laptop and this friendly host is running
the autoconfiguration protocol. I immediately get an address as
"mac1.friendly.host.com". (What is the difference between my
laptop and a bona fide autoconfigured local station?)
[Security-S, mobility]
S7。 私はラップトップとともに旅しています、そして、この愛想の良い主人は自動構成プロトコルを走らせています。 私はすぐに、"mac1.friendly.host.com"としてアドレスを得ます。 (私のラップトップと誠実な自動構成された地方局の違いは何ですか?) [セキュリティS、移動性]
S8. Multiple people are connected to a subnetwork providing mobility
(e.g., cellular, packet radio). The subnetwork is connected to
multiple places in the "fixed" backbone. How can routing be done
efficiently? [Routing, mobility]
S8。 複数人は移動性(例えば、携帯電話、パケットラジオ)を提供するサブネットワークに接続されます。 サブネットワークは「修理された」背骨の複数の場所に接続されます。 どのように効率的にルーティングできますか? [ルート設定、移動性]
The following scenarios that were suggested do not fit into the primary thrust of the workshop, generally because they are single- issue topics. Most of them are pure security topics and are concerned with the security perimeter. The last two do not fit into our classification system at all.
示された以下のシナリオはワークショップの第一の突きに収まりません、それらが一般にただ一つの問題話題であるので。 それらの大部分は、純粋なセキュリティ話題であり、セキュリティ周辺に関係があります。 最後の2は全く私たちの分類システムに収まりません。
S9. XYZ corporation has two major branches on opposite ends of the
world, and they want to communicate securely over the Internet,
with each branch having IP-level connectivity to the other (not
through application gateways).
S9。 XYZ会社には2つの主要なブランチが世界の反対端にあります、そして、インターネットの上でしっかりと交信したがっています、もう片方(アプリケーションゲートウェイを通した)にIP-レベルの接続性を持っている各ブランチと共に。
S10. I am visiting XYZ corporation, with my laptop. I want to
connect it to their LAN to read my email remotely over the
Internet. Even though I am inside their corporate firewall,
they want to be protect their machines from me.
S10。 私は私のラップトップでXYZ会社を訪問しています。 インターネットの上で私のメールを離れて読むためにそれらのLANにそれを関連づけたいと思います。 私はそれらの法人のファイアウォールの中にいますが、彼らは私からそれらのマシンを保護するためにことになりたがっています。
S11. XYZ corporation is trying to use the Internet to support both
private and public networking. It wants to provide full
connectivity internally between all of its resources, and to
provide public access to certain resources (analogous of
anonymous ftp servers)
S11。 XYZ会社は、個人的なものと同様に公共のネットワークをサポートするのにインターネットを使用しようとしています。 それは、内部的にリソースのすべての間に完全な接続性を提供して、あるリソースにパブリックアクセスを提供したがっています。(アノニマスFTPサーバにおける類似)です。
S12. The travel industry wants to use Internet to deliver tickets to
customer premises directly in a secure way.
S12。 観光業は、直接安全な方法で顧客構内にチケットを届けるのにインターネットを使用したがっています。
S13. Some hacker is deliberately subverting routing protocols,
including mobile and multicast routing. Design counter
measures.
S13。 ハッカーは故意にルーティング・プロトコルを打倒していて、包含は可動、そして、マルチキャストルーティングです。 対応策を設計してください。
S14. Part of the Internet is running IPv4 and part is running IPng
(i.e. the Internet is in transition). How can we assure
continued secure operation through such a transition?
S14。 インターネットの一部がIPv4を走らせています、そして、部分はIPngを走らせています(すなわち、インターネットは変遷中です)。 私たちはそのような変遷でどうしたら継続的な安全な操作を保証できますか?
S15. A corporation uses ATM to connect a number of its sites. It also
uses Internet. It wants to make use of the ATM as its primary
carrier, but also wants to utilize other networking technologies
as appropriate (e.g., mobile radio). It wants to support all
S15。 会社は、多くのサイトをつなげるのにATMを使用します。 また、それはインターネットを使用します。 それは、第一のキャリヤーとしてATMを利用したいのですが、適宜(例えば、移動無線)他のネットワーク・テクノロジーをまた利用したがっています。 それはすべてを支持したがっています。
Braden, Clark, Crocker & Huitema [Page 51] RFC 1636 IAB Workshop Report June 1994
ブレーデン、クラーク、クロッカー、およびHuitema[51ページ]RFC1636IABワークショップレポート1994年6月
media (data, voice, video).
メディア(データ、声、ビデオ)。
Security Considerations
セキュリティ問題
This memo is entirely concerned with security issues.
このメモは安全保障問題に完全に関係があります。
Authors' Addresses
作者のアドレス
Bob Braden [Editor] USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695
ボブブレーデン[エディタ]USC情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695
Phone: (310) 822-1511 EMail: Braden@ISI.EDU
以下に電話をしてください。 (310) 822-1511 メールしてください: Braden@ISI.EDU
David Clark MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139-1986
技術の正方形のケンブリッジ、デヴィッドクラークMIT Laboratory for Computer Science545MA02139-1986
Phone: 617-253-6003 EMail: ddc@lcs.mit.edu
以下に電話をしてください。 617-253-6003 メールしてください: ddc@lcs.mit.edu
Steve Crocker Trusted Information Systems, Inc. 3060 Washington Road (Rte 97) Glenwood, MD 21738
スティーブ・クロッカーは情報システムInc.3060ワシントンRoad(Rte97)グレンウッド、MD 21738を信じました。
Phone: (301) 854-6889 EMail: crocker@tis.com
以下に電話をしてください。 (301) 854-6889 メールしてください: crocker@tis.com
Christian Huitema INRIA, Sophia-Antipolis 2004 Route des Lucioles BP 109 F-06561 Valbonne Cedex France
クリスチャンのHuitema INRIA、2004台のソフィア-Antipolis Route desルシオールBP109F-06561Valbonne Cedexフランス
Phone: +33 93 65 77 15 EMail: Christian.Huitema@MIRSA.INRIA.FR
以下に電話をしてください。 +33 93 65 77 15はメールされます: Christian.Huitema@MIRSA.INRIA.FR
Braden, Clark, Crocker & Huitema [Page 52]
ブレーデン、クラーク、クロッカー、およびHuitema[52ページ]
一覧
スポンサーリンク
