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
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.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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]。不幸的是，这些系统的多样性足以使建立一种通用标签格式的尝试失败。这是因为系统实现了不同的强制访问控制（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.
一种解决方案可能是定义一种单一标签格式，该格式由给定时间已知的所有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 4301已经淘汰了RFC 2401，但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.
[RFC1108]中定义了“IP安全选项（IPSO）”标签格式。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从未向CIPSO分配任何IPv6选项值。
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.
[RFC5570]中规定了“通用体系结构标签IPv6安全选项（CALIPSO）”标签格式，并针对IPv6进行了定义。如[RFC5570]第10节所述，CALIPSO是IPv4“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节总结了烧瓶的结构，并描述了：
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].
本节为互联网分配号码管理局（IANA）提供了关于根据[RFC5226]创建新登记册的指南。
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.
标签描述：一个人类可读的ASCII[RFC20]文本字符串，用于描述标签格式，例如，“公共体系结构标签IPv6安全选项（CALIPSO）”。此字段的长度限制为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 | 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策略规范将用于处理此类请求。请注意，“所需规范”政策意味着该过程需要指定专家，即向该注册表添加新条目需要发布标签格式规范和指定专家审查。
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模型和策略管理。另一个需要考虑的问题是，标签格式是否允许正确完整地实现协议，以作为策略管理机制来处理和执行标签。最后，为了减少互操作性问题，审阅者必须确定新标签格式规范是否为建议的新标签明确定义了语法和语义。
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 | | |
+--------------+--------------------+-----------+-------------------+
+--------------+--------------------+-----------+-------------------+
| 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.
修改说明或已发布标签格式规范的请求还需要应用IANA策略所需的规范。指定的专家评审员需要确定已发布的标签格式规范是否淘汰了标签格式说明符或更新了标签语法和/或模型。如果标签格式说明符已过时，则审查员将遵循第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，“在RFCs中编写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，“安全计算机系统：数学基础和模型”，技术报告M74-244，麻省贝德福德米特尔公司，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）”，正在进行的工作，草案-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安全体系结构：对不同安全策略的系统支持”，《第八届USENIX安全研讨会论文集》，第123-139页，1999年8月<https://www.cs.cmu.edu/~dga/papers/flask-usenix sec99.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]安全计算公司，“Fluke微内核正式安全策略模型中的保证”，文件00-0930896A001版本B，1999年2月17日，安全计算公司，美国明尼苏达州罗斯维尔，1999年2月<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]Kent，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]Kent，S.和R.Atkinson，“互联网协议的安全架构”，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，“通用体系结构标签IPv6安全选项（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]Haynes，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.
戴夫·诺维克帮助解释了术语。
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
Email: dpquigl@davequigley.com
Jarrett Lu Oracle
贾雷特路甲骨文
Email: jarrett.lu@oracle.com
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，加利福尼亚州，美国94022
Phone: +1 408 215 1519
Email: thomas.haynes@primarydata.com
Phone: +1 408 215 1519
Email: thomas.haynes@primarydata.com