Dear Christian, Thank you for the review, the authors have updated the document to address your comments and posted the updated document as draft-ietf-ccamp-layer1-types-17. Your suggestions for improvements of the Security Considerations section are understood and we are grateful. We have added some additional clarification text and plan to discuss the more general optical security best practice guide that would also apply to this document, and several other CCAMP WG documents currently being worked on. This advice could be documented in a new I-D, or on a CCAMP Wiki. If ok, we may follow-up with you on this specific guidance. Again, thanks for the support and review. Authors, Haomian and Italo. > -----Original Message----- > From: Christian Huitema via Datatracker <noreply@xxxxxxxx> > Sent: lunedì 13 novembre 2023 04:19 > To: secdir@xxxxxxxx > Cc: ccamp@xxxxxxxx; draft-ietf-ccamp-layer1-types.all@xxxxxxxx; last- > call@xxxxxxxx > Subject: [CCAMP] Secdir last call review of draft-ietf-ccamp-layer1-types-16 > > Reviewer: Christian Huitema > Review result: Ready > > 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. > > The summary of the review is 'Ready'. > > draft-ietf-ccamp-layer1-types specifies a YANG module for describing the > common data types, groupings and identities for use in YANG [RFC7950] > data models of Layer 1 networks, such as for example Optical Transport > Networking. > > The security section asserts that potential security issues do not derived > from the particulars of the Yang modules, but from potential unauthorized > access to the data and unauthorized modification of the data. Access is > expected to be protected using either SSH for NETCONF or HTTPS for > RESTCONF, as per standard practice. I would not expect a Yang module to > state anything else. > > I do not have enough expertise in Optical Transport Networking and other > Layer > 1 networks to evaluate the details of the specification. I assume that other > reviewers will conduct such specialized review. > > And now, a side remark, not related to this specific document but applying > to the general practice of saying "just use NETCONF with SSH or RESTCONF > with TLS", but SSH and HTTPS support a variety of authentication > mechanisms. SSH, for example, can authenticate a client using a public key, a > password, a host identity, or even nothing. HTTPS has a similar range of > options. Some of those options are much more vulnerable than others -- > password based authentication, for example, is vulnerable to phishing > attacks and password reuse. > > The NETCONF and RESTCONF specifications leave the choice of > authentication to the organization deploying the Yang based management, > with statements like "the identity of the SSH client MUST also be verified and > authenticated by the SSH server according to local policy". I did not find a > specification of what the local policy should be. It would be nice if the safety > of network infrastructure could not be defeated by a password-based attack, > or other simple attacks. It might be useful to do some work here, and > provide practical guidance on the deployment of strong authentication > mechanisms. > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
