idnits 2.17.1 draft-ietf-netconf-tls-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 432. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 416. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 422. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 5, 2008) is 5804 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) == Unused Reference: 'I-D.ietf-netconf-notification' is defined on line 379, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 4741 (Obsoleted by RFC 6241) ** Obsolete normative reference: RFC 4742 (Obsoleted by RFC 6242) == Outdated reference: A later version (-14) exists of draft-ietf-netconf-notification-13 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NETCONF Working Group Mohamad Badra 2 Internet Draft LIMOS Laboratory 3 Intended status: Standards Track June 5, 2008 4 Expires: December 2008 6 NETCONF over Transport Layer Security (TLS) 7 draft-ietf-netconf-tls-03.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on December 5, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 The Network Configuration Protocol (NETCONF) provides mechanisms to 41 install, manipulate, and delete the configuration of network devices. 42 This document describes how to use the Transport Layer Protocol (TLS) 43 to secure NETCONF exchanges. 45 Table of Contents 47 1. Introduction...................................................3 48 1.1. Conventions used in this document.........................3 49 2. NETCONF over TLS...............................................3 50 2.1. Connection Initiation.....................................3 51 2.2. Connection Closure........................................4 52 3. Endpoint Authentication and Identification.....................4 53 3.1. Server Identity...........................................5 54 3.2. Client Identity...........................................6 55 3.3. Password-Based Authentication.............................6 56 4. Cipher Suite Requirements......................................7 57 5. Security Considerations........................................7 58 6. IANA Considerations............................................8 59 7. Acknowledgments................................................8 60 A. Appendix - Test Vectors for the PSK Derivation Function........9 61 Normative References..............................................9 62 Authors' Addresses...............................................10 63 Intellectual Property Statement..................................10 64 Disclaimer of Validity...........................................11 66 1. Introduction 68 The NETCONF protocol [RFC4741] defines a simple mechanism through 69 which a network device can be managed. NETCONF is connection- 70 oriented, requiring a persistent connection between peers. This 71 connection must provide reliable, sequenced data delivery, integrity 72 and confidentiality and peers authentication. This document 73 describes how to use TLS [RFC4346] to secure NETCONF connections. 75 Throughout this document, the terms "client" and "server" are used to 76 refer to the two ends of the TLS connection. The client actively 77 opens the TLS connection, and the server passively listens for the 78 incoming TLS connection. The terms "manager" and "agent" are used to 79 refer to the two ends of the NETCONF protocol session. The manager 80 issues NETCONF remote procedure call (RPC) commands, and the agent 81 replies to those commands. When NETCONF is run over TLS using the 82 mapping defined in this document, the client is always the manager, 83 and the server is always the agent. 85 1.1. Conventions used in this document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC-2119 [RFC2119]. 91 2. NETCONF over TLS 93 Since TLS is application protocol-independent, NETCONF can operate on 94 top of the TLS protocol transparently. This document defines how 95 NETCONF can be used within a Transport Layer Security (TLS) session. 97 2.1. Connection Initiation 99 The peer acting as the NETCONF manager MUST also act as the TLS 100 client. It MUST connect to the server that passively listens for the 101 incoming TLS connection on the IANA-to-be-assigned TCP port . 102 It MUST therefore send the TLS ClientHello to begin the TLS 103 handshake. Once the TLS handshake has been finished, the client and 104 the server MAY then send their NETCONF exchanges. In particular, the 105 client will send complete XML documents to the server containing 106 elements, and the server will respond with complete XML 107 documents containing elements. The client MAY indicate 108 interest in receiving event notifications from a NETCONF server by 109 creating a subscription to receive event notifications [I-D.ietf- 110 netconf-notification], in which the NETCONF server replies to 111 indicate whether the subscription request was successful and, if it 112 was successful, begins sending the event notifications to the NETCONF 113 client as the events occur within the system. All these elements are 114 encapsulated into TLS records of type "application data". These 115 records are protected using the TLS material keys. 117 Current NETCONF messages don't include a message's length. This 118 document uses consequently the same delimiter sequence defined in 119 [RFC4742] and therefore the special character sequence, ]]>]]>, to 120 delimit XML documents. 122 2.2. Connection Closure 124 Either NETCONF peer MAY stop the NETCONF connection at any time and 125 therefore notify the other NETCONF peer that no more data on this 126 channel will be sent and that any data received after a closure 127 request will be ignored. This MAY happen when no data is received 128 from a connection for a long time, where the application decides what 129 "long" means. 131 TLS has the ability for secure connection closure using the Alert 132 protocol. When the NETCONF peer closes the NETCONF connection, it 133 MUST send a TLS close_notify alert before closing the TCP connection. 134 Any data received after a closure alert is ignored. 136 Unless a fatal error has occurred, each party is required to send a 137 close_notify alert before closing the write side of the connection 138 [RFC4346]. The other party MUST respond with a close_notify alert of 139 its own and close down the connection immediately, discarding any 140 pending writes. It is not required for the initiator of the close to 141 wait for the responding close_notify alert before closing the read 142 side of the connection. 144 3. Endpoint Authentication and Identification 146 NETCONF requires that its transport provide mutual authentication of 147 client and server, so cipher suites that are anonymous or which only 148 authenticate the server to the client MUST NOT be used with NETCONF. 149 This document specifies how to use TLS with endpoint authentication, 150 which can be based on either preshared keys [RFC4279] or public key 151 certificates [RFC4346]. Some cipher suites (e.g. 152 TLS_RSA_PSK_WITH_AES_128_CBC_SHA) use both. Section 3.1 describes 153 how the client authenticates the server if public key certificates 154 are provided by the server, section 3.2 describes how the server 155 authenticates the client if public key certificates are provided by 156 the client, and section 3.3 describes how the client and server 157 mutually authenticate one another using a password. 159 3.1. Server Identity 161 During the TLS negotiation, the client MUST carefully examine the 162 certificate presented by the server to determine if it meets their 163 expectations. Particularly, the client MUST check its understanding 164 of the server hostname against the server's identity as presented in 165 the server Certificate message, in order to prevent man-in-the-middle 166 attacks. 168 Matching is performed according to these rules [RFC4642]: 170 - The client MUST use the server hostname it used to open the 171 connection (or the hostname specified in TLS "server_name" 172 extension [RFC4366]) as the value to compare against the server 173 name as expressed in the server certificate. The client MUST 174 NOT use any form of the server hostname derived from an 175 insecure remote source (e.g., insecure DNS lookup). CNAME 176 canonicalization is not done. 178 - If a subjectAltName extension of type dNSName is present in the 179 certificate, it MUST be used as the source of the server's 180 identity. 182 - Matching is case-insensitive. 184 - A "*" wildcard character MAY be used as the left-most name 185 component in the certificate. For example, *.example.com would 186 match a.example.com, foo.example.com, etc., but would not match 187 example.com. 189 - If the certificate contains multiple names (e.g., more than one 190 dNSName field), then a match with any one of the fields is 191 considered acceptable. 193 If the match fails, the client MUST either ask for explicit user 194 confirmation or terminate the connection and indicate the server's 195 identity is suspect. 197 Additionally, clients MUST verify the binding between the identity of 198 the servers to which they connect and the public keys presented by 199 those servers. Clients SHOULD implement the algorithm in Section 6 200 of [RFC5280] for general certificate validation, but MAY supplement 201 that algorithm with other validation methods that achieve equivalent 202 levels of verification (such as comparing the server certificate 203 against a local store of already-verified certificates and identity 204 bindings). 206 If the client has external information as to the expected identity of 207 the server, the hostname check MAY be omitted. 209 3.2. Client Identity 211 Typically, the server has no external knowledge of what the client's 212 identity ought to be and so checks (other than that the client has a 213 certificate chain rooted in an appropriate CA) are not possible. If 214 a server has such knowledge (typically from some source external to 215 NETCONF or TLS) it MUST check the identity as described above. 217 3.3. Password-Based Authentication 219 [RFC4279] supports authentication based on pre-shared keys (PSKs). 220 These pre-shared keys are symmetric keys, shared in advance among the 221 communicating parties. 223 The PSK can be generated in many ways and its length is variable. 224 Implementation of this document MAY rely on [RFC4279] to enable 225 password based user authentication. In this case, the password is 226 used to generate the PSK. It is RECOMMENDED that implementations 227 that allow the administrator to manually configure the password also 228 provide functionality for generating a new random password, taking 229 [RFC4086] into account. 231 This document generates the PSK from the password as follow: 233 PSK = SHA-1(SHA-1(psk_identity + "Key Pad for Netconf" + password) + 234 psk_identity_hint) 236 Where + means concatenation. 238 The label "Key Pad for Netconf" is an ASCII string. 240 The psk_identity_hint is initially defined in section 5.1 of 241 [RFC4279]. The psk_identity_hint can do double duty and also provide 242 a form of server authentication in the case where the user has the 243 same password on a number of NETCONF servers. If a hint is provided, 244 the psk_identity_hint is encoded in the same way as in [RFC4279] and 245 should be a string representation of the name of the server 246 recognizable to the administrator or his software. In the case where 247 the user types a server name to connect to, it should be that string. 248 If the string the user enters differs from the one returned as 249 psk_identity_hint, the software could display the server's name and 250 ask the user to confirm. For automated scripts, the names could be 251 expected to match. It is highly recommended that implementations set 252 the psk_identity_hint to the DNS name of the NETCONF server (i.e., 253 the TLS server). 255 It is RECOMMENDED that users choose different passwords for the 256 different servers they manage. 258 Note 1: The NETCONF over TLS implementation need not store the 259 password in clear text, but rather can store the value of the 260 inner SHA-1, (SHA-1(psk_identity + "Key Pad for Netconf" + 261 password)), which could not be used as a password equivalent for 262 applications other than NETCONF. Deriving the PSK from a password 263 is not secure. This construction is used because it is 264 anticipated that people will do it anyway. 266 Note 2: [RFC4279] defines some conformance requirements for the 267 PSK, for the PSK identity encoding and for the identity hint. The 268 same requirements apply here as well; in particular on the 269 password. Moreover, the management interface by which the 270 password is provided MUST accept ASCII strings of at least 64 271 octets and MUST NOT add a null terminator before using them as 272 shared secrets. It MUST also accept a HEX encoding of the 273 password. The management interface MAY accept other encodings if 274 the algorithm for translating the encoding to a binary string is 275 specified. 277 4. Cipher Suite Requirements 279 A compliant implementation of the protocol specified in this document 280 MUST implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA and 281 MAY implement any TLS cipher suite that provides mutual 282 authentication. 284 5. Security Considerations 286 The security considerations described throughout [RFC4346] and 287 [RFC4279] apply here as well. 289 This document in its current version doesn't support third party 290 authentication due to the fact that TLS doesn't specify this way of 291 authentication and that NETCONF depends on the transport protocol for 292 the authentication service. If third party authentication is needed, 293 BEEP or SSH transport can be used. 295 As with all schemes involving shared keys and passwords, special care 296 should be taken to protect the shared values and passwords as well as 297 to limit their exposure over time. Alternatively, using certificates 298 would provide better protection. 300 6. IANA Considerations 302 IANA is requested to assign a TCP port number that will be the 303 default port for NETCONF over TLS sessions as defined in this 304 document. 306 IANA has assigned port for this purpose. 308 7. Acknowledgments 310 A significant amount of the text in Section 3.1 was lifted from 311 [RFC4642]. 313 The author would like to acknowledge David Harrington, Miao Fuyou, 314 Eric Rescorla, Juergen Schoenwaelder, Simon Josefsson, Olivier 315 Coupelon and the NETCONF mailing list members for their comments on 316 the document. The author appreciates also Bert Wijnen, Mehmet Ersue 317 and Dan Romascanu for their efforts on issues resolving discussion, 318 and Charlie Kaufman for the thorough review of this document and for 319 the helpful comments on the password-based authentication. 321 A. Appendix - Test Vectors for the PSK Derivation Function 323 The test vectors for the PSK derivation function in this document 324 have been cross-verified by two independent implementations. An 325 implementation that concurs with the results provided in this 326 document should be interoperable with other similar implementations. 328 password = password 329 psk_identity = psk_identity 330 psk_identity_hint = psk_identity_hint 332 The inner SHA-1 value (in hex): 334 inner := SHA-1(psk_identity + "Key Pad for Netconf" + password) 335 == SHA-1("psk_identityKey Pad for Netconfpassword") 336 => 6d6eeb6a b8d0466b 45245d07 47d86726 b41b868c 338 The outer SHA-1 value (in hex): 340 outer := SHA-1(inner + psk_identity_hint) 341 => 88f3824b 3e5659f5 2d00e959 bacab954 b6540344 343 Normative References 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 349 Housley, R., and W. Polk, "Internet X.509 Public Key 350 Infrastructure Certificate and Certificate Revocation List 351 (CRL) Profile", RFC 5280, May 2008. 353 [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, 354 "Randomness Requirements for Security", BCP 106, RFC 4086, 355 June 2005. 357 [RFC4279] Eronen, P. and H. Tschofenig., "Pre-Shared Key Ciphersuites 358 for Transport Layer Security (TLS)", RFC 4279, December 359 2005. 361 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 362 (TLS) Protocol 1.1", RFC 4346, April 2006. 364 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 365 and T. Wright, "Transport Layer Security (TLS) Extensions", 366 RFC 4366, April 2006. 368 [RFC4642] Murchison, K., Vinocur, J., Newman, C., "Using Transport 369 Layer Security (TLS) with Network News Transfer Protocol 370 (NNTP)", RFC 4642, October 2006 372 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 373 December 2006. 375 [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF 376 Configuration Protocol over Secure Shell (SSH)", RFC 4742, 377 December 2006. 379 [I-D.ietf-netconf-notification] 380 Chisholm, S. and H. Trevino, "NETCONF Event Notifications", 381 draft-ietf-netconf-notification-13.txt, (work in progress), 382 May 2008. 384 Authors' Addresses 386 Mohamad Badra 387 LIMOS Laboratory - UMR6158, CNRS 388 France 390 Email: badra@isima.fr 392 Contributors 394 Ibrahim Hajjeh 395 INEOVATION 396 France 398 Email: hajjeh@ineovation.com 400 Intellectual Property Statement 402 The IETF takes no position regarding the validity or scope of any 403 Intellectual Property Rights or other rights that might be claimed to 404 pertain to the implementation or use of the technology described in 405 this document or the extent to which any license under such rights 406 might or might not be available; nor does it represent that it has 407 made any independent effort to identify any such rights. Information 408 on the procedures with respect to rights in RFC documents can be 409 found in BCP 78 and BCP 79. 411 Copies of IPR disclosures made to the IETF Secretariat and any 412 assurances of licenses to be made available, or the result of an 413 attempt made to obtain a general license or permission for the use of 414 such proprietary rights by implementers or users of this 415 specification can be obtained from the IETF on-line IPR repository at 416 http://www.ietf.org/ipr. 418 The IETF invites any interested party to bring to its attention any 419 copyrights, patents or patent applications, or other proprietary 420 rights that may cover technology that may be required to implement 421 this standard. Please address the information to the IETF at 422 ietf-ipr@ietf.org. 424 Disclaimer of Validity 426 This document and the information contained herein are provided on an 427 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 428 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 429 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 430 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 431 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 432 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 434 Copyright Statement 436 Copyright (C) The IETF Trust (2008). 438 This document is subject to the rights, licenses and restrictions 439 contained in BCP 78, and except as set forth therein, the authors 440 retain all their rights. 442 Acknowledgment 444 Funding for the RFC Editor function is currently provided by the 445 Internet Society.