idnits 2.17.1 draft-ietf-nfsv4-lfs-registry-06.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 date (April 20, 2015) is 3288 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 22, 2015 Oracle 6 T. Haynes 7 Primary Data 8 April 20, 2015 10 Registry Specification for Mandatory Access Control (MAC) Security Label 11 Formats 12 draft-ietf-nfsv4-lfs-registry-06.txt 14 Abstract 16 In the past Mandatory Access Control (MAC) systems have used very 17 rigid policies which were implemented in particular protocols and 18 platforms. As MAC systems became more widely deployed, additional 19 flexibility in mechanism and policy will be required. While 20 traditional trusted systems implemented Multi-Level Security (MLS) 21 and integrity models, modern systems have expanded to include 22 technologies such as type enforcement. Due to the wide range of 23 policies and mechanisms which need to be accommodated, it is unlikely 24 that use of a single security label format and model will be viable. 26 To allow multiple MAC mechanisms and label formats to co-exist in a 27 network, this document creates a registry of label format 28 specifications. This registry contains label format identifiers and 29 provides for the association of each such identifier with a 30 corresponding extensive document document outlining the exact syntax 31 and use of the particular label 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 22, 2015. 50 Copyright Notice 52 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Exisiting Label Format Specifications . . . . . . . . . . . . 4 70 3.1. IP Security Option (IPSO), Basic Security Option (BSO) . 4 71 3.2. Commercial IP Security Option (CIPSO) . . . . . . . . . . 4 72 3.3. Common Architecture Label IPv6 Security Option (CALIPSO) 5 73 3.4. Flux Advanced Security Kernel (FLASK) . . . . . . . . . . 5 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 76 5.1. Initial Registry . . . . . . . . . . . . . . . . . . . . 6 77 5.2. Adding a New Entry to the Registry . . . . . . . . . . . 6 78 5.3. Obsoleting a Label Format Specifier . . . . . . . . . . . 7 79 5.4. Modifying an Existing Entry in the Registry . . . . . . . 8 80 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 82 6.2. Informative References . . . . . . . . . . . . . . . . . 8 83 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 9 84 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 87 1. Introduction 89 With the acceptance of security labels in several mainstream 90 operating systems the need to communicate labels between these 91 systems becomes more important. In a typical client and server 92 scenario, the client request to the server acts as a subject trying 93 to access an object on the server [RFC7204]. Unfortunately these 94 systems are diverse enough that attempts at establishing one common 95 label format have been unsucessful. The reason for this is that 96 systems implement different Mandatory Access Control (MAC) models, 97 which typically do not share any common ground. 99 One solution might be to define a single label format which consists 100 of the union of the requirements of all MAC models/implementations, 101 known at a given time. This approach is not desirable because it 102 introduces an environment where many MAC models would either have 103 blank fields for many of the label's components or where many 104 implementations would ignore many of values that are present 105 altogether. The resulting complexity would be likely to result in a 106 confusing situation in which the interaction of fields that that 107 derive from different MAC models is never clearly specified and the 108 addition of new models or extension of existing models is unduly 109 difficult. 111 An additional consideration is that if a policy authority or 112 identifier field is specified in the label format it would require a 113 robust description that encompassed multiple MAC models where 114 implementation would lock policy administration into the described 115 model. 117 Ideally a mechanism to address this problem should allow the most 118 flexibility possible in terms of policy administration while 119 providing a specification that is suffient to allow for 120 implementation of the label format and understanding of the semantics 121 of the label. This means that the label format specification would 122 ideally contain a syntactic description of the label format and a 123 description of the semantics for each component in the label. This 124 allows protocols to specify the type of label and label semantics 125 that it requires while leaving policy and policy administration to 126 the individual organizations using the protocol in their environment. 128 Policy administration within an organization is a difficult problem. 129 This should not be made even more difficult by having to request 130 permission from external entities when crafting new policy or just 131 making department specific modifications to existing policies. The 132 policy authority field would allow an label format specification to 133 specify a scheme for policy administration without forcing it on all 134 users of security labels. However by agreeing to implement a 135 particular label format specification, the protocol agrees to that 136 policy administration mechanism when processing labels of that type. 138 This document presents a registry of label format specifications to 139 allow multiple MAC mechanisms and label formats to co-exist in a 140 network. While the initial use of this registry is for the Network 141 File System (NFS) protocol, it might also be referenced and used by 142 other IETF protocols in future. 144 2. Definitions 146 Label Format Specifier: an identifier used by the client to 147 establish the syntactic format of the security label and the 148 semantic meaning of its components. 150 Label Format Specification: is a reference to a stable, public 151 document that specifies the label format. 153 Multi-Level Security (MLS): a traditional model where subjects are 154 given a security level (Unclassified, Secret, Top Secret, etc.) 155 and objects are given security labels that mandate the access of 156 the subject to the object (see [BL73] and [RFC2401]). 158 object: a passive resource within the system that we wish to 159 protect. Objects can be entities such as files, directories, 160 pipes, sockets, and many other system resources relevant to the 161 protection of the system state. 163 subject: an active entity, usually a process, user, or client, that 164 is requesting access to an object. 166 3. Exisiting Label Format Specifications 168 3.1. IP Security Option (IPSO), Basic Security Option (BSO) 170 The "IP Security Option (IPSO)" label format is defined in [RFC1108]. 171 IANA has assigned IPv4 Option 130 to the IPSO Basic Security Option 172 (BSO). IPSO is the only IPv4 sensitivity label option implemented in 173 commercial IP routers. IPSO BSO continues to have widespread 174 implementation in hosts, and widespread deployment. For the purposes 175 of this document, only the BSO labels in Table 1 on Page 3 of 176 [RFC1108] are used. 178 In some locales, the BSO value "(Reserved 2)" is used for marking 179 information that is considered "Restricted" by local policy, where 180 "Restricted" is less sensitive than "Confidential" but more sensitive 181 than "Unclassified". 183 3.2. Commercial IP Security Option (CIPSO) 185 The "Commercial IP Security Option (CIPSO)" label format is 186 documented in [CIPSO] and in [FIPS-188]. While the cited Internet- 187 Draft is long expired, it is widely supported in deployed MLS systems 188 that support IPv4. IANA has assigned IPv4 option number 134 to 189 CIPSO. CIPSO is defined ONLY as an IPv4 option. IANA has never 190 assigned any IPv6 option value to CIPSO. 192 3.3. Common Architecture Label IPv6 Security Option (CALIPSO) 194 The "Common Architecture Label IPv6 Security Option (CALIPSO)" label 195 format is specified in [RFC5570] and is defined for IPv6. As noted 196 in Section 10 of [RFC5570] CALIPSO is a direct derivative of the 197 IPv4 "Simple IP Security Option (SIPSO)", therefore CALIPSO is NOT 198 derived from CIPSO in any way. 200 3.4. Flux Advanced Security Kernel (FLASK) 202 The Flux Advanced Security Kernel (FLASK) [FLASK99] is an 203 impelementation of an architecture to provide flexible support for 204 security policies. Section 2.1 of [FLASK99b], summarizes the 205 architecture of FLASK to: 207 1. describe the interactions between a subsystem which enforces 208 security policy decisions and a subsystem which makes those 209 decisions 211 2. the requirements on the components within each subsystem. 213 4. Security Considerations 215 This document defines a mechanism to associate the Label Format 216 Specifier identifier with a document outlining the syntax and format 217 of a label. There is no security consideration in such an 218 association. The label specification documents referenced by each 219 registration entry should state security considerations for the label 220 mechanism it specifies. 222 5. IANA Considerations 224 This section provides guidance to the Internet Assigned Numbers 225 Authority (IANA) regarding creation of a new registry in accordance 226 with [RFC5226]. 228 This submission requests the creation of a new registry called 229 "Security Label Format Selection Registry". The new registry has the 230 following fields: 232 Label Format Specifier: An integer number that maps to a particular 233 label format, e.g., the CALIPSO label format defined by [RFC5570]. 234 The name space of this identifier has the range of 0..65,535. 236 Label Description: A human readable ASCII ([RFC20]) text string that 237 describes the label format, e.g., "Common Architecture Label IPv6 238 Security Option (CALIPSO)". The length of this field is limited 239 to 128 bytes. 241 Status: A short ASCII text string indicating the status of an entry 242 in the registry. The status field for most entries should have 243 the value "active". In the case that a label format selection 244 entry is obsolete, the status field of the obsoleted entry should 245 be "obsoleted by entry NNN". 247 Label Format Specification: A reference to a stable, public document 248 that specifies the label format, e.g., an URL to [RFC5570]. 250 5.1. Initial Registry 252 The initial assignments of the registry are as follows: 254 +---------------+---------------------+--------+--------------------+ 255 | Label Format | Description | Status | Reference | 256 | Specifier | | | | 257 +---------------+---------------------+--------+--------------------+ 258 | 0 | Reserved | - | - | 259 | 1 - 127 | Private Use | - | - | 260 | 128 - 255 | Experimental Use | - | - | 261 | 256 | CIPSO (tag type #1) | active | [[FIPS-188] URL] | 262 | 257 | CALIPSO ([RFC5570]) | active | [[RFC5570] URL] | 263 | 258 | FLASK Security | active | [[FLASK99] URL] | 264 | | Context | | | 265 | 259 | IPSO | active | [[RFC1108] URL] | 266 | 260 - 65535 | Available for IANA | - | - | 267 | | Assignment | | | 268 +---------------+---------------------+--------+--------------------+ 270 Label Format Specifier Ranges 272 Table 1 274 5.2. Adding a New Entry to the Registry 276 A label format specification document is required to add a new entry 277 to the "Security Label Format Selection Registry". If the label 278 format document is inside the RFC path, then The IANA Consideration 279 section of the label format document should clearly reference the 280 Label Format Selection registry and request allocation of a new 281 entry. The well-known IANA policy, Specification Required, as 282 defined in section 4.1 of [RFC5226], will be used to handle such 283 requests. Note that "Specification Required" policy implies this 284 process requires a Designated Expert reviewer, i.e., adding a new 285 entry to this registry requires both a published label format 286 specification and a Designated Expert review. 288 In reviewing the published label format specification, the Designated 289 Expert should consider whether or not the specification provides 290 sufficient semantics for the object and subject labels to enforce the 291 MAC model and policy administration when deployed within an 292 organization. Another consideration is if the label format allows a 293 correct and complete implementation of the protocol to process and 294 enforce labels as a policy administration mechanism. Finally, to 295 reduce interoperability issues, the review must determine if the new 296 label format specification has clearly defined syntax and semantics 297 for the proposed new labels. 299 5.3. Obsoleting a Label Format Specifier 301 In the case that a label format selector number is assigned to a 302 label format and the label format specification is changed later, a 303 new selector assignment should be requested. The same Specification 304 Required IANA policy applies to such requests. The IANA 305 Consideration section of the updated label format specification 306 should be explicit in which old label selector assignment it 307 obsoletes. Below is an example of obsoleted entry in the registry: 309 +--------------+--------------------+-----------+-------------------+ 310 | Label Format | Description | Status | Reference | 311 | Specifier | | | | 312 +--------------+--------------------+-----------+-------------------+ 313 | 0 | Reserved | - | - | 314 | 1 - 127 | Private Use | - | - | 315 | 128 - 255 | Experimental Use | - | - | 316 | 256 | CIPSO (tag type | active | [[FIPS-188] URL] | 317 | | #1) | | | 318 | 257 | CALIPSO | active | [[RFC5570] URL] | 319 | | ([RFC5570]) | | | 320 | 258 | FLASK Security | obsoleted | [[FLASK99] URL] | 321 | | Context | by 263 | | 322 | ... | | | | 323 | 263 | FLASK Security | active | [new spec URL] | 324 | | Context (v2) | | | 325 | 264 - 65535 | Available for IANA | - | - | 326 | | Assignment | | | 327 +--------------+--------------------+-----------+-------------------+ 329 Example Label Format Specifier Updated Ranges 331 Table 2 333 5.4. Modifying an Existing Entry in the Registry 335 A request to modify either the Description or the published label 336 format specification will also require the Specification Required 337 IANA policy to be applied. The Designated Expert reviewer will need 338 to determine if the published label format specification either 339 obsoletes the Label Format Specifier or updates the label syntax and/ 340 or model. If the Label Format Specifier is obsoleted, then the 341 reviewer will follow the process defined in Section 5.3. Otherwise 342 for the update of either the label syntax and/or the model, the 343 reviewer will approve the change. 345 6. References 347 6.1. Normative References 349 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 350 October 1969. 352 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 353 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 354 May 2008. 356 6.2. Informative References 358 [BL73] Bell, D. and L. LaPadula, "Secure Computer Systems: 359 Mathematical Foundations and Model", Technical Report 360 M74-244, The MITRE Corporation, Bedford, MA, May 1973. 362 [CIPSO] IETF CIPSO Working Group, "Commercial IP Security Option 363 (CIPSO 2.2)", draft-ietf-cipso-ipsecurity-01 (expired), 364 July 1992. 366 [FIPS-188] 367 US National Institute of Standards and Technology, 368 "Standard Security Labels for Information Transfer", 369 Federal Information Processing Standard (FIPS) 188, 370 September 1994, . 373 [FLASK99] Spencer, R., Smalley, S., Loscocco, P., Hibler, M., 374 Andersen, D., and J. Lepreau, "The Flask Security 375 Architecture: System Support for Diverse Security 376 Policies", In Proceedings of the Eighth USENIX Security 377 Symposium, pages 123-139, August 1999. 379 [FLASK99b] 380 Secure Computing Corporation, "Assurance in the Fluke 381 Microkernel Formal Security Policy Model", Document 382 00-0930896A001 Rev B, 17 Feb 1999, Secure Computing 383 Corporation, Roseville, MN, USA, February 1999. 385 [RFC1108] Kent, S., "Security Options for the Internet Protocol", 386 RFC 1108, November 1991. 388 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 389 Internet Protocol", RFC 2401, November 1998. 391 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 392 Architecture Label IPv6 Security Option (CALIPSO)", RFC 393 5570, July 2009. 395 [RFC7204] Haynes, T., "Requirements for Labeled NFS", RFC 7204, 396 April 2014. 398 Appendix A. Acknowledgments 400 Ran Atkinson contributed the text for IPSO. 402 Dave Noveck helped detangle the terminology. 404 Alexey Melnikov caught that a process was needed for modifying 405 entries in the registry. 407 Appendix B. RFC Editor Notes 409 [RFC Editor: please remove this section prior to publishing this 410 document as an RFC] 412 Authors' Addresses 414 David P. Quigley 416 Email: dpquigl@davequigley.com 418 Jarrett Lu 419 Oracle 421 Email: jarrett.lu@oracle.com 422 Thomas Haynes 423 Primary Data, Inc. 424 4300 El Camino Real Ste 100 425 Los Altos, CA 94022 426 USA 428 Phone: +1 408 215 1519 429 Email: thomas.haynes@primarydata.com