[Freeipa-devel] Re-send

[Aldo Pietropaolo]

Hello John,

I completely agree with your assessment. There would be some sort of
authentication protocol between sender and receiver for both the client
monitor / IPA and any third party receiver. Now there would also be some
hashing mechanism or CRC to ensure that the message sent was intact. The
other ideas that I have tested are client caching mechanisms to ensure the
message gets sent in case of receiver failure. Although PKI might be a
natural choice to provide keys for data encryption and confidentiality,
there might be other options to make it less complicated to deploy and
administer. There is of course an option to also include some sort of key
server to rotate any symmetric keys used for clients and servers. Now the
topic of kernel audit ability is an interesting topic I have not thought
about before which is very interesting and necessary.  It would be a very
exciting to see this added to IPA. In any case, what areas do you need
contribution in?

Thank you for your feedback!

Aldo Pietropaolo

On 8/25/08 7:44 AM, "John Dennis" <jdennis at redhat.com> wrote:

> Aldo Pietropaolo wrote:
>>  Re-send I apologize for the re-send but the .pptx file might be corrupt so I
>> attached a pdf. Below are some notes I had in the second slide.
>>  
>> ³The idea is to provide a stand alone freeIPA identity monitor that listens
>> to real time event information performed in the directory service such as
>> adds, modifications, deletes, password expiry, etc. These events would then
>> be sent to freeIPA server and be processed by freeIPA Audit extensions in
>> slide 1. Client side plugins may also be written to handle message
>> normalization of event data and to send event to multiple event consumers if
>> desired.
>>  
>>  
>> ClientMonitor will register for identity events and receive the events
>> asynchronously from the directory server. Call back interface may normalize
>> the data with default schema and send to freeIPA Server for processing.
>> Client monitor may also instantiate an audit plugin for additional
>> processing.²
>>  
> This is an interesting idea. I would imagine the functionality could be
> provided by some sort of "trigger" which could be registered with IPA. When a
> matching event is seen then an action is taken.  Directory server is one of
> the applications which we anticipate would be IPA audit aware and would use
> the IPA audit API. However, as I alluded to earlier we are not currently
> designing a real time monitoring system, although that may very well be a
> follow-on feature. One of my initial concerns with audit triggers distributing
> audit information to a listener is the security implications. It is vital
> audit data does not escape, if audit data were to be re-transmitted to a third
> party there would have to be a robust mechanism to assure the authenticity of
> the receiver and a centralized mechanism to shut the stream down. It is very
> hard to verify audit data sent to a third party will not escape from the 3rd
> party even if it's identity is verified. So while the idea of registering to
> receive audit events via a trigger has a lot of appeal in some scenarios I
> also imagine such a feature would be globally defeated by many organizations
> because it might violate enterprise security policy. These are some of the
> issues which would have to be solved.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20080825/195e75ca/attachment.htm>