[Osiris-devel]Osiris Auth Scheme

[Paul Holman]

Brian and I have discussed the crypto requirements for Osiris 2.0 over 
the last couple months, and tonight I outlined for him, the general 
approach that I think we should take.  I won't cover all the supporting 
data at how we've arrived at this here, but if any part of it concerns 
or interests you, please feel free to ask me about it.

There are effectively three components in Osiris 2.0:

	osirismd - Osiris Management Daemon
	osirisd  - Osiris Daemon (client component for scanning hosts)
	osiris   - Command line UI

Each of these components communicates with the others via the network.  
The osirismd is meant to run on one or more management hosts, osirisd 
must be installed on every client you want to scan, and osiris is a 
feature-complete but not feature-rich reference UI that will someday be 
supplanted by a full GUI.  Note that communication between components is 
as such:

	osiris <---> osirismd <---> osirisd

First, I propose that each of these components talk to each other using 
HTTPS (SSL secured HTTP).  This is very easy to do thanks to OpenSSL.

Second, I believe the most important thing is for the clients to 
authenticate the management host.  You don't want them responding to 
impostors.  So osirismd will have the equivalent of a web server cert, 
and osirisd instances will only communicate with an osirismd that they 
trust.

Third, the osiris UI will also communicate with the osirismd vi HTTPS, 
authenticating the server's cert.  The osirismd will authenticate these 
UI users via user/pass over that secured connection.  This should all be 
viewed as identical to a typical secured browser/web server 
interaction.  Eventually, osirismd will offer various user management 
and ACL functions.

A more detailed description of the procedures follows:

osirismd - This app needs to implement a feature for generating a 
keypair.  Ideally, this is performed once per site.  I suggest that we 
use OpenSSL to generate a keypair and a self-signed server cert, like 
the snake-oil cert typically generated for an Apache install.  There is 
no root cert, this cert must be trusted on it's own merits.  We can make 
up our own X.509 extension to indicate that a cert is valid for use with 
Osiris.  If people wish to integrate with their own PKI, they can swap 
out this cert for one they generated on their own.  The cert should be 
stored in $OSIRISHOME/certs and the key in $OSIRISHOME/private.  All the 
same conventions as Apache should apply, if a user wants to keep the 
private key encrypted, then a password will be needed when osirismd is 
started, otherwise it can start anytime.  The osirismd needs it's own 
user/pass database with ACL support to control which hosts/configs a 
given user can run.  Personally, I'd like to see this hooked into the 
operating system's user accounts, just create an "osirisadmin" group 
that is allowed to login.  The osirismd must have the ability to 
generate a random session key per host and store hashes of them in 
$OSIRISHOME/hosts/$HOSTNAME/host.conf.

osirisd - This application will be installed in various ways, depending 
on platform and user preference.  The first time it is run, it will 
allow connections from any osirismd but will save the cert on disk and 
permission it read only.  All future connections from an osirismd will 
be authenticated by this cert.  Think of this as an initialization 
process similar to what you experience with SSH the first time you 
connect to a new host.  The key fingerprint can be shown in syslog and 
manually verified.  The client can be reset to it's virgin state by 
simply deleting this cert from the filesystem.  The osirisd should be 
built to trust either a cert, or a root.  It should also check for the 
Osiris extension in the cert.  This cert should be stored in 
$OSIRISHOME/certs on the client.  Note that no private key or config 
exists on the client filesystem.  When osirisd starts up, osirismd must 
connect to it, providing a new symmetric session key and logging an 
alert that the osirisd instance has been cycled.  The session key is 
made persistent on the osirismd server, but is stored only in RAM on the 
osirisd client, this ensures that the server can always tell if osirisd 
has been cycled.  Additionally, a scan of the osirisd binary, and cert 
should be added at the beginning of every scan and compared to a 
reference in $OSIRISHOME/hosts/$HOSTNAME/host.conf on the osirismd host 
to ensure that the software hasn't been tampered with.  Failure to pass 
this test generates dire log events and any scans performed must be 
flagged as "untrusted."

osiris - This app works just like osirisd as described above except that 
it initiates a connection to osirismd instead of the other way around.  
It should have the same server cert stored in $OSIRISHOME/certs.  The 
osiris UI app must provide a facililty for sending username/password 
credentials to osirismd.

Please keep in mind that Osiris is a host based intrusion detection 
tool, so it is paramount for us to identify changes to the client hosts 
which run osirisd.  At the same time, we don't want to provide a false 
sense of security by attempting to obscure, inveigle and obfuscate 
authentication credentials in the client.  This is truly impossible 
without the aide of tamper-proof crypto devices (Hardware Security 
Module).  In our scheme, a client is trusted only as long as it is 
running, and we "do our best" to revalidate it after it is cycled.  We 
believe the best authentication of the client is going to be the scan 
history stored on the osirismd machine.  The greatest challenge we can 
present an attacker is having to spoof an entire osiris scan.

Thanks, please feel free to talk to me more about this anytime.

pablos.
--
Paul Holman
The Shmoo Group
pablos at shmoo.com
415.420.3806