Subject: Re: [OPSAWG] New Version Notification for draft-zheng-opsawg-tacacs-yang-01.txt

From: "Wubo (lana)" <[email-masked]>
Date: Fri, 15 Mar 2019 08:48:37 +0000

Dear WG,

We uploaded the 01 version of draft-zheng-opsawg-tacacs-yang-01 to address some comments since last meeting.
https://tools.ietf.org/html/draft-zheng-opsawg-tacacs-yang-01

Here are some major changes in this version:
-  Align the tacacs  YANG structure to system(RFC 7317) Radius client YANG naming.
-  Change major tacacs properties to be configurable for each tacacs-server.
- Add the authorization and accounting model as a system augmentation to support the full AAA configuration.

Please review the document, comments and suggestions are welcome!

Thanks, 
Bo

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2019年3月11日 11:11
收件人: wangzitao <[email-masked]>; Wubo (lana) <[email-masked]>; Zhengguangying (Walker) <[email-masked]>; Wubo (lana) <[email-masked]>; wangzitao <[email-masked]>
主题: New Version Notification for draft-zheng-opsawg-tacacs-yang-01.txt

A new version of I-D, draft-zheng-opsawg-tacacs-yang-01.txt
has been successfully submitted by Bo Wu and posted to the IETF repository.

Name:		draft-zheng-opsawg-tacacs-yang
Revision:	01
Title:		Yang data model for Terminal Access Controller Access Control System Plus
Document date:	2019-03-10
Group:		Individual Submission
Pages:		19
URL:            https://www.ietf.org/internet-drafts/draft-zheng-opsawg-tacacs-yang-01.txt
Status:         https://datatracker.ietf.org/doc/draft-zheng-opsawg-tacacs-yang/
Htmlized:       https://tools.ietf.org/html/draft-zheng-opsawg-tacacs-yang-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-zheng-opsawg-tacacs-yang
Diff:           https://www.ietf.org/rfcdiff?url2=draft-zheng-opsawg-tacacs-yang-01

Abstract:
   This document defines two YANG modules that augment the System data
   model defined in the [RFC 7317] with TACACS+ client model and
   additional AAA model.  The data model of Terminal Access Controller
   Access Control System Plus (TACACS+) client allows the configuration
   of TACACS+ servers for centralized Authentication, Authorization and
   Accouting.  While the current system model only supports
   authentication configuration, the additional AAA model allows system
   authorization and accouting configuration.

   The YANG modules in this document conforms to the Network Management
   Datastore Architecture (NMDA) defined in [RFC8342].

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Alan DeKok <[email-masked]>
Date: Fri, 15 Mar 2019 08:42:42 -0400

> - Add the authorization and accounting model as a system augmentation to support the full AAA configuration.

  Please don't refer to TACACS+ as an AAA protocol.  It's really not.  It's a management protocol, and doesn't do generic user AAA.

  Using "AAA" here is just confusing, IMHO.  e.g.:

   Additionally, to support full AAA feature, the "ietf-aaa" YANG module

  The document later refers to "ietf-aaa-tacacs", not "ietf-aaa".  I would strongly suggest changing the name of the model to "ietf-tacacs".

  Similarly:

   module: ietf-system-aaa

  Please change this to ietf-system-tacacs.

  I don't see it as at all useful to re-define "AAA" to mean "TACACS" here.  AAA has a well-defined meaning, which doesn't include TACACS.  

  Alan DeKok.

---

From: Alex Campbell <[email-masked]>
Date: Sun, 17 Mar 2019 21:30:12 +0000

Are you sure about that? I don't see anything specific to TACACS+ in ietf-system-aaa.yang.

I did notice some issues and nits while reading the document:
* "accouting" should be spelled "accounting"
* "attribuets" should be spelled "attributes"
* TACACS should be TACACS+. TACACS is an older protocol which is not compatible with TACACS+.
* ietf-system already has a local-users identity. Are you proposing to deprecate this in favour of the one defined in ietf-system-aaa?
* I don't understand the purpose of /system/authorization/events and /system/accounting/events - even with the text in section 4.1 and 4.2.

