Re: [i2rs] [Last-Call] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
How about adding something like this: Privacy Considerations The Yang model for layer 2 topology exposes privacy sensitive information, for example the MAC addresses of devices. Unrestricted use of such information can lead to privacy violations. For example, listing MAC addresses in a network allows monitoring of devices and their movements. Location information can be derived from MAC addresses of network devices, bypassing protection of location information by the Operating System. Deployments should mitigate this privacy concerns by limiting access to the layer 2 topology information. Access to the information should be restricted to a minimal list of authorized agents, and should require proper authentication of these agents. -- Christian Huitema On 6/25/2020 7:00 AM, Susan Hares wrote: > Qin and Christian: > > Thank you for your prompt attention to the privacy issue. > I'm sure Christian will respond in a bit - since he might be in PDT > time-zone. > > Once you have a solution you both like, we should > validate the privacy changes to the security considerations section with the > Yang-doctors, OPS-ADs, and Security-ADs. > > Martin's watching this thread so I'm sure he'll help us out as well. > > Sue > > -Original Message- > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Qin Wu > Sent: Thursday, June 25, 2020 9:25 AM > To: Susan Hares; 'Christian Huitema'; sec...@ietf.org > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l2-network-topology@ietf.org; > last-c...@ietf.org > Subject: Re: [i2rs] Secdir last call review of > draft-ietf-i2rs-yang-l2-network-topology-13 > > Sue and Christian: > I have responded to Christian on privacy issue, my proposal is to add MAC > address as another data node vulnerability example in our original security > consideration section. > But If Christian or security directorate has recommending text, we authors > are happy to accept it. > > -Qin > -邮件原件- > 发件人: Susan Hares [mailto:sha...@ndzh.com] > 发送时间: 2020年6月25日 21:04 > 收件人: 'Christian Huitema' ; sec...@ietf.org > 抄送: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; i2rs@ietf.org; > last-c...@ietf.org > 主题: RE: Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13 > > Christian: > > Thank you for catching the privacy issues. > > I've got a few questions to help the authors scope this change: > > 1) Since this is common to all L2 Topologies, can you or the security > directorate recommend some text that might be appropriate? >If you have recommended text, has this text been reviewed by OPS-DIR and > Yang doctors? > > 2) Will it be a problem If we write privacy considerations on IEEE > specifications? > 3) Do we need to consider the range of deployments of L2 (home, enterprise, > public PBB service, national PBB service, Data centers) > > > Thank you, Sue > > > -Original Message- > From: Christian Huitema via Datatracker [mailto:nore...@ietf.org] > Sent: Thursday, June 25, 2020 1:01 AM > To: sec...@ietf.org > Cc: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; i2rs@ietf.org; > last-c...@ietf.org > Subject: 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. > > 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. > > 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
Re: [i2rs] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
Sue and Christian: I have responded to Christian on privacy issue, my proposal is to add MAC address as another data node vulnerability example in our original security consideration section. But If Christian or security directorate has recommending text, we authors are happy to accept it. -Qin -邮件原件- 发件人: Susan Hares [mailto:sha...@ndzh.com] 发送时间: 2020年6月25日 21:04 收件人: 'Christian Huitema' ; sec...@ietf.org 抄送: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; i2rs@ietf.org; last-c...@ietf.org 主题: RE: Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13 Christian: Thank you for catching the privacy issues. I've got a few questions to help the authors scope this change: 1) Since this is common to all L2 Topologies, can you or the security directorate recommend some text that might be appropriate? If you have recommended text, has this text been reviewed by OPS-DIR and Yang doctors? 2) Will it be a problem If we write privacy considerations on IEEE specifications? 3) Do we need to consider the range of deployments of L2 (home, enterprise, public PBB service, national PBB service, Data centers) Thank you, Sue -Original Message- From: Christian Huitema via Datatracker [mailto:nore...@ietf.org] Sent: Thursday, June 25, 2020 1:01 AM To: sec...@ietf.org Cc: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; i2rs@ietf.org; last-c...@ietf.org Subject: 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. 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. 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. 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. ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
Hi, Christian: Thanks for valuable comments, please see reply inline. -邮件原件- 发件人: Christian Huitema via Datatracker [mailto:nore...@ietf.org] 发送时间: 2020年6月25日 13:01 收件人: sec...@ietf.org 抄送: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; i2rs@ietf.org; last-c...@ietf.org 主题: 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 i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
Christian: Thank you for catching the privacy issues. I've got a few questions to help the authors scope this change: 1) Since this is common to all L2 Topologies, can you or the security directorate recommend some text that might be appropriate? If you have recommended text, has this text been reviewed by OPS-DIR and Yang doctors? 2) Will it be a problem If we write privacy considerations on IEEE specifications? 3) Do we need to consider the range of deployments of L2 (home, enterprise, public PBB service, national PBB service, Data centers) Thank you, Sue -Original Message- From: Christian Huitema via Datatracker [mailto:nore...@ietf.org] Sent: Thursday, June 25, 2020 1:01 AM To: sec...@ietf.org Cc: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; i2rs@ietf.org; last-c...@ietf.org Subject: 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. 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. 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. 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. ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] Yangdoctors last call review of draft-ietf-i2rs-yang-l2-network-topology-13
Hi Lada, Thank you for the review. We have already fixed the first two comments in our local copy. We updated the text to fix the two remaining ones: FWIW, the updated text can be seen at: https://github.com/boucadair/draft-ietf-i2rs-yang-l2-network-topology/blob/master/draft-ietf-i2rs-yang-l2-network-topology-14.txt diff: https://github.com/boucadair/draft-ietf-i2rs-yang-l2-network-topology/blob/master/diff-IETF-LC.pdf Cheers, Med > -Message d'origine- > De : Ladislav Lhotka via Datatracker [mailto:nore...@ietf.org] > Envoyé : mardi 23 juin 2020 15:52 > À : yang-doct...@ietf.org > Cc : last-c...@ietf.org; draft-ietf-i2rs-yang-l2-network- > topology@ietf.org; i2rs@ietf.org > Objet : Yangdoctors last call review of draft-ietf-i2rs-yang-l2-network- > topology-13 > > Reviewer: Ladislav Lhotka > Review result: Ready with Nits > > I already reviewed revision -04 of this document with the conclusion that > from > YANG point of view it is ready to be published. It is still the case with > the > current revision -13. All my earlier comments have been addressed. > > I appreciate the example in Appendix B, it is really useful. However, I > discovered several problems with the JSON instance data: > > - In all 6 entries of the "ietf-network-topology:link" list, commas are > missing > after the "source" object. > > - The identifier "ietf-l2-topology:l2-termination-point-attributes" is > split > between two lines (7 times), which makes it invalid. While this is > explained in > the introductory text, I would suggest to find another way of satisfying > the 72 > character limit that doesn't affect the instance data validity. One option > is > to use the convention of draft-ietf-netmod-artwork-folding-12, but it is > also > possible to simply dedent the offending lines. > > - According to the rules of RFC 7951, the identifier of "termination-point" > list needs to be qualified with module name, i.e. > "ietf-network-topology:termination-point". > > - The format of "mac-address" leaves doesn't match the regex pattern of > their > types: semicolons rather than dashes have to be used as octet separators. > _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
