<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-reddy-sfc-nsh-encrypt-00" ipr="trust200902">
  <front>
    <title abbrev="Auth and encrypted NSH service chain">Authenticated and
    encrypted NSH service chains</title>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street></street>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Prashanth Patil" initials="P." surname="Patil">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street></street>
        </postal>

        <email>praspati@cisco.com</email>
      </address>
    </author>

    <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street></street>

          <street></street>

          <city></city>
        </postal>

        <email>sfluhrer@cisco.com</email>
      </address>
    </author>

    <author fullname="Paul Quinn" initials="P." surname="Quinn">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street></street>

          <street></street>

          <city></city>
        </postal>

        <email>paulq@cisco.com</email>
      </address>
    </author>

    <date />

    <workgroup>SFC</workgroup>

    <abstract>
      <t>This specification adds data origin authentication and optional
      encryption directly to Network Service Headers (NSH) used for Service
      Function Chaining.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>Service function chaining (SFC) <xref
      target="I-D.ietf-sfc-architecture"></xref> involves steering traffic
      flows through a set of service functions in a specific order, such an
      ordered list of service functions is called a Service Function Chain
      (SFC). The actual forwarding path used to realize an SFC is called the
      Service Function Path (SFP). Network Service Headers (NSH) <xref
      target="I-D.ietf-sfc-nsh"></xref> provides a mechanism to carry metadata
      between service functions. The NSH structure is defined in <xref
      target="I-D.ietf-sfc-nsh"></xref> and NSH data can be divided into two
      parts:</t>

      <t><list style="symbols">
          <t>Path information used to construct the SFP.</t>

          <t>Metadata carrying the information about the packets being
          chained</t>
        </list></t>

      <t>NSH data is unauthenticated and unencrypted, forcing a service
      topology that requires security to use a transport encapsulation that
      support such features (e.g. IPsec). This draft adds authentication and
      optional encryption directly to NSH. This way NSH data does not have to
      rely on underlying transport encapsulation for security and
      confidentiality.</t>

      <t>This specification introduces new TLVs to carry fields necessary for
      Authenticated and Encrypted NSH, and is hence only applicable to NSH
      MD-Type 2 defined in <xref target="I-D.ietf-sfc-nsh"></xref>.</t>
    </section>

    <section anchor="notation" title="Notational Conventions">
      <t>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 <xref
      target="RFC2119"></xref>.</t>

      <t>This note uses the terminology defined in <xref
      target="I-D.ietf-sfc-problem-statement"></xref>.</t>

      <section title="Definitions and Notation">
        <t>KMS: Key Management Service.</t>

        <t>Ticket: A Kerberos like object used to identify and deliver keys
        over an untrusted network.</t>

        <t>NSH imposer: Imposes NSH header including Service Path ID, Service
        Index and metadata.</t>

        <t>SF : Service function.</t>
      </section>
    </section>

    <section anchor="alg_over" title="Design considerations">
      <t>SFC <xref target="I-D.ietf-sfc-architecture"></xref> removes the
      constraint of strict ordering of service functions and allows dynamic
      ordering of service functions. Service function paths (SFP) could vary
      for different traffic and it is not possible to pre-determine peer
      service functions in service function paths and pre-distribute
      credentials for security association between all possible combinations
      of peer service functions for authentication and encryption of NSH
      data.</t>

      <t>The keying material should be unique for each SFP so that only the
      authorized service functions participating in the SFP can act on the NSH
      data. A trusted KMS can be used to propagate keying material to
      authorized service functions as and when needed and avoids the use of
      pair-wise keys. A KMS based on symmetric keys has particular advantages,
      as symmetric key algorithms are generally much less computationally
      intensive than asymmetric key algorithms and the size of cipher-text
      generated using symmetric key algorithm is smaller compared to the
      cipher-text generated using asymmetric encryption algorithm. Systems
      based on a KMS require a signaling mechanism that allows peers to
      retrieve other peers dynamic credentials. A convenient way to implement
      such a signaling scheme is to use a ticket concept, similar to that in
      Kerberos <xref target="RFC4120"></xref> to identify and deliver keys.
      The ticket can be forwarded in the NSH data. The NSH imposer requests a
      ticket from the KMS and sends the ticket in NSH data. The service
      function in SFP gets the ticket from NSH, requests KMS to provide the
      keying material associated with the ticket. If the service function is
      authorized then KMS returns the corresponding keys.</t>

      <t>Note: Key management services may introduce a single point of
      (security) failure. The security requirements on the implementation and
      protection of the KMS may therefore, in high-security applications, be
      more or less equivalent to the requirements of an AAA (Authentication,
      Authorization, and Accounting) server or a Certification Authority
      (CA).</t>

      <t>KMS is used in GDOI [<xref target="RFC6407"></xref>], MIKEY-TICKET
      [<xref target="RFC6043"></xref>], end-to-end encryption key management
      service <xref target="I-D.abiggs-saag-key-management-service"></xref>
      etc.</t>
    </section>

    <section anchor="overview" title="Overview">
      <t>The service functions do not share any credentials; instead, they
      trust a third party, the KMS, with which they have or can establish
      shared credentials. These pre-established trust relations are used to
      establish a security association between service functions.</t>

      <t>The NSH imposer requests keys and a ticket from the KMS. The request
      message also includes identities of the service functions authorized to
      receive the keying material associated with the ticket. Each SF is
      referenced using an identifier that is unique within an SF-enabled
      domain. If the request is authorized then KMS generates the encryption
      and message integrity keys (referred to as ENC and MAC keys), ticket,
      and returns them in a response message. The ticket could be
      self-contained (key encrypted in the ticket) or just a handle to some
      internal datastructure within the KMS. The need to encrypt NSH metadata
      is determined based on the classification decision and the metadata
      conveyed in NSH. The encryption and authentication algorithms will
      either be negotiated between the NSH imposer and KMS or determined by
      the KMS and conveyed to the NSH imposer.</t>

      <t>The NSH imposer includes the ticket in NSH data. The NSH data is
      protected using the MAC key and optionally NSH metadata is encrypted
      using the ENC key. Service functions in the SFP forward the ticket to
      the KMS and request the KMS to provide the keying material. If the
      service function is authorized and the ticket is valid then the KMS
      retrieves the keys and algorithms associated with the ticket and conveys
      them to the service function. The other alternative technique is that
      KMS implicitly pushes the keying material to service functions
      authorized by the NSH imposer.</t>

      <t>If the SFP for a flow changes then NSH imposer requests new keys and
      a new ticket from KMS. The request message from NSH imposer to KMS
      includes identities of the service functions authorized to receive the
      keying material associated with the new ticket. For subsequent packets
      of the flow the new ticket will be conveyed in the NSH data, NSH data
      will be integrity protected using the new MAC key and NSH metadata
      encrypted using the new ENC key.</t>

      <t><xref target="figure1"></xref> shows an example of NSH imposer
      requesting keys and ticket from the KMS. The request message includes
      identifiers of SF1 and SF2 service functions authorized to receive
      keying material associated with the ticket. KMS returns the ENC key, MAC
      key and ticket in the response message. The NSH imposer includes the
      ticket in the NSH data. SF1 in the SFP forwards the ticket to the KMS
      and requests the KMS for keying material associated with the ticket (In
      Ticket resolve request message). If SF1 is authorized and the ticket is
      valid then KMS retrieves the keys and algorithms associated with the
      ticket and conveys them to the SF1 (In Resolve response message).
      Similarly, SF2 retrieves the keying material associated with the ticket
      from KMS.</t>

      <t><figure anchor="figure1" title="Interaction with KMS">
          <artwork><![CDATA[

+----------------+                  +-------+        +------+       +------+
|   NSH Imposer  |                  |  KMS  |        | SF1  |       | SF2  |
+----+-----------+                  +----+--+        +----+-+       +--+---+
     |                                   |                |            |    
     |                                   |                |            |    
     |   Ticket Request                  |                |            |    
     +---------------------------------->|                |            |    
     |                                   |                |            |    
     |   Ticket Response                 |                |            |    
     |<----------------------------------+                |            |    
     |                                   |                |            |    
     |   Ticket sent in NSH              |                |            |    
     +--------------------------------------------------->+----------->|    
     |                                   |                |            |    
     |                                   | Ticket resolve |            |    
     |                                   |<------------+--+            |    
     |                                   |                +            |    
     |                                   | Resolve response            |    
     |                                   +------+-------->+            |    
     |                                   |                |            |    
     |                                   | Ticket resolve |            |    
     |                                   |<-----+------+---------------+    
     |                                   | Resolve response            |    
     |                                   +-------+-------------------->|    
     +                                   +                +            +    

       ]]></artwork>
        </figure></t>
    </section>

    <section title="NSH Format">
      <figure>
        <artwork><![CDATA[    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Base Header                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Service Path Header                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Ticket                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Sequence Number                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Encrypted Metadata                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Authentication Tag                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>

      <section title="Ticket TLV">
        <t>A variable length Kerberos-like object used to identify and deliver
        keys over an untrusted network to service functions. This is a
        mandatory TLV that MUST be present if an authenticated and encrypted
        NSH solution is desired.</t>

        <figure>
          <artwork><![CDATA[      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          TLV Class            |      TKT      |R|R|R|   Len   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           TICKET                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>
      </section>

      <section title="Sequence Number TLV">
        <t>A 32-bit sequence number per ticket. In this solution, a sequence
        number needs to be incremented every time NSH is included by the NSH
        imposer. The number should not be incremented if an existing NSH is
        being updated. This is a mandatory TLV that MUST be present if an
        authenticated and encrypted NSH solution is desired.</t>

        <t><figure>
            <artwork><![CDATA[      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         TLV Class             |   SEQ         |R|R|R|   1     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Sequence Number                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure></t>
      </section>

      <section title="Authentication Tag TLV">
        <t>A variable-length TLV that carries the hash based Message
        Authentication Codes for the entire NSH calculated using the MAC key.
        If Authenticated Encryption with Associated Data (AEAD) algorithm
        defined in <xref target="RFC5116"></xref> is used then there is no
        need explicitly compute HMAC and include this TLV.</t>

        <figure>
          <artwork><![CDATA[      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            TLV Class          |   AUTH-TAG    |R|R|R|   Len   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Authentication Tag                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>
      </section>

      <section title="Encrypted Metadata">
        <t>A variable-length TLV that carries the metadata encrypted using ENC
        key obtained from the KMS. The C bit in the Type field MUST be set to
        1 indicating that the TLV is mandatory for the receiver to understand
        and process.</t>

        <figure>
          <artwork><![CDATA[      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               TLV Class       |      ENC-MD   |R|R|R|   Len   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | IV Len        |    Initialization Vector                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Encrypted Metadata                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>

        <t>Randomly generated Initialization Vector (IV) prevents generation
        of identical cipher-text from packets which have identical metadata,
        use of IV in AES CBC is explained in <xref
        target="RFC3602"></xref>.</t>

        <t>If AEAD algorithm is used <list style="symbols">
            <t>The Initialization Vector field will carry the nonce and the
            length of the nonce for AEAD algorithms is specified in <xref
            target="RFC5116"></xref>.</t>

            <t>The associated data MUST be the entire NSH data excluding the
            metadata to be encrypted and the nonce value.</t>
          </list></t>

        <t>If one or more service functions in the SFP are authorized to
        validate the message integrity of NSH data and update the unencrypted
        NSH data but not decrypt the encrypted metadata then AEAD algorithm
        MUST NOT be used and these service functions MUST only be given access
        to the MAC key.</t>
      </section>
    </section>

    <section anchor="prorules" title="Processing rules">
      <t>The following sections describe processing rules for authenticated
      and encrypted NSH.</t>

      <section title="Encrypted NSH metadata Generation">
        <t>An NSH imposer can encrypt all NSH metadata or only a subset of
        metadata i.e., encrypted and unencrypted metadata may be carried
        simultaneously. Using the ENC key and encryption algorithm obtained
        from the KMS, the imposer encrypts metadata of choice and inserts the
        resulting payload in the encrypted metadata TLV.</t>

        <t>An authorized entity in the service path that intends to update
        encrypted metadata, MUST also do the above.</t>

        <t>If NSH encryption is desired, encryption is performed first, before
        the integrity algorithm is applied. This order of processing
        facilitates rapid detection and rejection of bogus packets by the
        receiver, prior to decrypting the metadata, hence potentially reducing
        the impact of denial of service (DoS) attacks.</t>
      </section>

      <section title="Authenticated NSH data Generation">
        <t>An NSH imposer inserts an Authentication Tag TLV for data origin
        authentication and integrity protection. After requesting ENC and MAC
        keys from the KMS, the imposer computes the message integrity for the
        entire NSH data using the MAC key and HMAC algorithm. It inserts the
        result in the AUTH-TAG TLV. The length of the Authentication Data
        field is decided by the HMAC algorithm adopted for the particular
        ticket.</t>

        <t>An entity in the service function path that intends to update NSH
        MUST do the above to maintain message integrity of the NSH for
        subsequent validations.</t>
      </section>

      <section anchor="seq"
               title="Sequence number validation for replay attack">
        <t>A Sequence Number is an unsigned 32-bit counter value that
        increases by one for each NSH created and sent from the NSH imposer,
        i.e., a per-ticket packet sequence number. The field is mandatory and
        MUST always be present. Processing of the Sequence Number field is at
        the discretion of the receiver, but all implementations MUST be
        capable of validating that the Sequence Number that does not duplicate
        the Sequence Number of any other NSH received during the life of the
        ticket.</t>

        <t>The NSH imposer's counter is initialized to 0 when a new ticket is
        to be used . The sender increments the Sequence Number counter for
        this ticket and inserts the 32-bit value into the Sequence Number TLV.
        Thus the first NSH sent using a given ticket will contain a Sequence
        Number of 1. The imposer checks to ensure that the counter has not
        cycled before inserting the new value in the Sequence Number TLV. In
        other words, the sender MUST NOT send a packet on a ticket if doing so
        would cause the Sequence Number to rollover. Sequence Number counters
        of all participating nodes MUST be reset by establishing a new ticket
        prior to the transmission of the 2^32nd packet of NSH for a particular
        ticket.</t>
      </section>

      <section title="NSH data Validation">
        <t>When an SFC node receives an NSH header with encrypted metadata, it
        MUST first ensure that all mandatory TLVs required for NSH data
        authentication exist. The node MUST discard NSH if mandatory TLVs are
        absent or if the sequence number is invalid (described in <xref
        target="seq"></xref>). The node should then go on to do data
        validation. The node calculates the message integrity for the entire
        NSH data using the MAC key and HMAC algorithm obtained from the KMS
        for the ticket being carried in NSH. If the value of the newly
        generated digest is identical to the one in NSH, the node is certain
        that the header has not been tampered and validation succeeds.
        Otherwise, the NSH MUST be discarded.</t>
      </section>

      <section title="Decryption of NSH metadata">
        <t>After NSH data validation is complete, an SFC node decrypts
        metadata using the ENC key and decryption algorithm obtained from the
        KMS for the ticket in NSH. If AEAD algorithm is used then it has only
        a single output, either a plaintext or a special symbol FAIL that
        indicates that the inputs are not authentic.</t>
      </section>
    </section>

    <section title="IANA Considerations">
      <t>TODO</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>The interaction between the Service functions and the KMS requires
      Transport Layer Security (TLS) with a ciphersuite offering
      confidentiality protection. The ENC and MAC keys MUST NOT be transmitted
      in clear since this would completely destroy the security benefits of
      the proposed scheme.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>Authors would like to thank Dan Wing and Jim Guichard for their
      comments and review.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.I-D.ietf-sfc-nsh'?>

      <?rfc include="reference.RFC.4120"?>

      <?rfc include="reference.I-D.ietf-sfc-problem-statement"?>

      <?rfc include="reference.I-D.ietf-sfc-architecture"?>

      <?rfc include='reference.RFC.6407'?>

      <?rfc include="reference.RFC.6043"?>

      <?rfc include="reference.RFC.5116"?>

      <?rfc include="reference.RFC.3602"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.abiggs-saag-key-management-service"?>
    </references>
  </back>
</rfc>
