Network Working Group A. Melnikov Internet-Draft K. Zeilenga Intended status: Standards Track Isode Limited Expires: February 9, 2012 August 8, 2011 Security Labels in Internet Email draft-zeilenga-email-seclabel-01 Abstract This document describes a header field for use in Internet Mail to convey a security label and associated data. 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 9, 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 9, 2012 [Page 1] Internet-Draft email-seclabel August 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Relationship to Enhanced Security Services for S/MIME . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. The SIO-Label header field . . . . . . . . . . . . . . . . . . 4 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 9 Melnikov & Zeilenga Expires February 9, 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 SECRET" label, and hence requiring the sender and the receiver to have a clearance granting access to "EXAMPLE SECRET" 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 SECRET" is a textual representation of the sensitivity. A security policy can be used to generate display markings from security labels. 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. 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. 2. Relationship to Enhanced Security Services for S/MIME While it may be possible to utilize the protocol described in this document concurrently with Enhanced Security Services for S/MIME (ESS) [RFC2634], this protocol is generally viewed as an alternative to ESS. It is noted that in ESS, the 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, labels are securely bound to the MIME content through the use of digital signatures, where, in this protocol, labels are not security bound to the message. This protocol is designed for use where securely binding the label to the labeled information, at least through sender signing, is not necessary but may well be inappropriate, such in deployment where labels are replaced when crossing between security domains. Melnikov & Zeilenga Expires February 9, 2012 [Page 3] Internet-Draft email-seclabel August 2011 3. 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]. 4. 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. MTAs 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 prominently display the display marking conveyed in the header field. The display marking SHOULD be displayed using the foreground and background colors conveyed in the header field. MUAs are not expected to make authorization decisions based upon values of the SIO-Label header field. 5. 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 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. Melnikov & Zeilenga Expires February 9, 2012 [Page 4] Internet-Draft email-seclabel August 2011 The type parameter is either the string ":ess" or the string ":x411" or a URI [RFC3986] denoting the type of label and its encoding as held contained in the label parameter. The type parameter SHALL be present if the label parameter is present. The string ":ess" indicates the label parameter value is the base64 [RFC4648] encoding of the BER [X.690] encoding of an ESS security label [RFC2634]. The label parameter SHALL be present if the type parameter is present. ESS Label Example: SIO-Label: marking="EXAMPLE SECRET"; fgcolor=black; bgcolor=red; type=":ess" label="MQYCAQIGASk=" The URI ":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]. The label parameter SHALL be present if the type parameter is present. X.411 Label Example: SIO-Label: marking="EXAMPLE SECRET"; fgcolor=black; bgcolor=red; type=":x411" label="MQYCAQIGASk=" 6. 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 9, 2012 [Page 5] 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 bgcolor-parm = "bgcolor" "=" color ; default value "white" is assumed fgcolor-parm = "fgcolor" "=" color ; default value "black" 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 Melnikov & Zeilenga Expires February 9, 2012 [Page 6] Internet-Draft email-seclabel August 2011 7. 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): [[anchor7: this document]] 8. Security Considerations Security labels and display markings are used to express the sensitivity of a piece of information. This document describes how to convey the security label and display marking expressing the sensitivity of an email message, as a whole, including its headers and body. This extension 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 extension is intended to be used in environments/situations where it not necessary for the security label and other sensitivity information to be securely bound to message through use of digital signatures, and hence this document does not detail how security labels digital signatures could be used to securely bind the security label to the message. In environments/situations where security labels are used to make authorization decisions, MTAs making those authorization decisions are to ensure appropriate data confidential and integrity protection services are in place, such as requiring use of TLS [RFC5246] in email protocols such as SMTP [RFC5321] and IMAP [RFC3501]. 9. References 9.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. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, Melnikov & Zeilenga Expires February 9, 2012 [Page 7] Internet-Draft email-seclabel August 2011 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 (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, . 9.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. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [X.841] International Telephone and Telegraph Consultative Melnikov & Zeilenga Expires February 9, 2012 [Page 8] Internet-Draft email-seclabel August 2011 Committee, "Security information objects for access control", CCITT Recommendation X.841, October 2000. Appendix A. Acknowledgements The authors appreciate the review, comment, and text provided by community members, including Dave Cridland, Brad Hards, Steve Kille, Alan Ross, 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 9, 2012 [Page 9]