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

Re: MUST vs. SHOULD audit



Stephen Kent says:
> 	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.

> On that basis, I'd argue that auditing is within the
> scope of the IPsec specs, especially since auditing is a security function
> and IPsec defines security protocols.

By this logic, since physical access to the computer room is a security
function too - why don't you put it in the IPSEC paper?

> 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.

> Auditing is a common concern for both AH and ESP, so I'd prefer not
> duplicating the text in each document, although I could be persuaded
> otherwise.

No, you are correct here (I think).
-- 
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-
<Disclaimer>


Follow-Ups: References: