[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]



Network                                                        S. Prasad
Internet-Draft                            Technical University of Munich
Updates: 7296 (if approved)                                   P. Wouters
Intended status: Standards Track                                 Red Hat
Expires: September 5, 2018                                 March 4, 2018


            Labeled IPsec Traffic Selector support for IKEv2
                 draft-sprasad-ipsecme-labeled-ipsec-00

Abstract

   Some IPsec implementations support Security Labels otherwise known as
   Security Contexts, to be configured as a selector within the Security
   Policy Database (SPD) for IPsec SAs.  This document adds support to
   IKEv2 to negotiate these Security Labels or Contexts using a new
   Traffic Selector (TS) Type TS_SECLABEL.  The approach is named
   "Labeled IPsec".  It assumes that the SPD processing of RFC 4303 is
   already extended to support Security Labels.  This document only adds
   the ability for IKE to negotiate the Security Labels used with the
   SPD.

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 https://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 September 5, 2018.

Copyright Notice

   Copyright (c) 2018 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Prasad & Wouters        Expires September 5, 2018               [Page 1]


Internet-Draft                Labeled IPsec                   March 2018


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Labeled IPsec Traffic Selector  . . . . . . . . . . . . . . .   3
     2.1.  Narrowing of Labeled IPsec Traffic Selector . . . . . . .   4
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   A Security Context or Security Label is a mechanism used to classify
   resources.  It allows the enforcement of rules on how or by whom
   these resources are accessable.  This document introduces a mechanism
   to negotiate these values using IKE.  This negotiation is done via a
   new Traffic Selector (TS) Type in the TSi/TSr Payloads of the
   IKE_AUTH Exchange.

   Traffic Selector (TS) payloads allow endpoints to communicate some of
   the information from their SPD to their peers.  Section 2.9 in the
   Internet Key Exchange protocol version 2 [RFC7296] illustrates the
   Traffic selector negotiation procedure.

   Two or more TS payloads appear in each of the messages in the
   exchange that creates a Child SA pair.  Each TS payload contains one
   or more Traffic Selectors.  The Traffic Selector types
   TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE consists of an address
   range, a port range, and an IP protocol ID.  [RFC4595] defines
   Traffic Selector type TS_FC_ADDR_RANGE to denote a list of Fibre
   Channel (FC) addresses and protocol ranges.  This document extends
   the above set by adding a new TS Type that allows endpoints to agree
   on assigning a Security Label or Context to the IPsec SA.

   Negotiating and applying the Security Label or Context in the new TS
   Type will act as an additional selector criterium that has to match
   along with any other existing Traffic Selectors.





Prasad & Wouters        Expires September 5, 2018               [Page 2]


Internet-Draft                Labeled IPsec                   March 2018


1.1.  Requirements Language

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

2.  Labeled IPsec Traffic Selector

   Labeled IPsec Traffic Selectors allow endpoints to negotiate the
   Security Label using the Selector Type TS_SECLABEL.  In addition to
   the regular prcessing of Traffic Selectors as described in
   Section 3.13.1 of [RFC7296], the context or label of an IP packet now
   also has to match the Security Label Traffic Selector.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+-------------------------------+
   |    TS TYPE    |   Reserved    |       Selector Length         |
   +---------------+---------------+-------------------------------+
   |                                                               |
   ~                     Security Label                            ~
   |                                                               |
   +---------------------------------------------------------------+

   o  TS TYPE (one octet) - Specifies the type of Traffic Selector.

   o  Selector Length (2 octets, network byte order) - Specifies the
      length of Security Label including the header.

   o  Security Label - This field contains the opaque payload.

   The following table lists the assigned value for the Labeled IPsec
   Traffic Selector Type field:


               TS Type       Value
               -------       -----
               TS_SECLABEL   [TBD]


   To indicate support and a requirement for agreeing on a specific
   security context, the initiator MUST include the security context or
   label via TS_SECLABEL in the TSi (Traffic Selector-initiator) and TSr
   (Traffic Selector-responder) Payloads.  On reception of TS_SECLABEL,
   the responder MUST find a matching Security Policy Database (SPD)
   entry that contains a Security Label and match the proposed label.
   Assuming that this proposal was acceptable to the responder, it would
   send the same or narrowed TS payloads in the IKE_AUTH reply.  If the



Prasad & Wouters        Expires September 5, 2018               [Page 3]


Internet-Draft                Labeled IPsec                   March 2018


   Security Label was not found in the SPD by the responder, it MUST
   respond with a TS_UNACCEPTABLE Notify message.

   As per section 2.9.2 in [RFC7296], TS sets MUST BE kept identical
   during rekey.  If a Security Label needs to change, the IPsec SA must
   be torn down and a new one must be negotiated with the updated
   TS_SECLABEL values.

2.1.  Narrowing of Labeled IPsec Traffic Selector

   The IKE daemon might or might not be able to interpret the Security
   Label beyond an exact match.  It might be possible for the IKE daemon
   to apply narrowing to the Security Labels.  For example, a Security
   Label "Top Secret" could mean that this IPsec SA may also transport
   traffic with label "Secret".  An initiator requesting "Top Secret"
   might be willing to be narrowed down to a "Secret" security context.
   Or a security context of "*" might mean "any security context".  If
   the daemon does not interpret the Security Label, then it can only
   support an exact match of the raw data of the TS.

   The rules of responder narrowing as explained in section 2.9 in
   [RFC7296] are applicable to TS_SECLABEL.

   The TS_SECLABEL Traffic Selector Type if present MUST be mutually
   agreed upon.  If one side includes a TS_SECLABEL and the other sides
   does not, the IPsec SA negotiation MUST fail with TS_UNAVAILABLE.  If
   a responder insists on a TS_SECLABEL security context and receives a
   TSi/TSr set that does not contain a TS_SECLABEL Traffic Selector, it
   MUST fail the negotiation with TS_UNAVAILABLE.

   DISCUSS: Should a TS_SECLABEL of length 0 be allowed?  If so, should
   it mean "any label" ?

3.  Security Considerations

   While matching the Security Label on the endpoints, an assumption
   that the Security label will contain only ASCII text MUST NOT be
   made.  If the Security Label is handed off to a helper routine for
   interpretation, it MUST be assumed that the content can be malicious.
   While Security Labels might look like text, there is no guarantee
   this text is null terminated.

   Any errors in handling the SPD entry, such as failing to add the SPD
   entry with the negotiated Security Label, MUST be abled as any other
   failure of SPD processing as defined in [RFC4303].






Prasad & Wouters        Expires September 5, 2018               [Page 4]


Internet-Draft                Labeled IPsec                   March 2018


4.  IANA Considerations

   This document defines one new Traffic Selector Type in the IKEv2
   Traffic Selector Types Registry namespace.


             TS Type       Value
             -------       -----
             TS_SECLABEL   [TBD]


                                 Figure 1

5.  References

5.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4595]  Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel
              Security Association Management Protocol", RFC 4595,
              DOI 10.17487/RFC4595, July 2006,
              <https://www.rfc-editor.org/info/rfc4595>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

5.2.  Informative References

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/info/rfc4303>.

Authors' Addresses

   Sahana Prasad
   Technical University of Munich

   Email: sahana.prasad07@gmail.com







Prasad & Wouters        Expires September 5, 2018               [Page 5]


Internet-Draft                Labeled IPsec                   March 2018


   Paul Wouters
   Red Hat

   Email: pwouters@redhat.com















































Prasad & Wouters        Expires September 5, 2018               [Page 6]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/