TLS support for argus and argus-clients

[Chas DiFatta]

Hey Carter,

Adopting the TLS transport feature option has been on the top of my wish list. While SASL, albeit a great technology, it seems complex and not an active effort as is TLS, but I could be wrong.  Here is my thinking with respect to features and issues regarding adding TLS. 

Configuration:

1. Argus/Radium certificate binding:
	I assume that given each argus or radium instance, the connecting client (or another radium) needs at least the following two attributes to complete the setup.

	ENCRYPTION = [on,off]
	CERTIFICATE = [file name path]

	You're the expert here, but would it be logical to extend the variable syntax used in argus.conf to use those two attributes?  Here a a few examples,

	ARGUS_AUTH_TYPE="TLS"								// where type can be, NONE, SASL, TLS
	ARGUS_AUTH_CERTIFICATE="/usr/local/argus/cert/foo.cert" 	// path to the certificate
	ARGUS_AUTH_ENCRYPTION="yes"						// yes and no are the only options

	I assume this is predicated that the ARGUS_BIND_IP variable must be set.

	I really don't know the minutia of SASL, but this suggested syntax may have to change given the SASL configuration constructs if you wish to use it for SASL as well.

	This may "beg" a higher question that we may want to think about, but not necessarily implement at this phase. 

		Should there be a /etc/argus directory which contains specific directories/files for both argus and radium which is similar to /etc/ssh?

2. Client binding:
	You may want to extend the RA_ARGUS_SERVER naming conventions variable in .rarc to be consistent with the above,  E.g.

	RA_ARGUS_SERVER=localhost:561
	RA_ARGUS_SERVER_ AUTH_TYPE="TLS"						// where type can be, NONE, SASL, TLS
	RA_ARGUS_SERVER_CERTIFICATE="/usr/local/argus/cert/foo.cert" 	// path to the certificate
	RA_ARGUS_SERVER_AUTH_ENCRYPTION="yes"					// yes and no are the only options
 	
Diagnostics:
	A simple request to put adequate diagnostic messages into /var/log/messages and debug levels to diagnose any problems with TLS as well as SASL.

Examples
	To make this feature easier for folks to adopt, especially if they don't know the details of generating a certificate, some example documentation on how to generate their own certificates would go a long way.

Thoughts?

	...cd

On Feb 5, 2013, at 10:23 AM, Carter Bullard wrote:

> Gentle people,s
> There are a few requests to provide TLS authentication and confidentiality protection for
> argus data on the wire, in addition to the SASL support we currently provide.
> 
> I'm looking into the effort now and would like to get your opinions on this feature.
> Using your SSL certificates seems like a good thing, and getting around the complexities
> of SASL account creation, mechanisms etc… sounds like a good thing, but the SASL
> stuff does work, so, …. extend security capabilities,  not replace, seems like a good thing.
> 
> Currently, security protection for argus data in transit is provided by SASLv2.
> You have to configure it at compile time for argus, the clients get it by default.
> 
> You configure the argus data source to set a protection policy, by setting the
> various MIN_SSF and MAX_SSF values in the configuration file.  This applies to
> argus and radium  These are pretty cryptic SASL configurations that set the minimum
> and maximum level of protection.  We have command line support to specify
> particular SASL mechanisms for the clients ( -M saslmech="mech" ).
> 
> If MIN_SSF is not zero, then argus / radium will tell attaching clients that a
> security association must be created.  Clients can declare that they need security,
> if their RA_MIN_SSF is non-zero.  The source and clients negotiate things, and
> if they can create an association, then all is well.  SASL handles the establishment,
> providing things like "Password: " prompts to get you through, if necessary.
> 
> To add TLS to this mix, we need to provide ./configure support to load TLS at
> compile time, we'll need data sources and client configuration support to chose TLS,
> SASL or none.  We need to add TLS as an option to the argus transport protocol, and
> we'll need to provide some guidance on certificates, etc…..
> 
> Seems like a bit of work, but I can see a good reason to do it.
> Are there opinions on this?  Anyone added this type of support to their applications?
> Suggestions for configuration?  Do other packages provide this level of options?
> Please send suggestions / opinions / ideas / flames / concerns to the list or to me.
> 
> Hope all is most excellent,
> 
> Carter