RFC 3114

Implementing Company Classification Policy with the S/MIME Security Label

📅 published May 2002, from ietf

RFC 3114: Implementing Company Classification Policy with the S/MIME Security Label 🎀

Okay bestie, this one is from the Network Working Group 🌸 It was written by W. Nicolls of Forsythe Solutions, it's marked as Informational, and it's dated May 2002 ✨ The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🌈

Okay so this doc is about how a company's data classification policy can be mapped onto the S/MIME security label 🫶 It walks through real policies from three companies as worked examples, which is honestly my favourite part ✨

1. Introduction 💖

Security labels are an optional security service for S/MIME 🎀 A security label is a bundle of security info about how sensitive the content protected by S/MIME encapsulation is 🔥 You can put a security label in the signed attributes of any SignedData object, and it can go in the inner signature, the outer signature, or both 🦋 The syntax and processing rules for security labels are described in RFC 2634 [ESS] 🧚

The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119 [MUSTSHOULD] 💅 This is the bit where the capital words are doing the heavy lifting, so read it carefully bestie 👑

1.1 Information Classification Policies 🍓

Information is an asset, but not all information is worth the same to a business 💜 Not all of it needs the same level of protection either ✨

Research and development plans, marketing strategies, and manufacturing quality specifications give a company its competitive advantage, so that kind of info needs stronger protection than the rest 🔥 If it gets disclosed or modified, the company takes moderate to severe damage 😭

Other stuff, like internal org charts, employee lists, and policies, might need little or no protection, depending on how much the organization values it 🌸

A corporate information classification policy spells out how information assets get protected 🫶 It gives employees guidance on classifying assets, and it defines how to label and protect an asset based on its classification and its state (for example facsimile, electronic transfer, storage, shipping, and so on) 💅

1.2 Access Control and Security Labels 🦋

"Access control" is a means of enforcing authorizations 🎀 There are a bunch of access control methods, and they're based on different kinds of policies and rely on different security mechanisms 🌈

  • Rule based access control is based on policies that can be algorithmically expressed. ✨
  • Identity based access control is based on a policy that applies explicitly to an individual person or host entity, or to a defined group of those entities. Once identity has been authenticated, if the identity is verified to be on the access list, then access is granted. 🔥
  • Rank base access control is based on a policy of hierarchical positions in an organization. It's about who you are in the company structure. A rank-based policy would define what information the position of Partner or Senior Consultant could access. 👑
  • Role based access control is based on a policy of roles in an organization. It may or may not be hierarchical. It's about who you are in the company. A role-based policy would define what information the role of Database Administrator, Network Administrator, Mailroom Clerk, or Purchaser could access. 💖

Rule, rank, and role-based access control methods can all use a security label as the mechanism that conveys how sensitive or classified the info is 🫶 When an S/MIME encapsulated message gets processed, the sensitivity info in its security label can be compared against the recipient's authorizations to figure out whether they're allowed to access the protected content 🧚

An S/MIME security label can be included as a signed attribute in the inner (or only) signature or in the outer signature 💅 With a triple-wrapped message as defined in RFC 2634, the inner signature is used for access control decisions about the plaintext original content, and the outer signature is used for access control decisions about the encrypted message 🦋

1.3 User Authorizations 🌸

Users need to be granted authorizations before they can access information that an authority has classified 😭 The sending and receiving agents need to be able to securely figure out the user's authorizations for access control processing 🎀

X.509 [X.509] and the Internet profile for X.509 certificates [CERTCRL] don't define a way to represent and convey authorizations in a certificate 💅

X.501 [X.501] defines how to represent authorization as a clearance attribute 🌈 The clearance attribute names the security policy in force, and a list of possible classifications and security categories relates to that policy ✨

X.501 also points out two ways to bind the clearance to a named entity: an Attribute Certificate, or a Certificate extension field (for example, within the subjectDirectoryAttribute extension) 🔥

