after I finished the login and session management for the access control I think about what's doing next. There are three options
1. start thinking about ACLs 2. start implementing OpenCA::LOG 3. start implementing the passphrase manager for keys
These are the three major TODOs for 0.9.2. I have no good ideas for the ACLs until now and the ideas for the logging which I attached requires a really advanced passphrase manager for the HSMs. Finally I would like to start with the passphrase manager.
First of all what should be the name of the module? OpenCA::Token? The only usage of the module is the collection of all the data which is necessary to run a cryptooperation. So there can be the following operations:
- login to one or more HSMs
- logout from one or more HSM depending on the configuration of the different HSMs
- support for several HSMs modes
* standby - logout after the command finished
* session - logout if the session will be closed
* daemon - runs forever
- explicit HSM login
- automatic request for HSM login
- passphrase splitting for conventional PEM files
- automatic requests for passphrase
- cgi variable protection during automatic requests
Does somebody be missing a required feature? The first step would be the definition of the interface of the module. Therefore we should know all the needed features.
Best regards
Michael -- ------------------------------------------------------------------- Michael Bell Email (private): [EMAIL PROTECTED] Rechenzentrum - Datacenter Email: [EMAIL PROTECTED] Humboldt-University of Berlin Tel.: +49 (0)30-2093 2482 Unter den Linden 6 Fax: +49 (0)30-2093 2704 10099 Berlin Germany http://www.openca.org
List of Contents ---------------- 1. logging methods 2. message types 3. message levels 4. message formats 5. signing of logmessages
1. logging methods
==================
Please bear in mind that all methods work additonally. This
mean that you can log into SYSLOG and into the filesytem at
the same time and for the same event. So you can store the
event in the filesystem for better datamining and in the
same moment you can send the message to the syslog to support
tools which checks the logs for special events.
We can support the following theoretical methods.
- filesystem based
OPENCADIR/var/log/year/moth/day/utc-timestamp.xml
- database
- ID = UTC timestamp in numeric format + session_id
- perhaps difficult to implement
- difficult to handle by the admins
- not easily usable with script
- local syslog without syslogd
logging with Unix::Syslog
- syslogd with local configuration
logging with Sys::Syslog
- direct connect to a remote syslogd
logging with Net::Syslog to use a remote syslogd directly
Perhaps we should only implement filesystem and syslog based services.
A database is a nice thing but it is not so flexible like files.
The syslog usage requires a transformation of the XML format
into a textrepresentation. So it looks like the filesystem
based XML storage with activated syslog is the best option.
2. message types
================
alert
error
warning
info
3. message levels
=================
uncritical
normal
critical
4. message formats
==================
Perhaps we should log all CGI content in every message to allow
the detection of general attacks like bufferoverflow attacks against
some modules or DOS attacks.
channel verification error
--------------------------
<event>
<type>alert</type>
<level>defined by error</level>
<class>channel</class>
<timestamp>iso utc timestamp</timestamp>
<module>module id</module>
<channel>
<type></type>
<protocol></protocol>
<source></source>
<asymmetric_cipher></asymmetric_cipher>
<asymmetric_keylength></asymmetric_keylength>
<symmetric_cipher></symmetric_cipher>
<symmetric_keylength></symmetric_keylength>
</channel>
<message>...</message>
</event>
login error
-----------
<event>
<type>alert</type>
<level>critical</level>
<class>login</class>
<timestamp>iso utc timestamp</timestamp>
<module>module id</module>
<channel>
<type></type>
<protocol></protocol>
<source></source>
<asymmetric_cipher></asymmetric_cipher>
<asymmetric_keylength></asymmetric_keylength>
<symmetric_cipher></symmetric_cipher>
<symmetric_keylength></symmetric_keylength>
</channel>
----------begin of optional part----------------
--------------- passwd -------------------------
<login>
<type>passwd</type>
<name>used user name</name>
</login>
--------------- x509 ---------------------------
<login>
<type>x509</type>
<signature>PKCS#7 signature - if it violates
XML then escape the <
</signature>
<session_id>2873abc</session_id>
</login>
-----------end of optional part-----------------
<message>...</message>
</event>
login success (session start)
-------------
all like for login error excepts:
1. type: info
2. level: normal
3. add the path event/session_id with the new session_id
4. add the path event/login/session_type with the type of the session (cookie)
4. add the path event/login/name
5. remove message
login starts
------------
all like for login error excepts:
1. type: info
2. level: uncritical
3. remove signature and name from the login part
4. remove message
logout (session stop)
------
<event>
<type>info</type>
<level>uncritical</level>
<class>logout</class>
<timestamp>iso utc timestamp</timestamp>
<module>module id</module>
<session_id>123abc</session_id>
</event>
acl
---
This is not implemented until now so we cannot specify the
errormessages for it. If somebody has some experiences with ACLs
then he can make proposals for message formats. We will include
it at this place.
scripts
-------
This scheme can be used for eventtypes. This mean that a script can generate
such messages by itself but this message format can be used after the access
control to log every contact too.
<event>
<type></type>
<level></level>
<class>script|library</script>
<timestamp>iso utc timestamp</timestamp>
<session_id>123abc</session_id>
<cmd>command name</cmd>
<lib>libname if library error</lib>
<cgi>
all submitted cgi data excepts from passphrases
</cgi>
<message>...</message>
</event>a
5. signing of logmessages
=========================
Some softwaresystems like signed logmessages. The only way to implement such
things is a HSMs. After the creation of the session the user must logout from
the interface without logging out from the HSM. This functionality must be part
the passphrase manager and the access control.
If a session will be deleted then the user must specify to logout from
the HSM or not. This mean that the access control has to check the HSM status
and decide what to do. The HSM can be runned in three modes - standby, session
and daemon. Please take in mind that OpenCA MUST support several HSMs because
OpenCA knows three different keys without the one for logging:
- CA key
- logging
- batchprocessors
- keyrecovery
So that's all until know. The last point is more a part of the key manager
than of the logging.
