Implementing Company Classification Policy with the S/MIME Security Label
RFC 3114
Document | Type | RFC - Informational (May 2002; No errata) | |
---|---|---|---|
Author | Weston Nicolls | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
This information refers to IESG processing after the RFC was initially published: | |||
IESG | IESG state | RFC 3114 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Steven Bellovin | ||
Send notices to | <turners@ieca.com>, <blake@brutesquadlabs.com> |
Network Working Group W. Nicolls Request for Comments: 3114 Forsythe Solutions Category: Informational May 2002 Implementing Company Classification Policy with the S/MIME Security Label 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 Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document discusses how company security policy for data classification can be mapped to the S/MIME security label. Actual policies from three companies provide worked examples. 1. Introduction Security labels are an optional security service for S/MIME. A security label is a set of security information regarding the sensitivity of the content that is protected by S/MIME encapsulation. A security label can be included in the signed attributes of any SignedData object. A security label attribute may be included in either the inner signature, 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]. 1.1 Information Classification Policies Information is an asset, but not all information has the same value for a business. Not all information needs to be protected as strongly as other information. Research and development plans, marketing strategies and manufacturing quality specifications developed and used by a company provide competitive advantage. This type of information needs Nicolls Informational [Page 1] RFC 3114 Implementing Company Classification Policy May 2002 stronger protective measures than other information, which if disclosed or modified, would cause moderate to severe damage to the company. Other types of information such as internal organization charts, employee lists and policies may need little or no protective measures based on value the organization places on it. A corporate information classification policy defines how its information assets are to be protected. It provides guidance to employees on how to classify information assets. It defines how to label and protect an asset based on its classification and state (e.g., facsimile, electronic transfer, storage, shipping, etc.). 1.2 Access Control and Security Labels "Access control" is a means of enforcing authorizations. There are a variety of access control methods that are based on different types 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 which applies explicitly to an individual person or host entity, or to a defined group of such 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 is based on who you are in the company structure. A rank-based policy would define what information that 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 is based on who you are in the company. The role-based policy would define what information that the role of Database Administrator, Network Administrator, Mailroom Clerk or Purchaser could access. Rule, rank and role-based access control methods can rely on a security label as the security mechanism to convey the sensitivity or classification of the information. When processing an S/MIME encapsulated message, the sensitivity information in the message's security label can be compared with the recipient's authorizations to determine if the recipient is allowed to access the protected content. Nicolls Informational [Page 2] RFC 3114 Implementing Company Classification Policy May 2002 An S/MIME security label may be included as a signed attribute in the inner (or only) signature or the outer signature. In the case of a triple-wrapped message as defined in RFC 2634, the inner signature would be used for access control decisions related to the plaintext original content, while the outer signature would be used for access control decisions related to the encrypted message.Show full document text