idnits 2.17.1 draft-ietf-smime-seclabel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 443 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 137 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 6 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 330: '... SET OF SecurityCategory OPTIONAL...' RFC 2119 keyword, line 350: '... SET OF SecurityCategory OPTIONAL...' RFC 2119 keyword, line 371: '... SET OF SecurityCategory OPTIONAL...' RFC 2119 keyword, line 391: '...data, the agents MUST allow the securi...' RFC 2119 keyword, line 394: '...sing, the agents SHOULD display to the...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 1999) is 8898 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) -- Missing reference section? 'RFC2026' on line 13 looks like a reference -- Missing reference section? 'ESS' on line 411 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 413 looks like a reference -- Missing reference section? 'CERTCRL' on line 116 looks like a reference -- Missing reference section? 'AC509' on line 406 looks like a reference -- Missing reference section? '0' on line 381 looks like a reference -- Missing reference section? '1' on line 382 looks like a reference -- Missing reference section? 'CMS' on line 409 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME Working Group Weston Nicolls 2 INTERNET DRAFT Ernst & Young LLP 3 Expires in six months December 1999 5 Implementing Company Classification Policy 6 with the S/MIME Security Label 7 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of [RFC2026]. 14 This document is an Internet-Draft. Internet-Drafts are working documents 15 of the Internet Engineering Task Force (IETF), its areas, and its working 16 groups. Note that other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months and 20 may be updated, replaced, or obsoleted by other documents at any time. It 21 is inappropriate to use Internet-Drafts as reference material or to cite 22 them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 <> 32 1. Introduction 34 This document discusses how company security policy for data classification can 35 be mapped to the S/MIME classification label. Actual policies from 3 companies 36 are used to provide worked examples. 38 Security labels are an optional security service for S/MIME. A security label is 39 a set of security information regarding the sensitivity of the content that is 40 protected by S/MIME encapsulation. A security label can be a bound attribute of 41 the original message content, the encrypted body, or both. The syntax and 42 processing rules for security labels are described in [ESS]. 44 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT','SHOULD', 45 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be 46 interpreted as described in [MUSTSHOULD]. 48 This draft is being discussed on the 'ietf-smime' mailing list. To join the 49 list, send a message to with the single word 50 'subscribe' in the body of the message. Also, there is a Web site for the 51 mailing list at . 53 1.1 Information Classification Policies 55 Information is an asset, but not all information has the same value for a 56 business. Not all information needs to be protected as strongly as other 57 information. 59 Research and development plans, marketing strategies and manufacturing quality 60 specifications developed and used by a company provide competitive advantage. 61 This type of information needs stronger protective measures than other 62 information, which if disclosed or modified, would cause little or no damage to 63 the company. 65 Other types of information such as internal organization charts, employee lists 66 and policies may need little and no protective measures based on value the 67 organization places on it. 69 A corporate information classification policy defines how its information assets 70 are to be protected. It provides guidance to employees on how to classify 71 information assets. It defines how to label and protect an asset based on its 72 classification and state (e.g. facsimile, electronic transfer, storage, 73 shipping, etc.). 75 1.2 Access Control and Security Labels 77 "Access control" is a means of enforcing authorizations. There are a variety of 78 access control methods that are based on different types of policies and rely on 79 different security mechanisms. 81 - Rule based access control is based on policies that can be algorithmically 82 expressed. 84 - Identity based access control is based on a policy which applies explicitly 85 to an individual person or host entity, or to a defined group of such entities. 86 Once identity has been authenticated, if the identity is verified to be on the 87 access list, then access is granted. 89 - Rank base access control is based on a policy of hierarchical positions in an 90 organization. A rank-based policy would define what information that the 91 position of Partner or Senior Consultant could access. 93 - Role based access control is based on a policy of hierarchical roles in an 94 organization. The role-based policy would define what information that the role 95 of Executive, Vice President or Staff could access. 97 Rule, rank and role-based access control methods can rely on a security label as 98 the security mechanism to convey the sensitivity or classification of the 99 information. When verifying an S/MIME encapsulated message, the sensitivity 100 information in the messages security label can be compared with the recipient's 101 authorizations to determine if the recipient is allowed to access the protected 102 content. 104 An S/MIME security label may be included as an authenticated attribute in the 105 inner (or only) signature or the outer signature. The inner signature would be 106 used for access control decisions related to the plaintext original content, 107 while he outer signature would be used for access control decisions related to 108 the encrypted message. 110 1.3 User Authorizations 112 Users need to be granted authorizations to access information that has been 113 classified by an authority. The sending and receiving agent need to be able to 114 securely determine the users authorizations for access control processing. 116 [X.509] and the Internet profile for X.509 certificates [CERTCRL] do not define 117 the means to represent and convey authorizations in a certificate. 119 [X.501] defines how to represent authorization in the form of a clearance 120 attribute. The clearance attribute identifies the security policy in force to 121 which a list of possible classifications and security categories relates. 123 [X.501] also notes two means for binding the clearance to a named entity: an 124 Attribute Certificate and a Certificate extension field (e.g., within the 125 subjectDirectoryAttribute extension). 127 [AC509] defines a profile of X.509 Attribute Certificate (AC) suitable for use 128 with authorization information within Internet Protocols. One of the defined 129 attributes is Clearance, which carries clearance (security labeling) information 130 about the AC owner. The syntax for Clearance is imported from [X.501]. 132 2. Developed Examples 134 2.1 Classification Policies 136 The following describes the information classification policies in effect at 3 137 companies. 139 2.1.1 Amoco Corporation 141 The description for the Amoco information classification policy was taken from 142 the Amoco Computer Security Guidelines. Amoco classifies its information assets 143 based on confidentiality and integrity and defines 3 hierarchical 144 classifications for each. 146 Highly Confidential - Information whose unauthorized disclosure will cause the 147 company severe financial, legal or reputation damage. Examples: Certain 148 acquisitions, bid economics, negotiation strategies. 150 Confidential - Information whose unauthorized disclosure may cause the company 151 financial, legal, or reputation damage. Examples: Employee Personnel & Payroll 152 Files, some interpreted Exploration Data. 154 General - Information that, because of its personal, technical, or business 155 sensitivity is restricted for use within the company. Unless otherwise 156 classified, all information within Amoco is in this category. 158 Maximum - Information whose unauthorized modification and destruction will cause 159 the company severe financial, legal, or reputation damage. 161 Medium - Information whose unauthorized modification and destruction may cause 162 the company financial, legal, or reputation damage. Examples: Electronic Funds, 163 Transfer, Payroll, and Commercial Checks 165 Minimum - Although an error in this data would be of minimal consequence, this 166 is still important company information and therefore will require some minimal 167 controls to ensure a minimal level of assurance that the integrity of the data 168 is maintained. This applies to all data that is not placed in one of the above 169 classifications. Examples: Lease Production Data, Expense Data, Financial Data, 170 and Exploration Data. 172 2.1.2 Caterpillar, Inc. 174 The description for the Caterpillar information classification policy is taken 175 from the Caterpillar Information Protection Guidelines. Caterpillar classifies 176 its information assets based on confidentiality and defines 4 hierarchical 177 classifications. 179 Caterpillar Confidential Red - Provides a significant competitive advantage. 180 Disclosure would cause severe damage to operations. Relates to or describes a 181 long-term strategy or critical business plans. Disclosure would cause regulatory 182 or contractual liability. Disclosure would cause severe damage to our reputation 183 or the public image. Disclosure would cause a severe loss of market share or the 184 ability to be first to market. Disclosure would cause a loss of an important 185 customer, shareholder, or business partner. Disclosure would cause a long-term 186 or severe drop in stock value. Strong likelihood somebody is seeking to acquire 187 this information. 189 Caterpillar Confidential Yellow - Provides a competitive advantage. Disclosure 190 could cause moderate damage to the company or an individual. Relates to or 191 describes an important part of the operational direction of the company over 192 time. Important technical or financial aspects of a product line or a business 193 unit. Disclosure could cause a loss of Customer or Shareholder confidence. 194 Disclosure could cause a temporary drop in stock value. A likelihood that 195 somebody could seek to acquire this information. 197 Caterpillar Confidential Green - Might provide a business advantage over those 198 who do not have access to the same information. Might be useful to a competitor. 199 Not easily identifiable by inspection of a product. Not generally known outside 200 the company or available from public sources. Generally available internally. 201 Little competitive interest. 203 Caterpillar Public - Would not provide a business or competitive advantage. 204 Routinely made available to interested members of the General Public. Little or 205 no competitive interest. 207 2.1.3 Whirlpool Corporation 209 The description for the Whirlpool information classification policy is taken 210 from the Whirlpool Information Protection Policy. Whirlpool classifies its 211 information assets based on confidentiality and defines 2 hierarchical 212 classifications. The policy states that: 214 "All information generated by or for Whirlpool, in whatever form, written, 215 verbal, or electronic, is to be treated as WHIRLPOOL INTERNAL or WHIRLPOOL 216 CONFIDENTIAL. Classification of information in either category depends on its 217 value, the impact of unauthorized disclosure, legal requirements, and the manner 218 in which it needs to be used by the company. Some WHIRLPOOL INTERNAL 219 information may be authorized for public release." 221 WHIRLPOOL CONFIDENTIAL - A subset of Whirlpool Internal information, the 222 unauthorized disclosure or compromise of which would likely have an adverse 223 impact on the companys competitive position, tarnish its reputation, or 224 embarrass an individual. Examples: Customer, financial, pricing, or personnel 225 data; merger/acquisition, product, or marketing plans; new product designs, 226 proprietary processes and systems. 228 WHIRLPOOL INTERNAL - All forms of proprietary information originated or owned by 229 Whirlpool, or entrusted to it by others. Examples: Organization charts, 230 policies, procedures, phone directories, some types of training materials. 232 WHIRLPOOL PUBLIC - Information officially released by Whirlpool for widespread 233 public disclosure. Example: Press releases, public marketing materials, 234 employment advertising, annual reports, product brochures, the public web site, 235 etc 237 The policy also states that privacy markings are allowable. Specifically: 239 For WHIRLPOOL INTERNAL, additional markings or caveats are option at the 240 discretion of the information owner. 242 For WHIRLPOOL CONFIDENTIAL, add additional marking or caveats as necessary to 243 comply with regulatory or heightened security requirements. Examples: MAKE NO 244 COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT, 245 DISTRIBUTION LIMITED TO ____, COVERED BY A NON-ANALYSIS AGREEMENT. 247 2.2 S/MIME Classification Label Developed Examples 249 [ESS] defines the ESSSecurityLabel syntax and processing rules. This section 250 builds upon those definitions to define detailed example policies. 252 2.2.1 Security Label Components 254 The examples are detailed using the various components of the eSSSecurity Label 255 syntax. 257 2.2.1.1 Security Policy Identifier 259 A security policy is a set of criteria for the provision of security services. 260 The eSSSecurityLabel security-policy-identifier is used to identify the security 261 policy in force to which the security label relates. It indicates the semantics 262 of the other security label components. 264 For the example policies, the following security policy object identifiers are 265 defined: 267 <> 269 Amoco security-policy-identifier ::= { } 271 Caterpillar security-policy-identifier ::= { } 273 Whirlpool security-policy-identifier ::= { } 275 2.2.1.2 Security Classification 277 The security classification values and meanings are defined by the governing 278 company policies. The security-classification values defined are hierarchical 279 and do not use integers 0 through 5. 281 Amoco-SecurityClassification ::= { 282 amoco general (6), 283 amoco confidential (7), 284 amoco highly confidential (8), 285 amoco minimum (9), 286 amoco medium (10), 287 amoco maximum (11) } (0..ub-integer-options) 289 Caterpillar-SecurityClassification values ::= { 290 caterpillar public (6), 291 caterpillar green (7), 292 caterpillar yellow (8), 293 caterpillar red (9) } (0..ub-integer-options) 295 Whirlpool-SecurityClassification values ::= { 296 whirlpool public (6), 297 whirlpool internal (7), 298 whirlpool confidential (8) } (0..ub-integer-options) 300 2.2.1.3 Privacy Mark 302 Privacy marks are specified the Whirlpool policy. The policy provides examples 303 of possible marking but other can be defined by users as necessary. User 304 specified privacy marks are defined using the following syntax. 306 <> 308 2.2.1.4 Security Categories 310 Security categories or caveats are not specified to any of the sample policies. 311 However, they are used in at least 2 of the companies informally. Though formal 312 security categories are not defined, some proprietary information does need more 313 granular access control. A category can be based organizationally or by project 314 (i.e., Legal or Project Vallor). User specified security categories are defined 315 using the following syntax. 317 << Need to develop the syntax. Suggestions?>> 319 2.2.2 Attribute Owner Clearance 321 The security clearance and category authorizations for the user are defined in 322 the clearance attribute. 324 2.2.2.1 Amoco User 326 Clearance ::= SEQUENCE { 327 policyId OBJECT IDENTIFIER, 328 classList ClassList DEFAULT {general}, 329 securityCategories 330 SET OF SecurityCategory OPTIONAL 331 } 333 ClassList ::= BIT STRING { 334 amoco general (6), 335 amoco confidential (7), 336 amoco highly confidential (8), 337 } 339 SecurityCategory ::= SEQUENCE { 340 type [0] IMPLICIT OBJECT IDENTIFIER, 341 value [1] ANY DEFINED BY type 342 } 344 2.2.2.1 Caterpillar User 346 Clearance ::= SEQUENCE { 347 policyId OBJECT IDENTIFIER, 348 classList ClassList DEFAULT {general}, 349 securityCategories 350 SET OF SecurityCategory OPTIONAL 351 } 353 ClassList ::= BIT STRING { 354 caterpillar public (6), 355 caterpillar confidential greeen (7), 356 caterpillar confidential yellow (8), 357 caterpillar confidential red (9) 358 } 360 SecurityCategory ::= SEQUENCE { 361 type [0] IMPLICIT OBJECT IDENTIFIER, 362 value [1] ANY DEFINED BY type 363 } 365 2.2.2.1 Whirlpool User 367 Clearance ::= SEQUENCE { 368 policyId OBJECT IDENTIFIER, 369 classList ClassList DEFAULT {general}, 370 securityCategories 371 SET OF SecurityCategory OPTIONAL 372 } 374 ClassList ::= BIT STRING { 375 whirlpool public (6), 376 whirlpool internal (7), 377 whirlpool confidential (8), 378 } 380 SecurityCategory ::= SEQUENCE { 381 type [0] IMPLICIT OBJECT IDENTIFIER, 382 value [1] ANY DEFINED BY type 383 } 385 2.2.3 Additional ESSSecurityLabel Processing Guidance 387 <> 389 <> 391 When originating enveloped data, the agents MUST allow the security label of the 392 data to be specified. 394 Upon successful access control processing, the agents SHOULD display to the 395 recipient the security label for the encrypted data. 397 <> 399 3. Security Considerations 401 All security considerations from [CMS] and [ESS] apply to applications that use 402 procedures described in this document. 404 A. References 406 [AC509] Farrell, S., Housley, R., "An Internet AttributeCertificate Profile for 407 Authorization", draft-ietf-pkix-ac509prof-01.txt. 409 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. 411 [ESS] Hoffman, P., Editor, "Enhanced Security Services for S/MIME", RFC 2634. 413 [MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 414 Levels", 415 RFC 2119. 417 [X.501] "ITU-T Recommendation X.501 : Information Technology - Open Systems 418 Interconnection - The Directory: Models", 1993. 420 [X.509] "ITU-T Recommendation X.509 (1997 E): Information 421 Technology - Open Systems Interconnection - The Directory: Authentication 422 Framework", June 1997. 424 B. Acknowledgements 426 I would like to thanks Russ Housley for helping me through the process of 427 developing this document. I would also like to thank the good people at (BP) 428 Amoco, Caterpillar and Whirlpool who allowed me to use their policies as the 429 real examples that make this document possible. 431 C. Authors Address 433 Weston Nicolls 434 Ernst & Young LLP 435 111 N. Canal St 436 Chicago, IL 60606 437 (312) 879-2075 438 weston.nicolls@ey.com 440 D. Open issues: