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

From: "Wubo (lana)" <[email-masked]>
Date: Tue, 20 Apr 2021 13:18:31 +0000

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:[email-masked]] 
发送时间: 2021年4月20日 6:08
收件人: The IESG <[email-masked]>
抄送: [email-masked]; [email-masked]; [email-masked]; Joe Clarke <[email-masked]>; [email-masked]
主题: 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.

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 20 Apr 2021 13:29:25 +0000

> [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.  T…

Today, we only have the obfuscation-by-shared-secret.  In the future, we
may have TLS or some other stronger encryption.  If we insist on making
the module forward-looking, should we rename this something like privacy
(similar to how SNMPv3 names this)?  I agree with Roman that encryption
is a bit strong of an umbrella under which to put shared-secret.

Joe

---

From: Alan DeKok <[email-masked]>
Date: Tue, 20 Apr 2021 09:42:47 -0400

> is a bit strong of an umbrella under which to put shared-secret.

  There was a long discussion in OPSAWF about this for the main TACACS document (RFC 8907).  That document says:

4.5.  Data Obfuscation

   The body of packets may be obfuscated.  The following sections
   describe the obfuscation method that is supported in the protocol.
   In "The Draft", this process was actually referred to as Encryption,
   but the algorithm would not meet modern standards and so will not be
   termed as encryption in this document.

...

  It would be prudent for the Yang model document to use the same terminology as RFC 8907.

  Alan DeKok.

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 20 Apr 2021 16:02:11 +0000

>   It would be prudent for the Yang model document to use the same terminology as RFC 8907.

Agreed on the point that the current payload is obfuscated.  The choice
element in the YANG module seems to want to be future-proof, too, such
that when true encryption is added, it could be augmented in as another
choice (instead of shared-secret obfuscation).  Therefore, my attempt
was to create a unifying term for both.  I wouldn't call the choice
obfuscation as that would not be true in a TLS world.  But that is
work-to-be-done.  I also wouldn't call it encryption as you and Roman
point out.  I didn't really like the combination encryption-obfuscation,
either.

If a single term was used for the choice and obfuscation was called out
in the description of the shared-secret leaf, would that be sufficient?

Joe

---

From: Alan DeKok <[email-masked]>
Date: Tue, 20 Apr 2021 13:36:30 -0400

On Apr 20, 2021, at 12:02 PM, Joe Clarke (jclarke) <[email-masked]> wrote:
> choice (instead of shared-secret obfuscation).

  We can't use this field for TLS, as TLS PSK has been deprecated in TLS 1.3 (outside of resumption).

  Would we want to use the same "key" field for a 1997-era ad hoc obfuscation as for (say) AES?  That suggests to me that failure modes are (a) using simple ASCII words for AES keys, or (b) using AES keys with 1997-era obfuscation.

  Either failure mode is worrying.

> in the description of the shared-secret leaf, would that be sufficient?

  I would lean towards to leaving this as "obfuscation".  And, suggesting that any newer security methods use entirely different fields in the YANG model.

  Alan DeKok.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Apr 2021 10:39:36 -0700

>   We can't use this field for TLS, as TLS PSK has been deprecated in TLS 1.3 (outside of resumption).

Reference?
External PSK is still a thing, and we even published RFC 8773 to expand its
use cases.

-Ben

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 20 Apr 2021 17:56:41 +0000

>   Either failure mode is worrying.

The idea is that when encryption is available, that would be another
choice option (a new leaf or container augmented in), and
"shared-secret" would not be used at all in that case.  That is, while
the "choice" is mandatory, you must make a choice and cannot use both
shared-secret and whatever else may be added to this choice.

>   I would lean towards to leaving this as "obfuscation".  And, suggesting that any newer security methods use entirely different fields in the YANG model.

Except that when encryption is added to T+, one would want to
rev/augment this module.  To do so in a backwards compatible way, one
might deprecate this choice altogether, but it would still be
"mandatory".  So the logical thing to do is still add an augmentation to
offer an alternative to shared-secret (maybe called "leaf tls" or
"container tls { ...}").  Now you have a value for the "obfuscation"
choice as "tls", which is not obfuscation and could lead to its own set
of confusion (i.e., am I really configuring true encryption?).

So I am proposing changing the choice name to some general term (I
proposed "privacy") and add this text (or the like) to the description
of the shared-secret leaf:

"Note: use of the shared-secret does not provide true privacy.  It is
instead obfuscating the TACACS+ packet payload."

My second choice would be, as Bo suggested, rename the choice to
"encryption-or-obfuscation" and change the description accordingly.  So,
it would look like:

choice encryption-or-obfuscation {
  mandatory true;
  description
    "Encryption or obfuscation mechanism to employ between TACACS+
client and server.";
   case shared-secret {
     leaf shared-secret {
       ...
       description
         "...Note: use of the shared-secret does not provide
encryption.  It is instead obfuscating the TACACS+ packet payload."
...
}

Joe

---

From: Alan DeKok <[email-masked]>
Date: Tue, 20 Apr 2021 13:58:18 -0400

> External PSK is still a thing, and we even published RFC 8773 to expand its

  That was my understanding from discussion on EMU about EAP-TLS.  If that's wrong for TLS in general, OK.

  I don't think it substantially changes my argument against using the same "key" field for "obfuscation" and real "encryption" is perhaps not ideal.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 20 Apr 2021 14:05:02 -0400

On Apr 20, 2021, at 1:56 PM, Joe Clarke (jclarke) <[email-masked]> wrote:
> ...  That is, while

  When we did this for RADIUS over TLS, we made the "legacy" RADIUS portion use a fixed key for backwards compatibility.  The TLS portion was then new, and completely different from the legacy obfuscation.

  i.e. when using RADIUS over TLS, there isn't even a choice of using a "shared secret".  Any GUI / config option must either omit it, or ignore it.  Instead, it uses the pre-defined fixed key.

> of confusion (i.e., am I really configuring true encryption?).

  Not being overly familiar with YANG, I won't disagree with anything on how YANG should or should not work.

  If there's a choice about what to do, perhaps it could instead just use a generic "key" to describe the shared secret / key field.  And then another field which describes what kind of encryption or obfuscation to use.  For now, only one value could be defined: obfuscation.  Future standards could add other methods.

  Having an "encryption type" setting being an "enum" style field of obfuscation OR encryption would resolve my concerns.

  Alan DeKok.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 22 Apr 2021 10:07:02 +0000

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Joe Clarke (jclarke)
> Sent: 20 April 2021 18:57
> To: Alan DeKok <[email-masked]>
> Cc: Roman Danyliw <[email-masked]>; Joe Clarke (jclarke)
> <jclarke=[email-masked]>; draft-ietf-opsawg-tacacs-
> [email-masked]; [email-masked]; The IESG <[email-masked]>; Wubo
> (lana) <[email-masked]>; [email-masked]
> Subject: Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-
> yang-10: (with DISCUSS and COMMENT)
> 
> >   Would we want to use the same "key" field for a 1997-era ad hoc
> obfuscation as for (say) AES?  That suggests to me that failure modes are
> (a) using simple ASCII words for AES keys, or (b) using AES keys with
> 1997-era obfuscation.
> >
> >   I would lean towards to leaving this as "obfuscation".  And,
> suggesting that any newer security methods use entirely different fields
> in the YANG model.
> 
[RW] 

Perhaps "security" could be a more generic name for the choice statement?  However, it is worth noting that I suggested adding the choice statement in my AD review with the specific aim to make the YANG model easier to extend the model with alternative security schemes in future.  If it looks like having that choice statement will make extending it harder then I have no objections to be it being removed, and just going back to a "shared-secret" leaf.

Regards,
Rob

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 22 Apr 2021 13:00:35 +0000

> Perhaps "security" could be a more generic name for the choice statement?  However, it is worth noting that I suggested adding the choice statement in my AD review with the specific aim to make the…

As another alternative (given Alan's comments), we could go back to a
leaf and add some identities (i.e., one for obfuscation).  Of course,
the base identity would need a name (security could be that name). 
Then, a new leaf could be introduced to indicate security type and
shared-secret uses a "when" to be in use when the type is obfuscation.

Of course, this is just more complexity that essentially has the same
taxonomy issues.  (As a contributor) I like having a somewhat
easier-to-extend module, so I would be in favor of leaving the choice,
calling it "security" and adding some text to the shared-secret
description that this is obfuscation.  However, if the WG feels strongly
that this is not clear enough, we can go back to a straight leaf as you say.

Joe