RFC 3281 [AC509] defines a profile of the X.509 Attribute Certificate (AC) that's suitable for authorization info in Internet Protocols 👑 One of its defined attributes is Clearance, which carries clearance (security labeling) info about the AC owner 💖 The syntax for Clearance is imported from X.501 🫶

2. Developed Examples 🧚

2.1 Classification Policies 💅

Here's how the information classification policies look at 3 companies 🦋

2.1.1 Amoco Corporation 🎀

This description of the Amoco information classification policy was taken from the Amoco Computer Security Guidelines 🌈 Amoco classifies its info assets by confidentiality and integrity, and it defines 3 hierarchical classifications for each one ✨ The confidentiality and integrity polices are independent of each other, so either one or both may be applied to the information 🔥 Amoco also defines an availability classification for time critical information 👑

  • HIGHLY CONFIDENTIAL: Info whose unauthorized disclosure will cause the company severe financial, legal, or reputation damage 💀 Examples are certain acquisitions, bid economics, and negotiation strategies 💖
  • CONFIDENTIAL: Info whose unauthorized disclosure may cause the company financial, legal, or reputation damage 🫶 Examples are Employee Personnel & Payroll Files and some interpreted Exploration Data 🧚
  • GENERAL: Info that is restricted for use within the company because of its personal, technical, or business sensitivity 🦋 Unless it's otherwise classified, all information within Amoco is in this category 🌸
  • MAXIMUM: Info whose unauthorized modification and destruction will cause the company severe financial, legal, or reputation damage 😭
  • MEDIUM: Info whose unauthorized modification and destruction may cause the company financial, legal, or reputation damage 🔥 Examples are Electronic Funds, Transfer, Payroll, and Commercial Checks 💅
  • MINIMUM: An error in this data would have minimal consequence, but it's still important company info, so it'll need some minimal controls to keep a minimal level of assurance that its integrity is maintained 🌈 This applies to all data that isn't placed in one of the above classifications 🎀 Examples are Lease Production Data, Expense Data, Financial Data, and Exploration Data ✨
  • CRITICAL: It's important to assess the availability requirements of data, applications, and systems 🧚 A business decision is needed to decide how long unavailability can be tolerated before extra resources get spent on making sure the required information availability is there 👑 Info should be labeled "CRITICAL" if it's been determined that special procedures should be used to keep it available 🔥

2.1.2 Caterpillar, Inc. 🌸

This description of the Caterpillar information classification policy is taken from the Caterpillar Information Protection Guidelines 💖 Caterpillar classifies its info assets by confidentiality and defines 4 hierarchical classifications 🦋

Caterpillar Confidential Red 🔥 This info provides a significant competitive advantage. Disclosing it would cause severe damage to operations and would cause regulatory or contractual liability. It relates to or describes a long-term strategy or critical business plans. It would also cause severe damage to our reputation or public image, a severe loss of market share, or the ability to be first to market, and a loss of an important customer, shareholder, or business partner. Disclosure would cause a long-term or severe drop in stock value. There's a strong likelihood somebody is trying to acquire it 😭

Caterpillar Confidential Yellow 🌈 This info provides a competitive advantage. Disclosing it could cause moderate damage to the company or to an individual 💅 It relates to or describes an important part of the company's operational direction over time, and important technical or financial aspects of a product line or business unit 🧚 Disclosure could cause a loss of Customer or Shareholder confidence and a temporary drop in stock value 🫶 There's a likelihood somebody could seek to acquire it 🎀

Caterpillar Confidential Green 🍓 This info might give a business advantage over people who don't have access to the same info, and it might be useful to a competitor ✨ It isn't easily identifiable by inspecting a product, it isn't generally known outside the company or available from public sources, and it's generally available internally 🌸 There's little competitive interest in it 💜

Caterpillar Public 🦋 This info would not provide a business or competitive advantage 🌈 It's routinely made available to interested members of the General Public, and there's little or no competitive interest in it 💖

