Subject: [OPSAWG] re opsawg-tacacs-yang & ietf-system user-authen-order

From: john heasley <[email-masked]>
Date: Wed, 20 Nov 2019 03:17:45 +0000

Regarding the question, on the second to last page of the opsawg-tacacs-yang
presentation slides, about the must in model ietf-system, which I believe was
whether to add a must for tacacs, remove the must for radius, or do nothing;
that must seems wrong to me.

I would expect the system to react no differently to missing sever
configuration than to a list of servers that all fail to respond.  Some
vendors have done this historically in cli.

Whether ietf-system should be changed, I do not know it is worth the effort.
If the WG agrees that its existence is wrong, that might be another question
for yang doctors.

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 20 Nov 2019 03:53:01 +0000

> On Nov 19, 2019, at 22:17, john heasley <[email-masked]> wrote:
> 

Thanks, heas.  Apparently, Ebben has already been discussing this with the other docs.  I’ve followed up, and I’m trying to get their take on it. Your point is appreciated.  I tend to agree that if I have no servers, I would just fall back (if fallback was configured).

Joe

> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 20 Nov 2019 05:30:29 +0000

On Nov 19, 2019, at 22:17, john heasley <[email-masked]<mailto:[email-masked]>> wrote:

Lada replied on YANG docs with a suggestion for the T+ module authors.  While we can’t affect the authentication-order node, the tacacsplus container could be defined like:

augment "/sys:system" {
 container tacacs {
   must "not(derived-from-or-self("
      + "../sys:authentication/sys:user-authentication-order, 'tacacs')"
      + "or server";
   list server {
      ...
   }
 }
}

In this manner, T+ can provide enforcement.  Lada also mentioned that this would have been a better way of handling RADIUS in ietf-system.  Certainly this could be an item for a .bis, but not sure if this alone is worth taking on that work.

Joe

---

From: john heasley <[email-masked]>
Date: Wed, 20 Nov 2019 08:54:40 +0000

> In this manner, T+ can provide enforcement.  Lada also mentioned that this would have been a better way of handling RADIUS in ietf-system.  Certainly this could be an item for a .bis, but not sure…

That would be an improvement, but I still assert that this constraint is
not necessary nor desired - tacacs nor radius - if I'm reading that
correctly (XPATH often confuses me).

ps. parens imbalanced?

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 20 Nov 2019 09:10:55 +0000

> On Nov 20, 2019, at 03:54, john heasley <[email-masked]> wrote:
> 

This XPath looks at the authentication order list to see if any node in it is “tacacs” (or tacacsplus in what we’d want).  If so, it enforces at least one server to be specified.  So I think you’re reading it right.  I agree, it likely isn’t required.  It does, however, get someone to think about properly configuring T+ if they are going to enable it in the order.  So it’s a nice to have.

> ps. parens imbalanced?

Yeah, yeah :-).  Mac Mail caused some weirdness.  Also, note, this is “pseudo-code” as we will want to use “tacacsplus” instead of just “tacacs”.

Joe