[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
Network Working Group                                   J. Latten
Internet-Draft                                          IBM
Intended Status: Standards Track                        D. Quigley
Expires: July 27, 2011                                  J. Lu
                                                  January 28, 2011

                    Security Label Extension to IKE

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), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on July 27, 2011.

Copyright Notice

   Copyright (c) 2010 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.

Latten, et al.           Expires July 27, 2011                  [Page 1]

Internet-Draft           IKEv2SecurityLabel                 January 2011


   This document describes extensions to the Internet Key Exchange
   Protocol Version 2 [RFC5996] to support Mandatory Access Control
   (MAC) security labels used on deployed systems.

1. Introduction

   In computer security, Mandatory Access Control usually refers to
   systems in which all subjects and objects are assigned a security
   label. A security label is comprised of a set of security attributes.
   The security labels along with a system authorization policy
   determine access. Rules within the system authorization policy
   determine whether the access will be granted based on the security
   attributes of the subject and object.

   Traditionally, security labels used by Multilevel Systems (MLS) are
   comprised of a sensitivity level (or classification) field and a
   compartment (or category) field, as defined in [FIPS188] and
   [RFC5570]. As MAC systems evolved, other MAC models gained in
   popularity. For example, SELinux, a Flux Advanced Security Kernel
   (FLASK) implementation, has security labels represented as
   colon-separated ASCII strings composed of values for identity, role,
   and type. The security labels are often referred to as security

   This document will describe extensions to IKEv2 to support its
   handling of security labels for implicit labeling schemes on
   network communications.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

3. Implicit Labeled Networking

   Within a MAC environment, a security label is applied to data (e.g.
   IP packets) transmitted over the network. The MAC policy can then use
   the label information to make informed access decisions.

   In a traditional Multilevel System envionment, IP packets are labeled
   with clear text labels. This is acceptable because the underlying
   physical network is assumed to be secure in an MLS environment and
   clear text labeling has performance advantage in secure physical
   network envionments. An obvious disadvantage of labeling data in

Latten, et al.           Expires July 27, 2011                  [Page 2]

Internet-Draft           IKEv2SecurityLabel                 January 2011

   clear text is its reliance on a secure physical network. This
   limitaion prevents traditional MLS MAC systems from being useful on
   public networks. With the proposed label extension to IKEv2, security
   labels can be established as part of the IKE negotiation. The
   security label is stored in the Security Association making it
   unnecessary for data packets to carry security label information,
   i.e. making packet labeling implicit. The implicit label scheme
   retains security label requirements demanded by MAC systems, but
   removes the reliance of underlying secure physical networks.

4. Security Label Transform

   This document introduces a new transform type to communicate the
   security label when creating Child SAs during the IKE_AUTH exchange
   and CREATE_CHILD_SA exchange. Security label transforms are only
   included in IPsec SAs and not IKE SAs.

   The transform type value is:

   Description        Transform Type      Used In
   Security Label       IANA          ESP and AH

   Only one security label transform containing only one security
   label is required per protocol. The security label data MUST
   be the same for each protocol within each proposal for a particular
   SA payload. In other words, only one instance of a security label
   is communicated for the proposed SA.

   For Security Label Transform Type, the defined Transform IDs are:

   Name                        Number           Defined In
   None                         0
   Label_Format_Selector_1      1                 TBD
   Label_Format_Selector_2      2                 TBD

   The acceptable Label_Format_Selectors (LFSs) are described in
   draft-quigley-label-format-regisry-00 (work-in-progress). The LFS
   indicates the format of the security label and how the security label
   is to be interpreted by the MAC layer.

   This transform requires a transform attribute to communicate the
   actual security label data.

Latten, et al.           Expires July 27, 2011                  [Page 3]

Internet-Draft           IKEv2SecurityLabel                 January 2011

   The Transform Attribute Type:

   Attribute Type             Value             Attribute Format
   Security Label              IANA                TLV

4.1 Attribute Negotiation

   The LFS indicates to a remote peer whether the security label can be
   understood and interpreted by the peer's MAC layer.

   An initiating IKE communicates the LFS and the security label data
   in the security label transform of a proposal. If the responder
   receives an LFS it does not understand, then it MUST consider the
   proposal unacceptable. IKE does not interpret the security label
   data itself.

5. Security Considerations

   [RFC5996] describes the NO_ADDITIONAL_SAS notification.
   It is possible that a traffic stream may require an SA for each
   instance of a security label on it. Thus a responder SHOULD be
   willing to accept more than one SA pair on an IKE_SA in this case.

   The addition of the security label transform should not change
   the underlying security characteristics of IKE.

6. IANA Considerations

   This document introduces the following IANA assignments:

   - IKEv2 Transform Type for the security label.

        Description             Transform type
        Security Label     To be assigned by IANA

   - IKEv2 Transform Attribute Type

        Attribute Type            Value            Attribute Format
        Security Label   To be assigned by IANA        TLV

7. Acknowledgements

   The authors would like to acknowledge Trent Jaeger, Serge Hallyn,
   and George Wilson, architects of the original design and
   implementation of labeled IPsec in Linux. The authors would also

Latten, et al.           Expires July 27, 2011                  [Page 4]

Internet-Draft           IKEv2SecurityLabel                 January 2011

   like to thank Stephen Smalley, James Morris and members of the
   SELinux community for their contributions during the initial design

   The original design of labeled IPsec was implemented in Linux
   with SELinux as it's MAC. Sun Microsystems also has a version
   of labeled IPsec in OpenSolaris Trusted Extensions.

8. References

8.1 Normative References

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Level", BCP 14, RFC 2119, March 1997.

   [RFC5996]    Kaufman, C., Hoffman, P., Nir, Y., Eronen, P.,
                "Internet Key Exchange (IKEv2) Protocol",
                RFC 5996, September 2010.

8.2 Informative References

   [FIPS188]    National Institute of Standards and Technology,
                "Standard Security Label for Information Transfer",
                Federal Information Processing Standard (FIPS)
                Publication 188, September 1994,

   [RFC5570]    StJohns, M., Atkinson, R., Thomas, G., "Common
                Architecture Label IPv6 Security Option (CALIPSO)",
                RFC 5570, July 2009.

Authors' Addresses

Joy Latten
email: latten@austin.ibm.com

David Quigley
email: dpquigl@tycho.nsa.gov

Jarrett Lu
email: Jarrett.Lu@oracle.com

Latten, et al.           Expires July 27, 2011                  [Page 5]