Implementing Company Classification Policy with the S/MIME Security Label
RFC 3114
|
| Document |
Type |
|
RFC - Informational
(May 2002; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
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)
|
|
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
Show full document text