I just spent some time figuring out how Add Additional Client works in the Client Control plugin by sniffing client/server traffic.
Whatever client names you enter into the Server\ Client Management\ Permitted Clients list will be searched for by the Client Control plugin after OpenFire prompts the user with an XMPP Service Discovery request (see: http://xmpp.org/extensions/xep-0115.html & http://xmpp.org/registrar/disco-categories.html#client [note the “name” parameter is optional and not described in the spec]).
The given string (the client name or any part of the name) will be included in a case-insensitive search of the http://jabber.org/protocol/disco#info response’s identity name parameter.
For example, Pidgin’s response:
<identity category='client' type='pc' name='Pidgin'/>
So you can add “idg” or “gin” or “pid” or “pidGIN”, and the plugin will allow the client.
Therefore, although it won’t be perfect, you can do the following to reduce the chances that a rouge client connects to the Openfire server:
utilize the “name” parameter as a sort of “shared secret” (obviously retrivable via the client… but having an locally accessible encrypted datastore and allowing your client access to this datastore would be interesting solution [note process explorer is an example of a program that can easily read strings in a process’s memory])
utilize client certificates for authentication.and your own CA.
look into application whitelisting (applocker for instance).
Not perfect, but #1 is an example of how you can utilize the Client Control plugin as a sort of gatekeeper.
It is spoofable of course… check out http://www.wildcroftsecurity.com/echo-mirage