idnits 2.17.1 draft-quigley-label-format-registry-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 17, 2014) is 3661 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'FLASK' is defined on line 302, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 D. Quigley 3 Internet-Draft 4 Intended status: Standards Track J. Lu 5 Expires: October 19, 2014 Oracle 6 T. Haynes 7 Primary Data 8 April 17, 2014 10 Registry Specification for Mandatory Access Control(MAC) Security Label 11 Formats 12 draft-quigley-label-format-registry-02.txt 14 Abstract 16 In the past Mandatory Access Control (MAC) systems have used very 17 rigid policies which were hardcoded into the particular protocol and 18 platform. As MAC systems are more widely deployed additional 19 flexibility in mechanism and policy is required. Where traditional 20 trusted systems implemented Multi-Level Security (MLS) and integrity 21 models, modern systems have expanded to include technologies such as 22 type enforcement. Due to the wide range of policies and mechanisms 23 it has proven through past efforts to be virtually impossible to 24 accomodate all parties in one security label format and model. 26 To allow multiple MAC mechanisms and label formats in a network, this 27 document proposes a registry of label format specifications. This 28 registry contains several identifiers to accomodate both integer and 29 string preferences and associates those identifiers with an extensive 30 document outlining the exact syntax and use of the particular label 31 format. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 19, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 70 4. Exisiting Label Format Specifications . . . . . . . . . . . . 4 71 4.1. Commercial IP Security Option (CIPSO) . . . . . . . . . . 4 72 4.2. Common Architecture Label IPv6 Security Option (CALIPSO) 4 73 4.3. Flux Advanced Security Kernel (FLASK) . . . . . . . . . . 4 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 76 6.1. Initial Registry . . . . . . . . . . . . . . . . . . . . 5 77 6.2. Adding a New Entry to the Registry . . . . . . . . . . . 5 78 6.3. Obsoleting a Label Format Selector . . . . . . . . . . . 6 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 81 7.2. Informative References . . . . . . . . . . . . . . . . . 7 82 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7 83 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 7 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 86 1. Introduction 88 With the acceptance of security labels in several mainstream 89 operating systems the need to communicate labels between these 90 systems becomes more important. In a typical client and server 91 scenario, the client request to the server acts as a subject trying 92 to access an object on the server [RFC7204]. Unfortunately these 93 systems are diverse enough that attempts at establishing one common 94 label format have been unsucessful. The reason for this is that 95 systems implement different Mandatory Access Control (MAC) models, 96 which typically do not share any common ground. 98 One solution is to define a single label format which consists of the 99 union of the requirements of all MAC models/implementations. This is 100 not ideal because it introduces an environment where many MAC models 101 would either have blank fields for many of the label's components or 102 will ignore the values that are present all together. This 103 environment introduces waste and complexity where it is not needed. 104 Additionally if a policy authority or identifier field is specified 105 in the label format it would require a robust description that could 106 be implemented which would lock policy administration into the 107 described model. 109 Ideally a mechanism to address this problem should allow the most 110 flexibility possible in terms of policy administration while 111 providing a specification that is suffient to allow for 112 implementation of the label format and understanding of the semantics 113 of the label. This means that the label format specification would 114 ideally contain a syntactic description of the label format and a 115 description of the semantics for each component in the label. This 116 allows protocols to specify the type of label and label semantics 117 that it requires while leaving policy and policy administration to 118 the individual organizations using the protocol in their environment. 120 Policy administration within an organization is a difficult problem. 121 This should not be made even more difficult by having to request 122 permission from external entities when crafting new policy or just 123 making department specific modifications to existing policies. The 124 policy authority field would allow an label format specification to 125 specify a scheme for policy administration without forcing it on all 126 users of security labels. However by agreeing to implement a 127 particular label format specification, the protocol agrees to that 128 policy administration mechanism when processing labels of that type. 130 2. Definitions 132 Label Format Specification: an identifier used by the client to 133 establish the syntactic format of the security label and the 134 semantic meaning of its components. 136 Multi-Level Security (MLS): a traditional model where objects are 137 given a sensitivity level (Unclassified, Secret, Top Secret, etc.) 138 and a category set [RH_MLS]. 140 Object: a passive resource within the system that we wish to 141 protect. Objects can be entities such as files, directories, 142 pipes, sockets, and many other system resources relevant to the 143 protection of the system state. 145 Subject: an active entity, usually a process, that is requesting 146 access to an object. 148 3. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 4. Exisiting Label Format Specifications 156 4.1. Commercial IP Security Option (CIPSO) 158 The Commercial IP Security Option (CIPSO) label format specification 159 is documented in [CIPSO]. While this draft has expired a long time 160 ago, it is the defacto standard for labeled networking. It is also 161 documented in [FIPS-188]. 163 4.2. Common Architecture Label IPv6 Security Option (CALIPSO) 165 The Common Architecture Label IPv6 Security Option (CALIPSO) [CIPSO] 166 is a successor to CIPSO. 168 4.3. Flux Advanced Security Kernel (FLASK) 170 The Flux Advanced Security Kernel (FLASK) is an impelementation of an 171 architecture to provide flexible support for security policies. 173 5. Security Considerations 175 This document defines a mechanism to associate LFS identifier with a 176 document outlining the syntax and format of a label. There is no 177 security consideration in such an association. The label 178 specification documents referenced by each registration entry should 179 state security considerations for the label mechanism it specifies. 181 6. IANA Considerations 183 This section provides guidance to the Internet Assigned Numbers 184 Authority (IANA) regarding creation of a new registry in accordance 185 with [RFC5226]. 187 This submission requests the creation of a new registry called 188 "Security Label Format Selection Registry". The new registry has the 189 following fields: 191 Label Format Selector: An integer number that maps to a particular 192 label format, e.g., the CALIPSO label format defined by [RFC5570]. 193 The name space of this identifier has the range of 0..65,535. 195 Label Description: A human readable ASCII text string that describes 196 the label format, e.g., "Common Architecture Label IPv6 Security 197 Option (CALIPSO)". The length of this field is limited to 128 198 bytes. 200 Status: A short ASCII text string indicating the status of an entry 201 in the registry. The status field for most entries should have 202 the value "active". In the case that a label format selection 203 entry is obsolete, the status field of the obsoleted entry should 204 be "obsoleted by entry NNN". 206 Label Format Specification: A reference to a stable, public document 207 that specify the label format, e.g., an URL to [RFC5570]. 209 6.1. Initial Registry 211 The initial assignments of the registry are as follows: 213 +-----------------+------------------+--------+---------------------+ 214 | Label Format | Description | Status | Reference | 215 | Selector | | | | 216 +-----------------+------------------+--------+---------------------+ 217 | 0 | Reserved | - | - | 218 | 1 - 127 | Private Use | - | - | 219 | 128 - 255 | Experimental Use | - | - | 220 | 256 | CIPSO (tag type | active | [[CIPSO] URL] | 221 | | #1) | | | 222 | 257 | CALIPSO (RFC | active | [[RFC5570] URL] | 223 | | 5570) | | | 224 | 258 | FLASK Security | active | [[FLASK] URL] | 225 | | Context | | | 226 | 258 - 65535 | Unassigned | - | - | 227 +-----------------+------------------+--------+---------------------+ 229 Label Format Specifier Ranges 231 Table 1 233 6.2. Adding a New Entry to the Registry 235 A label format specification document is required to add a new entry 236 to this registry. If the label format document is inside the RFC 237 path, then The IANA Consideration section of the label format 238 document should clearly reference the Label Format Selection registry 239 and request allocation of a new entry. The well-known IANA policy, 240 Specification Required, as defined in section 4.1 of [RFC5226], will 241 be used to handle such requests. Note that "Specification Required" 242 policy implies this process requires a Designated Expert reviewer, 243 i.e., adding a new entry to this registry requires both a published 244 label format specification and a Designated Expert review. 246 6.3. Obsoleting a Label Format Selector 248 In the case that a label format selector number is assigned to a 249 label format and the label format specification is changed later, a 250 new selector assignment should be requested. The same Specification 251 Required IANA policy applies to such requests. The IANA 252 Consideration section of the updated label format specification 253 should be explicit in which old label selector assignment it 254 obsoletes. Below is an example of obsoleted entry in the registry: 256 +---------------+-------------------+------------+------------------+ 257 | Label Format | Description | Status | Reference | 258 | Selector | | | | 259 +---------------+-------------------+------------+------------------+ 260 | 0 | Reserved | - | - | 261 | 1 - 127 | Private Use | - | - | 262 | 128 - 255 | Experimental Use | - | - | 263 | 256 | CIPSO (tag type | active | [[CIPSO] URL] | 264 | | #1) | | | 265 | 257 | CALIPSO (RFC | active | [[RFC5570] URL] | 266 | | 5570) | | | 267 | 258 | FLASK Security | obsoleted | [[FLASK] URL] | 268 | | Context | by 263 | | 269 | ... | | | | 270 | 263 | FLASK Security | active | [new spec URL] | 271 | | Context (v2) | | | 272 | 264 - 65535 | Unassigned | - | - | 273 +---------------+-------------------+------------+------------------+ 275 Example Label Format Specifier Updated Ranges 277 Table 2 279 7. References 281 7.1. Normative References 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", March 1997. 286 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 287 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 288 May 2008. 290 7.2. Informative References 292 [CIPSO] IETF CIPSO Working Group, "Commercial IP Security Option 293 (CIPSO 2.2)", draft-ietf-cipso-ipsecurity-01 (expired), 294 July 1992. 296 [FIPS-188] 297 US National Institute of Standards and Technology, 298 "Standard Security Labels for Information Transfer", 299 Federal Information Processing Standard (FIPS) 188, 300 September 1994. 302 [FLASK] Spencer, R., Smalley, S., Loscocco, P., Hibler, M., 303 Andersen, D., and J. Lepreau, "The Flask Security 304 Architecture: System Support for Diverse Security 305 Policies", In Proceedings of the Eighth USENIX Security 306 Symposium, pages 123-139 , August 1999. 308 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 309 Architecture Label IPv6 Security Option (CALIPSO)", RFC 310 5570, July 2009. 312 [RFC7204] Haynes, T., "Requirements for Labeled NFS", RFC 7204, 313 April 2014. 315 [RH_MLS] "Multi-Level Security (MLS)", "Deployment, configuration 316 and administration of Red Hat Enterprise Linux 5, Edition 317 10", Section 49.6, 2013, . 321 Appendix A. Acknowledgments 323 Appendix B. RFC Editor Notes 325 [RFC Editor: please remove this section prior to publishing this 326 document as an RFC] 328 Authors' Addresses 330 David P. Quigley 332 Email: dpquigl@davequigley.com 333 Jarrett Lu 334 Oracle 336 Email: jarrett.lu@oracle.com 338 Thomas Haynes 339 Primary Data, Inc. 340 4300 El Camino Real Ste 100 341 Los Altos, CA 94022 342 USA 344 Phone: +1 408 215 1519 345 Email: thomas.haynes@primarydata.com