[要約] RFC 7569は、強制アクセス制御（MAC）セキュリティラベル形式のためのレジストリ仕様であり、セキュリティラベル形式の標準化と相互運用性を目的としています。
Internet Engineering Task Force (IETF) D. Quigley
Request for Comments: 7569
Category: Standards Track J. Lu
ISSN: 2070-1721 Oracle
T. Haynes
Primary Data
July 2015
Registry Specification for Mandatory Access Control (MAC) Security Label Formats
必須アクセス制御（MAC）セキュリティラベル形式のレジストリ仕様
Abstract
概要
In the past, Mandatory Access Control (MAC) systems have used very rigid policies that were implemented in particular protocols and platforms. As MAC systems become more widely deployed, additional flexibility in mechanism and policy will be required. While traditional trusted systems implemented Multi-Level Security (MLS) and integrity models, modern systems have expanded to include such technologies as type enforcement. Due to the wide range of policies and mechanisms that need to be accommodated, it is unlikely that the use of a single security label format and model will be viable.
これまで、強制アクセス制御（MAC）システムは、特定のプロトコルとプラットフォームに実装された非常に厳格なポリシーを使用していました。 MACシステムがより広く展開されるようになると、メカニズムとポリシーに追加の柔軟性が必要になります。従来の信頼できるシステムはマルチレベルセキュリティ（MLS）と整合性モデルを実装していましたが、最新のシステムは型強制などのテクノロジーを含むように拡張されています。対応が必要なポリシーとメカニズムは多岐にわたるため、単一のセキュリティラベル形式とモデルを使用することは現実的ではありません。
To allow multiple MAC mechanisms and label formats to co-exist in a network, this document creates a registry of label format specifications. This registry contains label format identifiers and provides for the association of each such identifier with a corresponding extensive document outlining the exact syntax and use of the particular label format.
複数のMACメカニズムとラベル形式をネットワークで共存させるために、このドキュメントではラベル形式仕様のレジストリを作成します。このレジストリにはラベル形式の識別子が含まれており、そのような各識別子と、特定のラベル形式の正確な構文と使用法を概説する対応する広範なドキュメントとの関連付けを提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7569.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7569で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions .....................................................4
3. Existing Label Format Specifications ............................4
3.1. IP Security Option (IPSO), Basic Security Option (BSO) .....4
3.2. Commercial IP Security Option (CIPSO) ......................5
3.3. Common Architecture Label IPv6 Security Option (CALIPSO) ...5
3.4. Flux Advanced Security Kernel (FLASK) ......................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................5
5.1. Initial Registry ...........................................6
5.2. Adding a New Entry to the Registry .........................7
5.3. Obsoleting a Label Format Specifier ........................8
5.4. Modifying an Existing Entry in the Registry ................8
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References .....................................9
Acknowledgments ...................................................10
Authors' Addresses ................................................10
With the acceptance of security labels in several mainstream operating systems, the need to communicate labels between these systems becomes more important. In a typical client-and-server scenario, the client request to the server acts as a subject trying to access an object on the server [RFC7204]. Unfortunately, these systems are diverse enough that attempts at establishing one common label format have been unsuccessful. This is because systems implement different Mandatory Access Control (MAC) models, which typically do not share any common ground.
いくつかの主流のオペレーティングシステムでセキュリティラベルが受け入れられるようになると、これらのシステム間でラベルを通信する必要性がより重要になります。典型的なクライアントとサーバーのシナリオでは、サーバーへのクライアント要求は、サーバー上のオブジェクトにアクセスしようとする主体として機能します[RFC7204]。残念ながら、これらのシステムは非常に多様であるため、1つの共通ラベル形式を確立する試みは失敗しています。これは、システムが異なる共通アクセス制御（MAC）モデルを実装しているためです。これらのモデルは通常、共通の基盤を共有していません。
One solution might be to define a single label format that consists of the union of the requirements of all MAC models/implementations, known at a given time. This approach is not desirable, because it introduces an environment where either (1) many MAC models would have blank fields for many of the label's components or (2) many implementations would ignore altogether many of the values that are present. The resulting complexity would be likely to result in a confusing situation in which the interaction of fields that are derived from different MAC models is never clearly specified and the addition of new models or extensions of existing models is unduly difficult.
1つの解決策は、特定の時点で既知のすべてのMACモデル/実装の要件の和集合で構成される単一のラベル形式を定義することです。このアプローチは、（1）多くのMACモデルがラベルのコンポーネントの多くに対して空白のフィールドを持つか、（2）多くの実装が存在する多くの値を完全に無視する環境を導入するため、望ましくありません。結果として生じる複雑さは、異なるMACモデルから派生したフィールドの相互作用が明確に指定されず、新しいモデルの追加や既存のモデルの拡張が過度に困難である、混乱する状況をもたらす可能性があります。
An additional consideration is that if a policy authority or identifier field is specified in the label format, it would require a robust description that would encompass multiple MAC models where an implementation would lock policy administration into the described model.
追加の考慮事項は、ポリシー機関または識別子フィールドがラベル形式で指定されている場合、実装がポリシー管理を記述されたモデルにロックする複数のMACモデルを網羅する堅牢な記述が必要になることです。
Ideally, a mechanism to address this problem should allow the most flexibility possible in terms of policy administration while providing a specification that is sufficient to allow for implementation of the label format and understanding of the semantics of the label. This means that the label format specification would ideally contain a syntactic description of the label format and a description of the semantics for each component in the label. This allows protocols to specify the type of label and label semantics that it requires while leaving policy and policy administration to the individual organizations using the protocol in their environment.
理想的には、この問題に対処するメカニズムは、ラベル形式の実装とラベルのセマンティクスの理解を可能にするのに十分な仕様を提供しながら、ポリシー管理の観点から可能な限りの柔軟性を可能にする必要があります。つまり、ラベル形式の仕様には、理想的にはラベル形式の構文記述とラベル内の各コンポーネントのセマンティクスの記述が含まれます。これにより、プロトコルは、必要なラベルのタイプとラベルのセマンティクスを指定でき、ポリシーとポリシーの管理は、その環境でプロトコルを使用する個々の組織に任せます。
Policy administration within an organization is a difficult problem. This should not be made even more difficult by having to request permission from external entities when crafting new policy or just making department specific modifications to existing policies. The policy authority field would allow a label format specification to specify a scheme for policy administration without forcing it on all users of security labels. However, by agreeing to implement a particular label format specification, the protocol agrees to that policy administration mechanism when processing labels of that type.
組織内のポリシー管理は難しい問題です。これは、新しいポリシーを作成するとき、または単に既存のポリシーに部門固有の変更を加えるときに、外部エンティティからの許可を要求する必要があることによって、さらに難しくするべきではありません。ポリシー機関フィールドでは、ラベル形式の仕様で、セキュリティラベルのすべてのユーザーに強制することなく、ポリシー管理のスキームを指定できます。ただし、特定のラベル形式の仕様を実装することに同意することにより、プロトコルはそのタイプのラベルを処理するときにそのポリシー管理メカニズムに同意します。
This document creates a registry of label format specifications to allow multiple MAC mechanisms and label formats to co-exist in a network. While the initial use of this registry is for the Network File System (NFS) protocol, it might also be referenced and used by other IETF protocols in the future.
このドキュメントでは、ラベル形式仕様のレジストリを作成して、複数のMACメカニズムとラベル形式をネットワークで共存させることができます。このレジストリの最初の使用はネットワークファイルシステム（NFS）プロトコル用ですが、将来的には他のIETFプロトコルでも参照および使用される可能性があります。
Label Format Specifier: an identifier used by the client to establish the syntactic format of the security label and the semantic meaning of its components.
ラベル形式指定子：セキュリティラベルの構文形式とそのコンポーネントの意味の意味を確立するためにクライアントが使用する識別子。
Label Format Specification: a reference to a stable, public document that specifies the label format.
ラベル形式の仕様：ラベル形式を指定する安定した公開ドキュメントへの参照。
Multi-Level Security (MLS): a traditional model where subjects are given a security level (Unclassified, Secret, Top Secret, etc.) and objects are given security labels that mandate the access of the subject to the object (see [BL73] and [RFC2401]).
マルチレベルセキュリティ（MLS）：サブジェクトにセキュリティレベル（未分類、シークレット、トップシークレットなど）が付与され、オブジェクトにサブジェクトからオブジェクトへのアクセスを要求するセキュリティラベルがオブジェクトに付与される従来のモデル（[BL73]を参照）および[RFC2401]）。
(Although RFC 2401 has been obsoleted by RFC 4301, RFC 2401 is still the definitive reference for MLS as discussed in this document.)
（RFC 2401はRFC 4301によって廃止されましたが、このドキュメントで説明されているように、RFC 2401はMLSの最も信頼できるリファレンスです。）
object: a passive resource within the system that we wish to protect. Objects can be entities such as files, directories, pipes, sockets, and many other system resources relevant to the protection of the system state.
オブジェクト：保護したいシステム内のパッシブリソース。オブジェクトは、ファイル、ディレクトリ、パイプ、ソケット、およびシステム状態の保護に関連する他の多くのシステムリソースなどのエンティティです。
subject: an active entity, usually a process, user, or client, that is requesting access to an object.
サブジェクト：オブジェクトへのアクセスを要求しているアクティブなエンティティ、通常はプロセス、ユーザー、またはクライアント。
The "IP Security Option (IPSO)" label format is defined in [RFC1108]. IANA has assigned IPv4 Option 130 to the IPSO Basic Security Option (BSO). IPSO is the only IPv4 sensitivity label option implemented in commercial IP routers. IPSO BSO continues to have widespread implementation in hosts, and widespread deployment. For the purposes of this document, only the BSO labels in Table 1 on Page 3 of [RFC1108] are used.
「IP Security Option（IPSO）」ラベル形式は[RFC1108]で定義されています。 IANAはIPv4オプション130をIPSO基本セキュリティオプション（BSO）に割り当てました。 IPSOは、商用IPルーターに実装されている唯一のIPv4機密ラベルオプションです。 IPSO BSOは、ホストでの広範な実装、および広範な展開を続けています。このドキュメントでは、[RFC1108]の3ページの表1にあるBSOラベルのみが使用されています。
In some locales, the BSO value "(Reserved 2)" is used for marking information that is considered "Restricted" by local policy, where "Restricted" is less sensitive than "Confidential" but more sensitive than "Unclassified".
一部のロケールでは、BSO値「（予約済み2）」は、ローカルポリシーによって「制限付き」と見なされる情報をマークするために使用されます。「制限付き」は「機密」よりも機密性が低く、「未分類」よりも機密性が高くなります。
The "Commercial IP Security Option (CIPSO)" label format is documented in [CIPSO] and in [FIPS-188]. While [CIPSO] is long expired, it is widely supported in deployed MLS systems that support IPv4. IANA has assigned IPv4 option number 134 to CIPSO. CIPSO is defined ONLY as an IPv4 option. IANA has never assigned any IPv6 option value to CIPSO.
「商用IPセキュリティオプション（CIPSO）」ラベル形式は、[CIPSO]と[FIPS-188]で文書化されています。 [CIPSO]は期限切れですが、IPv4をサポートする展開されたMLSシステムで広くサポートされています。 IANAはIPv4オプション番号134をCIPSOに割り当てました。 CIPSOは、IPv4オプションとしてのみ定義されます。 IANAがIPv6オプション値をCIPSOに割り当てたことはありません。
The "Common Architecture Label IPv6 Security Option (CALIPSO)" label format is specified in [RFC5570] and is defined for IPv6. As noted in Section 10 of [RFC5570], CALIPSO is a direct derivative of the IPv4 "Son of IPSO" (SIPSO); therefore, CALIPSO is NOT derived from CIPSO in any way.
「Common Architecture Label IPv6 Security Option（CALIPSO）」ラベル形式は[RFC5570]で指定されており、IPv6用に定義されています。 [RFC5570]のセクション10で述べたように、CALIPSOはIPv4「Son of IPSO」（SIPSO）の直接の派生物です。したがって、CALIPSOはCIPSOから派生したものではありません。
The Flux Advanced Security Kernel (FLASK) [FLASK99] is an implementation of an architecture to provide flexible support for security policies. Section 2.1 of [FLASK99b] summarizes the architecture of FLASK and describes:
Flux Advanced Security Kernel（FLASK）[FLASK99]は、セキュリティポリシーの柔軟なサポートを提供するアーキテクチャの実装です。 [FLASK99b]のセクション2.1は、FLASKのアーキテクチャを要約し、次のことを説明しています。
1. the interactions between a subsystem that enforces security policy decisions and a subsystem that makes those decisions.
1. セキュリティポリシーの決定を実施するサブシステムとそれらの決定を行うサブシステムの間の相互作用。
2. the requirements on the components within each subsystem.
2. 各サブシステム内のコンポーネントの要件。
This document defines a mechanism to associate the Label Format Specifier identifier with a document outlining the syntax and format of a label. There are no security considerations for such an association. The label specification documents referenced by each registration entry should state security considerations for the label mechanism it specifies.
このドキュメントでは、ラベル形式指定子識別子をラベルの構文と形式の概要を示すドキュメントに関連付けるメカニズムを定義しています。このような関連付けには、セキュリティに関する考慮事項はありません。各登録エントリで参照されるラベル仕様ドキュメントには、指定するラベルメカニズムのセキュリティに関する考慮事項を記載する必要があります。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding the creation of a new registry in accordance with [RFC5226].
このセクションは、[RFC5226]に準拠した新しいレジストリの作成に関するInternet Assigned Numbers Authority（IANA）へのガイダンスを提供します。
Per this document, IANA has created a new registry called "Security Label Format Selection Registry". The new registry has the following fields:
このドキュメントに従って、IANAは「セキュリティラベル形式選択レジストリ」と呼ばれる新しいレジストリを作成しました。新しいレジストリには次のフィールドがあります。
Label Format Specifier: An integer that maps to a particular label format, e.g., the CALIPSO label format defined by [RFC5570]. The namespace of this identifier has the range of 0..65535.
ラベル形式指定子：特定のラベル形式にマップする整数。たとえば、[RFC5570]で定義されているCALIPSOラベル形式。この識別子の名前空間の範囲は0..65535です。
Label Description: A human-readable ASCII [RFC20] text string that describes the label format, e.g., "Common Architecture Label IPv6 Security Option (CALIPSO)". The length of this field is limited to 128 bytes.
ラベルの説明：「Common Architecture Label IPv6 Security Option（CALIPSO）」など、ラベル形式を説明する人間が読めるASCII [RFC20]テキスト文字列。このフィールドの長さは128バイトに制限されています。
Status: A short ASCII text string indicating the status of an entry in the registry. The status field for most entries should have the value "active". In the case where a label format selection entry is obsolete, the status field of the obsoleted entry should be "obsoleted by entry NNN".
ステータス：レジストリのエントリのステータスを示す短いASCIIテキスト文字列。ほとんどのエントリのステータスフィールドの値は「アクティブ」である必要があります。ラベル形式選択エントリが廃止された場合、廃止されたエントリのステータスフィールドは「エントリNNNによって廃止され」ます。
Label Format Specification: A reference to a stable, public document that specifies the label format, e.g., a URL to [RFC5570].
ラベル形式の仕様：[RFC5570]へのURLなど、ラベル形式を指定する安定した公開ドキュメントへの参照。
The initial assignments of the registry are as follows:
レジストリの初期割り当ては次のとおりです。
+---------------+---------------------+--------+--------------------+
| Label Format | Description | Status | Reference |
| Specifier | | | |
+---------------+---------------------+--------+--------------------+
| 0 | Reserved | - | - |
| 1 - 127 | Private Use | - | - |
| 128 - 255 | Experimental Use | - | - |
| 256 | CIPSO (tag type #1) | active | [FIPS-188] |
| 257 | CALIPSO [RFC5570] | active | [RFC5570] |
| 258 | FLASK Security | active | [FLASK99] |
| | Context | | |
| 259 | IPSO | active | [RFC1108] |
| 260 - 65535 | Available for IANA | - | - |
| | Assignment | | |
+---------------+---------------------+--------+--------------------+
Label Format Specifier Ranges
ラベル形式指定子の範囲
Table 1
表1
A label format specification document is required to add a new entry to the "Security Label Format Selection Registry". If the label format document is inside the RFC path, then the IANA Considerations section of the label format document should clearly reference the "Security Label Format Selection Registry" and request allocation of a new entry. The well-known IANA policy Specification Required, as defined in Section 4.1 of [RFC5226], will be used to handle such requests. Note that the "Specification Required" policy implies that this process requires a Designated Expert, i.e., adding a new entry to this registry requires both a published label format specification and a Designated Expert review.
「セキュリティラベルフォーマット選択レジストリ」に新しいエントリを追加するには、ラベルフォーマット仕様書が必要です。ラベルフォーマットドキュメントがRFCパス内にある場合、ラベルフォーマットドキュメントのIANA考慮事項セクションは、「セキュリティラベルフォーマット選択レジストリ」を明確に参照し、新しいエントリの割り当てを要求する必要があります。 [RFC5226]のセクション4.1で定義されている、よく知られたIANAポリシー仕様がこのようなリクエストを処理するために使用されます。 「Specification Required」ポリシーは、このプロセスにはDesignated Expertが必要であることを示しています。つまり、このレジストリに新しいエントリを追加するには、公開されたラベル形式の仕様とDesignated Expertレビューの両方が必要です。
In reviewing the published label format specification, the Designated Expert should consider whether or not the specification provides sufficient semantics for the object and subject labels to enforce the MAC model and policy administration when deployed within an organization. Another consideration is if the label format allows a correct and complete implementation of the protocol to process and enforce labels as a policy administration mechanism. Finally, to reduce interoperability issues, the reviewer must determine if the new label format specification has clearly defined syntax and semantics for the proposed new labels.
公開されたラベル形式の仕様を確認する際、指定専門家は、仕様がオブジェクトおよびサブジェクトラベルに十分なセマンティクスを提供して、組織内に展開されたときにMACモデルとポリシー管理を実施するかどうかを検討する必要があります。もう1つの考慮事項は、ラベルのフォーマットにより、プロトコル管理メカニズムとしてラベルを処理および適用するプロトコルの正確かつ完全な実装が可能かどうかです。最後に、相互運用性の問題を減らすために、レビュー担当者は、新しいラベル形式の仕様で、提案された新しいラベルの構文とセマンティクスが明確に定義されているかどうかを判断する必要があります。
In the case where a label format selector number is assigned to a label format and the label format specification is changed later, a new selector assignment should be requested. The same Specification Required IANA policy applies to such requests. The IANA Considerations section of the updated label format specification should be explicit regarding which old label selector assignment it obsoletes. Below is an example of an obsoleted entry in the registry:
ラベルフォーマットセレクター番号がラベルフォーマットに割り当てられ、ラベルフォーマット仕様が後で変更された場合、新しいセレクター割り当てを要求する必要があります。同じ仕様が必要なIANAポリシーがそのようなリクエストに適用されます。更新されたラベル形式仕様のIANAの考慮事項セクションでは、廃止された古いラベルセレクター割り当てについて明示する必要があります。以下は、レジストリで廃止されたエントリの例です。
+--------------+--------------------+-----------+-------------------+
| Label Format | Description | Status | Reference |
| Specifier | | | |
+--------------+--------------------+-----------+-------------------+
| 0 | Reserved | - | - |
| 1 - 127 | Private Use | - | - |
| 128 - 255 | Experimental Use | - | - |
| 256 | CIPSO (tag type | active | [FIPS-188] |
| | #1) | | |
| 257 | CALIPSO [RFC5570] | active | [RFC5570] |
| 258 | FLASK Security | obsoleted | [FLASK99] |
| | Context | by 263 | |
| ... | | | |
| 263 | FLASK Security | active | [new spec URL] |
| | Context (v2) | | |
| 264 - 65535 | Available for IANA | - | - |
| | Assignment | | |
+--------------+--------------------+-----------+-------------------+
Example Label Format Specifier Updated Ranges
ラベル形式指定子の更新された範囲の例
Table 2
表2
A request to modify either the Description or the published label format specification will also require the Specification Required IANA policy to be applied. The Designated Expert reviewer will need to determine if the published label format specification either obsoletes the Label Format Specifier or updates the label syntax and/ or model. If the Label Format Specifier is obsoleted, then the reviewer will follow the process defined in Section 5.3. Otherwise, for the update of the label syntax and/or the model, the reviewer will approve the change.
説明または公開されたラベル形式の仕様を変更するリクエストには、Specification Required IANAポリシーを適用する必要もあります。 Designated Expertレビュアーは、公開されたラベル形式の仕様がラベル形式指定子を廃止するか、ラベルの構文やモデルを更新するかを決定する必要があります。ラベル形式指定子が廃止された場合、レビュー担当者はセクション5.3で定義されたプロセスに従います。それ以外の場合は、ラベルの構文やモデルを更新するために、レビュー担当者が変更を承認します。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<http://www.rfc-editor.org/info/rfc20>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[BL73] Bell, D. and L. LaPadula, "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74-244, The MITRE Corporation, Bedford, MA, May 1973.
[BL73] Bell、D.、L。LaPadula、「Secure Computer Systems：Mathematical Foundations and Model」、Technical Report M74-244、The MITER Corporation、マサチューセッツ州ベッドフォード、1973年5月。
[CIPSO] IETF CIPSO Working Group, "Commercial IP Security Option (CIPSO 2.2)", Work in Progress, draft-ietf-cipso-ipsecurity-01, July 1992.
[CIPSO] IETF CIPSOワーキンググループ、「商用IPセキュリティオプション（CIPSO 2.2）」、作業中、draft-ietf-cipso-ipsecurity-01、1992年7月。
[FIPS-188] US National Institute of Standards and Technology, "Standard Security Labels for Information Transfer", Federal Information Processing Standards (FIPS) 188, September 1994, <http://csrc.nist.gov/publications/ fips/fips188/fips188.pdf>.
[FIPS-188]米国国立標準技術研究所、「情報転送のための標準セキュリティラベル」、連邦情報処理標準（FIPS）188、1994年9月、<http://csrc.nist.gov/publications/fips/fips188 /fips188.pdf>。
[FLASK99] Spencer, R., Smalley, S., Loscocco, P., Hibler, M., Andersen, D., and J. Lepreau, "The Flask Security Architecture: System Support for Diverse Security Policies", In Proceedings of the Eighth USENIX Security Symposium, pages 123-139, August 1999, <https://www.cs.cmu.edu/~dga/papers/ flask-usenixsec99.pdf>.
[FLASK99] Spencer、R.、Smalley、S.、Loscocco、P.、Hibler、M.、Andersen、D。、およびJ. Lepreau、「Flask Security Architecture：System Support for Diverse Security Policies」、Proceedings of第8回USENIXセキュリティシンポジウム、ページ123-139、1999年8月、<https://www.cs.cmu.edu/~dga/papers/フラスコ-usenixsec99.pdf>。
[FLASK99b] Secure Computing Corporation, "Assurance in the Fluke Microkernel Formal Security Policy Model", Document 00-0930896A001 Rev B, 17 Feb 1999, Secure Computing Corporation, Roseville, MN, USA, February 1999, <http://www.cs.utah.edu/flux/fluke/html/fspm.ps.gz>.
[FLASK99b] Secure Computing Corporation、 "Assurance in the Fluke Microkernel Formal Security Policy Model"、Document 00-0930896A001 Rev B、17 Feb 1999、Secure Computing Corporation、Roseville、MN、USA、February 1999、<http：// www。 cs.utah.edu/flux/fluke/html/fspm.ps.gz>。
[RFC1108] Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, DOI 10.17487/RFC1108, November 1991, <http://www.rfc-editor.org/info/rfc1108>.
[RFC1108]ケントS.、「インターネットプロトコルのための米国国防総省セキュリティオプション」、RFC 1108、DOI 10.17487 / RFC1108、1991年11月、<http://www.rfc-editor.org/info/rfc1108>。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, DOI 10.17487/RFC2401, November 1998, <http://www.rfc-editor.org/info/rfc2401>.
[RFC2401]ケント、S。、およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、DOI 10.17487 / RFC2401、1998年11月、<http://www.rfc-editor.org/info/rfc2401>。
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, DOI 10.17487/RFC5570, July 2009, <http://www.rfc-editor.org/info/rfc5570>.
[RFC5570] StJohns、M.、Atkinson、R。、およびG. Thomas、「Common Architecture Label IPv6 Security Option（CALIPSO）」、RFC 5570、DOI 10.17487 / RFC5570、2009年7月、<http：//www.rfc- editor.org/info/rfc5570>。
[RFC7204] Haynes, T., "Requirements for Labeled NFS", RFC 7204, DOI 10.17487/RFC7204, April 2014, <http://www.rfc-editor.org/info/rfc7204>.
[RFC7204]ヘインズ、T。、「ラベル付きNFSの要件」、RFC 7204、DOI 10.17487 / RFC7204、2014年4月、<http://www.rfc-editor.org/info/rfc7204>。
Acknowledgments
謝辞
Ran Atkinson contributed the text for IPSO.
Ran AtkinsonがIPSOのテキストを寄稿しました。
Dave Noveck helped detangle the terminology.
Dave Noveckが用語のもつれを解きました。
Alexey Melnikov caught that a process was needed for modifying entries in the registry.
Alexey Melnikovさんは、レジストリのエントリを変更するにはプロセスが必要であることを発見しました。
Authors' Addresses
著者のアドレス
David P. Quigley
デビッドP.クイグリー
Email: dpquigl@davequigley.com
Jarrett Lu Oracle
ジャレット・ルー・オラクル
Email: jarrett.lu@oracle.com
Thomas Haynes Primary Data, Inc. 4300 El Camino Real Ste 100 Los Altos, CA 94022 United States
Thomas Haynes Primary Data、Inc. 4300 El Camino Real Ste 100 Los Altos、CA 94022アメリカ合衆国
Phone: +1 408 215 1519
Email: thomas.haynes@primarydata.com