> -----Original Message-----
> From: iesg <iesg-boun...@ietf.org> On Behalf Of Joe Clarke (jclarke)
> Sent: 20 April 2021 18:57
> To: Alan DeKok <al...@deployingradius.com>
> Cc: Roman Danyliw <r...@cert.org>; Joe Clarke (jclarke)
> <jclarke=40cisco....@dmarc.ietf.org>; draft-ietf-opsawg-tacacs-
> y...@ietf.org; opsawg-cha...@ietf.org; The IESG <i...@ietf.org>; Wubo
> (lana) <lana.w...@huawei.com>; opsawg@ietf.org
> Subject: Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-
> yang-10: (with DISCUSS and COMMENT)
>
> On 4/20/21 13:36, Alan DeKok wrote:
> > On Apr 20, 2021, at 12:02 PM, Joe Clarke (jclarke) <jcla...@cisco.com>
> wrote:
> >> 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).
> > 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.
>
> 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.
>
> >
> >> 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?
> > 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."
> ...
> }
[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
>
> Joe
>
> >
> > Alan DeKok.
> >
> >
>
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
