home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / security / fipslabl.txt < prev    next >
Text File  |  1996-09-03  |  36KB  |  517 lines

  1. Standard Security Label for the Government Open Systems Interconnection Profile (DRAFT)
  2.  
  3.  
  4. Federal Information Processing Standards Publication DRAFT 1992 July 15 DRAFT 
  5. U.S. DEPARTMENT OF COMMERCE / National Institute of Standards and Technology 
  6. CATEGORY: ADP OPERATIONS 
  7. SUBCATEGORY: COMPUTER SECURITY 
  8.  
  9. U.S. DEPARTMENT OF COMMERCE, Barbara Hackman Franklin, Secretary NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY, John W. Lyons, Director 
  10. Foreword 
  11. The Federal Information Processing Standards Publication Series of the National Institute of Standards and Technology (NIST) is the official publication relating to standards and guidelines adopted and promulgated under the provisions of Section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law 100-235. These mandates have given the Secretary of Commerce and NIST important responsibilities for improving the utilization and management of computer and related telecommunications systems in the Federal Government. The NIST, through the Computer Systems Laboratory, provides leadership, technical guidance, and coordination of Government efforts in the development of standards and guidelines in these areas. 
  12. Comments concerning Federal Information Processing Standards Publications are welcomed and should be addressed to the Director, Computer Systems Laboratory, National Institute of Standards and Technology, Gaithersburg, MD, 20899. 
  13. James H. Burrows, Director 
  14. Computer Systems Laboratory 
  15.  
  16. Abstract 
  17. This Standard specifies a security label for the U.S. Government Open Systems Interconnection Profile (GOSIP). GOSIP security labels indicate to protocol entities how to handle unclassified but sensitive data communicated between open systems. Information carried by the label described here can be used to control access, specify protective measures, and indicate other handling restrictions required by a communications security policy. The specification for this security label is given in Abstract Syntax Notation 1 (ASN.1) form, an implementation independent notation. A label encoding for use at the Network and Transport Layers is given in an Appendix. 
  18.  
  19. Key words: ADP security, U.S. Government Open Systems 
  20.  Interconnection Profile (GOSIP) security, network 
  21.  security, security labels, trusted Open Systems 
  22.  Interconnection (OSI) 
  23.  
  24. Federal Information 
  25. Processing Standard Publication XXX DRAFT 1992 July 15 DRAFT ANNOUNCING A Standard Security Label for the Government Open Systems Interconnection Profile Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to Section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law 100-235. 
  26. Name of Standard: Standard Security Label for the Government Open Systems Interconnection Profile. 
  27. Category of Standard: ADP Operations, Computer Security. 
  28. Explanation: This Standard gives an implementation independent specification of a security label for the U.S. Government Open Systems Interconnection Profile (GOSIP). Security labels indicate sensitivity and the possible damage which may occur due to accidental or intentional disclosure, modification, or destruction of data. Labels are used to make access control decisions, to specify protective measures, and to indicate handling restrictions required by a communications security policy. The Standard Security Label is intended for use on U. S. Government OSI networks that exchange unclassified but sensitive data. 
  29. The label presented here defines security tags that may be combined into tag sets to carry security-related information. Five basic security tag types allow the representation of bit maps, attribute enumerations, attribute range selections, security level indication, and of generic information in a free form field. 
  30. A Computer Security Objects Register (CSOR), established by NIST, 
  31. will provide the semantics for labels represented using this 
  32. standard. Documents referencing this labeling standard shall 
  33. either point to a CSOR and its procedures for registration of 
  34. labels, or provide all the pertinent information regarding the 
  35. label(s) to be supported. 
  36.  
  37.  
  38. Approving Authority: Secretary of Commerce. 
  39. Maintenance Agency: Computer Systems Laboratory, National Institute of Standards and Technology. 
  40. Cross Index: 
  41. Federal Information Resources Management Regulations, subpart 201-20.303, Standards, and subpart 201-39.1002, Federal Standards. 
  42. "Procedures for Registration of Computer Security Objects", NIST 1992. 
  43. "U.S. Government Open Systems Interconnection Profile" (GOSIP), FIPS PUB 146-1, April 1991. 
  44. Scope: This standard specifies, in abstract notation, a security label for GOSIP-compliant implementations. Following this implementation independent specification, security labels may be encoded for use within various Open Systems Interconnection (OSI) 
  45. protocols. The Abstract Syntax Notation 1 (ASN.1) label 
  46. description provided here shall be used for security labels in 
  47. Application Layer protocols. A normative Appendix to this standard provides the label encoding for the Network and Transport Layers. Other encodings of this Standard Label may be produced for use at the remaining layers if necessary. The specification given here is limited to the syntactic aspect of the label. The semantics of security labels, as defined for different security domains, are given by a Computer Security Objects Register. 
  48. Applicability: The specified Standard Security Label (SSL) applies to OSI communications systems handling U.S. government unclassified but sensitive data. This security label type shall be used by OSI systems required to label data as indicated in the security chapter of GOSIP. 
  49. The SSL shall be used by OSI protocols to control access, specify protective measures, and indicate handling restrictions required by a network security policy as registered in a Computer Security Objects Register. 
  50. Complying implementations shall be capable of transmitting, receiving, and handling security labels based on the high level specification in this document. 
  51. Specifications: Federal Information Processing Standard (FIPS xxx) 
  52. Standard Security Label for the Government Open Systems 
  53. Interconnection Profile (affixed). 
  54.  
  55.  
  56. Implementation Schedule: This standard becomes effective six months after publication of a notice in the Federal Register of its approval by the Secretary of Commerce. 
  57. Waiver Procedure: Under certain exceptional circumstances, the heads of Federal departments and agencies may approve waivers to Federal Information Processing Standards (FIPS). The head of such agency may redelegate such authority only to a senior official designated pursuant to section 3506(b) of Title 44, United States Code. Waiver shall be granted only when: 
  58. a.    Compliance with a standard would adversely affect the accomplishment of the mission of an operator of a Federal computer system; or 
  59. b.    Compliance with a standard would cause a major adverse financial impact on the operator which is not offset by Government-wide savings. 
  60.  
  61. Agency heads may act upon a written waiver request containing the information detailed above. Agency heads may also act without a written waiver request when they determine that conditions for meeting the standard cannot be met. Agency heads may approve waivers only by a written decision which explains the basis on which the agency head made the required finding(s). A copy of each decision, with procurement sensitive or classified portions clearly identified, shall be sent to: National Institute of Standards and Technology; ATTN: FIPS Waiver Decisions, Technology Building, Room B-154, Gaithersburg, MD 20899. 
  62. In addition, notice of each waiver granted and each delegation of authority to approve waivers shall be sent promptly to the Committee on Government Operations of the House of Representatives and the Committee on Government Affairs of the Senate and shall be published promptly in the Federal Register. 
  63. When the determination on a waiver applies to the procurement of equipment and/or services, a notice of the waiver determination must be published in the Commerce Business Daily as a part of the notice of solicitation for offers of an acquisition or, if the waiver determination is made after that notice is published, by amendment to such notice. 
  64. A copy of the waiver, any supporting documents, the document approving the waiver and any accompanying documents, with such deletions as the agency is authorized and decides to make under 5 United States Code Section 552(b), shall be part of the procurement documentation and retained by the agency. 
  65. Special Information: References to this standard will appear in the security chapter of the U.S Government Open Systems Interconnection Profile (GOSIP) in a planned version 3 and future versions. Modifications to the planned version 3 will maintain backwards compatibility with the labeling options defined for the Connectionless Network Protocol (CLNP) in the first two versions. NIST plans that security protocols added to GOSIP in the future that require security labels will only use the Standard Security Label described in this document. 
  66. Where to Obtain Copies: Copies of this publication are for sale by the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. When ordering, refer to Federal Information Processing Standards Publication XX (FIPS PUB XX), and identify the title. When microfiche is desired, this should be specified. Prices are published by NTIS in current catalogs and other issuances. Payment may be made by check, money order, deposit account or charged to a credit card accepted by NTIS. 
  67. Federal Information 
  68. Processing Standard Publication xxx 
  69. DRAFT 1992 July 15 DRAFT 
  70.  
  71. Specifications for a Standard Security Label for the Government Open Systems Interconnection Profile 
  72.  
  73.  
  74. 1.    INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 
  75. 2.    REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 
  76. 3.    ACRONYMS AND DEFINITIONS . . . . . . . . . . . . . . . . . . . . . . . 10 
  77. 3.1    Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 
  78. 3.2    Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 10 
  79. 4.    SECURITY LABEL SPECIFICATION . . . . . . . . . . . . . . . . . . . . . 12 
  80. 5.    EXPLANATION AND USAGE. . . . . . . . . . . . . . . . . . . . . . . . . 13 
  81. 5.1    Registered Fields . . . . . . . . . . . . . . . . . . . . . . . 14 
  82. 5.2    Security Tag Set Name . . . . . . . . . . . . . . . . . . . . . 14 
  83. 5.3    Security Tag Set. . . . . . . . . . . . . . . . . . . . . . . . 15 
  84. 5.3.1    Security Tag Type 1 . . . . . . . . . . . . . . . . . . 15 
  85. 5.3.2    Security Tag Type 2 . . . . . . . . . . . . . . . . . . 16 
  86. 5.3.3    Security Tag Type 3 . . . . . . . . . . . . . . . . . . 16 
  87. 5.3.4    Security Tag Type 4 . . . . . . . . . . . . . . . . . . 16 
  88. 5.3.5    Security Tag Type 5 . . . . . . . . . . . . . . . . . . 17 
  89. Appendix A: Standard Security Label Encoding for the Network and Transport Layers . . . . . . . . . . . . . . . . . . . . . . . . 18 
  90. A.1    Local Acronyms and Definitions. . . . . . . . . . . . . . . . . 18 
  91. A.2    Security Label Format . . . . . . . . . . . . . . . . . . . . . 18 
  92. A.3    Security Label Indicator. . . . . . . . . . . . . . . . . . . . 19 
  93. A.4    Length Indicator. . . . . . . . . . . . . . . . . . . . . . . . 19 
  94. A.5    Registered Field Set. . . . . . . . . . . . . . . . . . . . . . 19 
  95. A.5.1    Tag Set Name Length . . . . . . . . . . . . . . . . . . 19 
  96. A.5.2    Tag Set Name. . . . . . . . . . . . . . . . . . . . . . 20 
  97. A.5.3    Tag Set Length. . . . . . . . . . . . . . . . . . . . . 20 
  98. A.5.4    Security Tags . . . . . . . . . . . . . . . . . . . . . 20 
  99. A.5.4.1    Security Tag Type. . . . . . . . . . . . . . . . . . 20 
  100. A.5.4.2    Security Tag Length. . . . . . . . . . . . . . . . . 20 
  101. A.5.4.3    Security Information . . . . . . . . . . . . . . . . 21 
  102. A.5.4.3.1    Security Tag Type 1 . . . . . . . . . . . . . 21 
  103. A.5.4.3.2    Security Tag Type 2 . . . . . . . . . . . . . 21 
  104. A.5.4.3.3    Security Tag Type 3 . . . . . . . . . . . . . 22 
  105. A.5.4.3.4    Security Tag Type 4 . . . . . . . . . . . . . 23 
  106. A.5.4.3.5    Security Tag Type 5 . . . . . . . . . . . . . 23 
  107. A.6    Usage Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 23 
  108.  
  109. 1.    INTRODUCTION 
  110.  
  111. U.S. Government agencies are required to protect data essential to their operations. This requirement covers data stored, processed, and transmitted by computer and communications systems. This standard defines, in abstract notation, a security label type for use in the U.S. Government Open Systems Interconnection (OSI) Profile (GOSIP, FIPS PUB 146-1) [10]. GOSIP is a mandatory set of specifications for procurement of OSI communications systems. 
  112. The security label specified here may be used to indicate data sensitivity and possible damage due to accidental or intentional disclosure, modification, or destruction. Labels following this specification can be used to make access control decisions, specify protective measures, and indicate handling restrictions required by the applicable security policy. 
  113. The Abstract Syntax Notation 1 (ASN.1) [4] is used to define the Standard Security Label (SSL). ASN.1 provides an implementation independent means of expressing complex Application Layer protocol elements. ASN.1 specifications are typically encoded using the Basic Encoding Rules (BER) [5], although other encodings may be used. 
  114. Our security labeling approach takes advantage of this flexibility to specify a common label type for use throughout the OSI stack. The ASN.1 specification of the SSL can be encoded to conform to specific layer protocols. This standard provides the encoding for security labels at OSI layers 3 and 4 in a normative appendix. Documents calling for encodings of the SSL for use at layers other than 3 and 4, shall provide such encoding or a reference to the document providing the encoding. 
  115. The SSL provides a set of tools that can be combined to support different security policies. Instances of this type of labels are registered in a Computer Security Objects Register (CSOR) where the rules for their interpretation are given. The CSOR associates a unique object identifier to each label definition provided thus enabling implementations to identify the labels and process them accordingly. Documents referencing this FIPS shall indicate the source and all information necessary for the use and implementation of the labels to be supported. This includes the identity of the CSOR, identifiers, and definitions for all labeling objects supported. 
  116. 2.    REFERENCES 
  117.  
  118. [1] European Computer Manufacturers Association, "Security in Open 
  119.  Systems - Data Elements and Service Definitions", ECMA 
  120.  Standard 138, December 1989. 
  121.  
  122. [2] International Standards Organization (ISO), "Information 
  123.  processing systems - Open Systems Interconnection - Basic 
  124.  Model", ISO 7498, 1988. 
  125.  
  126. [3] International Standards Organization (ISO), "Information 
  127.  processing systems - Open Systems Interconnection - Security 
  128.  Addendum", ISO 7498/2, 1988. 
  129.  
  130. [4] International Standards Organization (ISO), "Information 
  131.  Technology - Open Systems Interconnection - Specification of 
  132.  Abstract Syntax Notation One (ASN.1)", ISO/IEC 8824 (DIS), 
  133.  1990. 
  134.  
  135. [5] International Standards Organization (ISO), "Information 
  136.  Technology - Open Systems Interconnection - Specification of 
  137.  Basic Encoding Rules for Abstract Syntax Notation One 
  138.  (ASN.1)", ISO/IEC 8825 (DIS), 1990. 
  139.  
  140. [6] Internet CIPSO Working Group, "Commercial IP Security Option", 
  141.  Proposed Request for Comments (RFC), February 7, 1991. 
  142.  
  143. [7] Nazario Noel, "Security Labeling in Unclassified Networks", 
  144.  Proceedings of the 13th National Computer Security Conference, 
  145.  Volume 1, pp. 44-48, October 1990. 
  146.  
  147. [8] Nazario Noel, "Security Labels for Open Systems - An 
  148.  Invitational Workshop", NISTIR 4362, June 1990. 
  149.  
  150. [9] Nazario Noel, "Standard Security Label for GOSIP - An 
  151.  Invitational Workshop", NISTIR 4614, June 1991. 
  152.  
  153. [10] "U.S. Government Open Systems Interconnection Profile" 
  154. (GOSIP), 
  155. FIPS PUB 146-1, April 1991. 
  156.  
  157.  
  158. 3.    ACRONYMS AND DEFINITIONS 
  159.  
  160.  
  161. 3.1    Acronyms 
  162.  
  163. CSOR - Acronym for Computer Security Objects Register. 
  164. GOSIP - Acronym for (U.S.) Government Open Systems 
  165. Interconnection Profile. GOSIP, or Federal Information 
  166. Processing Standard (FIPS) 146-1, is a procurement 
  167. profile for open systems computer network products. [10] 
  168.  OSI - Acronym for Open System Interconnection. 
  169.  
  170.  PDU - Acronym for Protocol Data Unit. 
  171.  
  172.  TSN - Acronym for Tag Set Name. 
  173.  
  174.  
  175. 3.2    Definitions 
  176.  
  177. computer security object - (CSO). A resource, tool, or 
  178. mechanism used to maintain a condition of security in a 
  179. computerized environment. These objects are defined in terms of attributes they possess, operations they perform or are performed on them, and their relationship with other objects. 
  180. Computer Security Objects Register - (CSOR). A collection of CSO names and definitions kept by a registration authority. 
  181. domain - See security domain. 
  182. entity - An active element in an open system. [2] 
  183. open system - A set of one or more computers, the associated 
  184. software, peripherals, terminals, human operators, physical 
  185. processes, information transfer means, etc., that forms an 
  186. autonomous whole capable of processing and/or transferring 
  187. information that complies with the requirements of OSI 
  188. standards. [2] 
  189.  
  190. Open Systems Interconnection - This term qualifies standards for the exchange of information among systems that are "open"to one another for this purpose by virtue of their mutual use of applicable standards. The Basic reference model for OSI is given in [2]. 
  191. protocol data unit - A unit of data specified in a protocol 
  192. and consisting of protocol information and, possibly, user 
  193. data.[2] 
  194. policy - See security policy 
  195. protocol entity - Entity that follows a set of rules and 
  196. formats (semantic and syntactic) that determine the 
  197. communication behavior of other entities. [2] 
  198.  
  199. Registered Field - An instance of an entry to the Computer Security Objects Register (CSOR) as carried in the label. Contains a Tag Set Name and a set of tags. 
  200. registration authority - Organization responsible for the 
  201. maintenance of a branch of the ISO naming hierarchy. 
  202. security attribute - A security-related quality of a security object. Security attributes may be represented as hierarchical levels, bits in a bit map, or numbers. Compartments, caveats, and release markings are examples of security attributes. 
  203. security domain - A collection of entities to which applies a 
  204. single security policy executed by a single security 
  205. administrator. [1] 
  206.  
  207. security label - A marking bound to a resource (which may be 
  208. a data unit) that names or designates the security attributes 
  209. of that resource. [3] 
  210. security policy - A set of criteria for the provision of 
  211. security services that provide adequate protection for systems 
  212. and data transfers. [3] A set of rules that define and 
  213. constrain the activities of a data processing facility in order 
  214. to maintain a condition of security. [1] 
  215. security tag - Information unit containing a representation of certain security-related information (e.g., a category bit map). 
  216. security threat - Circumstance with the potential to cause 
  217. loss or harm to a computer system or the information it 
  218. handles. 
  219. Tag Set Name - Unique object identifier associated with a set of security tags. 
  220. 4.    SECURITY LABEL SPECIFICATION 
  221.  
  222. The Abstract Syntax Notation 1 (ASN.1) [4] definition of the Standard Security Label (SSL) is given in Figure 4.1 below. This definition shall be encoded as appropriate to the layer where it will be used. At the Network and Transport Layers, the encoding given in the appendix shall be used. 
  223. ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 
  224. 3 ASN.1 Definition for Standard Security Label 
  225.  3 
  226. 3 Standard Security Label ::= IMPLICIT SET OF RegisteredField 
  227. 3 RegisteredField ::= IMPLICIT SEQUENCE { 
  228. 3 tagsetname TagSetName, 
  229.  3 
  230.  
  231. 3 securityTags SEQUENCE OF SecurityTag } 
  232. 3 TagSetName ::= OBJECT IDENTIFIER 
  233. 3 SecurityTag ::= CHOICE { 
  234.  3 
  235. 3 -- Type 1 
  236. 3 bitMap [1] IMPLICIT BIT STRING, 
  237.  3 
  238.  
  239. 3 -- Type 2 
  240. 3 enumeratedAttributes [2] IMPLICIT SET OF SecurityAttribute, 
  241.  3 
  242.  
  243. 3 -- Type 3 
  244. 3 rangeset [3] IMPLICIT SET OF SecurityAttributeRange, 
  245.  3 
  246.  
  247. 3 -- Type 4 
  248. 3 securityLevel [4] IMPLICIT SecurityAttribute, 
  249. 3 -- Type 5 
  250. 3 freeFormField [5] IMPLICIT ANY DEFINED BY TagSetName } 
  251.  3 
  252.  
  253.  
  254. 3 SecurityAttributeRange ::= IMPLICIT SEQUENCE { 
  255. 3 upperBound SecurityAttribute, 
  256. 3 lowerbound SecurityAttribute } 
  257. 3 SecurityAttribute ::= IMPLICIT INTEGER (0..65535) 
  258. @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 
  259. Figure 4.1 
  260. 5.    EXPLANATION AND USAGE 
  261.  
  262. According to the above abstract definition for the (SSL), a security label is defined as a collection of Registered Fields. These Registered Fields contain security information required by an organization's security policy. This information is used to maintain the security condition of a resource (e.g., communications system, data file, application process). 
  263. 3DDDDDDD Standard Security Label DDDDDD3 
  264.  ZDDDDDDDDDDDDBDDDD DDDBDDDDDDDDDDDD? 
  265.  3 Registered 3 3 Registered 3 
  266.  3 Field 1 3 ___ 3 Field N 3 
  267.  @DDDDDDDDDDDDADD DDDDDDADDDDDDDDDDDDY 
  268.  
  269. Figure 5.1 
  270. 5.1    Registered Fields 
  271.  
  272. Registered Fields are an instance of a security label registered 
  273. in a Computer Security Objects Register (CSOR). A Registered Field 
  274. has two parts, a security tag set name (TSN), and a security tag 
  275. set. The TSN is an unique name associated with the semantics for 
  276. interpreting the security tags carried in the field. The security 
  277. tags carry the actual security information. A Registered Field is 
  278. depicted in Figure 5.2. Every SSL must carry, at least, one 
  279. Registered Field. The use of multiple Registered Fields in a 
  280. single label provide for protection under multiple security 
  281. policies. This is useful for maintaining an appropriate degree of protection when information is shared across security domain boundaries. Implementations shall be able to scan the whole label even if a Registered Field is not recognized. Failure to recognize a Registered Field may constitute a security relevant event. The system security policy is responsible for identifying those events whose occurrence is relevant and indicating the action to follow. 
  282. 3DDDDDDDDDDDD Registered Field DDDDDDDDDDD3 
  283. ZDDDDDDDDD?ZDDDDDDDDDDBD DDDDDBDDDDDDDDDD? 
  284.  3 Tag Set 33 Security 3 3 Security 3 
  285.  3 Name 33 Tag 3 ___ 3 Tag 3 
  286.  @DDDDDDDDDY@DDDDDDDDDDADDDD DADDDDDDDDDDY 
  287.  
  288. Figure 5.2 
  289. 5.2    Security Tag Set Name 
  290.  
  291. Security tag set names (TSNs) uniquely identify the labeling scheme supported by the data in the set of security tags that follow. A Computer Security Objects Register (CSOR) maintains the semantics necessary for interpretation of label information. The Register assigns unique TSNs based on a hierarchy of registration authorities. These unique names are described in terms of Object Identifiers as defined for the Abstract Syntax Notation 1 (ASN.1) [4]. Documents referencing this labeling standard shall either point to a CSOR and its procedures for registration of labels, or indicate the TSN and definition of the label(s) to be supported. 
  292. 5.3    Security Tag Set 
  293.  
  294. The set of security tags in each Registered Field carry the security information. Five tag types are defined in this standard. These tag types are, (1) Bit Map, (2) Enumerated, (3) Range, (4) Security Level, and (5) Free Form. Any combination of tag types may be used to represent the security information required by the local security policy for protection of the data being exchanged. This standard relies on the services of a Computer Security Objects Register to maintain the tag-specific information necessary for the correct implementation of labels. Upon registration, the value and significance of the following items shall be provided: 
  295.  _number of tags, 
  296.  _number of tags of each type, 
  297.  _length of the set, 
  298.  _length of each tag, 
  299.  _ordering of tags, 
  300.  _security relevant conditions, 
  301. The above list may be augmented by the Registration Authority for the CSOR. 
  302. 5.3.1    Security Tag Type 1 
  303.  
  304. Tag type 1 is the Bit Map Tag Type. Tags of this type are used to convey security parameters, such as compartments and protection categories, that may be selected from a set by setting a one-bit flag to a predefined value (logic 0 or 1). The use of either 0s or 1s to mark the set condition of the individual bits allows the implementation of permissive (e.g., release markings) and restrictive (e.g., categories) markings using the same mechanism to test both conditions. 
  305. 5.3.2    Security Tag Type 2 
  306.  
  307. Tag type 2 is the Enumerated Tag Type. Tags of this type are used when only a few security attributes out of a large set need to be singled out when labeling a given protocol data unit (PDU). This is done by assigning a fixed-size non-negative binary number to each security attribute and enumerating those attributes that apply (set inclusion), or do not apply (set exclusion). This enumeration shall start with the lowest numbered attribute following an ascending order. 
  308. The entry registered in the CSOR will indicate whether attributes enumerated in a type 2 tag will be interpreted as included or excluded from the applicable set. 
  309. 5.3.3    Security Tag Type 3 
  310.  
  311. Tag Type 3 is the Range Tag Type. Tags of this type are used when all the security attributes between certain lower and upper bound need to be singled out when labeling a PDU. This is done by indicating the higher-numbered and lower-numbered attributes as bounds for the range. The entry registered in the CSOR will indicate whether attributes in a range will be interpreted as included or excluded from the applicable set. 
  312. A single tag may indicate multiple security attribute ranges. 
  313. These ranges shall be listed in descending numerical order and shall not overlap. Each upper or lower bound attribute is indicated by a fixed size number. 
  314. 5.3.4    Security Tag Type 4 
  315.  
  316. Tag type 4 is the Security Level Tag Type. Tags of this type are used to label PDUs according to a hierarchical security level scheme. The set of possible values shall be ordered such that higher values indicate higher security levels. The set of possible values and the tag length are indicated in the CSOR. 
  317.  
  318. 5.3.5    Security Tag Type 5 
  319.  
  320. Tag type 5 is the Free Form Tag Type. Tags of this type carry a free format field. This tag may hold character strings, or any other user-defined data. The entry registered in the CSOR shall indicate the format and interpretation for the information in this tag. 
  321.  
  322. Appendix A: Standard Security Label Encoding for the Network and Transport Layers (Normative) 
  323. A.1    Local Acronyms and Definitions 
  324.  
  325. LI - Acronym for Length Indicator. 
  326. Length Indicator - This field indicates the length of the 
  327. Security Information field of a label. 
  328. Security Label Indicator field - This field identifies the 
  329. information that follows as a security label. 
  330. Security Tag Length field - Gives the length in octets of the information in a tag. 
  331. Security Tag Type field - Identifies which kind of tag 
  332. follows. 
  333. TL - Acronym for Security Tag Length field. 
  334. Tag Set Length field - Gives the length in octets of the 
  335. security tag set that follows. 
  336.  
  337. A.2    Security Label Format 
  338.  
  339. Figure A.1 shows the security label format for use at the Network and Transport Layers. This figure identifies three fields: 
  340. Security Label Indicator, Length Indicator, and Registered Field Set. 
  341. ZDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDDDDDDDD? 
  342.  3 Security 3 Length 3 Registered 3 
  343.  3 Label 3 Indicator 3 Field Set 3 
  344.  3 Indicator 3 3 3 
  345.  3 C0 (hex) 3 3 3 
  346.  @DDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDDDDDDDDY 
  347.  1 octet 1 octet Var 
  348.  
  349. Security Label Format Layers 3 and 4 
  350. Figure. A.1 
  351.  
  352.  
  353. A.3    Security Label Indicator 
  354.  
  355. The size of the Security Label Indicator field is 1 octet. Its 
  356. value is 1100 0000 (C0 hex). 
  357.  
  358.  
  359. A.4    Length Indicator 
  360.  
  361. The size of the Length Indicator (LI) field is 1 octet. Its value is the total length of the Registered Field Set, Security Label Indicator, and Length Indicator in octets. The maximum value of the LI is 255. 
  362. A.5    Registered Field Set 
  363.  
  364. One or more Registered Fields are carried in a single label. At this level, every Registered Field is an ordered set of the following: Tag Set Name Length, a Tag Set Name, Tag Set Length, and Security Tags. Figure A.2 depicts a Register Field. 
  365. ZDDDDDDDD Security Tag Set DDDDD? 
  366. ZDDDDDDDDDD?ZDDDDDDDDDD?ZDDDDDDDDDD?ZDDDDDDDDDDBDD D D D DDBDDDDDDDDDD? 
  367.  3 Tag Set 33 Tag Set 33 Tag 33 Security 3 3 Security 3 
  368.  3 Name 33 Name 33 Set 33 Tag 3 3 Tag 3 
  369.  3 Length 33 33 Length 33 3 3 3 
  370. @DDDDDDDDDDY@DDDDDDDDDDY@DDDDDDDDDDY@DDDDDDDDDDADD D D D DDADDDDDDDDDDY 
  371.  1 octet Var 1 octet Var 
  372.  
  373.  Registered Field 
  374.  Figure A.2 
  375.  
  376.  
  377.  
  378. A.5.1    Tag Set Name Length 
  379.  
  380. The size of the Tag Set Name (TSN) Length field is 1 octet. Its value is the length of the TSN in octets plus 1. The sum of the values of all the TSN Lengths and TSLs shall equal the value of the LI. 
  381.  
  382. A.5.2    Tag Set Name 
  383.  
  384. The Tag Set Name (TSN) is a variable-size field containing the value portion of the numerical object identifier for the label definition registered in the Computer Security Objects Register (CSOR). The Numeric Name assigned by the CSOR is encoded according to the Basic Encoding Rules (BER) [5] rules for Object Identifiers. The registered definition provides the semantics for the Security Tag Set in the Registered Field. 
  385. A.5.3    Tag Set Length 
  386.  
  387. The size of the Tag Set Length (TSL) field is 1 octet. Its value is the total length, in octets, of the tags in the set plus 1. 
  388. This length field makes it possible to skip over an unrecognized Registered Field when scanning a label. The sum of the values of all the TSN Lengths and TSLs shall equal the value of the LI. 
  389. A.5.4    Security Tags 
  390.  
  391. The security information is conveyed using Security Tags. The type, number, usage, and interpretation of the security tags are given by the CSOR. The Tag Set Name points to a label definition in the CSOR. Each Security Tag has one-octet type and length fields plus a variable size information field. 
  392. A.5.4.1    Security Tag Type 
  393.  
  394. The size of the Security Tag Type field is 1 octet. Its value indicates the tag type. Values range between 0 and 255. This standard defines tag types 1 through 5. All other tag types are reserved for definition by NIST. At least one tag must be present in every Registered Field. 
  395. A.5.4.2    Security Tag Length 
  396.  
  397. The size of the Security Tag Length (TL) is 1 octet. Its value is 
  398. the length, in octets, of the information in the tag plus 2 (for 
  399. the length of the Type and Length fields). Its value ranges 
  400. between 2 and 250 octets. The sum of all the TL values in a 
  401. Registered Field shall equal the value of the TSL. 
  402.  
  403.  
  404. A.5.4.3    Security Information 
  405.  
  406. This variable length field contains the value of the Security Tag. This standard describes this field for Tag Types 1 - 5. All other tag types are reserved for later definition by NIST. 
  407. A.5.4.3.1    Security Tag Type 1 
  408.  
  409. Security tags of this type carry a bit map of security attributes. The complete set of possible attributes is represented with the bit values off and on set as appropriate. The interpretation of bit values in a bit map is given by the CSOR. 
  410. Bits in the map shall be numbered starting with the most 
  411. significant bit of the first transmitted octet (bit 0). Bit maps 
  412. shall be padded to the right (i.e., up to the least significant bit of the last octet), if necessary. 
  413. The format of this tag type is as follows: 
  414. 0123 ... 
  415. ZDDDDDDDDDDDDBDDDDDDDDDDDDBDDDDDDD D D DDDDDD? 
  416. 3 00000001 3 LLLLLLLL 3 BBBB BBBB 3 
  417. @DDDDDDDDDDDDADDDDDDDDDDDDADDDDDDD D D DDDDDDY 
  418. Tag Type Tag Length Bit Map 
  419. Security Tag Type 1 
  420. Figure A.3 
  421.  
  422. A.5.4.3.2    Security Tag Type 2 
  423.  
  424. Tag Type 2 is used when only a few security attributes out of a large set need to be singled out for a PDU. This is done by enumerating the attributes that apply (set inclusion), or do not apply (set exclusion). This enumeration shall start with the lowest numbered attribute following an ascending order. Valid TL field values for this tag type are multiples of 2. The CSOR will indicate whether attributes enumerated in a type 2 tag will be interpreted as included or excluded from the applicable set. 
  425.  
  426. A single tag may enumerate several security attributes, assigning 2 octets per attribute. The attributes enumerated may be between 0 and 65535. 
  427. The format of this tag type is as follows: 
  428. ZDDDDDDDDDDDDBDDDDDDDDDDDDBDDDDDDD D D DDDDDDD? 
  429. 3 00000010 3 LLLLLLL0 3 AA AA AA AA 3 
  430. @DDDDDDDDDDDDADDDDDDDDDDDDADDDDDDD D D DDDDDDDY 
  431.  Tag Type Tag Length Enumerated 
  432.  Attributes 
  433.  
  434. Security Tag Type 2 
  435. Figure A.4 
  436.  
  437. A.5.4.3.3    Security Tag Type 3 
  438.  
  439. Tag Type 3 is used when all the security attributes between certain lower and upper bound need to be singled out for a PDU. This is done by indicating the higher-numbered and lower-numbered attributes as bounds for the range. Valid length (TL) field values for this tag type are multiples of 2. The CSOR will indicate whether attributes in a range will be interpreted as included or excluded from the applicable set. 
  440. A single tag may indicate multiple security attribute ranges. 
  441. These ranges shall be listed in descending numerical order and shall not overlap. Each bound attribute is indicated by a 2-octet binary number. The final lower bound may be omitted if its value is 0. Security attributes are identified by integers between 0 and 65535. 
  442. The format of this tag type is as follows: 
  443. ZDDDDDDDDDDDDBDDDDDDDDDDDDBDDDDDD D D DDDDDD? 
  444. 3 00000011 3 LLLLLLL0 3 UUUU DDDD 3 
  445. @DDDDDDDDDDDDADDDDDDDDDDDDADDDDDD D D DDDDDDY 
  446. Tag Type Tag Length Range Set 
  447. Security Tag Type 3 
  448. Figure A.5 
  449.  
  450.  
  451. A.5.4.3.4    Security Tag Type 4 
  452.  
  453. Tag type 4 carries a security level indicator. Possible values are non-negative integers. The set of possible levels shall be assigned such that higher values indicate higher security levels. The set of possible values and the tag length are indicated in the CSOR. 
  454. The format of this tag type is as follows: 
  455. ZDDDDDDDDDDDDBDDDDDDDDDDDDBDDDDDD D D DDDDDD? 
  456. 3 00000100 3 LLLLLLLL 3 SSSS SSSS 3 
  457. @DDDDDDDDDDDDADDDDDDDDDDDDADDDDDD D D DDDDDDY 
  458. Tag Type Tag Length Security Level 
  459. Security Tag Type 4 
  460. Figure A.6 
  461.  
  462. A.5.4.3.5    Security Tag Type 5 
  463.  
  464. Tag type 5 carries a free format field of up to 248 octets. The information field of this tag may hold character strings, or any user-defined data. 
  465. The format of this tag type is as follows: 
  466. ZDDDDDDDDDDDDBDDDDDDDDDDDDBDDDDD D D DDDDD? 
  467. 3 00000101 3 LLLLLLLL 3 FFFF FFFF 3 
  468. @DDDDDDDDDDDDADDDDDDDDDDDDADDDDD D D DDDDDY 
  469. Tag Type Tag Length Free Form 
  470. Field 
  471. Security Tag Type 5 
  472. Figure A.7 
  473.  
  474. A.6    Usage Rules 
  475.  
  476. Throughout this appendix it is assumed that the leftmost bit is the most significant bit (MSB). The MSB, labeled bit 0, is always transmitted first. All illustrated fields are transmitted from left to right. 
  477.  
  478.  
  479.