idnits 2.17.1 draft-ietf-smime-seclabel-03.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. Found some kind of copyright notice around line 29 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-19) 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: ---------------------------------------------------------------------------- == 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 521 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.) ** There are 179 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 9 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 366: '...to the labeled message. Access MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (January 2001) is 8495 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 488 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 490 looks like a reference -- Missing reference section? 'CERTCRL' on line 119 looks like a reference -- Missing reference section? 'AC509' on line 483 looks like a reference -- Missing reference section? '0' on line 350 looks like a reference -- Missing reference section? '1' on line 351 looks like a reference -- Missing reference section? 'CMS' on line 486 looks like a reference -- Missing reference section? 'ISO15816' on line 500 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 11 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 Telenisus Corporation 3 Expires July, 2001 January 2001 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 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months and 19 may be updated, replaced, or obsoleted by other documents at any time. It 20 is inappropriate to use Internet-Drafts as reference material or to cite 21 them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright (C) The Internet Society (2001). All Rights Reserved. 31 1. Introduction 33 This document discusses how company security policy for data classification 34 can be mapped to the S/MIME security label. Actual policies from 3 companies 35 are used to provide worked examples. 37 Security labels are an optional security service for S/MIME. A security label 38 is a set of security information regarding the sensitivity of the content 39 that is protected by S/MIME encapsulation. A security label can be included 40 in the signed attributes of any SignedData object. A security label attribute 41 may be included in either the inner signature, outer signature, or both. 42 The syntax and 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 moderate to severe 63 damage to 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. It is based on who you are in the company structure. A rank-based 91 policy would define what information that the position of Partner or Senior 92 Consultant could access. 94 - Role based access control is based on a policy of roles in an organization. 95 It may or may not be hierarchical. It is based on who you are in the company. 96 The role-based policy would define what information that the role of Database 97 Administrator, Network Administrator, Mailroom Clerk or Purchaser could access. 99 Rule, rank and role-based access control methods can rely on a security label as 100 the security mechanism to convey the sensitivity or classification of the 101 information. When processing an S/MIME encapsulated message, the sensitivity 102 information in the message's security label can be compared with the recipient's 103 authorizations to determine if the recipient is allowed to access the protected 104 content. 106 An S/MIME security label may be included as a signed attribute in the inner 107 (or only) signature or the outer signature. In the case of a triple-wrapped 108 message as defined in RFC 2634, the inner signature would be used for access 109 control decisions related to the plaintext original content, while the outer 110 signature would be used for access control decisions related to the encrypted 111 message. 113 1.3 User Authorizations 115 Users need to be granted authorizations to access information that has been 116 classified by an authority. The sending and receiving agents need to be able to 117 securely determine the user's authorizations for access control processing. 119 [X.509] and the Internet profile for X.509 certificates [CERTCRL] do not define 120 the means to represent and convey authorizations in a certificate. 122 [X.501] defines how to represent authorization in the form of a clearance 123 attribute. The clearance attribute identifies the security policy in force to 124 which a list of possible classifications and security categories relates. 126 [X.501] also notes two means for binding the clearance to a named entity: an 127 Attribute Certificate and a Certificate extension field (e.g., within the 128 subjectDirectoryAttribute extension). 130 [AC509] defines a profile of X.509 Attribute Certificate (AC) suitable for use 131 with authorization information within Internet Protocols. One of the defined 132 attributes is Clearance, which carries clearance (security labeling) information 133 about the AC owner. The syntax for Clearance is imported from [X.501]. 135 2. Developed Examples 137 2.1 Classification Policies 139 The following describes the information classification policies in effect at 3 140 companies. 142 2.1.1 Amoco Corporation 144 The description for the Amoco information classification policy was taken from 145 the Amoco Computer Security Guidelines. Amoco classifies its information assets 146 based on confidentiality and integrity and defines 3 hierarchical 147 classifications for each. The confidentiality and integrity polices are 148 independent, so either or both may be applied to the information. Amoco also 149 defines an availability classification for time critical information. 151 HIGHLY CONFIDENTIAL - Information whose unauthorized disclosure will cause the 152 company severe financial, legal or reputation damage. Examples: Certain 153 acquisitions, bid economics, negotiation strategies. 155 CONFIDENTIAL - Information whose unauthorized disclosure may cause the company 156 financial, legal, or reputation damage. Examples: Employee Personnel & Payroll 157 Files, some interpreted Exploration Data. 159 GENERAL - Information that, because of its personal, technical, or business 160 sensitivity is restricted for use within the company. Unless otherwise 161 classified, all information within Amoco is in this category. 163 MAXIMUM - Information whose unauthorized modification and destruction will cause 164 the company severe financial, legal, or reputation damage. 166 MEDIUM - Information whose unauthorized modification and destruction may cause 167 the company financial, legal, or reputation damage. Examples: Electronic Funds, 168 Transfer, Payroll, and Commercial Checks 170 MINIMUM - Although an error in this data would be of minimal consequence, this 171 is still important company information and therefore will require some minimal 172 controls to ensure a minimal level of assurance that the integrity of the data 173 is maintained. This applies to all data that is not placed in one of the above 174 classifications. Examples: Lease Production Data, Expense Data, Financial Data, 175 and Exploration Data. 177 CRITICAL - It is important to assess the availability requirements of data, 178 applications and systems. A business decision will be required to determine the 179 length of unavailability that can be tolerated prior to expending additional 180 resources to ensure the information availability that is required. Information 181 should be labeled "CRITICAL" if it is determined that special procedures should 182 be used to ensure its availability. 184 2.1.2 Caterpillar, Inc. 186 The description for the Caterpillar information classification policy is taken 187 from the Caterpillar Information Protection Guidelines. Caterpillar classifies 188 its information assets based on confidentiality and defines 4 hierarchical 189 classifications. 191 Caterpillar Confidential Red - Provides a significant competitive advantage. 192 Disclosure would cause severe damage to operations. Relates to or describes a 193 long-term strategy or critical business plans. Disclosure would cause regulatory 194 or contractual liability. Disclosure would cause severe damage to our reputation 195 or the public image. Disclosure would cause a severe loss of market share or the 196 ability to be first to market. Disclosure would cause a loss of an important 197 customer, shareholder, or business partner. Disclosure would cause a long-term 198 or severe drop in stock value. Strong likelihood somebody is seeking to acquire 199 this information. 201 Caterpillar Confidential Yellow - Provides a competitive advantage. Disclosure 202 could cause moderate damage to the company or an individual. Relates to or 203 describes an important part of the operational direction of the company over 204 time. Important technical or financial aspects of a product line or a business 205 unit. Disclosure could cause a loss of Customer or Shareholder confidence. 206 Disclosure could cause a temporary drop in stock value. A likelihood that 207 somebody could seek to acquire this information. 209 Caterpillar Confidential Green - Might provide a business advantage over those 210 who do not have access to the same information. Might be useful to a competitor. 211 Not easily identifiable by inspection of a product. Not generally known outside 212 the company or available from public sources. Generally available internally. 213 Little competitive interest. 215 Caterpillar Public - Would not provide a business or competitive advantage. 216 Routinely made available to interested members of the General Public. Little or 217 no competitive interest. 219 2.1.3 Whirlpool Corporation 221 The description for the Whirlpool information classification policy is taken 222 from the Whirlpool Information Protection Policy. Whirlpool classifies its 223 information assets based on confidentiality and defines 2 hierarchical 224 classifications. The policy states that: 226 "All information generated by or for Whirlpool, in whatever form, written, 227 verbal, or electronic, is to be treated as WHIRLPOOL INTERNAL or WHIRLPOOL 228 CONFIDENTIAL. Classification of information in either category depends on its 229 value, the impact of unauthorized disclosure, legal requirements, and the manner 230 in which it needs to be used by the company. Some WHIRLPOOL INTERNAL 231 information may be authorized for public release." 233 WHIRLPOOL CONFIDENTIAL - A subset of Whirlpool Internal information, the 234 unauthorized disclosure or compromise of which would likely have an adverse 235 impact on the company's competitive position, tarnish its reputation, or 236 embarrass an individual. Examples: Customer, financial, pricing, or personnel 237 data; merger/acquisition, product, or marketing plans; new product designs, 238 proprietary processes and systems. 240 WHIRLPOOL INTERNAL - All forms of proprietary information originated or owned by 241 Whirlpool, or entrusted to it by others. Examples: Organization charts, 242 policies, procedures, phone directories, some types of training materials. 244 WHIRLPOOL PUBLIC - Information officially released by Whirlpool for widespread 245 public disclosure. Example: Press releases, public marketing materials, 246 employment advertising, annual reports, product brochures, the public web site, 247 etc. 249 The policy also states that privacy markings are allowable. Specifically: 251 For WHIRLPOOL INTERNAL, additional markings or caveats are optional at the 252 discretion of the information owner. 254 For WHIRLPOOL CONFIDENTIAL, add additional marking or caveats as necessary to 255 comply with regulatory or heightened security requirements. Examples: MAKE NO 256 COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT, 257 DISTRIBUTION LIMITED TO ____, COVERED BY A NON-ANALYSIS AGREEMENT. 259 2.2 S/MIME Classification Label Organizational Examples 261 [ESS] defines the ESSSecurityLabel syntax and processing rules. This section 262 builds upon those definitions to define detailed example policies. 264 2.2.1 Security Label Components 266 The examples are detailed using the various components of the eSSSecurity Label 267 syntax. 269 2.2.1.1 Security Policy Identifier 271 A security policy is a set of criteria for the provision of security services. 272 The eSSSecurityLabel security-policy-identifier is used to identify the security 273 policy in force to which the security label relates. It indicates the semantics 274 of the other security label components. 276 For the example policies, the following security policy object identifiers are 277 defined: 279 -- S/MIME Working Group Object Identifier Registry 280 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) 281 pkcs(1) pkcs-9(9) 16 } 283 -- S/MIME Test Security Policy Arc 284 id-tsp OBJECT IDENTIFIER ::= { id-smime 7 } 286 -- Test Security Policies 287 id-tsp-TEST-Amoco OBJECT IDENTIFIER ::= { id-tsp 1 } 288 id-tsp-TEST-Caterpillar OBJECT IDENTIFIER ::= { id-tsp 2 } 289 id-tsp-TEST-Whirlpool OBJECT IDENTIFIER ::= { id-tsp 3 } 291 2.2.1.2 Security Classification 293 The security classification values and meanings are defined by the governing 294 company policies. The security-classification values defined are hierarchical 295 and do not use integers 0 through 5. 297 Amoco-SecurityClassification ::= INTEGER { 298 amoco-general (6), 299 amoco-confidential (7), 300 amoco-highly-confidential (8) } 302 Caterpillar-SecurityClassification ::= INTEGER { 303 caterpillar-public (6), 304 caterpillar-green (7), 305 caterpillar-yellow (8), 306 caterpillar-red (9) } 308 Whirlpool-SecurityClassification ::= INTEGER { 309 whirlpool-public (6), 310 whirlpool-internal (7), 311 whirlpool-confidential (8) } 313 2.2.1.3 Privacy Mark 315 Privacy marks are specified the Whirlpool policy. The policy provides examples 316 of possible markings but others can be defined by users as necessary (though no 317 guidance is given). The Whirlpool policy provides the following examples: 318 MAKE NO COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT, 319 DISTRIBUTION LIMITED TO ____, and COVERED BY A NON-ANALYSIS AGREEMENT. 321 The Amoco policy does not identify any privacy marks but the classification 322 labels defined for availability and integrity would be most appropriately 323 displayed here. The CRITICAL, MAXIMUM, MEDIUM, and MINIMUM labels are examples 324 of information classifications that are not used for access control. 326 In general, the privacy marks should provide brief but clear direction to the 327 user on how to handle the information. 329 2.2.1.4 Security Categories 331 Security categories or caveats are not specified in any of the sample policies. 332 However, they are used in at least 2 of the companies. Though the security 333 categories are not defined formally in their security policies, once locally 334 defined they are formal and are to be enforced. The security categories are 335 defined when necessary to provide identifiable proprietary information more 336 granular access control. A category can be based organizationally or by project 337 (i.e., Legal Only or Project Vallor). 339 2.2.1.4.1 Syntax 341 Security categories are represented in the RFC 2634 ESSSecurityLabel 342 (to specify the sensitivity of labeled data) and X.501 Clearance attribute 343 (to specify an entity's authorizations) using the following syntax. 345 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategory 347 ub-security-categories INTEGER ::= 64 349 SecurityCategory ::= SEQUENCE { 350 type [0] OBJECT IDENTIFIER 351 value [1] ANY DEFINED BY type -- defined by type 353 One example of a SecurityCategory syntax is SecurityCategoryValues, as follows. 355 When id-securityCategoryValues is present in the SecurityCategory type field, 356 then the SecurityCategory value field could take the form of: 358 SecurityCategoryValues ::= SEQUENCE OF UTF8String 360 2.2.1.4.2 Use 362 An organization will define a securityCategoryType OID representing the 363 syntax for representing a security category value within their security policy. 365 For the example security category syntax, a UTF8String is used to convey the 366 security category value that applies to the labeled message. Access MUST be 367 restricted to only those entities who are authorized to access every 368 SecurityCategoryValue. Access is authorized if the ESSSecurity Label 369 SecurityCategoryValue EXACTLY matches the Clearance SecurityCategoryValue. 371 2.2.2 Attribute Owner Clearance 373 The security clearance and category authorizations for the user are defined in 374 the clearance attribute. 376 2.2.2.1 Amoco User 378 Clearance: 379 policyId: 1 2 840 113549 1 9 16 7 1 380 classList: amoco-general (6), 381 amoco-confidential (7), 382 amoco-highly confidential (8), 384 2.2.2.2 Caterpillar User 386 Clearance: 387 policyId: 1 2 840 113549 1 9 16 7 2 388 classList: caterpillar-public (6), 389 caterpillar-confidential greeen (7), 390 caterpillar-confidential yellow (8), 391 caterpillar-confidential red (9) 393 2.2.2.3 Whirlpool User 395 Clearance: 396 policyId: 1 2 840 113549 1 9 16 7 3 397 classList: whirlpool-public (6), 398 whirlpool-internal (7), 399 whirlpool-confidential (8), 401 2.2.3 Security Category Example 403 This section includes an example RFC 2634 ESSSecurityLabel including the example 404 Security Category syntax. This section also includes example X.501 405 Clearance attributes. One of the example Clearance attributes includes a 406 set of authorizations that pass the access control check for the example 407 ESSSecurityLabel. The other example Clearance attributes each include a set 408 of authorizations that fail the access control check for the example 409 ESSSecurityLabel. 411 These examples use the id-tsp-TEST-Whirlpool OID defined 412 in section 2.2.1.1. Assume that the security policy identified 413 by id-tsp-TEST-Whirlpool defines one securityCategoryType OIDs as follows: 415 id-tsp-TEST-Whirlpool-Categories OBJECT IDENTIFIER ::= { id-tsp 4 } 417 Example ESSSecurityLabel: 418 security-policy-identifier: id-tsp-3 419 security-classification: 8 420 privacy-mark: ATTORNEY-CLIENT PRIVILEGED INFORMATION 421 security-categories: SEQUENCE OF SecurityCategory 423 SecurityCategory #1 424 type: id-tsp-4 425 value: LAW DEPARTMENT USE ONLY 427 Example Clearance Attribute #1 (passes access control check): 429 Clearance: 430 policyId: id-tsp-3 431 classList BIT STRING: Bits 6, 7, 8 are set to TRUE 432 securityCategories: SEQUENCE OF SecurityCategory 434 SecurityCategory #1 435 type: id-tsp-4 436 value: LAW DEPARTMENT USE ONLY 438 Example Clearance Attribute #2 (fails access control check because 439 SecurityCategoryValues do not match): 441 Clearance: 442 policyId: id-tsp-3 443 classList BIT STRING: Bits 6, 7, 8 are set to TRUE 444 securityCategories: SEQUENCE OF SecurityCategory 446 SecurityCategory #1: 447 type: id-tsp-4 448 value: HUMAN RESOURCES USE ONLY 450 2.2.4 Additional ESSSecurityLabel Processing Guidance 452 An implementation issue can be the mapping of the security label values to 453 displayable characters. This is an issue for users who want to develop and 454 retire their own classifications and categories a regular basis and when the 455 values are encoded in non-human readable form. Applications 456 should provide a means for the enterprise to manage these changes. The practice 457 of hard coding the mapping into the applications is discouraged. 459 This issue is viewed as local issue for the application vendor, as the solution 460 does not need to be interoperable between vendors. 462 An approach is the use of a Security Policy Information File (SPIF)[ ISO15816]. 463 A SPIF is a construct that conveys domain-specific security policy information. 464 It is a signed object to protect it from unauthorized changes and to 465 authenticate the source of the policy information. It contains critical display 466 information such as the text string for security classifications and security 467 categories to be displayed to the user, as well as additional security policy 468 information. 470 Another implementation issue can be obtaining the recipient's certificate when 471 sending a signed-only message with a security label. Normally the recipient's 472 certificate is only needed when sending an encrypted message. Applications will 473 need to be able to retrieve the recipient's certificate so that the recipient's 474 clearance information is available for the access control check. 476 3. Security Considerations 478 All security considerations from [CMS] and [ESS] apply to applications that use 479 procedures described in this document. 481 A. References 483 [AC509] Farrell, S., Housley, R., "An Internet Attribute Certificate Profile for 484 Authorization", draft-ietf-pkix-ac509prof-05.txt. 486 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. 488 [ESS] Hoffman, P., Editor, "Enhanced Security Services for S/MIME", RFC 2634. 490 [MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 491 Levels", RFC 2119. 493 [X.501] "ITU-T Recommendation X.501: Information Technology - Open Systems 494 Interconnection - The Directory: Models", 1993. 496 [X.509] "ITU-T Recommendation X.509 (1997 E): Information 497 Technology - Open Systems Interconnection - The Directory: Authentication 498 Framework", June 1997. 500 [ISO15816] "Information Technology - Security Techniques - Security Information 501 Objects for Access Control", ISO/IEC FDIS 15816:2000. 503 B. Acknowledgements 505 I would like to thank Russ Housley for helping me through the process of 506 developing this document. I would like to thank John Pawling for his technical 507 assistance and guidance. I would also like to thank the good people at Amoco 508 (bp), Caterpillar and Whirlpool who allowed me to use their policies as the 509 real examples that make this document possible. 511 C. Author's Address 513 Weston Nicolls 514 Telenisus Corporation (formerly with Ernst & Young LLP) 515 1701 Golf Rd 516 Tower 3, Suite 600 517 Rolling Meadows, IL 60008 518 (847) 871-5086 519 wnicolls@telenisus.com