RFC1457 日本語訳
1457 Security Label Framework for the Internet. R. Housley. May 1993. (Format: TXT=35802 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Housley Request for Comments: 1457 Xerox Special Information Systems May 1993
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 1457 情報システム1993年5月に特別なゼロックス
Security Label Framework for the Internet
インターネットへの機密保護ラベルフレームワーク
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Acknowledgements
承認
The members of the Privacy and Security Research Group and the attendees of the invitational Security Labels Workshop (hosted by the National Institute of Standards and Technology) helped me organize my thoughts on this subject. The ideas of these professionals are scattered throughout the memo.
PrivacyとSecurity Research Groupのメンバーと招待者に限る催しSecurity Labels Workshop(米国商務省標準技術局によって接待される)の出席者は、私がこの問題に関して考えをまとめるのを助けました。 これらの専門家の考えはメモ中に点在します。
1.0 Introduction
1.0 序論
This memo presents a security labeling framework for the Internet. The framework is intended to help protocol designers determine what, if any, security labeling should be supported by their protocols. The framework should also help network architects determine whether or not a particular collection of protocols fulfill their security labeling requirements. The Open Systems Interconnection Reference Model [1] provides the structure for the presentation, therefore OSI protocol designers may also find this memo useful.
このメモはセキュリティラベリングフレームワークをインターネットに提示します。 フレームワークが、プロトコルデザイナーが、セキュリティラベリングがどんなであるもそうするべきであることが彼らのプロトコルによってサポートされると決心しているのを助けることを意図します。 また、フレームワークは、ネットワーク建築家が、プロトコルの特定の収集が要件をラベルするそれらのセキュリティを実現させるかどうかと決心しているのを助けるべきです。 オープン・システム・インターコネクションReference Model[1]は構造をプレゼンテーションに供給します、したがって、また、OSIプロトコルデザイナーはこのメモが役に立つのがわかるかもしれません。
2.0 Security Labels
2.0 セキュリティラベル
Data security is the set of measures taken to protect data from accidental, unauthorized, intentional, or malicious modification, destruction, or disclosure. Data security is also the condition that results from the establishment and maintenance of protective measures [2]. Given this two-pronged definition for data security, this memo examines security labeling as one mechanism which provides data security. In general, security labeling by itself does not provide sufficient data security; it must be complemented by other security mechanisms.
データ機密保護は偶然の、または、権限のないか、意図的であるか、悪意がある変更、破壊、または公開からデータを保護するために実施される対策のセットです。 また、データ機密保護は保護処分[2]の設立とメインテナンスから生じる状態です。 データ機密保護のためのこの2方面からの定義を考えて、このメモはデータ機密保護を提供する1つのメカニズムとしてセキュリティラベリングを調べます。 一般に、それ自体でセキュリティラベリングは十分なデータ機密保護を提供しません。 それは他のセキュリティー対策で補足とならなければなりません。
In data communication protocols, security labels tell the protocol processing how to handle the data transferred between two systems. That is, the security label indicates what measures need to be taken to preserve the condition of security. Handling means the activities
データ通信プロトコルで、機密保護ラベルは2台のシステムの間に移されたデータを扱う方法をプロトコル処理に教えます。すなわち、機密保護ラベルは、どんな測定が、セキュリティの状態を保存するために取られる必要であるかを示します。 取り扱いは活動を意味します。
Housley [Page 1] RFC 1457 Security Label Framework for the Internet May 1993
インターネット1993年5月のためのHousley[1ページ]RFC1457機密保護ラベルフレームワーク
performed on data such as collecting, processing, transferring, storing, retrieving, sorting, transmitting, disseminating, and controlling [3].
[3]を集めて、処理して、移して、保存して、検索して、分類して、伝えて、広めて、制御などなどのデータに実行されます。
The definition of data security includes protection from modification and destruction. In computer systems, this is protection from writing and deleting. These protections implement the data integrity service defined in the OSI Security Architecture [4].
データ機密保護の定義は変更と破壊からの保護を含んでいます。 コンピュータ・システムでは、これは書くことと削除からの保護です。 これらの保護は、データ保全がOSI Security Architecture[4]で定義されたサービスであると実装します。
Biba [5] has defined a data integrity model which includes security labels. The Biba model specifies rule-based controls for writing and deleting necessary to preserve data integrity. The model also specifies rule-based controls for reading to prevent a high integrity process from relying on data that has less integrity than the process.
ビバ[5]は機密保護ラベルを含んでいるデータ保全モデルを定義しました。 ビバモデルはデータ保全を保存するのに必要な書法と削除のためのルールベース制御を指定します。 また、モデルは高い保全プロセスがプロセスより少ない保全を持っているデータを当てにするのを防ぐために読書するためのルールベース制御を指定します。
The definition of data security also includes protection from disclosure. In computer systems, this is protection from reading. This protection is the data confidentiality service defined in the OSI Security Architecture [4].
また、データ機密保護の定義は公開からの保護を含んでいます。 コンピュータ・システムでは、これは読書からの保護です。 この保護はOSI Security Architecture[4]で定義されたデータの機密性サービスです。
Bell and LaPadula [6] defined a data confidentiality model which includes security labels. The Bell and LaPadula model specifies rule-based controls for reading necessary to preserve data confidentiality. The model also specifies rule-based controls for writing to ensure that data is not copied to a container where confidentiality can not be guaranteed.
ベルとLaPadula[6]は機密保護ラベルを含んでいるデータの機密性モデルを定義しました。 ベルとLaPadulaモデルはデータの機密性を保存するのに必要な読書のためのルールベース制御を指定します。 また、モデルはデータが秘密性を保証できないコンテナにコピーされないのを保証するために書くためのルールベース制御を指定します。
In both the Biba model and the Bell and LaPadula model, the security label is an attribute of the data. In general, the security label associated with the data remains constant. Exceptions will be discussed later in the memo, but relabeling is always the result of some network entity handling the data. Since the security label is an attribute of data, it should be bound to the data. When data moves through the network, the integrity security service [4] is generally used to accomplish this binding. If the communications environment does not include a protocol which provides the integrity security service to bind the security label to the data, then the communications environment should include other mechanisms to preserve this binding.
ビバモデルとベルとLaPadulaモデルの両方では、機密保護ラベルはデータの属性です。 一般に、データに関連している機密保護ラベルは一定のままで残っています。 後でメモで例外について議論するでしょうが、いつも再ラベルはデータを扱う何らかのネットワーク実体の結果です。 機密保護ラベルがデータの属性であるので、それはデータに縛られるべきです。 データがネットワークを通して移行するとき、一般に、保全セキュリティー・サービス[4]は、この結合を実行するのに使用されます。 コミュニケーション環境がデータに機密保護ラベルを縛るために保全セキュリティー・サービスを提供するプロトコルを含んでいないなら、コミュニケーション環境は、この結合を保存するために他のメカニズムを含むべきです。
2.1 Integrity Labels
2.1 保全ラベル
Integrity labels are security labels which support data integrity models, like the Biba model. The integrity label tells the degree of confidence that may be placed in the data and also indicates which measures the data requires for protection from modification and destruction.
保全ラベルはデータ保全がビバモデルのようにモデルであるとサポートする機密保護ラベルです。 保全ラベルは、データに置かれるかもしれない信用の度合いを言って、また、データが保護のために変更と破壊からどの測定を必要とするかを示します。
Housley [Page 2] RFC 1457 Security Label Framework for the Internet May 1993
インターネット1993年5月のためのHousley[2ページ]RFC1457機密保護ラベルフレームワーク
As data moves through the network, the confidence that may be placed in that data may change as a result of being handled by various network components. Therefore, the integrity label is a function of the integrity of the data before being transmitted on the network and the path that the data takes through the network. The confidence that may be placed in data does not increase because it was transferred across a network, but the confidence that may be placed in data may decrease as a result of being handled by arbitrary network components. Entities are assigned integrity labels which indicate how much confidence may be placed in data that is handled by them. Thus, when data is handled by an entity with an integrity label lower than the integrity label of the data, the data is relabeled with the integrity label of the entity. Such relabeling should be avoided by limiting the possible paths that data may take through the network to those where the data will be handled only by entities with the same or a higher integrity label than the data.
データがネットワークを通して移行するとき、様々なネットワーク要素によって扱われることの結果、そのデータに置かれるかもしれない信用は変化するかもしれません。 したがって、データがネットワークを通して取るネットワークと経路で伝えられる前に保全ラベルはデータの保全の機能です。 データに置かれるかもしれない信用はネットワークの向こう側にそれを移したので、大きくなりませんが、任意のネットワーク要素によって扱われることの結果、データに置かれるかもしれない信用は静まるかもしれません。 どのくらいの信用がそれらによって扱われるデータに置かれるかもしれないかを示す保全ラベルが実体に割り当てられます。 保全ラベルがデータの保全ラベルより低い状態でデータが実体によって扱われるとき、したがって、データは実体の保全ラベルで再ラベルされます。 そのような再ラベルは、同じくらいかデータより高い保全ラベルでデータがネットワークを通してデータが実体だけによって扱われるところのそれらに取るかもしれない可能な経路を制限することによって、避けられるべきです。
When integrity labels are used, each of the systems on a network must implement the integrity model and the protocol suite must transfer the integrity label with the data, if the confidence of the data is to be maintained throughout the network. Each of the systems on a network may have its own internal representation for a integrity label, but the protocols must provide common syntax and semantics for the transfer of the integrity label, as well as the data itself. To date, no protocols have been standardized which include integrity labels in the protocol control information.
保全ラベルが使用されているとき、ネットワークのそれぞれのシステムは保全モデルを実装しなければなりません、そして、プロトコル群はデータで保全ラベルを移さなければなりません、データの信用がネットワーク中で維持されることであるなら。 ネットワークのそれぞれのシステムには、それ自身の保全ラベルの内部の表現があるかもしれませんが、プロトコルは一般的な構文と意味論を保全ラベルの転送に提供しなければなりません、データ自体と同様に。 これまで、プロトコル制御情報に保全ラベルを含んでいるプロトコルが全く標準化されていません。
2.2 Sensitivity Labels
2.2 感度ラベル
Sensitivity labels are security labels which support data confidentiality models, like the Bell and LaPadula model. The sensitivity label tells the amount of damage that will result from the disclosure of the data and also indicates which measures the data requires for protection from disclosure. The amount of damage that results from unauthorized disclosure depends on who obtains the data; the sensitivity label should reflect the worst case.
感度ラベルはデータの機密性がベルとLaPadulaモデルのようにモデルであるとサポートする機密保護ラベルです。 感度ラベルは、データの公開から生じる損害額を言って、また、データが保護のために公開からどの測定を必要とするかを示します。 不当開示から生じる損害額をだれがデータを得るかに依存します。 感度ラベルは最悪の場合を反映するはずです。
As data moves through the network, it is processed by various network components and may be mixed with data of differing sensitivity. If these network components are not trusted to segregate data of differing sensitivities, then all of the data processed by those components must be handled as the most sensitive data processed by those network components. For example, poor buffer management may append highly sensitive data to the end of a protocol data unit that was otherwise publicly releasable. Therefore, the sensitivity label is a function of the sensitivity of the data before being transmitted on the network and the most sensitive data handled by the network components, and the trustworthiness of those network components. The
データがネットワークを通して移行するとき、それは、様々なネットワーク要素によって処理されて、異なった感度に関するデータに混ぜられるかもしれません。 これらのネットワーク要素が異なった敏感さに関するデータを隔離すると信じられないなら、最も機密のデータがそれらのネットワーク要素によって処理されたので、それらのコンポーネントによって処理されたデータのすべてを扱わなければなりません。 例えば、不十分なバッファ管理はそうでなければ公的にリリース可能だったプロトコルデータ単位の終わりに非常に機密のデータを追加するかもしれません。 したがって、ネットワークとネットワーク要素、およびそれらのネットワーク要素の信頼できることによって扱われる中で最も機密のデータで伝えられる前に感度ラベルはデータの感度の関数です。 The
Housley [Page 3] RFC 1457 Security Label Framework for the Internet May 1993
インターネット1993年5月のためのHousley[3ページ]RFC1457機密保護ラベルフレームワーク
amount of damage that will result from the disclosure of the data does not decrease because it was transferred across a network, but the amount of damage that will result from the disclosure of the data may increase as a result of being mixed with more sensitive data by arbitrary network components. Thus, when data is handled by an untrusted entity with a sensitivity label higher than the sensitivity label of the data, the data is relabeled with the higher sensitivity label. Such relabeling should be avoided by limiting the possible paths that data may take through the network to those where the data will be handled only by entities with the same sensitivity label as the data or by using trustworthy network components. Entities with lower sensitivity labels may not handle the data because this would be disclosure.
データの公開から生じる損害額がネットワークの向こう側にそれを移したので、減少しませんが、より機密のデータに混ぜられることの結果、データの公開から生じる損害額は任意のネットワーク要素で増加するかもしれません。 感度ラベルがデータの感度ラベルより高い状態でデータが信頼されていない実体によって扱われるとき、したがって、データは、より高い感度ラベルで再ラベルされます。 そのような再ラベルは、データと同じ感度ラベルでデータがネットワークを通してデータが実体だけによって扱われるところのそれらに取るかもしれない可能な経路を制限するか、または信頼できるネットワーク要素を使用することによって、避けられるべきです。 これは公開でしょう、したがって、低感度ラベルがある実体がデータを扱わないかもしれません。
When sensitivity labels are used, each of the systems on a network must implement the sensitivity model and the protocol suite must transfer the sensitivity label with the data, if the protection from disclosure is to be maintained throughout the network. Each of the systems on a network may have its own internal representation for a sensitivity label, but the protocols must provide common syntax and semantics for the transfer of the sensitivity label, as well as the data itself. Sensitivity labels, like the ones provided by the IP Security Option (IPSO) [7], have been used in a few networks for years.
感度ラベルが使用されているとき、ネットワークのそれぞれのシステムは感度モデルを実装しなければなりません、そして、プロトコル群はデータで感度ラベルを移さなければなりません、公開からの保護がネットワーク中で維持されることであるなら。 ネットワークのそれぞれのシステムには、それ自身の感度ラベルの内部の表現があるかもしれませんが、プロトコルは一般的な構文と意味論を感度ラベルの転送に提供しなければなりません、データ自体と同様に。 長年、IP Security Option(IPSO)[7]によって提供されたもののように、感度ラベルはいくつかのネットワークに使用されています。
3.0 Security Label Usage
3.0 機密保護ラベル用法
The Internet includes two major types of systems: end systems and intermediate systems [1]. These terms should be familiar to the reader. For this discussion, the definition of intermediate system is understood to include routers, packet switches, and bridges. End systems and intermediate systems use security labels differently.
インターネットは2つの主要なタイプのシステムを含んでいます: システムと中間システム[1]を終わらせてください。 読者にとって、これらの用語は身近であるはずです。 この議論において、中間システムの定義がルータ、パケット交換機、およびブリッジを含んでいるのが理解されています。 エンドシステムと中間システムは機密保護ラベルを異なって使用します。
3.1 End System Security Label Usage
3.1 終わりのシステム機密保護ラベル用法
When two end systems communicate, common security label syntax and semantics are needed. The security label, as an attribute of the data, indicates what measures need to be taken to preserve the condition of security. The security label must communicate all of the integrity and confidentiality handling requirements. These requirements can become very complex.
2台のエンドシステムが交信するとき、共通の安全保障ラベル構文と意味論が必要です。 データの属性として、機密保護ラベルは、どんな測定が、セキュリティの状態を保存するために取られる必要であるかを示します。 機密保護ラベルは保全と秘密性取り扱い要件のすべてを伝えなければなりません。 これらの要件は非常に複雑になることができます。
Some operating systems label the data they process. These security labels are not part of the data; they are attributes of the data. Some database management systems (DBMSs) perform similar labeling. The format of these security labels is a local matter, but they are usually in a format different than the one used by the data communication protocols. Security labels must be translated by these
いくつかのオペレーティングシステムがそれらが処理するデータをラベルします。 これらの機密保護ラベルはデータの一部ではありません。 それらはデータの属性です。 いくつかのデータベース管理システム(DBMSs)が同様のラベリングを実行します。 これらの機密保護ラベルの形式は地域にかかわる事柄ですが、通常、データ通信プロトコルによって使用されるものと異なった形式にはそれらがあります。 これらで機密保護ラベルを翻訳しなければなりません。
Housley [Page 4] RFC 1457 Security Label Framework for the Internet May 1993
インターネット1993年5月のためのHousley[4ページ]RFC1457機密保護ラベルフレームワーク
operating systems and DBMSs between the local format and the format used in the data communication protocols without any loss of meaning.
意味の少しも損失なしでデータ通信プロトコルに使用される地方の形式と形式の間のオペレーティングシステムとDBMSs。
Trusted operating systems that implement rule-based access control policies require security labels on the data they import [8,9]. These security labels permit the Trusted Computing Base (TCB) in the end system to perform trusted demultiplexing. That is, the traffic is relayed from the TCB to a process only if the process has sufficient authorization for the data. In most cases, the TCB must first translate the security label into the local syntax before it can make the access control decision.
規則ベースのアクセスがコントロール方針であると実装する信じられたオペレーティングシステムがそれらがインポートするデータ[8、9]で機密保護ラベルを必要とします。 これらの機密保護ラベルは、エンドシステムのTrusted Computing基地(TCB)が信じられた逆多重化を実行するのを可能にします。 プロセスにデータのための十分な承認がある場合にだけ、すなわち、トラフィックはTCBからプロセスまでリレーされます。 多くの場合、アクセス制御決定をすることができる前にTCBは最初に、ローカルの構文に機密保護ラベルを翻訳しなければなりません。
3.2 Intermediate System Security Label Usage
3.2 中間システム機密保護ラベル用法
This section discusses "user" data security labels within the intermediate system. The labeling requirements associated with intermediate system-to-end system (IS-ES) traffic, intermediate system-to-intermediate system (IS-IS) traffic, and intermediate system-to-network management (IS-NM) traffic are not included in this discussion.
このセクションは中間システムの中で「ユーザ」データ機密保護ラベルについて論じます。 ラベリング要件が中間システムからエンドへのシステムに関連づけた、(-、ES、)、トラフィック、中間システムから中間システム、(-、)、トラフィック、および中間システムからネットワークマネージメント、(-、ニューメキシコ、)、トラフィックはこの議論に含まれていません。
Intermediate systems may make routing choices or discard traffic based on the security label. The security label used by the intermediate system should contain only enough information to make the routing/discard decision and may be a subset of the security label used by the end system. Some portions of the label may not effect routing decisions, but they may effect processing done within the end system.
中間システムは、ルーティング選択をするか、または機密保護ラベルに基づくトラフィックを捨てるかもしれません。 中間システムによって使用される機密保護ラベルは、ルーティング/破棄を決定にすることができるくらいの情報だけを含むべきであり、エンドシステムによって使用される機密保護ラベルの部分集合であるかもしれません。 ラベルのいくつかの一部がルーティング決定に作用しないかもしれませんが、それらはエンドシステムの中で行われた処理に作用するかもしれません。
In the Internet today, very few intermediate systems actually make access control decisions. For performance reasons, only those intermediate systems which do make access control decisions should be burdened with parsing the security label. That is, information hiding principles apply. Further, security labels which are to be parsed only by end systems should not be visible to physical, data link, or network layer protocols, where intermediate systems will have to examine them.
今日のインターネットでは、ほんのわずかな中間システムは実際にアクセスをコントロール決定にします。 性能理由で、アクセスをコントロール決定にするそれらの中間システムだけが機密保護ラベルを分析することで負担されるべきです。 すなわち、情報隠蔽原則は適用されます。 さらに、単にエンドシステムによって分析されることになっている機密保護ラベルは物理的なデータリンク、またはネットワーク層プロトコルに目に見えるべきではありません。そこでは、中間システムがそれらを調べなければならないでしょう。
Intermediate systems do not usually translate the security labels to a local format. They use them "as is" to make their routing/discard decisions. However, when two classification authorities share a network by bilateral agreement, the intermediate systems may be required to perform security label translation. Security label translations should be avoided whenever possible by using a security label format that is supported by all systems that will process the security label. Since end systems do not generally know which intermediate systems will process their traffic, security label translation cannot always be avoided.
通常、中間システムは地方の形式に機密保護ラベルを翻訳しません。 彼らは、彼らのルーティング/破棄を決定にするのに「そのままで」それらを使用します。 しかしながら、2つの人事権を有する隊長が二国間条約でネットワークを共有するとき、中間システムが、機密保護ラベル翻訳を実行するのに必要であるかもしれません。 機密保護ラベルを処理するすべてのシステムによってサポートされる機密保護ラベル形式を使用することによって可能であるときはいつも、機密保護ラベル翻訳は避けられるべきです。 エンドシステムが、どの中間システムがそれらのトラフィックを処理するかを一般に知らないので、いつも機密保護ラベル翻訳を避けることができるというわけではありません。
Housley [Page 5] RFC 1457 Security Label Framework for the Internet May 1993
インターネット1993年5月のためのHousley[5ページ]RFC1457機密保護ラベルフレームワーク
Since security labels which are to be parsed only by end systems should not be carried by protocols interpreted by intermediate systems, such security labels should be carried by upper layer protocols, and end systems which use different formats for such security labels cannot rely on an intermediate systems to perform security label translation. Neither the Internet nor the OSI architecture includes such transformation functions in the transport, session, or presentation layer, which means that application layer gateways should be used to translate between different end system security label formats. Such application gateways should be avoided because they impinge on operation, especially when otherwise compatible protocols are used. This complication is another reason why the use of a security label format that is supported by all systems is desirable. A standard label syntax with registered security label semantics goes a long way toward avoiding security label translation [10].
中間システムによって解釈されたプロトコルで単にエンドシステムによって分析されることになっている機密保護ラベルを運ぶべきでないので、そのような機密保護ラベルは上側の層のプロトコルによって運ばれるべきです、そして、そのような機密保護ラベルに異なった形式を使用するエンドシステムは機密保護ラベル翻訳を実行するために中間システムを当てにすることができません。 インターネットもOSIアーキテクチャも応用層ゲートウェイが異なった終わりのシステム機密保護ラベル形式の間で翻訳するのに使用されるべきであることを意味する輸送、セッション、またはプレゼンテーション層にそのような変形関数を含んでいません。 操作に衝突するので、特にそうでなければ、コンパチブルプロトコルが使用されているとき、そのようなアプリケーションゲートウェイは避けられるべきです。 この複雑さはすべてのシステムによってサポートされる機密保護ラベル形式の使用が望ましい別の理由です。 登録証券ラベル意味論がある標準ラベル構文は、機密保護ラベル翻訳[10]を避けるのに貢献します。
4.0 Approaches to Labeling
4.0 ラベリングへのアプローチ
There are several tradeoffs to be made when determining how a particular network will perform security labeling. Explicit or implicit labels can be used. Also, security labels can either be connectionless or connection-oriented. A combination of these alternatives may be appropriate.
特定のネットワークがどのようにセキュリティラベリングを実行するかを決定するとき作られるいくつかの見返りがあります。 明白であるか内在しているラベルを使用できます。 また、機密保護ラベルも、コネクションレスであるか、または接続指向である場合があります。 これらの代替手段の組み合わせは適切であるかもしれません。
4.1 Explicit Versus Implicit Security Labels
4.1 暗黙のセキュリティに対して明白なラベル
Explicit security labels are actual bits in the protocol control information (PCI). The IP Security Option (IPSO) is an example of an explicit security label [7]. Explicit security labels may be either connectionless or connection-oriented. The syntax and semantics of the explicit security label may be either tightly or loosely coupled. If the syntax and semantics are tightly coupled, then the explicit security label format supports a single security policy. If the syntax and semantics are loosely coupled, then the explicit security label format can support multiple security policies through registration. In both cases, software enforces the security policy, but the label parsing software can be written once if the syntax and semantics are loosely coupled. Fixed length explicit security label format parsers are generally faster than parsers for variable length formats. Intermediate systems suffer less performance impact when fixed length explicit security labels can be used, but end systems often need variable length explicit security labels to express data handling requirements.
明白な機密保護ラベルはプロトコル制御情報(PCI)の実際のビットです。 IP Security Option(IPSO)は明白な機密保護ラベル[7]に関する例です。 明白な機密保護ラベルは、コネクションレスであるか、または接続指向であるかもしれません。 明白な機密保護ラベルの構文と意味論はしっかりか緩く結合されるかもしれません。 構文と意味論が密結合であるなら、明白な機密保護ラベル形式はただ一つの安全保障政策をサポートします。 構文と意味論が緩く結合されるなら、明白な機密保護ラベル形式は登録で複数の安全保障政策をサポートすることができます。 どちらの場合も、ソフトウェアは安全保障政策を実施しますが、構文と意味論が緩く結合されるなら、一度ラベル構文解析ソフトウェアを書くことができます。 一般に、可変長形式には、固定長の明白な機密保護ラベル形式パーサはパーサより速いです。 固定長の明白な機密保護ラベルを使用できるとき、中間システムは、より少ない性能影響を受けますが、エンドシステムは、データハンドリング要件を言い表すためにしばしば可変長の明白な機密保護ラベルを必要とします。
Implicit security labels are not actual bits in the PCI; instead, some attribute is used to determine the security label. For example, the choice of cryptographic key in the SP4 protocol [11] can
内在している機密保護ラベルはPCIの実際のビットではありません。 代わりに、何らかの属性が、機密保護ラベルを決定するのに使用されます。 例えば、SP4プロトコル[11]における暗号化キーの選択はそうすることができます。
Housley [Page 6] RFC 1457 Security Label Framework for the Internet May 1993
インターネット1993年5月のためのHousley[6ページ]RFC1457機密保護ラベルフレームワーク
determine the security label. Implicit security labels may be either connectionless or connection-oriented.
機密保護ラベルを決定してください。 内在している機密保護ラベルは、コネクションレスであるか、または接続指向であるかもしれません。
4.2 Connectionless Versus Connection-oriented Security Labels
4.2 接続指向のセキュリティに対してコネクションレスなラベル
When connectionless security labels are used, the security label appears in every protocol data unit (PDU). The IP Security Option (IPSO) [7] is an example of connectionless labeling. All protocols have limits on the size of their PCI, and the explicit security label cannot exceed this size limit. It cannot use the entire PCI space either; the protocol has other fields that must be transferred as well. This size limitation may prohibit explicit connectionless security labels from meeting the requirements of end systems. However, the requirements of intermediate systems are more easily satisfied by explicit connectionless security labels.
コネクションレスな機密保護ラベルが使用されているとき、機密保護ラベルはあらゆるプロトコルデータ単位(PDU)に現れます。 IP Security Option(IPSO)[7]はコネクションレスなラベリングに関する例です。 すべてのプロトコルがそれらのPCIのサイズに限界を持っています、そして、明白な機密保護ラベルはこのサイズ限界を超えることができません。 それは全体のPCIスペースを使用できません。 プロトコルはまた、移さなければならない他の野原を持っています。 このサイズ制限はエンドシステムについて条件を満たすのから明白なコネクションレスな機密保護ラベルを禁じるかもしれません。しかしながら、中間システムの要件は明白なコネクションレスな機密保護ラベルによって、より容易に満たされています。
Connection-oriented security labels are attributes of virtual circuits, connections, and associations. For simplicity, all of these are subsequently referred to as connections. Connection- oriented security labels are used when the SDNS Key Management Protocol (KMP) [12] is used to associate security labels with each of the transport connection protected by the SP4 protocol [10,11] (using SP4C). The security label is defined at connection establishment, and all data transferred over the connection inherits that security label. This approach is more compatible with end system requirements than intermediate system requirements. One noteworthy exception is X.25 packets switches; these intermediate systems could associate connection-oriented labels with each virtual circuit.
接続指向の機密保護ラベルは仮想の回路、接続、および協会の属性です。 簡単さにおいて、これらのすべてが次に、接続と呼ばれます。 接続SDNS Key Managementプロトコル(KMP)[12]がSP4プロトコル[10、11]によって保護される輸送接続各人に機密保護ラベルを関連づけるのに使用されるとき(SP4Cを使用して)、指向の機密保護ラベルは使用されています。 機密保護ラベルはコネクション確立で定義されます、そして、接続の上に移されたすべてのデータがその機密保護ラベルを引き継ぎます。 このアプローチは中間システム要件より終わりのシステム要求と互換性があります。 1つの注目に値する例外がX.25パケットスイッチです。 これらの中間システムは接続指向のラベルをそれぞれの仮想の回路に関連づけるかもしれません。
Connectionless security labels may be used in conjunction with connectionless or connection-oriented data transfer protocols. However, connection-oriented security labels may only be used in conjunction with connection-oriented data transfer protocols.
コネクションレスな機密保護ラベルはコネクションレスであるか接続指向のデータ転送プロトコルに関連して使用されるかもしれません。 しかしながら、接続指向の機密保護ラベルは接続指向のデータ転送プロトコルに関連して使用されるだけであるかもしれません。
5.0 Labeling Within the OSI Reference Model
5.0 OSIの中で規範モデルにレッテルを貼ること。
This section examines each of the seven OSI layers with respect to security labels.
このセクションは機密保護ラベルに関してそれぞれの7つのOSI層を調べます。
5.1 Layer 1, The Physical Layer
5.1 層1、物理的な層
Explicit security labels are not possible in the Physical Layer. The Physical Layer does not include any protocol control information (PCI), so there is no place to include the bits which represent the label.
明白な機密保護ラベルはPhysical Layerで可能ではありません。 Physical Layerが少しのプロトコル制御情報(PCI)も含んでいないので、ラベルを表すビットを含む場所が全くありません。
Implicit security labels are possible in the Physical Layer. For example, all of the data that comes in through a particular physical
内在している機密保護ラベルはPhysical Layerで可能です。 例えば、特定の身体検査で入るデータのすべて
Housley [Page 7] RFC 1457 Security Label Framework for the Internet May 1993
インターネット1993年5月のためのHousley[7ページ]RFC1457機密保護ラベルフレームワーク
port could inherit one security label. Most Physical Layer communication is connectionless, supporting only bit-at-a-time or byte-at-a-time operations. Thus, these implicit security labels are connectionless.
ポートは1個の機密保護ラベルを引き継ぐかもしれません。 一度にビットか一度にバイト操作だけをサポートして、ほとんどのPhysical Layerコミュニケーションがコネクションレスです。 したがって、これらの内在している機密保護ラベルはコネクションレスです。
Implicit security labels in the Physical Layer may be used to meet the requirements of either end systems or intermediate systems so long as the communication is single level. That is, only one security label is associated with all of the data received or transmitted through the physical connection.
Physical Layerの内在している機密保護ラベルは、コミュニケーションがただ一つのレベルである限り、エンドシステムか中間システムのどちらかに関する必要条件を満たすのに使用されるかもしれません。 すなわち、1個の機密保護ラベルだけが物理接続で受け取るか、または伝えるデータのすべてに関連しています。
5.2 Layer 2, The Data Link Layer
5.2 層2、データ・リンク層
Explicit security labels are possible in the Data Link Layer. In fact, the IEEE 802.2 Working Group is currently working on an optional security label standard for the Logical Link Control (LLC) protocol (IEEE 802.2) [13]. These labels will optionally appear in each LLC frame. These are connectionless security labels.
明白な機密保護ラベルはData Link Layerで可能です。 事実上、802.2作業部会が現在任意のセキュリティを扱っているIEEEはLogical Link Controlにおける標準(LLC)のプロトコル(IEEE802.2)[13]をラベルします。 これらのラベルはそれぞれのLLCフレームに任意に現れるでしょう。 これらはコネクションレスな機密保護ラベルです。
Explicit connection-oriented security labels are also possible in the Data Link Layer. One could imagine a security label standard which worked with LLC Type II.
また、明白な接続指向の機密保護ラベルもData Link Layerで可能です。 人はLLC Type IIと共に働いていた機密保護ラベル規格を想像できました。
Of course, implicit security labels are also possible in the Data Link Layer. Such labels could be either connectionless or connection-oriented. One attribute that might be used in IEEE 802.3 (CSMA/CD) [14] to determine the implicit security label is the source address of the frame.
もちろん、また、内在している機密保護ラベルもData Link Layerで可能です。 そのようなラベルは、コネクションレスであるか、または接続指向であるかもしれません。 内在している機密保護ラベルを決定するのにIEEE802.3(CSMA/CD)[14]で使用されるかもしれない1つの属性がフレームのソースアドレスです。
Security labels in the Data Link Layer may be used to meet the requirements of end systems and intermediate systems (especially bridges). Explicit security labels in this layer tend to be small because the protocol headers for data link layer protocols are themselves small. Therefore, when end systems require large security labels, a higher protocol layer should used to carry them. However, when end systems do not require large security labels, the data link layer is attractive because in many cases the data link layer protocol supports several protocol suites simultaneously. Label- based routing/relay decisions made by bridges are best supported in this layer.
Data Link Layerの機密保護ラベルは、エンドシステムと中間システム(特にブリッジ)に関する必要条件を満たすのに使用されるかもしれません。 この層の明白な機密保護ラベルは、データリンク層プロトコルのためのプロトコルヘッダーが自分たちで小さいので小さい傾向があります。 したがって、エンドシステムが大きい機密保護ラベルを必要とするときの、より高いプロトコル層は以前はよくそれらを運んだはずです。 しかしながら、エンドシステムが大きい機密保護ラベルを必要としないとき、データリンク層プロトコルが同時に多くの場合いくつかのプロトコル群を支えるので、データ・リンク層は魅力的です。 この層の中でブリッジによってされたラベルのベースのルーティング/リレー決定をサポートするのは最も良いです。
5.3 Layer 3, The Network Layer
5.3 層3、ネットワーク層
Explicit security labels are possible in the Network Layer. In fact, the IP Security Option (IPSO) [7] has been used for many years. These labels optionally appear in each IP datagram. IPSO labels are obviously connectionless security labels.
明白な機密保護ラベルはNetwork Layerで可能です。 事実上、IP Security Option(IPSO)[7]は何年間も使用されています。 これらのラベルはそれぞれのIPデータグラムに任意に現れます。 IPSOラベルは明らかにコネクションレスな機密保護ラベルです。
Housley [Page 8] RFC 1457 Security Label Framework for the Internet May 1993
インターネット1993年5月のためのHousley[8ページ]RFC1457機密保護ラベルフレームワーク
Explicit connection-oriented security labels are also possible in the Network Layer. One could easily imagine a security label standard for X.25 [15], but none exists.
また、明白な接続指向の機密保護ラベルもNetwork Layerで可能です。 人は容易にX.25[15]の機密保護ラベル規格を想像できましたが、なにも存在していません。
Of course, implicit security labels are also possible in the Network Layer. These labels could be either connectionless or connection- oriented. One attribute that might be used to determine the implicit security label is the X.25 virtual circuit.
もちろん、また、内在している機密保護ラベルもNetwork Layerで可能です。 これらのラベルがコネクションレスであるかもしれませんか、または接続は指向しています。 内在している機密保護ラベルを決定するのに使用されるかもしれない1つの属性がX.25の仮想の回路です。
Security labels in the Network Layer may be used to meet the requirements of end systems and intermediate systems. Explicit security labels in this layer tend to be small because the protocol headers for network layer protocols are themselves small. Small fixed size network layer protocol headers allow efficient router implementations. Therefore, when end systems require large security labels, a higher protocol layer should used to carry them. Alternatively, the Network Layer (especially the Subnetwork Independent Convergence Protocol (SNICP) sublayer) is an excellent place to carry a security label to support trusted demultiplexing, because many implementations demultiplex from an system-wide daemon to a user process after network layer processing. The SNICP is end- to-end, yet it is low enough in the protocol stack to aid trusted demultiplexing.
Network Layerの機密保護ラベルは、エンドシステムと中間システムに関する必要条件を満たすのに使用されるかもしれません。この層の明白な機密保護ラベルは、ネットワーク層プロトコルのためのプロトコルヘッダーが自分たちで小さいので小さい傾向があります。 小さい固定サイズネットワーク層プロトコルヘッダーは効率的なルータ実装を許容します。 したがって、エンドシステムが大きい機密保護ラベルを必要とするときの、より高いプロトコル層は以前はよくそれらを運んだはずです。 あるいはまた、Network Layer(特にSubnetwork無党派Convergenceプロトコル(SNICP)副層)は信じられた逆多重化をサポートするために機密保護ラベルを運ぶ素晴らしい場所です、多くの実装がネットワーク層処理の後にシステム全体のデーモンからユーザ・プロセスまで反多重送信されるので。 SNICPが終わりから終わりである、しかし、それは信じられた逆多重化を支援するプロトコル・スタックで十分低いです。
Label-based routing/relay decisions made by routers and packet switches are best supported in the Network Layer. Routers can also add labels at subnetwork boundaries. However, placement of these security labels must be done carefully to ensure that their addition does not degrade overall network performance by forcing routers that do not make label-based routing decisions to parse the security label. Also, performance will suffer if the addition of security labels at subnet boundaries induces fragmentation/segmentation.
Network Layerでルータとパケット交換機によってされたラベルベースのルーティング/リレー決定をサポートするのは最も良いです。 また、ルータはサブネットワーク境界でラベルを加えることができます。 しかしながら、それらの追加が機密保護ラベルを分析するというラベルベースのルーティング決定をしないルータを強制するのによる総合的なネットワーク性能を下げないのを保証するために慎重にこれらの機密保護ラベルのプレースメントをしなければなりません。 また、サブネット境界の機密保護ラベルの追加が断片化/分割を引き起こすと、性能に苦しむでしょう。
5.4 Layer 4, The Transport Layer
5.4 層4、トランスポート層
Explicit security labels are possible in the Transport Layer. For example, the SP4 protocol [10,11] includes them. These labels can be either connectionless (using SP4E) or connection-oriented (using SP4C). SP4 is an addendum to the TP [16] and CLTP [17] protocols.
明白な機密保護ラベルはTransport Layerで可能です。 例えば、SP4プロトコル[10、11]はそれらを含んでいます。 これらのラベルは、コネクションレスであるか(SP4Eを使用します)、または接続指向である場合があります(SP4Cを使用して)。 SP4はTP[16]とCLTP[17]プロトコルへの付加物です。
Implicit security labels are also possible in the Transport Layer. Such labels could be either connectionless or connection-oriented. One attribute that might be used to determine the implicit label in the SP4 protocol (when explicit labels are not used as discussed above) is the choice of cryptographic key.
また、内在している機密保護ラベルもTransport Layerで可能です。 そのようなラベルは、コネクションレスであるか、または接続指向であるかもしれません。 SP4プロトコル(明白なラベルが上で議論するとして使用されないとき)で内在しているラベルを決定するのに使用されるかもしれない1つの属性は暗号化キーの選択です。
Security labels in the Transport Layer may be used to meet the requirements of end systems. The Transport Layer cannot be used to
Transport Layerの機密保護ラベルは、システムTransport Layerが使用されているはずがない終わりに関する必要条件を満たすのに使用されるかもしれません。
Housley [Page 9] RFC 1457 Security Label Framework for the Internet May 1993
インターネット1993年5月のためのHousley[9ページ]RFC1457機密保護ラベルフレームワーク
meet the requirements of intermediate systems because intermediate systems, by definition, do not process protocols above the Network Layer. Connection-oriented explicit security labels in this layer are especially good for meeting end system requirements where large labels are required. The security label is transmitted only at connection establishment, so overhead is kept to a minimum. Of course, connectionless transport protocols may not take advantage of this overhead reduction technique. Yet, in many implementations the Transport Layer is low enough in the protocol stack to aid trusted demultiplexing.
中間システムが定義上Network Layerの上でプロトコルを処理しないので、中間システムに関する必要条件を満たしてください。 ミーティング終わりのシステム要求には、この層の接続指向の明白な機密保護ラベルは大きいラベルが必要であるところで特に良いです。 機密保護ラベルがコネクション確立だけで伝えられるので、オーバーヘッドは最小限に保たれます。 もちろん、コネクションレスなトランスポート・プロトコルはこの頭上の減少のテクニックを利用しないかもしれません。 しかし、多くの実装では、Transport Layerは信じられた逆多重化を支援するプロトコル・スタックで十分低いです。
5.5 Layer 5, The Session Layer
5.5 層5、セッション層
Explicit security labels are possible in the Session Layer. Such labels could be either connectionless or connection-oriented. However, it is unlikely that a standard will ever be developed for such labels because the OSI Security Architecture [4] does not allocate any security services to the Session Layer, and the Internet protocol suite does not have a Session Layer.
明白な機密保護ラベルはSession Layerで可能です。 そのようなラベルは、コネクションレスであるか、または接続指向であるかもしれません。 しかしながら、OSI Security Architecture[4]がSession Layerへの少しのセキュリティー・サービスも割り当てないので規格が今までに、そのようなラベルのために開発されて、インターネット・プロトコル群がSession Layerを持っていないのは、ありそうもないです。
Implicit security labels are also possible in the Session Layer. These implicit labels could be either connectionless or connection- oriented. Again, the OSI Security Architecture makes this layer an unlikely choice for security labeling.
また、内在している機密保護ラベルもSession Layerで可能です。 これらの内在しているラベルがコネクションレスであるかもしれませんか、または接続は指向しています。 一方、OSI Security Architectureはこの層をセキュリティラベリングのためのありそうもない選択にします。
Security labels in the Session Layer may be used to meet the requirements of end systems, but the Session Layer is too high in the protocol stack to support trusted demultiplexing. The Session Layer cannot be used to meet the requirements of intermediate systems because intermediate systems, by definition, do not process protocols above the Network Layer. Security labels in the Session Layer do not offer any advantages to security labels in the Transport Layer.
Session Layerの機密保護ラベルはエンドシステムに関する必要条件を満たすのに使用されるかもしれませんが、Session Layerはプロトコル・スタックで信じられた逆多重化をサポートすることができないくらい高いです。 中間システムが定義上Network Layerの上でプロトコルを処理しないので中間システムに関する必要条件を満たすのにSession Layerを使用できません。 Session Layerの機密保護ラベルはTransport Layerの機密保護ラベルの少しの利点も示しません。
5.6 Layer 6, The Presentation Layer
5.6 層6、プレゼンテーション層
Explicit security labels are possible in the Presentation Layer. The presentation syntax may include a security label. This approach naturally performs translation to the local label format and supports both connectionless and connection-oriented security labeling.
明白な機密保護ラベルはPresentation Layerで可能です。 プレゼンテーション構文は機密保護ラベルを含むかもしれません。 このアプローチは、自然に地方のラベル形式に翻訳を実行して、コネクションレスなものと同様に接続指向のセキュリティがラベリングであるとサポートします。
Implicit security labels are also possible in the Presentation Layer. Such labels could be either connectionless or connection-oriented.
また、内在している機密保護ラベルもPresentation Layerで可能です。 そのようなラベルは、コネクションレスであるか、または接続指向であるかもしれません。
Security labels in the Presentation Layer may be used to meet the requirements of end systems, but the Presentation Layer is too high in the protocol stack to support trusted demultiplexing. The Presentation Layer cannot be used to meet the requirements of intermediate systems because intermediate systems, by definition, do
Presentation Layerの機密保護ラベルはエンドシステムに関する必要条件を満たすのに使用されるかもしれませんが、Presentation Layerはプロトコル・スタックで信じられた逆多重化をサポートすることができないくらい高いです。 中間システムが定義上するので中間システムに関する必要条件を満たすのにPresentation Layerを使用できません。
Housley [Page 10] RFC 1457 Security Label Framework for the Internet May 1993
インターネット1993年5月のためのHousley[10ページ]RFC1457機密保護ラベルフレームワーク
not process protocols above the Network Layer. To date, no Presentation Layer protocols have been standardized which include security labels.
Network Layerの上のプロセスプロトコルでない。 これまで、機密保護ラベルを含んでいるPresentation Layerプロトコルが全く標準化されていません。
5.7 Layer 7, The Application Layer
5.7 層7、応用層
Explicit security labels are possible in the Application Layer. The CCITT X.400 message handling system includes security labels in message envelopes [18]. Other Application Layer protocols will probably include security labels in the future. These labels could be either connectionless or connection-oriented. Should security labels be incorporated into transaction processing protocols and message handling protocols, these will most likely be connectionless security labels; should security labels be incorporated into other application protocols, these will most likely be connection-oriented security labels. Application layer protocols are unique in that they can include security label information which is specific to a particular application without burdening other applications with the syntax or semantics of that security label.
明白な機密保護ラベルはApplication Layerで可能です。 CCITT X.400メッセージハンドリングシステムはメッセージ封筒[18]に機密保護ラベルを含んでいます。 他のApplication Layerプロトコルは将来、たぶん機密保護ラベルを含むでしょう。 これらのラベルは、コネクションレスであるか、または接続指向であるかもしれません。 機密保護ラベルがトランザクション処理プロトコルとメッセージハンドリングプロトコルに組み入れられると、これらはたぶんコネクションレスな機密保護ラベルになるでしょう。 機密保護ラベルが他のアプリケーション・プロトコルに組み入れられると、これらはたぶん接続指向の機密保護ラベルになるでしょう。 その機密保護ラベルの構文か意味論で他のアプリケーションを負担しないで特定用途に特定の機密保護ラベル情報は含むことができるので、応用層プロトコルはユニークです。
Store and forward application protocols, like electronic messaging and directory protocols, deserve special attention. In terms of the OSI Reference Model, they are end system protocols, but multiple end systems cooperate to provide the communications service. End systems may use security labels to determine which end system should be next in a chain of store and forward interactions; this use of security labels is very similar to the label-based routing/relay decisions made by routers except that the security labels are carried in an Application Layer protocol. Also, Application Layer protocols must be used to carry security labels in a store and forward application when sensitivity labels must be concealed from some end systems in the chain or when some end systems in the chain are untrustworthy.
アプリケーション・プロトコルを保存して、進めてください、そして、電子メッセージ通信とディレクトリプロトコルのように、特別な注意に値してください。 OSI Reference Modelに関して、それらは終わりのシステムプロトコルですが、複数のエンドシステムが協力して、情報提供サービスを提供します。 エンドシステムは店と前進の相互作用のチェーンでどのエンドシステムが次であるべきであるかを決定するのに機密保護ラベルを使用するかもしれません。 機密保護ラベルのこの使用はルータによって機密保護ラベルがApplication Layerプロトコルで運ばれるのを除いて、されたラベルベースのルーティング/リレー決定と非常に同様です。 また、いくつかのエンドシステムからチェーンで感度ラベルを隠さなければならない、さもなければ、チェーンにおけるいくつかのエンドシステムが信頼できないときに、店と前進のアプリケーションで機密保護ラベルを運ぶのにApplication Layerプロトコルを使用しなければなりません。
Implicit security labels are also possible in the Application Layer. These labels could be either connectionless or connection-oriented. Application title or well know port number might be used to determine the implicit label.
また、内在している機密保護ラベルもApplication Layerで可能です。 これらのラベルは、コネクションレスであるか、または接続指向であるかもしれません。 応用名称か井戸が、ポートナンバーが内在しているラベルを決定するのに使用されるかもしれないのを知っています。
Security labels in the Application Layer may be used to meet the requirements of end systems, but the Application Layer is too high in the protocol stack to support trusted demultiplexing. The Application Layer cannot be used to meet the requirements of intermediate systems because intermediate systems, by definition, do not process protocols above the Network Layer.
Application Layerの機密保護ラベルはエンドシステムに関する必要条件を満たすのに使用されるかもしれませんが、Application Layerはプロトコル・スタックで信じられた逆多重化をサポートすることができないくらい高いです。 中間システムが定義上Network Layerの上でプロトコルを処理しないので中間システムに関する必要条件を満たすのにApplication Layerを使用できません。
Housley [Page 11] RFC 1457 Security Label Framework for the Internet May 1993
インターネット1993年5月のためのHousley[11ページ]RFC1457機密保護ラベルフレームワーク
6.0 Summary
6.0 概要
Very few hard rules exist for security labels. Internet architects and protocol designers face many tradeoffs when making security label placement decisions. However, a few guidelines can be derived from the preceding discussion:
ほんのわずかな困難な規則は機密保護ラベルのために存在しています。 セキュリティをラベルプレースメント決定にするとき、インターネット建築家とプロトコルデザイナーは多くの見返りに直面しています。 しかしながら、前の議論からいくつかのガイドラインを得ることができます:
First, security label-based routing decisions are best supported by explicit security labels in the Data Link Layer and the Network Layer. When bridges are making the routing decisions, the Data Link Layer should carry the explicit security label; when routers are making the routing decisions, the Network Layer should carry the explicit security label.
まず最初にData Link LayerとNetwork Layerの明白な機密保護ラベルでセキュリティのラベルベースのルーティング決定を後押ししているのは最も良いです。 ブリッジがルーティングを決定にしているとき、Data Link Layerは明白な機密保護ラベルを運ぶはずです。 ルータがルーティングを決定にしているとき、Network Layerは明白な機密保護ラベルを運ぶはずです。
Second, when security labels are specific to a particular application it is wise to define them in the application protocol, so that these security labels will not burden other applications on the network.
機密保護ラベルが特定用途に特定であるときに、2番目に、アプリケーション・プロトコルでそれらを定義するのは賢明です、これらの機密保護ラベルがネットワークにおける他のアプリケーションを負わないように。
Third, when trusted demultiplexing is a concern, the Network Layer (preferably the SNICP) or Transport Layer should be used to carry the explicit security label. The SNICP or transport protocol are especially attractive when combined with a cryptographic protocol that binds the security label to the data and protects the both against undetected modification.
信じられた逆多重化が関心であることの3番目、Network Layer(望ましくはSNICP)またはTransport Layerが、明白な機密保護ラベルを運ぶのに使用されるべきです。 データに機密保護ラベルを縛って、非検出された変更に対して両方を保護する暗号のプロトコルに結合されると、SNICPかトランスポート・プロトコルが特に魅力的です。
Fourth, to avoid explicit security label translation, a common explicit security label format should be defined for the Internet. Registration of security label semantics should be used so that many security policies can be supported by the common explicit security label syntax.
4番目に、明白な機密保護ラベル翻訳を避けるために、一般的な明白な機密保護ラベル書式はインターネットと定義されるべきです。 機密保護ラベル意味論の登録は、一般的な明白な機密保護ラベル構文で多くの安全保障政策をサポートすることができるように使用されるべきです。
References
参照
[1] ISO Open Systems Interconnection - Basic Reference Model (ISO 7498). International Organization for Standardization, 1981.
[1]ISO開放型システム間相互接続--基本参照モデル(ISO7498)。 国際標準化機構、1981。
[2] Dictionary of Military and Associated Terms (JCS Pub 1). Joint Chiefs of Staff. 1 April 1984.
[2] 軍事の、そして、関連している用語(JCSパブ1)の辞書。 統合参謀本部。 1984年4月1日。
[3] Security Requirements for Automatic Data Processing (ADP) Systems (DODD 5200.28). Department of Defense. 21 March 1988.
[3] オートマティック・データ・プロセシング(ADP)システム(ドッド5200.28)のためのセキュリティ要件。 国防総省。 1988年3月21日。
[4] Information Processing Systems - Open Systems Interconnection Reference Model - Security Architecture (ISO 7498-2). Organization for Standardization, 1988.
[4]情報処理システム--オープンシステムインタコネクト参照はモデル化されます--セキュリティー体系(ISO7498-2)。 標準化、1988年の組織。
[5] Biba, K. J. "Integrity Considerations for Secure Computer Systems", MTR-3153, The Mitre Corporation, April 1977.
[5] ビバ、K. J. 「安全なコンピュータシステムズのための保全問題」、MTR-3153、斜め継ぎ社、1977年4月。
Housley [Page 12] RFC 1457 Security Label Framework for the Internet May 1993
インターネット1993年5月のためのHousley[12ページ]RFC1457機密保護ラベルフレームワーク
[6] Bell, D. E.; LaPadula, L. J. "Secure Computer System: Unified Exposition and Multics Interpretation", MTR-2997, The MITRE Corporation, March 1976.
[6] ベル、D.E.。 L. J. LaPadula、「コンピュータ・システムを固定してください」 「統一されたエキスポとMultics解釈」(MTR-2997、斜め継ぎ社)は1976を行進させます。
[7] Kent, S. "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, BBN Communications, November 1992.
[7] ケント、S. 「インターネットプロトコルのための米国国防総省のセキュリティオプション」、RFC1108、BBNコミュニケーション、1992年11月。
[8] Trusted Computer System Evaluation Criteria (DoD 5200.28-STD) National Computer Security Center, 26 December 1985.
[8] 信じられたコンピュータシステム評価(DoD 5200.28-STD)の国家のコンピュータセキュリティセンター、1985年12月26日。
[9] Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria, (NCSC-TG-005, Version-1). National Computer Security Center, 31 July 1987.
[9] 信じられたコンピュータシステム評価、(NCSC-TG-005、バージョン-1)の信じられたネットワーク解釈。 国家のコンピュータセキュリティセンター、1987年7月31日。
[10] Nazario, Noel (Chairman). "Standard Security Label for GOSIP An Invitational Workshop", NISTIR 4614, June 1991.
[10]Nazario、クリスマス(議長)。 「標準のセキュリティはGOSIPのために招待者に限る催しワークショップをラベルする」NISTIR4614、1991年6月。
[11] Dinkel, Charles (Editor). "Secure Data Network System (SDNS) Network, Transport, and Message Security Protocols", NISTIR 90- 4250, February 1990, pp 39-62.
[11] ディンケル、チャールズ(エディタ)。 「安全なData Network System(SDNS)のネットワーク、Transport、およびMessage Securityプロトコル」、NISTIR90- 4250 1990年2月、pp39-62。
[12] Dinkel, Charles (Editor). "Secure Data Network System (SDNS) Key Management Documents", NISTIR 90-4262, February 1990.
[12] ディンケル、チャールズ(エディタ)。 「安全なデータ網システム(SDNS)Key Managementドキュメント」、NISTIR90-4262、1990年2月。
[13] IEEE Standards for Local Area Networks: Logical Link Control, IEEE 802.2. The Institute of Electrical and Electronics Engineers, Inc, 1984.
[13] ローカル・エリア・ネットワークのIEEE規格: 論理的なリンク制御、IEEE802.2。 米国電気電子技術者学会、Inc、1984。
[14] IEEE Standards for Local Area Networks: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specification, IEEE 802.3. The Institute of Electrical and Electronics Engineers, Inc, 1985.
[14] ローカル・エリア・ネットワークのIEEE規格: IEEE802.3、衝突検出型搬送波検知多重アクセス(CSMA/CD)はメソッドと物理的な層の仕様にアクセスします。 米国電気電子技術者学会、Inc、1985。
[15] Recommendation X.25, Interface Between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminals Operating in the Packet Mode on Public Data Networks. Consultative Committee, International Telephone and Telegraph (CCITT), 1984.
[15] 推薦X.25、公共のデータ網がパケット形態で作動して、データ端末装置(DTE)とデータ回線終端装置(DCE)の間で端末に連結してください。 諮問委員会、国際電信電話(CCITT)、1984。
[16] Information Processing Systems - Open Systems Interconnection - Connection oriented transport protocol specification (ISO 8073). Organization for Standardization, 1985. [Also ISO 8208]
[16] 情報Processing Systems--オープン・システム・インターコネクション--接続は輸送プロトコル仕様(ISO8073)を適応させました。 標準化、1985年の組織。 [ISO8208も]
[17] Information Processing Systems - Open Systems Interconnection - Protocol for providing the connectionless-mode transport service (ISO 8602). Organization for Standardization, 1986.
[17] 情報Processing Systems(オープン・システム・インターコネクション)は、コネクションレスなモード輸送サービス(ISO8602)を提供するために議定書を作ります。 標準化、1986年の組織。
Housley [Page 13] RFC 1457 Security Label Framework for the Internet May 1993
インターネット1993年5月のためのHousley[13ページ]RFC1457機密保護ラベルフレームワーク
[18] Recommendation X.411, Message Handling Systems: Message Transfer System: Abstract Service Definition and Procedures. Consultative Committee, International Telephone and Telegraph (CCITT), 1988. [Also ISO 8883-1]
[18] 推薦X.411、メッセージハンドリングシステム: メッセージ転送システム: 抽象的なサービス定義と手順。 諮問委員会、国際電信電話(CCITT)、1988。 [ISO8883-1も]
Security Considerations
セキュリティ問題
This entire memo is devoted to a discussion of a Framework for labeling information for security purposes in network protocols.
この全体のメモはネットワーク・プロトコルのセキュリティ目的のためのラベリング情報のためにFrameworkの議論にささげられます。
Author's Address
作者のアドレス
Russell Housley Xerox Special Information Systems 7900 Westpark Drive McLean, Virginia 22102
ラッセル・Housleyのゼロックスの特別な情報システム7900Westpark Driveマクリーン、ヴァージニア 22102
Phone: 703-790-3767 EMail: Housley.McLean_CSD@Xerox.COM
以下に電話をしてください。 703-790-3767 メールしてください: Housley.McLean_CSD@Xerox.COM
Housley [Page 14]
Housley[14ページ]
一覧
スポンサーリンク