Hi Roman, Thanks you for your review. For the discussion part, please see Rob's reply. On your comment part, please see inline.
-----邮件原件----- 发件人: Roman Danyliw via Datatracker [mailto:nore...@ietf.org] 发送时间: 2021年4月20日 6:08 收件人: The IESG <i...@ietf.org> 抄送: draft-ietf-opsawg-tacacs-y...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org; Joe Clarke <jcla...@cisco.com>; jcla...@cisco.com 主题: Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10: (with DISCUSS and COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-opsawg-tacacs-yang-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** RFC8907 was published with informational status and it contained substantial caution in its security considerations that the protocol was fundamentally insecure and would not “meet modern-day requirements.” This measured approach was taken to provide a stable description of a widely deployed protocol and to serve as the basis for future improvements. The context for this follow-on, seemingly related work does not track the situation around RFC8907 (as I remember it). Specifically: -- this functionality is new, and is not documenting the “as is” deployed state -- this functionality is advocating for supporting an insecure approach with proposed standard (rather than informational) status ** Is this document intentionally breaking backward compatibility on the “shared-secret” size specified in RFC8907? (a) Section 4. case shared-secret { leaf shared-secret { type string { length "16..max"; } (b) Section 10.5.1 of RFC8907 says “TACACS+ server administrators SHOULD configure secret keys of a minimum of 16 characters in length.” As (b) is not a MUST (a “secret key” shorter than 16 is possible), it would appear that (a) breaks compatibility. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Yaron Sheffer for the SECDIR review, and for the changes in response. ** Section 1. Per “The System Management Model is augmented with TACACS+ YANG module … as an alternative to … local user configuration”, is “local user configuration” that same as the “user authentication model” noted earlier in the text? If so, it would be helpful to make that clearer. [Bo]: Thanks the comments. We will remove " or local user configuration " to make this clear. Since TACACS+ is another centralized authentication. About the question, "local user configuration” is not same as the “user authentication model”, because "user authentication model” of RFC 7317 defines both local user authentication and Radius authentication. ** Section 4. choice encryption. Per the name of this YANG item and the description (“Encryption mechanism between TACACS+ client and server”), please follow the convention of Section 4.5 of RFC8907 of calling this “obfuscation”. [Bo]: The reason we define this "encryption" choice is that shared-secret leaf is mandatory per RFC8907, but future TACACS+ protocol may define encryption node to replace the shared-secret leaf. Therefore, is it clearer to change "encryption" to " obfuscation-encryption"? ** Section 5. /system/tacacsplus/server: This list contains the data nodes used to control the TACACS+ servers used by the device. Unauthorized access to this list could cause a complete control over the device by pointing to a compromised TACACS+ server. Additional, outcomes also seem to be that modification of the counters could be used to hide attacks against the client [Bo] Thanks. We will add this risk. ** Additional nits: -- Section 4. Nit. s/TACAS server is providing/TACAS+ server is providing/ -- Section 5. Wrong Section. s/see Section 9 of TACACS+ Protocol [RFC8907]/ see Section 10 of TACACS+ Protocol [RFC8907]/ [Bo] Thanks. We will fix this. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
