[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MUST vs. SHOULD audit



Uri,


>> 	IPsec defines a protocol, and a protocol definition inlcludes the
>> processing that takes place at the sender and receiver in response to the
>> transmission and reception of packets, not just the format of the packet
>> bits on the wire.
>
>Yes, but what to do with the INFORMATION AFTER it is processed clearly
>is beyond the scope. Verify auth - within. Enter a certain state when
>the auth failed - within. Define what the alert contains, who it is
>sent to etc. - questionably outside. Insisting that this alert
>really gets somewhere - clearly outside.

The events that trigger audit activities are part of the protocol spec, as
are other specifications of error conditions.  A requirement that an
implementation be capable of creating audit log entries in response to such
events is also a legitimate part of the protocol processing spec.

[SNIP]

>> I also believe that the IPsec architecture document is a good place
>> to discuss when to audit, and what systems MUST/SHOULD provide an audit
>> capability and what is meant by "secure audit."  That audit records can be
>> maintained locally, or transmitted to a remote location, is an appropriate
>> elaboartion of the audit concept and I'm happy to include that as well.
>
>Let us not mix the two things! It is good and well to ADVISE the user
>and RECOMMEND the best spots to insert certain implementation-dependent
>features, like auditing. It is BAD to ENFORCE this 100% imlementation-
>dependent thing.

Responses from other WG members suggests that so long as we restrict the
specs to requring support for what COULD be audited, IF auditing is turned
on and IF the system in which IPsec is embedde supports auditing, then this
is a reasonable part of the IPsec specifications.

Steve




References: