[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MUST vs. SHOULD audit
Of course interoperability is the main point of the spec, but is the
discussion so far well-founded? I'm a little confused by the
responses --- most seem comfortable having the audit requirement
mentioned, as long as it's "should", but a "must" is declared out of
scope for a protocol specification. That doesn't seem logical; if
you're in for a "should", then you're in for a "must".
If there is an important security-related protocol event, it seems to
me on technical grounds that it "must" be logged, if at all possible.
If that can't be said in the protocol specification, then it "must" go
somewhere else. If the logging is deemed crucial, then we can discuss
where to put the requirement, I suppose.
I'd thought the group would have interest in whether or not receipt of
an invalid SA identifier (or any similar event) is significant enough
to require logging. I'd thought the reason in favor would be that
anything that seemed to indicate an attempt to explore the valid
security states of the host would probably indicate an attack attempt,
and it would be critically important to notify the administrator, if
at all possible. And I'd thought the argument against would be that
the built-in safeguards are strong enough to render such attempts
feeble and useless.
I can appreciate the reasons for the "should" preference on grounds of
scope, but maybe the requirements for security protocol
implementations "should" be more stringent. Not so stringent as to
constitute denial of solution, but something more than an SEP* nod to
security technology that is not evident on-the-wire.
Hilarie
* Somebody Else's Problem, cit. Douglas Adams
Follow-Ups: