Secure Transport for PCEP
Author(s): Oscar de Dios, Diego Lopez
The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a client and a PCE, or among PCEs. This document describe the usage of Transport Layer Security to enhance PCEP security, hence the PCEPS...
Path Computation Element D. Lopez Internet-Draft O. Gonzalez de Dios Intended status: Standards Track Telefonica I+D Expires: January 11, 2014 July 10, 2013 Secure Transport for PCEP draft-lopez-pcp-pceps-00 Abstract The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a client and a PCE, or among PCEs. This document describe the usage of Transport Layer Security to enhance PCEP security, hence the PCEPS acronym proposed for it. The additional security mechanisms are provided by the transport protocol supporting PCEP, and therefore they do not affect its flexibility and extensibility. 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 January 11, 2014. Copyright Notice Copyright (c) 2013 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 Lopez & Gonzalez de Dios Expires January 11, 2014 [Page 1] Internet-Draft Secure Transport for PCEP July 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applying TLS to PCEP . . . . . . . . . . . . . . . . . . . . . 3 2.1. TCP ports . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Connection Establishment . . . . . . . . . . . . . . . . . 4 2.3. Peer Identity . . . . . . . . . . . . . . . . . . . . . . . 5 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Lopez & Gonzalez de Dios Expires January 11, 2014 [Page 2] Internet-Draft Secure Transport for PCEP July 2013 1. Introduction PCEP [RFC5440] defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. These interactions include requests and replies that can be critical for a sustainable network operation and adequate resource allocation, and therefore appropriate security becomes a key element in the PCE infrastructure. As the appplications of the PCE framework evolves, and more complex service patterns emerge, the definition of a secure mode of operation becomes more relevant. [RFC5440] analyzes in its section on security considerations the potential threats to PCEP and their consequences, and discusses several mechanisms for protecting PCEP against security attacks, without making a specific recommendation on a particular one or defining their application in depth. Moreover, [RFC6952] remarks the importance of ensuring PCEP communication privacy, especially when PCEP communication endpoints do not reside in the same AS, as the interception of PCEP messages could leak sensitive information related to computed paths and resources. Among the possible solutions mentioned in these documents, Transport Layer Security (TLS) [RFC5246] provides support for peer authentication, and message encryption and integrity. TLS supports the usage of well-know mechanisms to support key configuration and exchange, and means to perform security checks on the results of PCE discovery procedures ([RFC5088] and [RFC5089]). Since TLS is a security container for the transport of PCEP requests and replies, it will not interfere with the protocol flexibility and extensibility. This document describes how to apply TLS in securing PCE interactions, including the handshake mechanisms, the methods for peer authentication, and the applicable TLS ciphersuites for data exchange. In the rest of the document we will refer to this usage of TLS as transport for PCEP as either "PCEP over TLS" or "PCEPS". 2. Applying TLS to PCEP 2.1. TCP ports The default destination port number for PCEP over TLS is TCP/XXXX. NOTE: This port has to be agreed and registered as PCEPS with IANA. Lopez & Gonzalez de Dios Expires January 11, 2014 [Page 3] Internet-Draft Secure Transport for PCEP July 2013 2.2. Connection Establishment PCEPS has no notion of negotiating TLS in an established connection. Both peers in the connection need to be preconfigured to use PCEPS for a given endpoint. The connection establishment SHALL follow the following steps: 1. After completing the TCP handshake, immediately negotiate TLS sessions according to [RFC5246]. The following restrictions apply: * Support for TLS v1.2 [RFC5246] or later is REQUIRED. * Support for certificate-based mutual authentication is REQUIRED. * Negotiation of mutual authentication is REQUIRED. * Negotiation of a ciphersuite providing for integrity protection is REQUIRED. * Negotiation of a ciphersuite providing for confidentiality is RECOMMENDED. * Support for and negotiation of compression is OPTIONAL. * PCEPS implementations MUST, at a minimum, support negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA, and SHOULD support TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as well. In addition, PCEPS implementations MUST support negotiation of the mandatory-to-implement ciphersuites required by the versions of TLS that they support. 2. Peer authentication can be performed in any of the following two REQUIRED operation models: * TLS with X.509 certificates using PKIX trust models: + Implementations MUST allow the configuration of a list of trusted Certification Authorities for incoming connections. + Certificate validation MUST include the verification rules as per [RFC5280]. + Implementations SHOULD indicate their trusted Certification Authorities (CAs). For TLS 1.2, this is done using [RFC5246], Section 7.4.4, "certificate_authorities" (server side) and [RFC6066], Section 6 "Trusted CA Indication" Lopez & Gonzalez de Dios Expires January 11, 2014 [Page 4] Internet-Draft Secure Transport for PCEP July 2013 (client side). + Peer validation always SHOULD include a check on whether the locally configured expected DNS name or IP address of the server that is contacted matches its presented certificate. DNS names and IP addresses can be contained in the Common Name (CN) or subjectAltName entries. For verification, only one of these entries is to be considered. The following precedence applies: for DNS name validation, subjectAltName:DNS has precedence over CN; for IP address validation, subjectAltName:iPAddr has precedence over CN. + NOTE: Consider here whether peer validation MAY be extended by means of the DANE procedures, including its specs as informative references. + Implementations MAY allow the configuration of a set of additional properties of the certificate to check for a peer's authorization to communicate (e.g., a set of allowed values in subjectAltName:URI or a set of allowed X509v3 Certificate Policies) * TLS with X.509 certificates using certificate fingerprints: Implementations MUST allow the configuration of a list of trusted certificates, identified via fingerprint of the DER encoded certificate octets. Implementations MUST support SHA- 256 as the hash algorithm for the fingerprint. 3. Start exchanging PCEP requests and replies. NOTE: TLS re-negotiation left as an open issue. 2.3. Peer Identity Depending on the peer authentication method in use, PCEPS supports different operation modes to establish peer's identity and whether it is entitled to perform requests or can be considered authoritative in its replies. PCEPS implementations SHOULD provide mechanisms for associating peer identities with different levels of access and/or authoritativeness, and they MUST provide a mechanism for establish a default level for properly identified peers. Any connection established with a peer that cannot be properly identified SHALL be terminated before any PCEP exchange takes place. In TLS-X.509 mode using fingerprints, a peer is uniquely identified by the fingerprint of the presented client certificate. Lopez & Gonzalez de Dios Expires January 11, 2014 [Page 5] Internet-Draft Secure Transport for PCEP July 2013 There are numerous trust models in PKIX environments, and it is beyond the scope of this document to define how a particular deployment determines whether a client is trustworthy. Implementations that want to support a wide variety of trust models should expose as many details of the presented certificate to the administrator as possible so that the trust model can be implemented by the administrator. As a suggestion, at least the following parameters of the X.509 client certificate should be exposed: o Peer's IP address o Peer's FQDN o Certificate Fingerprint o Issuer o Subject o All X509v3 Extended Key Usage o All X509v3 Subject Alternative Name o All X509v3 Certificate Policies NOTE: Additional procedures enabled by DANE methods are TBD NOTE: Specific connections with PCE discovery procedures is TBD 3. IANA Considerations NOTE: PCEPS has to be registered as TCP port XXXX. No new PCEP messages or other objects are defined. 4. Security Considerations Since computational resources required by TLS handshake and ciphersuite are higher than unencrypted TCP, clients connecting to a PCEPS server can more easily create high load conditions and a malicious client might create a Denial-of-Service attack more easily. Some TLS ciphersuites only provide integrity validation of their payload, and provide no encryption. This specification does not forbid the use of such ciphersuites, but administrators must weight carefully the risk of relevant internal data leakage that can occur Lopez & Gonzalez de Dios Expires January 11, 2014 [Page 6] Internet-Draft Secure Transport for PCEP July 2013 in such a case, as explicitly stated by [RFC6952]. When using certificate fingerprints to identify PCEPS peers, any two certificates that produce the same hash value will be considered the same peer. Therefore, it is important to make sure that the hash function used is cryptographically uncompromised so that attackers are very unlikely to be able to produce a hash collision with a certificate of their choice. This document mandates support for SHA- 256, but a later revision may demand support for stronger functions if suitable attacks on it are known. 5. Acknowledgements This specification relies on the analysis and profiling of TLS included in [RFC6614]. 6. References 6.1. Normative References [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC5088, January 2008. [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC5089, January 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC5246, August 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC5280, May 2008. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC5440, March 2009. [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC6066, January 2011. Lopez & Gonzalez de Dios Expires January 11, 2014 [Page 7] Internet-Draft Secure Transport for PCEP July 2013 6.2. Informative References [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC6614, May 2012. [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC6952, May 2013. Authors' Addresses Diego R. Lopez Telefonica I+D Don Ramon de la Cruz, 82 Madrid, 28006 Spain Phone: +34 913 129 041 Email: firstname.lastname@example.org Oscar Gonzalez de Dios Telefonica I+D Don Ramon de la Cruz, 82 Madrid, 28006 Spain Phone: +34 913 129 041 Email: email@example.com Lopez & Gonzalez de Dios Expires January 11, 2014 [Page 8]