Security Considerations

[boucadair]

I'm afraid that the following text is to be revised:

None of the readable data nodes in these YANG module are considered sensitive or vulnerable in network environments. The NACM "default-deny-all" extension has not been set for any data nodes defined in these module.

None of the writable data nodes in these YANG modules are considered sensitive or vulnerable in network environments. The NACM "default-deny-write" extension has not been set for any data nodes defined in these modules.

There are several sensitive data node that should be listed. Access to some data by non-authorized parties may reveal internal topologies/etc.

There should be also a note about the "http-listen" use.

[fno2010]

Hi Med, I am not aware of which data nodes are sensitive in this module. If you find any, please point them out. But I am aware that the extended modules (e.g., examples in the appendix) may include sensitive data. Especially, the "data-source" node. So I added a new paragraph [1] to clarify this. Do you think it is enough? [1]: 5a2a40d Thanks, Jensen

…

On Mon, Mar 20, 2023 at 10:06 PM Med ***@***.***> wrote: I'm afraid that the following text is to be revised: None of the readable data nodes in these YANG module are considered sensitive or vulnerable in network environments. The NACM "default-deny-all" extension has not been set for any data nodes defined in these module. None of the writable data nodes in these YANG modules are considered sensitive or vulnerable in network environments. The NACM "default-deny-write" extension has not been set for any data nodes defined in these modules. There are several sensitive data node that should be listed. Access to some data by non-authorized parties may reveal internal topologies/etc. There should be also a note about the "http-listen" use. — Reply to this email directly, view it on GitHub <#33>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCCA5OI7SW6DOU4PSF52DTW5BP7TANCNFSM6AAAAAAWBELDRQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[fno2010]

Hi Jensen, Thanks for drafting that text. I do still that some sensitive data nodes have to be listed. For example, * Access to all authentication-related data nodes should be protected; those that are inherited from other models have already “nacm:default-deny-write” statement, while there is no such protected from the data node that are added in the draft. * Consider the example of “poll-interval”: a misbehaving node can set a very large value that would lead to maintaining stale data. Setting very low values can also be considered as a misbehavior. Cheers, Med

[fno2010]

Hi Med, Sorry for the late reply.

On Tue, May 9, 2023 at 9:39 PM ***@***.***> wrote: Hi Jensen, Thanks for drafting that text. I do still that some sensitive data nodes have to be listed. For example, - Access to all authentication-related data nodes should be protected; those that are inherited from other models have already “nacm:default-deny-write” statement, while there is no such protected from the data node that are added in the draft.

Thanks for the suggestion. I agree. But I think the only authentication-related data nodes explicitly added in the current document are "http-auth-client/user-id" and "https-auth-client/user-id" under "auth-client". The leaf nodes referenced by them have already been protected. Shall the leafrefs themselves be also protected?

- Consider the example of “poll-interval”: a misbehaving node can set a very large value that would lead to maintaining stale data. Setting very low values can also be considered as a misbehavior.

It is a very interesting point. I agree that the range of "poll-interval" should be limited. But the accepted range may depend on the data sources and implementations. It is hard to define a fixed range in the module. Do you have any suggestions about it? Or we just explain this consideration without any concrete solution? Thanks, Jensen

[fno2010]

Hi Jensen, Please see inline. Cheers, Med

Hi Med, Sorry for the late reply. > Hi Jensen, > > Thanks for drafting that text. I do still that some sensitive data nodes have to be listed. For example, > > * Access to all authentication-related data nodes should be protected; those that are inherited from other models have already “nacm:default-deny-write” statement, while there is no such protected from the data node that are added in the draft. Thanks for the suggestion. I agree. But I think the only authentication-related data nodes explicitly added in the current document are "http-auth-client/user-id" and "https-auth-client/user-id" under "auth-client". The leaf nodes referenced by them have already been protected. Shall the leafrefs themselves be also protected?

[Med] I think that is safe that the leafrefs themselves be protected. In addition, we need at least two other actions: (1) remind that imported authentication-related data are adequately protected as per my previous reply. (2) add a warning that given that no “nacm:*” statement is added in the top-level auth container, future augmentations should include those.

> * Consider the example of “poll-interval”: a misbehaving node can set a very large value that would lead to maintaining stale data. Setting very low values can also be considered as a misbehavior. > It is a very interesting point. I agree that the range of "poll-interval" should be limited. But the accepted range may depend on the data sources and implementations. It is hard to define a fixed range in the module. Do you have any suggestions about it? Or we just explain this consideration without any concrete solution?

[Med] We don’t need to define random ranges for this or touch the YANG model. We only need to list the data node in the security considerations with the associated vulnerability. Thanks.

…

Thanks, Jensen

[QiufangMa]

I think there are more nodes that should be considered sensitive, I am trying to use the following text to replace security consideration on OAM draft(-07) starts from paragraph 3, see if that makes sense to you guys, feel free to amend:

There are a number of data nodes defined in these two YANG modules that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes in "ietf-alto" YANG module and their sensitivity/vulnerability:

/alto:alto/alto:alto-client/alto:server-discovery: This subtree specifies a set of parameters for an ALTO client to discover ALTO server. Unauthorized access to it could cause intruders to modify the ALTO discovery parameters(e.g., dns-server) so as to expose an ALTO client to fake ALTO servers.

/alto:alto/alto:alto-server/logging-system: This subtree provides configuration to select a logging system to capture log messages generated by an ALTO server. Unauthorized read access of this node can allow intruders to access logging information, which could be used to craft an attack the server.

/alto:alto/alto:alto-server/auth-client: This list specifies all the authenticated ALTO clients on an ALTO server. Unauthorized write access to this list can allow intruders to modify the entries so as to add a client that have not been authenticated yet or delete a client that has already been authenticated.

/alto:alto/alto:alto-server/role: This list specifies roles which authenticated ALTO clients assigned to for access control. Unauthorized write access to this list can allow intruders to modify the entries so as to permit access that should not be permitted, or deny access that should be permitted.

/alto:alto/alto:alto-server/data-source/feed-interval: This leaf specifies a period for an ALTO server to wait for updates published by the data source. A malicious client could attempt to set a very low/large value to this node. Setting a very low value could attack the data source. And setting a very large value would lead to maintaining stale data in the ALTO server.

/alto:alto/alto:alto-server/data-source/poll-interval:This leaf specifies a period for an ALTO server to proactively poll updates from a data source. A malicious client could attempt to set a very low/
large value to this node. Setting a very low value could attack
the data source. And setting a very large value would lead to
maintaining stale data in the ALTO server.

Please be aware that this module uses grouping from the "ietf-tls-server" module defined in
[I-D.ietf-netconf-tls-client-server]. All of the data nodes defined
in the grouping have the NACM extension "default-deny-write" set,
thus preventing unrestricted write-access to the data nodes defined
in those groupings.

[boucadair]

I think there are more nodes that should be considered sensitive, I am trying to use the following text to replace security consideration on OAM draft(-07) starts from paragraph 3, see if that makes sense to you guys, feel free to amend:

Can you please propose this as a new PR so that we can review it easily? Thanks.

[QiufangMa]

see #68

[boucadair]

Thanks, Qiufang. I submitted my review to #68 right now.