|
Hi Andy, You make a good point.
We intend to add text (see below) that describes this point in the next version of the draft. Please let us know if you have further comments. Here is the updated text on the last paragraph of the security section: This YANG module defines the <cancel-schedule> RPC. This RPC may be considered sensitive or vulnerable in some network environments. Since the value of the
<schedule-id> is known to all the clients that are subscribed to notifications from the server, the <cancel-schedule> RPC may be used maliciously to attack servers by canceling their pending RPCs. This attack is addressed in two layers: (i) security at the
transport layer, limiting the attack only to clients that have successfully initiated a secure session with the server, and (ii) the authorization level required to cancel an RPC should be the same as the level required to schedule it, limiting the attack
only to attackers with an authorization level that is equal to or higher than that of the client that initiated the scheduled RPC. Thanks, Tal. From: Netconf [mailto:netconf-bounces@xxxxxxxx]
On Behalf Of Andy Bierman Hi, I am curious if this is a security concern. When an event is scheduled, the ID and its scheduled time are sent out in a notification to potentially all clients. notification netconf-scheduled-message {
leaf schedule-id {
type string;
description
"The ID of the scheduled message.";
}
leaf scheduled-time {
type yang:date-and-time;
description
"The time at which the RPC is scheduled to be performed.";
}
description
"Indicates that a scheduled message was received.";
reference
"draft-mm-netconf-time-capability:
Time Capability in NETCONF";
}
Any client can get these notifications and know the ID (to cancel it) and the scheduled time. Is is a security issue that any client can get the schedule-id and use it to cancel the scheduled RPC? Andy On Wed, Jul 29, 2015 at 2:15 PM, Olafur Gudmundsson <ogud@xxxxxxxx> wrote: I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready for publication The document is well written. The security considerations are clear and accurate. I would like highlight one omission though. This capability allows an attacker once it has gained access to schedule events in the future even though attackers access has been detected and revoked. Olafur
|