Regards, Alex
________________________________________
From: OPSAWG <[email-masked]> on behalf of Alan DeKok <[email-masked]>
Sent: Saturday, 16 March 2019 1:42 a.m.
To: Wubo (lana)
Cc: [email-masked]
Subject: Re: [OPSAWG] New Version Notification for draft-zheng-opsawg-tacacs-yang-01.txt

  Similarly:

   module: ietf-system-aaa

  Alan DeKok.

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

---

From: Alan DeKok <[email-masked]>
Date: Sun, 17 Mar 2019 18:17:20 -0400

> Are you sure about that? I don't see anything specific to TACACS+ in ietf-system-aaa.yang.

  That's not the point.

  Is this a TACACS+ YANG model, or is this a AAA YANG model?

  If it's a AAA YANG data model, then there are already two AAA working groups which haven't been consulted about this work. The aaa-doctors group hasn't been consulted, either.  There are still people working in this space who might have input here.

  There is already a RADIUS YANG module, which seems relevant.  It was done without consulting the RADEXT WG, either, or the aaa-doctors list.  It also doesn't match RFC 5080 for retransmissions, and doesn't allow for non-UDP transports, despite RFC 6613 (TCP), RFC 6614 (TLS), and RFC 7630 (DTLS).  But that's a separate point.

  IMHO, this document should focus on the TACACS+ needs, and define a YANG data model for TACACS+.  It should *not* define a generic AAA YANG data model.   It should *especially* not define a generic IETF AAA YANG data model in a document that's mixed up with a non-AAA protocol.

  As for "nothing specific to TACACS+", please see the text in the abstract:

   The data model of Terminal Access Controller
   Access Control System Plus (TACACS+) client allows the configuration
   of TACACS+ servers for centralized Authentication, Authorization and
   Accouting. 

  TACACS+ is not an AAA protocol.  We're had this discussion going back years.

  If we look at the document further, we see:

...
4.  AAA Model Augmentation

   This document augments the system model with authorization model and
   accouting model to support full AAA feature.
...

  So it's not augmenting the AAA model as the title suggests.  It's adding an entirely new AAA model to the ietf-system model.  So that's confusing.

  It continues with the next paragraph:

...
   For the authentication model, if the NETCONF server advertises the
   "tacacs" feature, the device also supports user authentication using
   TACACSPLUS.  For NETCONF transport protocols that support password
   authentication, the leaf-list "user-authentication-order" is used to
   control if TACACSPLUS password authentication should be used.
...

  So the only *example*  of the ietf-aaa model is TACACS+.  The document continues with:

...
   For the authorization model and accouting model, the extended AAA
   data model has the following structure:
...

  OK, so there's nothing *specifically* about TACACS+ in the YANG diagram.  That part is at least true.

  But to address your first sentence quoted way above, the next section is:

...
4.1.  User Authorization Model

   Following authentication, a user must gain authorization for doing
   certain tasks.  For instance, the user may try to issue commands.
   The authorization process determines whether the user has the
   authority to issue such commands.

   This document defines two optional authorization YANG features:
   "local-users" and "tacacs",
...

  Which entirely contradicts the claim that there's nothing TACACS+ specific in the model.

  In fact, the model *explicitly discusses* "ietf-aaa" as being (a) local users, or (b) TACACS+.  There are *zero* provisions for the the model more generic, e.g. to include RADIUS.

  I don't even know why we're having this argument.  The document is absolutely clear that "ietf-aaa" is for TACACS+, and not for any of the *actual* AAA protocols that we've been using for 30 years.  The document goes so far as to omit those other protocols entirely from consideration.

  Again, if this document is for TACACS+, it should define a TACACS+ YANG model and let it be.  If there's a need for a more generic ietf-system-aaa YANG model, then perhaps we should discuss that with the AAA people.  And if we want to really push the envelope, provide for those AAA protocols in the ietf-system-aaa YANG model.

  Alan DeKok.