Masaryk University Faculty}w¡¢£¤¥¦§¨ of Informatics!"#$%&'()+,-./012345<yA| Integrating SSH/TLS into Netopeer NETCONF server Master’s thesis Michal Vaško Brno, spring 2015 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Michal Vaško Advisor: RNDr. Petr Velan ii Acknowledgement I would like to thank RNDr. Petr Velan for analyzing my ideas, sug- gesting his own and general help with writing and implementing this thesis. iii Abstract The goal of this thesis is to integrate SSH and TLS protocol support into the Netopeer open-source NETCONF server. A brief comparison of these two protocol is included as well. Then, the new implementation of Netopeer is described as is the private key and certificate management. Lastly, the performed testing and the tool used for it is discussed. iv Keywords NETCONF, TLS, SSH, libssh, OpenSSL, security v Contents 1 Introduction ...........................3 2 NETCONF Protocol .....................5 2.1 Call Home ..........................7 2.2 cert-to-name .........................7 3 Cryptographic Network Protocols .............8 3.1 Secure Shell .........................8 3.2 Transport Layer Security ..................9 3.3 SSH Versus TLS ...................... 11 4 Netopeer Server ........................ 13 4.1 Current Architecture .................... 14 4.2 Issues ............................ 15 4.3 Suggested Architecture ................... 16 5 Technologies ........................... 17 5.1 SSH Library ......................... 17 5.1.1 libssh . 18 5.2 TLS Library ......................... 20 5.2.1 OpenSSL Suite . 21 6 Server Implementation .................... 24 6.1 Implementation Steps .................... 24 6.2 Data Structures ....................... 25 6.3 Transport-independent Server ............... 26 6.3.1 Main Function . 26 6.3.2 NETCONF-server transAPI . 27 6.3.3 Netopeer transAPI . 28 6.3.4 listen_loop() . 30 6.4 Transport-specific Server Parts ............... 31 6.4.1 NETCONF-server transAPI . 31 6.4.2 Netopeer transAPI . 32 6.4.3 np_(ssh|tls)_client_netconf_rpc() . 34 6.4.4 np_(ssh|tls)_client_data() . 36 6.4.5 np_(ssh|tls)_server_id_check() . 39 6.4.6 np_(ssh|tls)_create_client() . 39 6.5 Server Compilation ..................... 41 6.5.1 configure . 41 6.5.2 Makefile . 42 1 7 Server Configuration And Testing ............. 43 7.1 netopeer-configurator .................... 43 7.1.1 nc_sshauth . 43 7.1.2 nc_tlsauth . 44 7.2 netopeer-cli ......................... 46 7.3 Tests ............................. 47 8 Conclusion ............................ 49 A Complete Data Structures .................. 54 A.1 Generic Data Structures .................. 54 A.2 SSH Data Structures .................... 57 A.3 TLS Data Structures .................... 59 B netopeer-cfgnetopeer YANG Model ............ 61 2 1 Introduction From the technical point of view, a computer network is a network of nodes that are able to exchange data. Quite naturally, considering the massive size of the Internet network, the coordinating intermediary devices are complex and require detailed configuration to operate prop- erly[1]. The most common means of setting this configuration is either automatically by another device or manually by an administrator, but in both cases remotely, utilizing the network itself. To allow it, there needs to be a format of the messages specified. While there are several solutions available, the protocol NETCONF has recently been gaining popularity for its advantages such as conforming to the principles of Software-Defined Networking (SDN)[2]. There is a software bundle Ne- topeer1 that enables simple deployment of this protocol on network devices. These can be elementary, collecting some basic state data, or complicated systems with complex configuration. In either case, with NETCONF it is possible to execute Remote Procedure Calls on these devices in a secure way, managing their configuration and even the de- vice itself, connect several clients to one device, receive asynchronous notifications of certain events, and much more[3]. The goal of this thesis is to improve the Netopeer server, which is an implementation of the server-side NETCONF communication point. The current version of it suffers from several drawbacks, which are specifically discussed in the Section 4.2. All of them should be rectified by integrating the transport layer functionality into the server itself, because it currently uses external applications for handling the transport of data, but additional issues are likely to arise with this solution. The second chapter starts with a brief description of the NETCONF protocol and specially the requirements for the underlying protocol operating on the transport layer. Next, in the third chapter, the suitable secure protocols are explained, presented to the reader, and also com- pared to each other. The fourth chapter introduces the Netopeer server. Its present overall architecture with the focus on the communication flow is discussed followed by an analysis of the problems that itin- cludes causing it to be unsatisfactory. Then, a new improved integrated architecture is introduced. 1. https://code.google.com/p/netopeer 3 1. Introduction In the fifth chapter the used technologies are discussed. They consist of two libraries, one for each transport protocol integrated into Netopeer. The actual choices are explained and justified and each chosen library is described in more depth. The new Netopeer implementation is examined by a reasonably thorough analysis in the sixth chapter. The seventh chapter is about other Netopeer utilities and how they were used for server configuration and testing. The last chapter concludes the the- sis by discussing the thesis goals and justifying their completion and mentioning any possible future work. 4 2 NETCONF Protocol The NETCONF (NETwork CONFiguration) protocol defines mechanism for device management and configuration retrieval and modification. It uses a remote procedure call (RPC) paradigm and a system of exposing device (server) capabilities, which enables a client to adjust to the specific features of any network equipment. NETCONF further distinguishes between state data, which are read-only, and configuration data, which can also be modified. Any NETCONF communication happens on4 layers as shown in the Table 2.1. XML (eXtensible Markup Language) is used as the encoding format.[3] 1 Content Configuration data Notification data 2 Operations <edit-config> 3 Messages <rpc>, <rpc-reply> <notification> 4 Secure Transport SSH, TLS Table 2.1: The NETCONF Layers. The device configuration data are stored in the form of anXML document. The specific nodes in the document as well as the allowed values are defined by a model, which is usually in YANG format or possibly transformed into YIN format with XML-based syntax[4]. There are many such models created directly by IETF to further support stan- dardization and unification of the NETCONF interface of the common network devices. For example, the general system settings of a standard computer are described in the ietf-system model1 or the configuration of its network interfaces defined by the ietf-interfaces model2. However, it is usual for every system to have some specific parts exclusive to it. In that case there are mechanisms defined to enable extensions while keeping the support for the standardized core. Also, as this whole mech- anism is designed in a liberal fashion, the configuration does not have to concern strictly network. Even RPCs additional to those defined by NETCONF can be characterized, thus allowing the client to request an explicit action from the server. 1. https://tools.ietf.org/html/rfc7317 2. https://tools.ietf.org/html/rfc7223 5 2. NETCONF Protocol NETCONF was originally defined in the RFC 4741 at the endof 2006. Later, in 2011 there was a new version 1.1 created and published in the RFC 6241. Since then NETCONF has been on the rise and is already supported by several major network equipment vendors[5] and new related RFC drafts are being published or updated[6]. All this effort is governed by the NETCONF Working Group3. Since correct network device configuration is vital for creating aro- bust network[7] that can be used to transfer sensitive information and the configuration itself is, in fact, sensitive, NETCONF security isof high importance. There are several mandatory conditions as follows that the transport protocol must fulfill in order to be agreeable tobe used in conjuction with NETCONF. • Session type indication (client/server) • Connection persistence • Reliable and sequenced data delivery • Automatic release of connection-specific resources on its close • Authentication, data integrity, confidentiality, and replay protec- tion • Mechanism to provide a username A protocol that meets all these requirements is Secure Shell, for instance, whose support is mandatory[3]. Another suitable protocol for transporting NETCONF data is Transport Layer Security, which is currently extensively used for secure HTTP connections. It should also be mentioned that there are RFCs describing transporting NETCONF over SOAP or BEEP4. They are not taken into consideration, though, because they are dated back to the first NETCONF standardization and are now regarded as historic5. Also, both of these protocols depend on the underlying use of TLS, which examined