idnits 2.17.1 draft-lopez-pcp-pceps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 115: '...nection establishment SHALL follow the...' RFC 2119 keyword, line 122: '... * Support for TLS v1.2 [RFC5246] or later is REQUIRED....' RFC 2119 keyword, line 125: '... REQUIRED....' RFC 2119 keyword, line 127: '... of mutual authentication is REQUIRED....' RFC 2119 keyword, line 130: '... protection is REQUIRED....' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2013) is 3943 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Path Computation Element D. Lopez 3 Internet-Draft O. Gonzalez de Dios 4 Intended status: Standards Track Telefonica I+D 5 Expires: January 11, 2014 July 10, 2013 7 Secure Transport for PCEP 8 draft-lopez-pcp-pceps-00 10 Abstract 12 The Path Computation Element Communication Protocol (PCEP) defines 13 the mechanisms for the communication between a client and a PCE, or 14 among PCEs. This document describe the usage of Transport Layer 15 Security to enhance PCEP security, hence the PCEPS acronym proposed 16 for it. The additional security mechanisms are provided by the 17 transport protocol supporting PCEP, and therefore they do not affect 18 its flexibility and extensibility. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 11, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Applying TLS to PCEP . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. TCP ports . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Connection Establishment . . . . . . . . . . . . . . . . . 4 58 2.3. Peer Identity . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 64 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 PCEP [RFC5440] defines the mechanisms for the communication between a 70 Path Computation Client (PCC) and a Path Computation Element (PCE), 71 or between two PCEs. These interactions include requests and replies 72 that can be critical for a sustainable network operation and adequate 73 resource allocation, and therefore appropriate security becomes a key 74 element in the PCE infrastructure. As the appplications of the PCE 75 framework evolves, and more complex service patterns emerge, the 76 definition of a secure mode of operation becomes more relevant. 78 [RFC5440] analyzes in its section on security considerations the 79 potential threats to PCEP and their consequences, and discusses 80 several mechanisms for protecting PCEP against security attacks, 81 without making a specific recommendation on a particular one or 82 defining their application in depth. Moreover, [RFC6952] remarks the 83 importance of ensuring PCEP communication privacy, especially when 84 PCEP communication endpoints do not reside in the same AS, as the 85 interception of PCEP messages could leak sensitive information 86 related to computed paths and resources. 88 Among the possible solutions mentioned in these documents, Transport 89 Layer Security (TLS) [RFC5246] provides support for peer 90 authentication, and message encryption and integrity. TLS supports 91 the usage of well-know mechanisms to support key configuration and 92 exchange, and means to perform security checks on the results of PCE 93 discovery procedures ([RFC5088] and [RFC5089]). Since TLS is a 94 security container for the transport of PCEP requests and replies, it 95 will not interfere with the protocol flexibility and extensibility. 97 This document describes how to apply TLS in securing PCE 98 interactions, including the handshake mechanisms, the methods for 99 peer authentication, and the applicable TLS ciphersuites for data 100 exchange. In the rest of the document we will refer to this usage of 101 TLS as transport for PCEP as either "PCEP over TLS" or "PCEPS". 103 2. Applying TLS to PCEP 105 2.1. TCP ports 107 The default destination port number for PCEP over TLS is TCP/XXXX. 109 NOTE: This port has to be agreed and registered as PCEPS with IANA. 111 2.2. Connection Establishment 113 PCEPS has no notion of negotiating TLS in an established connection. 114 Both peers in the connection need to be preconfigured to use PCEPS 115 for a given endpoint. The connection establishment SHALL follow the 116 following steps: 118 1. After completing the TCP handshake, immediately negotiate TLS 119 sessions according to [RFC5246]. The following restrictions 120 apply: 122 * Support for TLS v1.2 [RFC5246] or later is REQUIRED. 124 * Support for certificate-based mutual authentication is 125 REQUIRED. 127 * Negotiation of mutual authentication is REQUIRED. 129 * Negotiation of a ciphersuite providing for integrity 130 protection is REQUIRED. 132 * Negotiation of a ciphersuite providing for confidentiality is 133 RECOMMENDED. 135 * Support for and negotiation of compression is OPTIONAL. 137 * PCEPS implementations MUST, at a minimum, support negotiation 138 of the TLS_RSA_WITH_3DES_EDE_CBC_SHA, and SHOULD support 139 TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as 140 well. In addition, PCEPS implementations MUST support 141 negotiation of the mandatory-to-implement ciphersuites 142 required by the versions of TLS that they support. 144 2. Peer authentication can be performed in any of the following two 145 REQUIRED operation models: 147 * TLS with X.509 certificates using PKIX trust models: 149 + Implementations MUST allow the configuration of a list of 150 trusted Certification Authorities for incoming connections. 152 + Certificate validation MUST include the verification rules 153 as per [RFC5280]. 155 + Implementations SHOULD indicate their trusted Certification 156 Authorities (CAs). For TLS 1.2, this is done using 157 [RFC5246], Section 7.4.4, "certificate_authorities" (server 158 side) and [RFC6066], Section 6 "Trusted CA Indication" 159 (client side). 161 + Peer validation always SHOULD include a check on whether 162 the locally configured expected DNS name or IP address of 163 the server that is contacted matches its presented 164 certificate. DNS names and IP addresses can be contained 165 in the Common Name (CN) or subjectAltName entries. For 166 verification, only one of these entries is to be 167 considered. The following precedence applies: for DNS name 168 validation, subjectAltName:DNS has precedence over CN; for 169 IP address validation, subjectAltName:iPAddr has precedence 170 over CN. 172 + NOTE: Consider here whether peer validation MAY be extended 173 by means of the DANE procedures, including its specs as 174 informative references. 176 + Implementations MAY allow the configuration of a set of 177 additional properties of the certificate to check for a 178 peer's authorization to communicate (e.g., a set of allowed 179 values in subjectAltName:URI or a set of allowed X509v3 180 Certificate Policies) 182 * TLS with X.509 certificates using certificate fingerprints: 183 Implementations MUST allow the configuration of a list of 184 trusted certificates, identified via fingerprint of the DER 185 encoded certificate octets. Implementations MUST support SHA- 186 256 as the hash algorithm for the fingerprint. 188 3. Start exchanging PCEP requests and replies. 190 NOTE: TLS re-negotiation left as an open issue. 192 2.3. Peer Identity 194 Depending on the peer authentication method in use, PCEPS supports 195 different operation modes to establish peer's identity and whether it 196 is entitled to perform requests or can be considered authoritative in 197 its replies. PCEPS implementations SHOULD provide mechanisms for 198 associating peer identities with different levels of access and/or 199 authoritativeness, and they MUST provide a mechanism for establish a 200 default level for properly identified peers. Any connection 201 established with a peer that cannot be properly identified SHALL be 202 terminated before any PCEP exchange takes place. 204 In TLS-X.509 mode using fingerprints, a peer is uniquely identified 205 by the fingerprint of the presented client certificate. 207 There are numerous trust models in PKIX environments, and it is 208 beyond the scope of this document to define how a particular 209 deployment determines whether a client is trustworthy. 210 Implementations that want to support a wide variety of trust models 211 should expose as many details of the presented certificate to the 212 administrator as possible so that the trust model can be implemented 213 by the administrator. As a suggestion, at least the following 214 parameters of the X.509 client certificate should be exposed: 216 o Peer's IP address 218 o Peer's FQDN 220 o Certificate Fingerprint 222 o Issuer 224 o Subject 226 o All X509v3 Extended Key Usage 228 o All X509v3 Subject Alternative Name 230 o All X509v3 Certificate Policies 232 NOTE: Additional procedures enabled by DANE methods are TBD 234 NOTE: Specific connections with PCE discovery procedures is TBD 236 3. IANA Considerations 238 NOTE: PCEPS has to be registered as TCP port XXXX. 240 No new PCEP messages or other objects are defined. 242 4. Security Considerations 244 Since computational resources required by TLS handshake and 245 ciphersuite are higher than unencrypted TCP, clients connecting to a 246 PCEPS server can more easily create high load conditions and a 247 malicious client might create a Denial-of-Service attack more easily. 249 Some TLS ciphersuites only provide integrity validation of their 250 payload, and provide no encryption. This specification does not 251 forbid the use of such ciphersuites, but administrators must weight 252 carefully the risk of relevant internal data leakage that can occur 253 in such a case, as explicitly stated by [RFC6952]. 255 When using certificate fingerprints to identify PCEPS peers, any two 256 certificates that produce the same hash value will be considered the 257 same peer. Therefore, it is important to make sure that the hash 258 function used is cryptographically uncompromised so that attackers 259 are very unlikely to be able to produce a hash collision with a 260 certificate of their choice. This document mandates support for SHA- 261 256, but a later revision may demand support for stronger functions 262 if suitable attacks on it are known. 264 5. Acknowledgements 266 This specification relies on the analysis and profiling of TLS 267 included in [RFC6614]. 269 6. References 271 6.1. Normative References 273 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 274 "OSPF Protocol Extensions for Path Computation Element 275 (PCE) Discovery", RFC 5088, January 2008. 277 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 278 "IS-IS Protocol Extensions for Path Computation Element 279 (PCE) Discovery", RFC 5089, January 2008. 281 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 282 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 284 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 285 Housley, R., and W. Polk, "Internet X.509 Public Key 286 Infrastructure Certificate and Certificate Revocation List 287 (CRL) Profile", RFC 5280, May 2008. 289 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 290 (PCE) Communication Protocol (PCEP)", RFC 5440, 291 March 2009. 293 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 294 Extension Definitions", RFC 6066, January 2011. 296 6.2. Informative References 298 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 299 "Transport Layer Security (TLS) Encryption for RADIUS", 300 RFC 6614, May 2012. 302 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 303 BGP, LDP, PCEP, and MSDP Issues According to the Keying 304 and Authentication for Routing Protocols (KARP) Design 305 Guide", RFC 6952, May 2013. 307 Authors' Addresses 309 Diego R. Lopez 310 Telefonica I+D 311 Don Ramon de la Cruz, 82 312 Madrid, 28006 313 Spain 315 Phone: +34 913 129 041 316 Email: diego@tid.es 318 Oscar Gonzalez de Dios 319 Telefonica I+D 320 Don Ramon de la Cruz, 82 321 Madrid, 28006 322 Spain 324 Phone: +34 913 129 041 325 Email: ogondio@tid.es