Cfengine Protocol
From Cfwiki
Contents |
Overview
Cfengine makes use of a network protocol to transfer files from the server to any clients. These files could be any number of things, but typically this is used to synchronize configurations for all machines involved. In order to do this safely, the client must be able to ensure it is talking to the correct server, and the server must confirm that it is talking to an approved client.
If a client makes a connection to a server acting as an imposter, then it is possible to overwrite the configurations on the client with malicious instructions. Likewise, if a server sends configurations to a non-approved client, then this may expose vulnerabilities in the Cfengine configuration, or distribute sensitive information to third parties.
Authentication Protocol
When initiating a connection between a client and server, Cfengine must verify that both machines involved are in reality who they claim to be. This accomplished using a challenge-response system. The client will challenge the identity of the server and likewise between the server and client. This is only useful after the initial connection which exchanges keys between server and client.
Stages
The authentication of a client-server connection in Cfengine can be broken down into several stages. These stages involve a reverse DNS lookup, two public-private key challenges, and finally, the generation and transmission of a random session key.
Connections in Cfengine are initiated by the client. Once the client opens the network connection, it begins the authentication process.
Reverse DNS Lookup
The first stage involves the server verifying the client's IP and hostname. The client transmits its IP, hostname, and username to the server. If the server does not have a public key for the client, then it performs a reverse DNS lookup to confirm that communication is coming from a valid source. If the server already has the public key of the client, then it is not necessary to do the reverse DNS lookup, since the validity of the client's identification will be revealed during the challenge-response section of the authentication protocol
Client to Server Challenge
If the client does not have a key for the server, then it trusts the server's identity. Otherwise, a challenge is sent to the server encrypted with the server's public key. After sending the challenge, the client's public key is sent to the server.
If the server currently has a public key for the client, then that key is trusted. If no key is found and the client is in the list of clients to trust, then the transmitted public key is trusted. Otherwise the connection is denied. After finding the client's public key, the MD5 of the decrypted challenge is sent to the client.
Server to Client Challenge
Now, the server attempts to authenticate the client's identity. It sends a counter challenge to the client, encrypted with the client's public key. Also, if the client does not currently have the server's public key, it is transmitted to the client.
The client responds to the counter challenge with the MD5 of the decrypted challenge.
Send Session Key
Once both client and server are authenticated, a random blowfish session key is generated by the client, encrypted with the server's public key, and sent to the server. This is the key used for further encrypted communication between the client and the server.
About This Article
This article was orignally written by Jeff Avallone for Perfect Order during his work on the SysNav Project. The original content has been reproduced here with the permission of Perfect Order. It is the intention of Perfect Order that this documentation will seed further effort towards documenting in more detail how the Cfengine Protocol works and is secured. The original content was written by doing an evaluation of the code. Please feel free to update and add to this article.
--pearcec 16:04, 18 Mar 2005 (EST)
