Re: Issue 9.1) DoS attack using global <lock>

[Andy Bierman <abierman@cisco.com>]

At 08:40 AM 12/5/2003, Eliot Lear wrote:
>Andy,
>
>Obviously 9.1 and 9.2 are related.  So long as we note this in the security considerations, because the individual who is screwing up the lock is authenticated, I'm not even sure we need a <steal-lock> command to get around it.

I agree with you.
The premise of the <steal-lock> operation is that an authenticated
attacker would be able to detect that his session was terminated
by another user, reestablish a new session, and issue another <lock>
operation, all before the user that issued the <kill-session>
operation could request a new <lock> operation.  

The <steal-lock> operation could be accomplished with a <kill-session>, 
followed by a <lock>.  IMO, this is sufficient.  We could add <steal-lock> 
in a future version if operational experience shows this particular
attack to be a problem.  It seems to me that a malicious user could
do much more damage by changing the running config than by simply
grabbing a lock and holding it.

Andy



>Andy Bierman wrote:
>
>>A DoS attack is possible if global lock allows users to lock more of the config dB than they have write access. Choose one of:
>>  - Only users with all-access can lock the dB
>>  - Only grant lock for areas that write-access is allowed
>>  - Support partial locks
>>  - Simply document the problem in the security section
>>
>>--
>>to unsubscribe send a message to netconf-request@ops.ietf.org with
>>the word 'unsubscribe' in a single line as the message text body.
>>archive: <http://ops.ietf.org/lists/netconf/>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>