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

From: "Wubo (lana)" <[email-masked]>
Date: Wed, 20 Nov 2019 06:09:02 +0000

Hi Joe,

Thanks for the suggestion and also the guidance from Lada and other YANG doctors.

With this ‘ietf-system-tacacsplus’ module level ‘must-statement’, rather than the system level, I will update the TACACS+ YANG draft in next release.

Thanks,
Bo

发件人: Joe Clarke (jclarke) [mailto:[email-masked]]
发送时间: 2019年11月20日 13:30
收件人: john heasley <[email-masked]>; Wubo (lana) <[email-masked]>
抄送: opsawg <[email-masked]>
主题: Re: [OPSAWG] re opsawg-tacacs-yang & ietf-system user-authen-order

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

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.

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