More RFC coming in the next part, bestie 🫶💅

2.1.3 Whirlpool Corporation ✨

Okay bestie, the Whirlpool entry comes straight from their Information Protection Policy 💅. They sort everything by confidentiality and have 3 hierarchical classifications 🔥. Their policy says:

"All information generated by or for Whirlpool, in whatever form, written, verbal, or electronic, is to be treated as WHIRLPOOL INTERNAL or WHIRLPOOL CONFIDENTIAL. Classification of information in either category depends on its value, the impact of unauthorized disclosure, legal requirements, and the manner in which it needs to be used by the company. Some WHIRLPOOL INTERNAL information may be authorized for public release."

So here's the lineup:

  • WHIRLPOOL CONFIDENTIAL 🔒: a subset of Whirlpool Internal info. If it gets leaked or compromised, it would likely hurt the company's competitive position, tarnish its reputation, or embarrass an individual. Examples are customer, financial, pricing, or personnel data, merger/acquisition, product, or marketing plans, new product designs, and proprietary processes and systems.
  • WHIRLPOOL INTERNAL 🏢: all forms of proprietary information that Whirlpool originated or owns, or that someone else entrusted to it. Examples are org charts, policies, procedures, phone directories, and some types of training materials.
  • WHIRLPOOL PUBLIC 🌸: information officially released for widespread public disclosure. Examples are press releases, public marketing materials, employment advertising, annual reports, product brochures, the public web site, etc.

The policy also allows privacy markings, and the rules are kinda specific 🙈:

For WHIRLPOOL INTERNAL, additional markings or caveats are optional at the discretion of the information owner.

For WHIRLPOOL CONFIDENTIAL, add additional marking or caveats as necessary to comply with regulatory or heightened security requirements. Examples: MAKE NO COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT, DISTRIBUTION LIMITED TO ____, COVERED BY A NON-ANALYSIS AGREEMENT.

2.2 S/MIME Classification Label Organizational Examples 💖

RFC 2634 [ESS] defines the ESSSecurityLabel syntax and processing rules. This section builds on those definitions to spell out detailed example policies 🧚

2.2.1 Security Label Components

The examples are broken down using the different components of the eSSSecurityLabel syntax 🎀

2.2.1.1 Security Policy Identifier

A security policy is a set of criteria for providing security services. The eSSSecurityLabel security-policy-identifier identifies the security policy in force that the security label relates to. It tells you what the other security label components mean 🔍

For the example policies, these security policy object identifiers are defined:

-- S/MIME Working Group Object Identifier Registry
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                               rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

-- S/MIME Test Security Policy Arc
id-tsp  OBJECT IDENTIFIER ::= { id-smime 7 }

-- Test Security Policies
id-tsp-TEST-Amoco          OBJECT IDENTIFIER ::= { id-tsp 1 }
id-tsp-TEST-Caterpillar    OBJECT IDENTIFIER ::= { id-tsp 2 }
id-tsp-TEST-Whirlpool      OBJECT IDENTIFIER ::= { id-tsp 3 }

2.2.1.2 Security Classification

The governing company policies define the security classification values and what they mean 📋. These values are hierarchical, and they do not use the integers 0 through 5 🙅‍♀️

Amoco-SecurityClassification ::= INTEGER {
  amoco-general (6),
  amoco-confidential (7),
  amoco-highly-confidential (8) }

Caterpillar-SecurityClassification ::= INTEGER {
  caterpillar-public (6),
  caterpillar-green (7),
  caterpillar-yellow (8),
  caterpillar-red (9) }

Whirlpool-SecurityClassification ::= INTEGER {
  whirlpool-public (6),
  whirlpool-internal (7),
  whirlpool-confidential (8) }

2.2.1.3 Privacy Mark

