Hi, Christian:
Thanks for valuable comments, please see reply inline.
-----邮件原件-----
发件人: Christian Huitema via Datatracker [mailto:[email protected]]
发送时间: 2020年6月25日 13:01
收件人: [email protected]
抄送: [email protected]; [email protected];
[email protected]
主题: Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
Reviewer: Christian Huitema
Review result: Has Issues
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 with the intent of improving security requirements and
considerations in IETF drafts. Comments not addressed in last call may be
included in AD reviews during the IESG review. Document editors and WG chairs
should treat these comments just like any other last call comments.
This document describes a Yang model for representing Link Layer topologies.
Representing such topologies is obviously useful for managing network.
The security section is focused on securing the usage of this information for
network management, but does not address potential privacy issues.
[Qin]: My understanding privacy issue can be addressed by using NACM. NACM
provide client authorization and restrict particular users to get access to a
preconfigured subset of all
available NETCONF or RESTCONF protocol operations and content.
The security considerations explain correctly how altering the link layer
information could enable attacks against the network. The proposed remedy is
access control, implemented using either SSH or TLS. This is fine, although the
discussion of TLS authorisation is a bit short. By default, TLS verifies the
identity of the server but not that of the client. RFC8040 section 2.5
specifies that "a RESTCONF server SHOULD require authentication based on TLS
client certificates. I assume that's the intent, but it might be useful to say
so.
[Qin]: Good observation on RESTCONF (RFC8040), Similarly, NETCONF (RFC6241)
stipulates that "NETCONF connections MUST be authenticated. The transport
protocol is
responsible for authentication of the server to the client and
authentication of the client to the server." TLS is one example of such
transport protocol. So it is the job of Transport protocol to provide mutual
authentication. Please refer to section 2.2 of RFC6241.
I am not sure we should emphasize mutual authentication using underlying
transport protocol in this document, since both RESTCONF and NETCONF has
already clarified client authentication and server authentication.
Let me know if you think I am wrong.
On the other hand, the security considerations do not describe privacy issues,
and I find that problematic. The proposed information model lists a number of
sensitive data, such as for example the MAC addresses of devices.
This information can be misused. For example, applications could assess device
location fetching the MAC addresses of local gateways. Third parties could
access link local information to gather identities of devices accessing a
particular network. Such information is often protected by privacy API in the
Operating System, but accessing the Yang module over the network might allow
applications to bypass these controls.
[Qin]: I think this is a valid point, in my thinking, we could add MAC address
as another sensitive data node examples under l2-node-attributes and
l2-termination-points-attributes.
Please note that we follow YANG security guideline template as follows:
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
Client authentication alone does not necessarily protect against these privacy
leaks. A classic configuration error would limit write access to authorized
users, but to allow read-only access to most users. This kind of error would
allow privacy leaks. Given the sensitive nature of MAC addresses and other
identifiers, it is useful to warn against such errors.
[Qin]:I agree client authentication alone doesn't protect against the privacy
leak but NACM does since it provides client authorization and restrict various
different use to get access to operation and contents.
If I am wrong, I would like to solicit opinion from NETMOD mailing list.
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
