Internet DRAFT - draft-reddy-sfc-nsh-encrypt
draft-reddy-sfc-nsh-encrypt
SFC T. Reddy
Internet-Draft P. Patil
Intended status: Standards Track S. Fluhrer
Expires: October 11, 2015 P. Quinn
Cisco
April 9, 2015
Authenticated and encrypted NSH service chains
draft-reddy-sfc-nsh-encrypt-00
Abstract
This specification adds data origin authentication and optional
encryption directly to Network Service Headers (NSH) used for Service
Function Chaining.
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 October 11, 2015.
Copyright Notice
Copyright (c) 2015 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.
Reddy, et al. Expires October 11, 2015 [Page 1]
Internet-Draft Auth and encrypted NSH service chain April 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions and Notation . . . . . . . . . . . . . . . . 3
3. Design considerations . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. NSH Format . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Ticket TLV . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Sequence Number TLV . . . . . . . . . . . . . . . . . . . 7
5.3. Authentication Tag TLV . . . . . . . . . . . . . . . . . 7
5.4. Encrypted Metadata . . . . . . . . . . . . . . . . . . . 8
6. Processing rules . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Encrypted NSH metadata Generation . . . . . . . . . . . . 8
6.2. Authenticated NSH data Generation . . . . . . . . . . . . 9
6.3. Sequence number validation for replay attack . . . . . . 9
6.4. NSH data Validation . . . . . . . . . . . . . . . . . . . 10
6.5. Decryption of NSH metadata . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Service function chaining (SFC) [I-D.ietf-sfc-architecture] 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) [I-D.ietf-sfc-nsh] provides a mechanism to
carry metadata between service functions. The NSH structure is
defined in [I-D.ietf-sfc-nsh] and NSH data can be divided into two
parts:
o Path information used to construct the SFP.
o Metadata carrying the information about the packets being chained
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.
Reddy, et al. Expires October 11, 2015 [Page 2]
Internet-Draft Auth and encrypted NSH service chain April 2015
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 [I-D.ietf-sfc-nsh].
2. Notational Conventions
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].
This note uses the terminology defined in
[I-D.ietf-sfc-problem-statement].
2.1. Definitions and Notation
KMS: Key Management Service.
Ticket: A Kerberos like object used to identify and deliver keys over
an untrusted network.
NSH imposer: Imposes NSH header including Service Path ID, Service
Index and metadata.
SF : Service function.
3. Design considerations
SFC [I-D.ietf-sfc-architecture] 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.
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 [RFC4120] to identify and
Reddy, et al. Expires October 11, 2015 [Page 3]
Internet-Draft Auth and encrypted NSH service chain April 2015
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.
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).
KMS is used in GDOI [[RFC6407]], MIKEY-TICKET [[RFC6043]], end-to-end
encryption key management service
[I-D.abiggs-saag-key-management-service] etc.
4. Overview
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.
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.
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
Reddy, et al. Expires October 11, 2015 [Page 4]
Internet-Draft Auth and encrypted NSH service chain April 2015
technique is that KMS implicitly pushes the keying material to
service functions authorized by the NSH imposer.
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.
Figure 1 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.
Reddy, et al. Expires October 11, 2015 [Page 5]
Internet-Draft Auth and encrypted NSH service chain April 2015
+----------------+ +-------+ +------+ +------+
| NSH Imposer | | KMS | | SF1 | | SF2 |
+----+-----------+ +----+--+ +----+-+ +--+---+
| | | |
| | | |
| Ticket Request | | |
+---------------------------------->| | |
| | | |
| Ticket Response | | |
|<----------------------------------+ | |
| | | |
| Ticket sent in NSH | | |
+--------------------------------------------------->+----------->|
| | | |
| | Ticket resolve | |
| |<------------+--+ |
| | + |
| | Resolve response |
| +------+-------->+ |
| | | |
| | Ticket resolve | |
| |<-----+------+---------------+
| | Resolve response |
| +-------+-------------------->|
+ + + +
Figure 1: Interaction with KMS
5. NSH Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reddy, et al. Expires October 11, 2015 [Page 6]
Internet-Draft Auth and encrypted NSH service chain April 2015
5.1. Ticket TLV
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. Sequence Number TLV
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3. Authentication Tag TLV
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 [RFC5116] is used then there is no need explicitly compute
HMAC and include this TLV.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reddy, et al. Expires October 11, 2015 [Page 7]
Internet-Draft Auth and encrypted NSH service chain April 2015
5.4. Encrypted Metadata
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [RFC3602].
If AEAD algorithm is used
o The Initialization Vector field will carry the nonce and the
length of the nonce for AEAD algorithms is specified in [RFC5116].
o The associated data MUST be the entire NSH data excluding the
metadata to be encrypted and the nonce value.
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.
6. Processing rules
The following sections describe processing rules for authenticated
and encrypted NSH.
6.1. Encrypted NSH metadata Generation
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.
Reddy, et al. Expires October 11, 2015 [Page 8]
Internet-Draft Auth and encrypted NSH service chain April 2015
An authorized entity in the service path that intends to update
encrypted metadata, MUST also do the above.
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.
6.2. Authenticated NSH data Generation
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.
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.
6.3. Sequence number validation for replay attack
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.
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.
Reddy, et al. Expires October 11, 2015 [Page 9]
Internet-Draft Auth and encrypted NSH service chain April 2015
6.4. NSH data Validation
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
Section 6.3). 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.
6.5. Decryption of NSH metadata
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.
7. IANA Considerations
TODO
8. Security Considerations
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.
9. Acknowledgements
Authors would like to thank Dan Wing and Jim Guichard for their
comments and review.
10. References
10.1. Normative References
[I-D.ietf-sfc-architecture]
Halpern, J. and C. Pignataro, "Service Function Chaining
(SFC) Architecture", draft-ietf-sfc-architecture-07 (work
in progress), March 2015.
Reddy, et al. Expires October 11, 2015 [Page 10]
Internet-Draft Auth and encrypted NSH service chain April 2015
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-00 (work in progress), March 2015.
[I-D.ietf-sfc-problem-statement]
Quinn, P. and T. Nadeau, "Service Function Chaining
Problem Statement", draft-ietf-sfc-problem-statement-13
(work in progress), February 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September
2003.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008.
[RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based
Modes of Key Distribution in Multimedia Internet KEYing
(MIKEY)", RFC 6043, March 2011.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, October 2011.
10.2. Informative References
[I-D.abiggs-saag-key-management-service]
Biggs, A. and S. Cooley, "Key Management Service
Architecture", draft-abiggs-saag-key-management-service-00
(work in progress), November 2014.
Authors' Addresses
Tirumaleswar Reddy
Cisco Systems, Inc.
Email: tireddy@cisco.com
Reddy, et al. Expires October 11, 2015 [Page 11]
Internet-Draft Auth and encrypted NSH service chain April 2015
Prashanth Patil
Cisco Systems, Inc.
Email: praspati@cisco.com
Scott Fluhrer
Cisco Systems, Inc.
Email: sfluhrer@cisco.com
Paul Quinn
Cisco Systems, Inc.
Email: paulq@cisco.com
Reddy, et al. Expires October 11, 2015 [Page 12]