Privacy marks are specified in the Whirlpool policy 🌈. That policy gives examples of possible markings, and users can define others when they need them, though no guidance is given for doing that. The Whirlpool policy's examples are: MAKE NO COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT, DISTRIBUTION LIMITED TO ____, and COVERED BY A NON-ANALYSIS AGREEMENT.

The Amoco policy doesn't identify any privacy marks, but the classification labels defined for availability and integrity would be the most fitting things to display here 🦋. The CRITICAL, MAXIMUM, MEDIUM, and MINIMUM labels are examples of classifications that are not used for access control.

In general, privacy marks should give the user brief but clear direction on how to handle the information ✨

2.2.1.4 Security Categories

Security categories (or caveats) aren't specified in any of the sample policies. However, at least 2 of the companies use them 👀. Even though their security policies don't define them formally, once they're defined locally they count as formal and must be enforced. Security categories get defined when needed to give more granular access control over identifiable proprietary information. A category can be based on the organization or on a project (for example, Legal Only or Project Vallor) 💜

2.2.1.4.1 Syntax

Security categories are represented in the RFC 2634 ESSSecurityLabel (to specify the sensitivity of labeled data) and the X.501 Clearance attribute (to specify an entity's authorizations) using the following syntax 📐

SecurityCategories ::= SET SIZE (1..ub-security-categories)
                       OF SecurityCategory

ub-security-categories INTEGER ::= 64

SecurityCategory ::= SEQUENCE {
  type  [0] OBJECT IDENTIFIER
  value [1] ANY DEFINED BY type } -- defined by type

One example of a SecurityCategory syntax is SecurityCategoryValues, shown below 🍓

When id-securityCategoryValues is present in the SecurityCategory type field, the SecurityCategory value field could take the form of:

SecurityCategoryValues ::= SEQUENCE OF UTF8String

2.2.1.4.2 Use

An organization will define a securityCategoryType OID that represents the syntax for a security category value within its security policy 🏷️

For the example security category syntax, a UTF8String is used to convey the security category value that applies to the labeled message. Access MUST be restricted to only those entities who are authorized to access every SecurityCategoryValue. Access is authorized if the ESSSecurityLabel SecurityCategoryValue EXACTLY matches the Clearance SecurityCategoryValue 🚫✅

2.2.2 Attribute Owner Clearance

The security clearance and category authorizations for the user are defined in the clearance attribute 🔑

2.2.2.1 Amoco User

Clearance:
  policyId:  1 2 840 113549 1 9 16 7 1
  classList:  amoco-general              (6),
              amoco-confidential         (7),
              amoco-highly-confidential  (8)

2.2.2.2 Caterpillar User

Clearance:
  policyId:  1 2 840 113549 1 9 16 7 2
  classList:  caterpillar-public              (6),
              caterpillar-confidential-green  (7),
              caterpillar-confidential-yellow (8),
              caterpillar-confidential-red    (9)

2.2.2.3 Whirlpool User

Clearance:
  policyId:  1 2 840 113549 1 9 16 7 3
  classList:  whirlpool-public        (6),
              whirlpool-internal      (7),
              whirlpool-confidential  (8)

2.2.3 Security Category Example

This section includes an example RFC 2634 ESSSecurityLabel with the example Security Category syntax 🎬. It also includes example X.501 Clearance attributes. One of them has a set of authorizations that passes the access control check for the example ESSSecurityLabel ✅. The other example Clearance attributes each have a set of authorizations that fails the access control check 🙈

These examples use the id-tsp-TEST-Whirlpool OID defined in section 2.2.1.1. Assume the security policy identified by id-tsp-TEST-Whirlpool defines one securityCategoryType OID as follows:

id-tsp-TEST-Whirlpool-Categories OBJECT IDENTIFIER ::= { id-tsp 4 }

Example ESSSecurityLabel:

 security-policy-identifier: id-tsp-3
 security-classification: 8
 privacy-mark: ATTORNEY-CLIENT PRIVILEGED INFORMATION
 security-categories: SEQUENCE OF SecurityCategory

 SecurityCategory #1
   type:  id-tsp-4
   value:  LAW DEPARTMENT USE ONLY

Example Clearance Attribute #1 (passes access control check):

Clearance:
  policyId: id-tsp-3
  classList BIT STRING: Bits 6, 7, 8 are set to TRUE
  securityCategories: SEQUENCE OF SecurityCategory

  SecurityCategory #1
    type:  id-tsp-4
    value:  LAW DEPARTMENT USE ONLY

Example Clearance Attribute #2 (fails access control check because SecurityCategoryValues do not match):

Clearance:
  policyId: id-tsp-3
  classList BIT STRING: Bits 6, 7, 8 are set to TRUE
  securityCategories: SEQUENCE OF SecurityCategory

  SecurityCategory #1:
    type:  id-tsp-4
    value:  HUMAN RESOURCES USE ONLY

2.2.4 Additional ESSSecurityLabel Processing Guidance

One implementation issue can be mapping the security label values to displayable characters 🗺️. This matters for users who want to create and retire their own classifications and categories on a regular basis, and when the values are encoded in a form humans can't read. Applications should provide a way for the enterprise to manage these changes. Hard coding the mapping into the applications is discouraged 🙅‍♀️

This is considered a local issue for the application vendor, since the solution doesn't need to be interoperable between vendors 🏠

One approach is to use a Security Policy Information File (SPIF) [ISO15816]. A SPIF is a construct that conveys domain-specific security policy information 📜. It's a signed object, which protects it from unauthorized changes and authenticates the source of the policy information. It contains critical display information, such as the text strings for security classifications and security categories that get shown to the user, plus additional security policy information 💅

Another implementation issue can be getting the recipient's certificate when sending a signed-only message with a security label 📨. Normally the recipient's certificate is only needed when sending an encrypted message. Applications need to be able to retrieve the recipient's certificate so the recipient's clearance information is available for the access control check 🫶

3. Security Considerations 🔥

All security considerations from RFC 2630 [CMS] and RFC 2634 [ESS] apply to applications that use the procedures described in this document 🚨 Like, this is a whole safety net, so don't skip it 😭

References 📚✨

Okay bestie, this is the bibliography, so every single source gets listed with all its details. Here we go 💅

  • [AC509] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002. 🎀
  • [CERTCRL] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. 🦋
  • [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. 🌸
  • [ESS] Hoffman, P., Editor, "Enhanced Security Services for S/MIME", RFC 2634, June 1999. 💜
  • [MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 👑
  • [X.501] "ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection - The Directory: Models", 1993. 🧚
  • [X.509] "ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", June 1997. ⭐
  • [ISO15816] "Information Technology - Security Techniques - Security Information Objects for Access Control", ISO/IEC FDIS 15816:2000. 🍓

Acknowledgements 🫶

Okay, the thank-yous are so sweet. Weston says a big thank you to Russ Housley for helping them through developing this document, to John Pawling for the technical assistance and guidance, and to Dan Quealy for the security policy expertise 🙌. They also thank Ernst & Young LLP and Telenisus for supporting the work while they were employed there 💖. And the real MVPs are the good people at Amoco (bp), Caterpillar and Whirlpool, who let them use their policies as the real examples that make this whole document possible 🌈.

Quick tea ☕: Caterpillar and Whirlpool were each asked if they wanted to give contacts about their security policies, but they politely said no thanks 🙈.

Author's Address 📮

Weston Nicolls Forsythe Solutions 7500 Frontage Rd Skokie, IL 60077

Phone: (847) 763-2370 EMail: wnicolls@forsythesolutions.com

Copyright (C) The Internet Society (2002). All Rights Reserved. 🔒

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💌

Funding for the RFC Editor function is currently provided by the Internet Society ✨.

📦 where this page comes from