Hi Roman, all, Thank you all for the review and discussion. The new revision is just posted based on the comments, please see the diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-yang-11
Thanks, Bo -----邮件原件----- 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Rob Wilton (rwilton) 发送时间: 2021年4月20日 17:19 收件人: Roman Danyliw <r...@cert.org>; The IESG <i...@ietf.org> 抄送: opsawg@ietf.org; opsawg-cha...@ietf.org; draft-ietf-opsawg-tacacs-y...@ietf.org 主题: Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10: (with DISCUSS and COMMENT) Hi Roman, Thanks for the review. I have chipped in a couple of comments on your discuss concerns below. > -----Original Message----- > From: iesg <iesg-boun...@ietf.org> On Behalf Of Roman Danyliw via > Datatracker > Sent: 19 April 2021 23:08 > To: The IESG <i...@ietf.org> > Cc: opsawg@ietf.org; Joe Clarke (jclarke) <jcla...@cisco.com>; opsawg- > cha...@ietf.org; draft-ietf-opsawg-tacacs-y...@ietf.org > Subject: 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 My understanding is that RFC8907 defines the current TACACS+ protocol as it stands, and that this draft is intended to document the YANG configuration data model that goes alongside RFC8907, and that these two documents act as a starting point for any future TACACS+ work in IETF. > > -- this functionality is advocating for supporting an insecure > approach with proposed standard (rather than informational) status [RW] The proposed standard status really comes from the fact that it is documenting a formal API (i.e., the YANG data model), and that this document should reflect IETF consensus on the data model for how TACACS+ is managed in YANG. I also believe that the intention is that we can build on RFC8907 and this draft to improve the security aspects of the TACACS+ protocol over time and having the base YANG model draft being standards track is probably better to build on. As a side note, a question from the routing ADs came up regarding what the status of documents containing YANG Modules should be (in that case for YANG models documenting experimental RFCs). Perhaps it would help for me to write up some guidelines and to discuss those with the IESG? > > ** 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. [RW] Section 10.5.1 of RFC8907 also states: * TACACS+ clients SHOULD NOT allow servers to be configured without a shared secret key or shared key that is less than 16 characters long. Given that an implementation could use a YANG deviation to allow shorter shared-secrets, I think that having the standard IETF YANG model require shared keys to be at least 16 characters is the right choice. If clients were currently using shared keys of less than 16 characters then they would need to change to longer secrets, but the YANG data model is defining a new API anyway, so a certain amount of migration would be expected anyway. Does this help with your discuss concerns? Regards, Rob > > > ---------------------------------------------------------------------- > 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. > > ** 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”. > > ** 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 > > ** 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]/ > > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
