One document matched: draft-zeilenga-email-seclabel-00.txt

Network Working Group                                        A. Melnikov
Internet-Draft                                               K. Zeilenga
Intended status: Standards Track                           Isode Limited
Expires: February 6, 2012                                 August 5, 2011


                   Security Labels in Internet Email
                    draft-zeilenga-email-seclabel-00

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 6, 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 6, 2012                [Page 1]

Internet-Draft               email-seclabel                  August 2011


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  The SIO-Label header field  . . . . . . . . . . . . . . . . . . 4
   5.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . . . 7






































Melnikov & Zeilenga     Expires February 6, 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.  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].

3.  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



Melnikov & Zeilenga     Expires February 6, 2012                [Page 3]

Internet-Draft               email-seclabel                  August 2011


   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.

4.  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 HTML color strings (e.g., "red" or
   "#ff0000").  The default foreground color is black.  The default
   background is white.  The fgcolor and bgcolor parameters SHALL be
   absence if the marking parameter is absent.

   The type parameter is 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 URI 'urn:ietf:rfc:THIS-RFC-NUMBER' indicates the label parameter
   value is the base64 [RFC4648] encoding of the BER [BER] encoding of
   an ESS security label [RFC2634].  The label parameter SHALL be
   present if the type parameter is present.

   [[Note to RFC Editor: Please replace THIS-RFC-NUMBER above and below
   with the RFC number assigned to this document when published as an
   RFC and then remove this note.]]

   Example:
   SIO-Label: marking="EXAMPLE SECRET";
   fgcolor=black; bgcolor=red;
   type="urn:ietf:rfc:THIS-RFC-NUMBER" label="MQYCAQIGASk="






Melnikov & Zeilenga     Expires February 6, 2012                [Page 4]

Internet-Draft               email-seclabel                  August 2011


5.  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].

  sio-label = "SIO-Label:" [FWS] sio-label-parm-seq CRLF

  sio-label-parm-seq = marking-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 = "#" 6HEXDIG /    ; Hex encoded RGB
           "aqua" /
           "black" /
           "blue" /
           "fuschia" /
           "gray" /
           "green" /
           "lime" /
           "maroon" /
           "navy" /
           "olive" /
           "purple" /
           "red" /
           "silver" /
           "teal" /
           "white" /
           "yellow" /
           "orange"

  type-parm = quoted-string ; URI

  label-parm = quoted-string ; encoded as indicated by type-parm URI





Melnikov & Zeilenga     Expires February 6, 2012                [Page 5]

Internet-Draft               email-seclabel                  August 2011


6.  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): [[anchor6: this document]]

7.  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 expresses the
   sensitivity of an email message, as a whole, including its headers
   and body.  This extension provides for no means to express the
   sensitivity of portions of an email message, such as the possibly
   different sensitivities of various MIME parts 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 makes those authorization decisions are
   to ensure appropriate data confidential and integrity protection
   services are in place, such as requiring use of TLS in email
   protocols such as SMTP and IMAP.

8.  References

8.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, RFC 3864,



Melnikov & Zeilenga     Expires February 6, 2012                [Page 6]

Internet-Draft               email-seclabel                  August 2011


              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.

   [BER]      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.

8.2.  Informative References

   [X.841]    ITU-T, "Security information objects for access control",
              ITU-T Series X 841, October 2000.

Appendix A.  Acknowledgements

   Many thanks for ideas, reviews and text provided by Dave Cridland,
   Alan Ross, Steve Kille, 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 6, 2012                [Page 7]