Subject: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 19 Apr 2021 15:08:18 -0700

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.

** 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]/

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 20 Apr 2021 09:18:38 +0000

Hi Roman,

Thanks for the review.   I have chipped in a couple of comments on your discuss concerns below.

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Roman Danyliw via
> Datatracker
> Sent: 19 April 2021 23:08
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Joe Clarke (jclarke) <[email-masked]>; opsawg-
> [email-masked]; [email-masked]
> Subject: Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10:
> (with DISCUSS and COMMENT)
> 

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.

> 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?

> 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