Network Working Group A. Melnikov
Internet-Draft K. Zeilenga
Intended status: Standards Track Isode Limited
Expires: February 15, 2012 August 14, 2011
Security Labels in Internet Email
draft-zeilenga-email-seclabel-02
Abstract
This document describes a header field, SIO-Label, for use in
Internet Mail to convey the sensitivity of the message. The SIO-
Label header field which may carry a textual representation (a
display marking) and/or a structural representation (a security
label) of the sensitivity of the message.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 15, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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.
Melnikov & Zeilenga Expires February 15, 2012 [Page 1]
Internet-Draft email-seclabel August 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Relationship to Inline Sensitivity Markings . . . . . . . . . 3
3. Relationship to preexisting Security Label Header Fields . . . 4
4. Relationship to Enhanced Security Services for S/MIME . . . . 5
5. Conventions Used in This Document . . . . . . . . . . . . . . 5
6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. The SIO-Label header field . . . . . . . . . . . . . . . . . . 6
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Melnikov & Zeilenga Expires February 15, 2012 [Page 2]
Internet-Draft email-seclabel August 2011
1. Introduction
A security label, sometimes referred to as a confidentiality label,
is a structured representation of the sensitivity of a piece of
information. A security label is used in conjunction with a
clearance, a structured representation of what information
sensitivities a person (or other entity) is authorized to access, and
a security policy to control access to each piece of information.
For instance, an email message could have a EXAMPLE CONFIDENTIAL
label, and hence requiring the sender and the receiver to have a
clearance granting access to EXAMPLE CONFIDENTIAL labeled
information. X.841 [X.841] provides a discussion of security labels,
clearances, and security policy.
A display marking is a textual representation of the sensitivity of a
piece of information. For instance, "EXAMPLE CONFIDENTIAL" is a
textual representation of the sensitivity. A security policy can be
used to generate display markings from security labels. Display
markings are generally expected to be prominently displayed whenever
the content is displayed.
Sensitivity-based authorization is used in networks which operate
under a set of information classification rules, such as in
government military agency networks. The standardized formats for
security labels, clearances, and security policy are generalized and
do have application in non-government networks.
Security labels may also be used for purposes other than
authorization. In particular, they may be used simply to convey the
sensitivity of a piece information. The security label could be
used, for instance, to organize content in a content store.
This document describes a protocol for conveying the sensitivity of a
electronic mail message [RFC5322], as a whole. In particular, this
document describes a header field SIO-Label to carry a security
label, a display marking, and display colors.
This protocol is based in part upon Security Labels in XMPP [XEP258]
protocol.
2. Relationship to Inline Sensitivity Markings
In environments requiring messages to be marked with an indication of
their sensitivity, it is common to place a textual representation of
the sensitivity, a display marking, within the body to the message
and/or in the Subject header field. For instance, the authors often
receives messages of the form:
Melnikov & Zeilenga Expires February 15, 2012 [Page 3]
Internet-Draft email-seclabel August 2011
To: author <author@example.com>
From: Some One <someone@example.net>
Subject: the subject (UNCLASSIFIED)
Marking: UNCLASSIFIED
Text of the message.
Marking: UNCLASSIFIED
Typically, when placed in the body of the message, the marking is
inserted into the content such that it appears as the first line(s)
of text of the body of the message. This is known as a FLOT. The
marking may or may not be surrounded by other text indicating the
marking denotes the sensitivity of the message. A FLOT may also
accompanied by a LLOT (last line(s) of text) marking. The message
above contains a two-line FLOT and a two-line LLOT (in both cases, a
line providing a Protective Marking and a empty line between the
marking and the original content).
Typically, when placed in the Subject of the message, the marking is
inserted before or after the original subject field contents
surrounded with by parentheses or the like, and separated from the
content by white space.
The particulars syntax and semantics of inline sensitivity markings
is generally a local matter. This hinders interoperability within an
organization wanting to take actions based upon these markings, and
hinders interoperability between cooperating organizations wanting to
usefully share sensitivity information
The authors expect such markings to be continued to widely used,
especially in absence of ubiquitous support for a standardized header
field indicating the sensitivity of the message.
The authors hope that through the use of standardized header field,
interoperability within organizations and between organizations can
be improved.
3. Relationship to preexisting Security Label Header Fields
A number of non-standard header fields, such as the X-X411 field, are
used to carry a representation of the sensitivity of the message,
whether a structured representation or textual representation.
The authors hope the use of non-standard header fields will be
replaced, over time, with use of the header field described in this
document.
Melnikov & Zeilenga Expires February 15, 2012 [Page 4]
Internet-Draft email-seclabel August 2011
4. Relationship to Enhanced Security Services for S/MIME
Enhanced Security Services for S/MIME (ESS) [RFC2634] provides,
amongst other services, signature services "for content integrity,
non-repudiation with the proof of origin, and [securely] binding
attributes (such as a security label) to the original content."
While it may be possible to utilize the protocol described in this
document concurrently with ESS, this protocol should generally be
viewed as an alternative to ESS.
It is noted that in ESS, the security label applies to MIME [RFC2045]
content, where in this protocol the label applies to the message as a
whole.
It is also noted that in ESS, security labels are securely bound to
the MIME content through the use of digital signatures. This
protocol does not provide message signing services, and hence does
not provide securely binding the label to the message, or for content
integrity, or for non-repudiation of the proof of origin.
This protocol is designed for situations/environments where message
signing is not necessary to provide sufficient security.
5. Conventions Used in This Document
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 [RFC2119].
6. Overview
A Mail User Agent (MUAs) originating a message can, if so configured,
offer the user with a menu of sensitivities to choose from and, upon
selection, insert the display marking, foreground and background
colors, and security label parameters associated with that selection
into the SIO-Label header field of the message.
Mail Submission Agents (MSAs), Mail Transfer Agents (MTAs), and Mail
Delivery Agents (MDAs) then can, if so configured, use the provided
(or lack thereof) sensitivity information in determining whether to
accept, forward, or otherwise act on the message as submitted. These
agents, here after referred to as Service Agents (SAs), can, if so
configured, modify the sensitivity information of the message, such
as replacing the security label with an equivalent security label of
a different policy.
Receiving MUAs which implement this extension SHALL, when displaying
Melnikov & Zeilenga Expires February 15, 2012 [Page 5]
Internet-Draft email-seclabel August 2011
the message, also prominently display the marking, if any, conveyed
in the header field or, if policy aware, a marking generated by the
conveyed label and the governing policy. It is also desirable to
display this marking in listings of messages. In the case the
conveyed marking is displayed, marking SHOULD be displayed using the
foreground and background colors conveyed in the header field. In
the case the marking was generated from conveyed label and the
governing policy, the marking SHOULD be displayed using the
foreground and background colors conveyed by the governing policy.
While MUAs are not expected to make authorization decisions based
upon values of the SIO-Label header field, MUAs can otherwise use the
provided (or lack thereof) sensitivity information in determining how
to act on the message. For instance, the MUA may organize messages
in its store of messages based upon the content of this header field.
7. The SIO-Label header field
The header field name is "SIO-Label" and its content is a set of key/
value pairs, each referred to as a parameter.
The marking parameter contains a display string for use by
implementations which are unable or unwilling to utilize the
governing security policy to generate display markings. The marking
parameter SHOULD generally be provided in SIO-Label header fields.
It ought only be absent where an SA relies on other SA to generate
the marking.
The fgcolor and bgcolor parameters contain the foreground and
background colors, respectively, for use in colorizing the display
marking string. Their values are RGB colors in hexadecimal format
(e.g., "#ff0000"), or one of the CSS color names (e.g., "red") given
in named-color type below (the 16 HTML4 colors + "orange")
[CSS3-Color]. The default foreground color is black. The default
background is white. The fgcolor and bgcolor parameters SHALL be
absent if the marking parameter is absent.
The type parameter is either the string ":ess" or the string ":x411"
or a URI [RFC3986] denoting the type and encoding of label parameter.
The type parameter SHALL be present if the label parameter is
present. The label parameter SHALL be present if the type parameter
is present. The absence of the type and label parameters indicates
the message is handled, where sensitivity-based authorization is
performed, under default handling rules (e.g., as if no SIO-Label was
present).
The string ":ess" indicates the label parameter value is the base64
[RFC4648] encoding of the BER [X.690] encoding of an ESS security
Melnikov & Zeilenga Expires February 15, 2012 [Page 6]
Internet-Draft email-seclabel August 2011
label [RFC2634].
ESS Label Example:
SIO-Label: marking="EXAMPLE CONFIDENTIAL";
fgcolor=black; bgcolor=red;
type=":ess"; label="MQYGASkCAQM="
The string ":x411" indicates the label parameter value is the base64
[RFC4648] encoding of the BER [X.690] encoding of an X.411 security
label [X.411].
X.411 Label Example:
SIO-Label: marking="EXAMPLE CONFIDENTIAL";
type=":x411"; label="MQYGASkCAQM="
The field SHALL minimally contain a marking parameter or contain both
type and label parameters.
This header field may be extended to include additional parameters by
future document formally updating (or replacing) this document.
Implementations SHOULD ignore additional parameters they do not
recognize.
8. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) as described in [RFC5234]. Terms not defined here are
taken from [RFC5322].
Melnikov & Zeilenga Expires February 15, 2012 [Page 7]
Internet-Draft email-seclabel August 2011
sio-label = "SIO-Label:" [FWS] sio-label-parm-seq CRLF
sio-label-parm-seq = sio-label-parm [ [FWS] ";" [FWS] sio-label-parm-seq ]
sio-label-parm = marking-parm / bgcolor-parm / fgcolor-parm /
type-parm / label-parm
marking-parm = "marking" "=" quoted-string
fgcolor-parm = "fgcolor" "=" color
; default value "black" is assumed
bgcolor-parm = "bgcolor" "=" color
; default value "white" is assumed
color = hex-color / named-color
hex-color = "#" 6HEXDIG ; Hex encoded RGB
named-color =
"aqua" /
"black" /
"blue" /
"fuschia" /
"gray" /
"green" /
"lime" /
"maroon" /
"navy" /
"olive" /
"purple" /
"red" /
"silver" /
"teal" /
"white" /
"yellow" /
"orange" ; named colors
type-parm = quoted-string ; ":ess" or ":x411" or URI
label-parm = quoted-string ; encoded as indicated by type-parm URI
As necessary to encode quoted-string values of substantial length, or
containing characters outside of US-ASCII, or other such cases,
parameter values are encoded using MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and Continuations
[RFC2231].
Melnikov & Zeilenga Expires February 15, 2012 [Page 8]
Internet-Draft email-seclabel August 2011
9. IANA Considerations
IANA is requested to add, as detailed below, the SIO-Label header
field to the "Permanent Message Header Field Registry", defined by
Registration Procedures for Message Header Fields [RFC3864].
Header field name: SIO-Label
Applicable protocol: mail [RFC5322]
Status: standard
Author/change controller: IETF (iesg@ietf.org)
Specification document(s): [[anchor9: this document]]
10. Security Considerations
Sensitive information should be appropriately protected (whether
labeled or not). For email messages, it is generally appropriate for
the sending entity to authenticate the receiving entity and to
establish transport level security, including both data integrity and
data confidential protective services. Where a receiving entity to
make authorization decisions based upon assertions of the sending
entity, including assertions of identity, it is generally appropriate
for the receiving entity to authenticate the sending entity.
This document provides a facility for expressing the sensitivity of
an email message. The mere expression of actual sensitivity of a
generally does not elevate the sensitivity of the message, however
expressions of sensitivities can themselves be sensitivity
information. For instance, a marking of "BLACK PROJECT RESTRICTED"
could disclose the existence of a sensitivity project.
The SIO-Label header field expresses the sensitivity of the whole
message, including the header and body. This document does not
provide a means to express the sensitivity of portions of an email
message, such as the possibly different sensitivities of various MIME
parts that the message may be composed of. This approach used in
this favors simplicity and ease of use of a single expression of
sensitivity over the complexity and difficultly of use of portion
marking and labeling.
The expressed sensitivity can be used in determining how to handle a
message. For instance, the value of the SIO-Label header field can
be used to determine if it appropriate to be forwarded to a
particular entity and, if so, what the minimum security services are
that ought to be used in the forwarding exchange.
The actual content may be more or less sensitivity than indicated by
the security label. Agents should avoid lowering security
requirements for message exchange with a particular entity based upon
Melnikov & Zeilenga Expires February 15, 2012 [Page 9]
Internet-Draft email-seclabel August 2011
conveyed sensitivity.
This protocol does not itself provide message signing services, such
a used in providing message integrity protection, non-repudiation,
and binding of attributes, such the security label, to the message.
While it possible that this protocol could be used with a general
message signing service, this document does not detail such use.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
Encoded Word Extensions:
Character Sets, Languages, and Continuations",
RFC 2231, November 1997.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90,
RFC 3864, September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[X.411] International Telephone and Telegraph Consultative
Committee, "Message Handling Systems (MHS) - Message
Transfer System: Abstract Service Definition and
Procedures", CCITT Recommendation X.411, June 1999.
[X.690] International Telephone and Telegraph Consultative
Committee, "ASN.1 encoding rules: Specification of
basic encoding Rules (BER), Canonical encoding rules
Melnikov & Zeilenga Expires February 15, 2012 [Page 10]
Internet-Draft email-seclabel August 2011
(CER) and Distinguished encoding rules (DER)",
CCITT Recommendation X.690, July 2002.
[CSS3-Color] Celik, T. and C. Lilley, "CSS3 Color Module", World
Wide Web Consortium CR CR-css3-color-20030514,
May 2003,
<http://www.w3.org/TR/2003/CR-css3-color-20030514>.
11.2. Informative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[X.841] International Telephone and Telegraph Consultative
Committee, "Security information objects for access
control", CCITT Recommendation X.841, October 2000.
[XEP258] Zeilenga, K., "XEP-0258: Security Labels in XMPP",
XEP XMPP Extension Protocols, August 2011.
Appendix A. Acknowledgements
The authors appreciate the review, comment, and text provided by
community members, including Dave Cridland, Brad Hards, Steve Kille,
Alan Ross, Jim Schaad, and David Wilson.
Authors' Addresses
Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
EMail: Alexey.Melnikov@isode.com
Kurt Zeilenga
Isode Limited
EMail: Kurt.Zeilenga@isode.com
Melnikov & Zeilenga Expires February 15, 2012 [Page 11]