Subject: [OPSAWG] TACACS+ New Version with AI extensions for playing Go.

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Sun, 7 Feb 2016 21:47:19 +0000

Š Apologies, just an attention grabbing headline. No specific AI support
has been added to T+ protocol to help play go, but the new version has
been uploaded with corrections after first round of comments. TACACS+
still restricted to plain AAA at this time!

The author collective would be grateful for any further feedback.

Many thanks!

On 16/12/2015 13:34, "OPSAWG on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>Send OPSAWG mailing list submissions to
>	[email-masked]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://www.ietf.org/mailman/listinfo/opsawg
>or, via email, send a message with subject or body 'help' to
>	[email-masked]
>
>You can reach the person managing the list at
>	[email-masked]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of OPSAWG digest..."
>
>
>Today's Topics:
>
>   1.  I-D Action: draft-ietf-opsawg-tacacs-00.txt
>      ([email-masked])
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 16 Dec 2015 05:34:08 -0800
>From: [email-masked]
>To: <[email-masked]>
>Cc: [email-masked]
>Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-00.txt
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset="utf-8"
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the Operations and Management Area Working
>Group Working Group of the IETF.
>
>        Title           : The TACACS+ Protocol
>        Authors         : Thorsten Dahm
>                          Andrej Ota
>                          Douglas C. Medway Gash
>                          David Carrel
>                          Lol Grant
>	Filename        : draft-ietf-opsawg-tacacs-00.txt
>	Pages           : 36
>	Date            : 2015-12-16
>
>Abstract:
>   TACACS+ provides access control for routers, network access servers
>   and other networked computing devices via one or more centralized
>   servers.  TACACS+ provides separate authentication, authorization and
>   accounting services.  This document describes the protocol that is
>   used by TACACS+.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-00
>
>
>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.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>OPSAWG mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/opsawg
>
>
>------------------------------
>
>End of OPSAWG Digest, Vol 103, Issue 11
>***************************************

---

From: Warren Kumari <[email-masked]>
Date: Tue, 09 Feb 2016 21:01:20 +0000

On Sun, Feb 7, 2016 at 1:47 PM Douglas Gash (dcmgash) <[email-masked]>
wrote:

> has been added to T+ protocol to help play go,

... but, some AI support may have been added for other purposes -- and the
only way you'll know for sure is if you go read the draft.

> but the new version has

As would the chairs... and I'm assuming any security conscious network
engineer.
Please review and provide feedback...

W

---

From: Alan DeKok <[email-masked]>
Date: Wed, 10 Feb 2016 15:31:47 -0500

On Feb 9, 2016, at 4:01 PM, Warren Kumari <[email-masked]> wrote:
> As would the chairs... and I'm assuming any security conscious network engineer.

  I have a number of comments.  The main question is how, exactly this document became adopted as a WG document.  I've gone through my inbox and the web archive, and I don't see any call for WG adoption.  Just a notice that the document was accepted as a WG document.

  I have *major* problems with the document as an IETF standard.  We already have two AAA IETF protocols.  Standardizing a third one is, in my opinion, entirely outside of the purview of OPSAWG.

  There are a host of procedural problems with how the document was adopted.  I suggest that the document be withdrawn, and re-submitted as an individual draft.

  Alan DeKok.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 10 Feb 2016 20:40:11 +0000

On 2/10/16, 15:31 , "OPSAWG on behalf of Alan DeKok"
<[email-masked] on behalf of [email-masked]> wrote:

>...
>  I have *major* problems with the document as an IETF standard.  We
>already have two AAA IETF protocols.  Standardizing a third one is, in my
>opinion, entirely outside of the purview of OPSAWG.

You have a point - but TACACS is a reality that isn’t going away. Thus
specifying how to use it/interoperate with it seems useful.

>I suggest that the document be withdrawn, and re-submitted as an
>individual draft.

No strong opinion here, but I’m not quite convinced by your reasoning.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 10 Feb 2016 15:51:11 -0500

> specifying how to use it/interoperate with it seems useful.

  Then it should be published as an individual submission, as an informational document.

  I submit that we should be parsimonious with the IETF "stamp of approval".  Publishing a proprietary vendor protocol as an *IETF standard protocol* is a huge problem.

  Cisco had 18 years to submit the document for consideration by the IETF.  They decided not to.  That's fine, it's their decision.

  This isn't publishing extensions to existing documents, where the WG has been disbanded.  This isn't publishing documents which are relevant to multiple working groups, but don't really belong in any particular one.

  This is creating an entirely new standard protocol, which is in direct competition to existing, and active, working groups.  Worse, it's a protocol which the vendor refused to document for 18 years.

  Now that they're getting bit by interoperability issues, they're seeking the IETF stamp of approval.  It's a complete end-run around the entire IETF process.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 10 Feb 2016 15:51:42 -0500

>  There are a host of procedural problems with how the document was adopted.  I suggest that the document be withdrawn, and re-submitted as an individual draft.

  To be clear:

1. the document never had a WG call for adoption as required in Section 4.2.1 of RFC 6174

2. the charter has not been updated to reflect this work.

3. the charter says:

  "All new work items and rechartering proposals  will be brought for approval with the IESG."

4. I can find no record of this approval taking place.  If it had taken place, the charter would have been updated.

5. I had objected to this in person at the OPSAWG meeting in IETF 94.  However, the web site shows no minutes from that meeting:

https://tools.ietf.org/wg/opsawg/minutes

6. I believe that this document is an incorrect technical choice as per section 6.5.1 of RFC 2016.

  As such, I ask the chairs to withdraw the document as a WG document until such time as the procedural issues above have been addressed.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 10 Feb 2016 15:57:44 -0500

And some more notes

7. The charter says:

"The Operations and Management Area receives occasional proposals for 
the development and publication of RFCs dealing with operational and
management topics that are not in scope of an existing working group
and do not justify the formation of a new working group. "

8. This document is competes directly with two existing working groups, RADEXT and DIME, to create a third AAA protocol.

9.  As such, this document should be explicitly outside of the scope of the OPSAWG.

> On Feb 10, 2016, at 3:51 PM, Alan DeKok <[email-masked]> wrote:
>

---

From: joel jaeggli <[email-masked]>
Date: Wed, 10 Feb 2016 14:09:35 -0800

> 8. This document is competes directly with two existing working groups, RADEXT and DIME, to create a third AAA protocol.

it's pretty hard to argue that we've created something that's been
around since 1993 I;m sure we had this dicussion before circa 1996, I
don't remember it thankfully. I dare say it is inappropriate for dime or
radext to undertake work on tacacs+ under their current charters.

it is entirely unclear how this would interfere with the activities of
either...

---

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Wed, 10 Feb 2016 22:17:16 +0000

Hi Alan,

TACACS+ cannot compete with RADIUS in the area RADIUS is strong: for
Network access. The authors have no interest in trying to do so.

TACACS+ in 2016 has quite a different use case: for device administration,
where it is widely deployed by multiple vendors. Its application for
device administration is why the authors approached opsawg. The authors
believe that it has a place for device administration in the datacenter
and would seek to get the TACACS+ protocol definition documented and
straightened out for this purpose, and registered with IETF.

I understand that you hold different view in this matter. I¹m sure that
the IETF checks and balances will resolve the conflict for the best
interests of the whole, and I¹ll happily follow their decision.

I don¹t think there was any conspiracy by Cisco not to pursue the
publication before. Cisco initiated the process to get the protocol
approved by IETF in 1996/1997
(https://tools.ietf.org/html/draft-grant-tacacs-02), but the original
authors pursued other endeavours, and no one followed up until now, with a
process that actually started up outside Cisco.

Regarding procedural matters, if we have missed any steps, that is my bad
and I will consult with those more versed in procedure to rectify that.

Best Regards,

Doug.

On 10/02/2016 20:57, "Alan DeKok" <[email-masked]> wrote:

>8. This document is competes directly with two existing working groups,
>RADEXT and DIME, to create a third AAA protocol.
>
>>> There are a host of procedural problems with how the document was
>>>adopted.  I suggest that the document be withdrawn, and re-submitted as
>>>an individual draft.
>> 
>>  To be clear:
>> 
>> 4. I can find no record of this approval taking place.  If it had taken
>>place, the charter would have been updated.
>> 
>> 5. I had objected to this in person at the OPSAWG meeting in IETF 94.
>>However, the web site shows no minutes from that meeting:
>> 
>>  As such, I ask the chairs to withdraw the document as a WG document
>>until such time as the procedural issues above have been addressed.
>> 
>>  Alan DeKok.
>>

---

From: Andrej Ota <[email-masked]>
Date: Wed, 10 Feb 2016 22:32:40 +0000

I cannot comment on procedural items. However, on the topic of actual draft
content, item no. 8 contains an error. Please see the in-line comments.

> RADEXT and DIME, to create a third AAA protocol.

On the topic of "a third AAA protocol":
Current TACACS+ draft work is continuation of original work which stalled
in 1997. This predates first DIAMETER draft and was created around the same
time as the first RADIUS RFC. TACACS+, as specified in the expired
draft[1], also has a wide deployment base, is actively used, new vendors
and new devices are appearing on the market implementing what is called
"TACACS+" with implementations that conform to the original and expired
TACACS+ draft.

Stating this is "a third AAA protocol" is a false statement and one I find
to be intellectually dishonest. At worst one could call it the 2nd AAA
protocol.

On the topic of "competes directly with ...":
The goals and aims are completely different. This is not a new protocol,
it's almost 20 years old (00 draft was published in October 1996). It's not
a new development trying to compete with anything or anyone. Draft is
attempting to standardise the current ground truth while providing a single
relevant addition to the original draft, which the use of TLS "tunnel".

> 9.  As such, this document should be explicitly outside of the scope of

In connection with the quote from charter under item no. 7, I claim the
following statements to be true:
 - Ground truth is that TACACS+ is widely deployed protocol for device
management AAA.
 - Ground truth is that new device vendors and new devices are entering
market which are implementing TACACS+. The protocol is not dying out.
 - Ground truth is that DIAMETER has no penetration in the area of network
device management AAA.
 - Ground truth is that TACACS+ implementations are based on an IETF draft
which expired in 1997.

Combination of these statements, which I claim to be all true, is causing
current and relevant operational issues for network operators.

As such I think this draft is well within the scope of the OPSAWG. I
believe the community at large will benefit if it will be maintain it's
current strict and narrow focus and ultimately get approved as an RFC. If
it turns out that the protocol which already has a widespread adoption and
had it for more than a decade, can actually be beaten by other
alternatives, may it happen on the basis of actual operational merit and
not based on attempt to disqualify TACACS+ as an "entry too late" item in
WG queue. It is not too late, it is an active protocol, it is not
standardised, lack of a standard is causing issues by itself. This last
item I believe can and should be addressed.

[1] https://tools.ietf.org/html/draft-grant-tacacs-02

> adopted.  I suggest that the document be withdrawn, and re-submitted as an
> individual draft.
> >
> >  To be clear:
> >

-- 
--
Andrej Ota

Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland
Registered in Dublin, Ireland -  Registration # 368047

---

From: Randy Bush <[email-masked]>
Date: Wed, 10 Feb 2016 14:35:08 -0800

> already have two AAA IETF protocols.  Standardizing a third one is, in
> my opinion, entirely outside of the purview of OPSAWG.

after all, it's the one we actually use.  so it has to be killed asap.

randy

---

From: Edwin Mallette <[email-masked]>
Date: Wed, 10 Feb 2016 15:34:48 -0800

Just a couple commentsŠ

1) As one operator (of many, I am certain) that utilizes TACACS+ for AAA
on every network device, I would certainly hate to see some procedural
minutiae bog this effort down.
2) This draft is well written and adds a few welcome additional features.
3) Please don¹t let any procedural issues (real or imagined) inhibit the
completion of this good and much needed effort.

Cheers!

Ed

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Feb 2016 13:12:46 +1300

> 1. the document never had a WG call for adoption as required in Section 4.2.1 of RFC 6174

That's an Informational RFC that can't require anything of anybody. The same
is true of RFC 7221, which is very clear that the process is optional:
http://tools.ietf.org/html/rfc7221#section-2.1

No smoking gun there, not even any smoke.

That said, I looked back at the WG mailing list for last November and there was
explicit discussion of adoption in the thread "New Version Notification for draft-dahm-opsawg-tacacs-01.txt".

A WG Last Call is of course required in due course.

> 2. the charter has not been updated to reflect this work.

I agree that the WG chairs and AD should be beaten with wet noodles for
failing to update the milestones since 2013.

>   "All new work items and rechartering proposals  will be brought for approval with the IESG."

I've always read that to mean new work items that fall outside the existing charter,
which covers "development and publication of RFCs dealing with operational and
management topics that are not in scope of an existing working group". TACACS+
clearly lies within that chartered scope.

However, it might be wise to delete that sentence from the charter. It's
unnecessary to say that rechartering requires approval, because that is a
basic IETF procedure.

   Brian

---

From: Alan DeKok <[email-masked]>
Date: Wed, 10 Feb 2016 22:30:28 -0500

> radext to undertake work on tacacs+ under their current charters.

  That's not my point.

  My point is that TACACS+ has a 100% overlap in functionality with the RADIUS protocol.

  It is a vendor-specific protocol, which the vendor refused to standardize.  My opinion is that it's because the vendor saw it as advantageous to have a proprietary protocol.  Both for customer lock-in, and for complete control.  

  Now that the other people have implemented the protocol, they see it as being beneficial to standardize it.  That is a *complete* end-run around the IETF process.

  Publishing it as an informational draft is a good idea.  Publishing it as an IETF standard means that we reject the work done in RADEXT and DIME to standardize AAA protocols.  That we should ignore the last 20 years of history of people working on those protocols, in good faith that they would be IETF standards.  That we should just publish any document which has sufficient implementations, no matter that there's an existing WG which is doing 100% similar work.

> it is entirely unclear how this would interfere with the activities of

  Standardizing IPX would not interfere with IPv4 standardization.  But it would send entirely the wrong message, that a vendor-specific protocol has the IETFs blessing.

  What we're saying by standardizing TACACS+ is that the IETF process is irrelevant.  The RADEXT WG is irrelevant.  All vendors need to do is to push proprietary protocols behind the scenes, and then present them to the IETF as a fait accompli.

  It's really a slap in the face for everyone who followed the IETF process for the last 20 years, and did work in RADIUS, AAA, DIME, and RADEXT.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 10 Feb 2016 22:37:14 -0500

On Feb 10, 2016, at 7:12 PM, Brian E Carpenter <[email-masked]> wrote:ny smoke.
> explicit discussion of adoption in the thread "New Version Notification for draft-dahm-opsawg-tacacs-01.txt".

  I've seen many WGs where lots of people were in favour of a draft.  That doesn't mean the draft is automatically accepted as a WG document.

> failing to update the milestones since 2013.

  I've seen documents refused as WG items, even with unanimity that the documents were appropriate... because they were not part of the charter work items.

  If the process matters, I would suggest that it should apply equally to everyone. 

> clearly lies within that chartered scope.

  TACACS+ has 100% functionality overlap with RADIUS.

  Sure, it's not extending RADIUS, and doesn't technically fall within the purview of RADEXT.  But I find it rather surprising that OPSAWG is standardizing a protocol which competes directly with an existing, active WG.

  Is this really what we want to do here?  If we standardize TACACS+, we might as well disband RADEXT and DIME, because there's no point in following a standards process when people can do an end-run around it.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 10 Feb 2016 23:08:50 -0500

On Feb 10, 2016, at 5:32 PM, Andrej Ota <[email-masked]> wrote:
> Current TACACS+ draft work is continuation of original work which stalled in 1997.

  "Stalled"?  I don't think that's an accurate description.

  More accurately, the IETF consensus for the past 20 years was that the official IETF AAA protocol was RADIUS.

  Wide-spread adoption of a vendor protocol is insufficient reason to make it an IETF standard.

  There is no *technical* reason to make the document an IETF standard.  The goal of documenting TACACS+ could be done by publishing it as an informational RFC.

  So I have to ask, why is it being proposed (much less accepted) as an IETF standard document?

  The only conclusion is that it's to get the "stamp of approval" from the IETF, as an official IETF AAA protocol.

  I suggest that the IETF should be *very* parsimonious with such approvals.  We already have two AAA protocols, and TACACS+ adds *no technical benefits* over either RADIUS or Diameter.

  As such, it is entirely inappropriate for the IETF to approve this document as a standards track document.

> Stating this is "a third AAA protocol" is a false statement and one I find to be intellectually dishonest. At worst one could call it the 2nd AAA protocol.

  Please keep the ad hominems out of this discussion.

  We already have two IETF AAA protocols.  There is no good reason to add a third one.  The fact that TACACS+ was originally proposed 20 years ago is irrelevant.  The IETF is already doing work in the space.

> The goals and aims are completely different.

  So it's not a AAA protocol?

  Your argument is logically inconsistent.  Either it is a AAA protocol, and competes directly with RADIUS and Diameter, or it isn't a AAA protocol, and your accusation that I was being "intellectually dishonest" is itself dishonest.

> This is not a new protocol, it's almost 20 years old (00 draft was published in October 1996). It's not a new development trying to compete with anything or anyone.

  You're saying that an AAA protocol with 100% overlap with RADIUS isn't competing with RADIUS.

  Um... no.  It's pretty obviously competing with RADIUS.  The only reason TACACS+ is alive today is because of major vendors pushing it *against* RADIUS.

> Draft is attempting to standardise the current ground truth while providing a single relevant addition to the original draft, which the use of TLS "tunnel".

  Note "standardise", not "document".  So the goal is an IETF standard stamp on the document, not a document describing the protocol.

> In connection with the quote from charter under item no. 7, I claim the following statements to be true:
>  - Ground truth is that TACACS+ is widely deployed protocol for device management AAA.
>  - Ground truth is that new device vendors and new devices are entering market which are implementing TACACS+. The protocol is not dying out.
>  - Ground truth is that DIAMETER has no penetration in the area of network device management AAA.

  The truth is that there is 100% overlap in functionality between TACACS+ and RADIUS. 

>  - Ground truth is that TACACS+ implementations are based on an IETF draft which expired in 1997.

  No.  It was an *individual* draft.  I could write a draft claiming I'm a genius, and it would mean nothing.  Similarly, some random person publishing a draft in 1997 doesn't mean it's an "IETF" draft.  It's just another person with an idea that was *rejected by the IETF*.

> Combination of these statements, which I claim to be all true, is causing current and relevant operational issues for network operators.

  None of that is relevant to the IETF process.

> As such I think this draft is well within the scope of the OPSAWG. I believe the community at large will benefit if it will be maintain it's current strict and narrow focus and ultimately get approved as an RFC. If it turns out that the protocol which already has a widespread adoption and had it for more than a decade, can actually be beaten by other alternatives, may it happen on the basis of actual operational merit and not based on attempt to disqualify TACACS+ as an "entry too late" item in WG queue. It is not too late, it is an active protocol, it is not standardised, lack of a standard is causing issues by itself. This last item I believe can and should be addressed.

  That is entirely mischaracterizing my position.

  The IETF consensus for the last 20 years has been that RADIUS was chosen over TACACS+.  There is no *technical* reason to re-visit that decision.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 10 Feb 2016 23:20:24 -0500

> Network access. The authors have no interest in trying to do so.

  Realistically TACACS+ is an AAA protocol with full AAA functionality.  As such, it is competing 100% with RADIUS.

> where it is widely deployed by multiple vendors.

  The solution to a common device administration problem would be to either create an IETF protocol, or to leverage an existing one.

  Please suggest how:

1) publishing TACACS+ as an *IETF standard* is required to document it

2) any functionality in TACACS+ cannot be implemented in RADIUS

> Its application for

  There are many device administration protocols in the IETF.  SNMP for one.

  So this response is a bit too vague to be explanatory.  Call me dumb, but I would like to have a clear statement as to what TACACS+ does that RADIUS doesn't.

> process that actually started up outside Cisco.

  The IETF consensus for the last 20 years is that RADIUS, and then Diameter, are the IETF AAA protocols.

  I see no technical reason to re-visit that decision now.

> and I will consult with those more versed in procedure to rectify that.

  The chairs and ADs are responsible for process administration, not the document authors.

  Alan DeKok.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 10 Feb 2016 20:03:02 -0900

On 2/10/16 7:20 PM, Alan DeKok wrote:
> Realistically TACACS+ is an AAA protocol with full AAA functionality.
> As such, it is competing 100% with RADIUS.

That could well be, but traditionally the IETF does
sometimes standardize protocols that do basically the
same things and might be seen as competing.  Our
job is to specify useful things (interoperable useful
things), and I don't think the IETF has ever made it
our job to choose a winner - we let the market choose.

That said, I think the process here has been very very
badly botched.  Very.

Melinda

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 Feb 2016 07:14:38 +0100 (CET)

>  My point is that TACACS+ has a 100% overlap in functionality with the 

As an operator that has been running TACACS for 15+ years, my answer to 
that is:

"I don't care".

I want the IETF to publish an RFC documenting TACACS as it's in use 
currently. It's in wide use, and I don't see a reason not to let a 
document through that documents what's already in use and potentially adds 
a few more features.

If someone came and asked for a new WG for TACACS, that would be a 
different matter.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Thu, 11 Feb 2016 11:16:07 +0200

+1
As an operator using tacacs+ for the role/level-based administration of
many thousands devices, i would like to see a standard RFC for tacacs+.
If that must be paired with a clear reference to device administration,
that's also fine by me.

--
Tassos

---

From: t.petch <[email-masked]>
Date: Thu, 11 Feb 2016 10:14:25 +0000

---- Original Message -----
From: "Alan DeKok" <[email-masked]>
To: "Warren Kumari" <[email-masked]>
Sent: Wednesday, February 10, 2016 8:51 PM

And at some stage in the process, there would be a check on any
applicable IPR, which may colour the thinking as to whether or not this
is suitable for an IETF Standard.

I have yet to see any such claim or declaration yet, given the genesis
of this protocol, would be surprised if there were not one.

Tom Petch

> 4. I can find no record of this approval taking place.  If it had
taken place, the charter would have been updated.

---

From: Andrej Ota <[email-masked]>
Date: Thu, 11 Feb 2016 12:29:23 +0000

I'll try to answer multiple points from multiple e-mails to try to avoid
fragmented discussion. I do not dispute errors or omissions I made and
which were pointed out.

On he topic of 1st, 2nd, ... AAA protocol:
My intention was not an ad hominem attack, but I did want to convey my
strong aversion to statement implying TACACS+ is a late arrival when it is
in fact a protocol we have been living with for almost 20 years without it
ever being standardised or agreed upon. A feat I do not wish to be
discounted or ignored, regardless of its origin. Ignoring it serves no
useful purpose and I don't see it as benefiting anyone who wishes to
discuss protocols and standardisation on the merit of usefulness to the
network operator and vendor communities.

On the topic of relation to other AAA protocols:
TACACS+ definitely is AAA protocol and as such can be seen and used as a
competitor to RADIUS. At the same time I do not see it as a direct
replacement (to consider it a viable competitor) as it caters to a very
specific niche related to a very specific work. Track record from last 20
years demonstrates the difference in scopes. Is it competing with RADIUS? I
would rather say that RADIUS is competing with TACACS+ at this niche for
last 20 years and still not doing a stellar job at it.

Is there a meaningful way to address this difference in scopes? Would it
help if we make it explicitly about network element AAA for management
purposes and avoid chatting about NAS?

I don't even know what to say about alleged push of vendors *against*
RADIUS. I have to deal with few of vendors that only implement RADIUS and
not TACACS+ while I have yet to bump into a vendor which does the opposite.

On the topic of informational vs. standards track:
Authors are aiming for standards track due to two reasons:
 1) In the face of differing implementations, we cannot provide a simple
recap of what works but we feel we have to make a statement on how it
should work in the first place (e.g. removing ambiguities) without
introducing major incompatibilities.
 2) Device management AAA as used in the field today carries security
risks. To address some of them, authors decided to slap some lipstick on a
pig in the form of TLS tunnel.

Having done this, we cannot honestly call this an informational RFC in the
sense of how RFC 3164 was informational.

On the topic of vendor-specific and the message that IETF sends:
I'm sure I'm missing something here, but from what I understand, the main
objection is procedural as in the draft wasn't properly adopted by
workgroup to work on it. As long as that is addressed in accordance with
the procedure, the draft could become IETF draft which WG would discuss and
modify as it sees fit and one which could ultimately be considered for
standards track RFC. I though we were in that process, but if it was
botched, we certainly want to have that addressed.

I understand and appreciate the sensitivity of IETF even appearing to give
"a seal of approval" to some random vendor stuff. I certainly know how this
work could be misinterpreted if not handled in a very transparent manner.
But instead of a flat out refusal to deal with this protocol as it stands
today, I would like to appeal for suggestions on how to address this in
order to bring value to the community and industry. It's clear that this
was originally a proprietary protocol. I also think it became more than
that over two decades of use in a very specific niche area where AAA is
used in network operations. With multi-vendor adoption and willingness of
original authors to release it to current IETF process (copyrights, IPR and
all included) I think we can accept both negative legacy and its
practically demonstrated usability and viability while not encroaching on
the territories which are undisputedly RADIUS and Diameter dominated.

On the topic of slapping anyone in the face:
Continued long-term existence of non-IETF and non-RFC AAA protocol, its
widespread adoption in a single niche area and impact it has on the day to
day network operations cannot be ignored or discounted. As much as RADIUS
can be used in the same niche (as any other AAA protocol and other stuff
like LDAP can be used for the same purpose), it did not supplant the
non-standard solution for the last 20 years. I do not see how TACACS+ RFC
(if it ever comes to it) would change this.

While IETF is and should be forward-looking in defining how things could
and should be done better, this doesn't mean that it should avoid dealing
with sometimes ugly issues at hand as long as the work helps the community
of users and vendors to do their work more efficiently.

On the topic of technical benefits:
There must be something that TACACS+ is doing at least good enough while
RADIUS isn't doing it so much better to replace it.

My personal opinion is that TACACS+ is simple and dumb enough protocol to
be cheap to implement and still fit for the purpose. This two properties
combined make it an attractive choice for both users and vendors.

My personal experience is that TACACS+ appears to work more consistently
over a range of different vendors than I can say for devices which provide
RADIUS exclusively. I also find it easier to diagnose and debug as it uses
reliable transport. RFC6613 was supposed to change the latter, but after 3+
years I still don't see it adopted for the purpose of network management
AAA.

On the topic of proprietary and vendor lock-in:
I don't see any evidence of vendor lock-in after 20 years of use, but I do
see a risk because there is no authoritative and standard definition of
what is TACACS+. The IETF process is aimed to address this and I don't
think calling out current proprietary status is an argument against
considering the proposal, but rather an argument to work on a proposal.

The IETF process should ensure that proprietary monicker is removed after
all conditions are met. Proprietary protocol probably isn't evil by itself,
but is made evil by the fact that even the original author cannot be held
accountable if it changes it or ignores it. This effort aims to address
that as well and is an argument to work on the proposal, not throwing it
out.

Current state of IPR for any TACACS+ implementor is unknown. The IETF
process must and will ensure that all IPR will be ultimately disclosed
which will take away a lot of stress an unknowns from both vendors and
users. How can this ever be a wrong thing to do and how could it be bad if
IETF is the one forcing the issue? I again see this as an argument to work
on this within IETF and not reject all work on it.

-- 
--
Andrej Ota

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Feb 2016 09:06:35 -0500

I'll reply mostly in summary.

  TACACS+ is a late arrival to the IETF.  It was never considered as an AAA protocol by the IETF.  20 years of IETF consensus is that TACACS+ is not an IETF protocol.  It is not appropriate for a WG to re-consider that decision without a larger involvement from the IETF.  The fact that a proprietary version of TACACS+ is also 20 years old is irrelevant to the IETF process.  If we ignore the IETF process here, we might as well shut down the IETF as irrelevant.

  One WG should not be able to over-rule the rest of the IETF.

  TACACS+ catering to a "nice" related to specific work is command authorization, or device administration.  This use case is so niche that it isn't even mentioned in the draft.  This use-case *remains* a vendor-specific proprietary protocol.  It's successfully competed with RADIUS in this space because the vendor refused to standardize command authorization in RADIUS.  Most likely because they saw it as a competitive advantage.

  So... TACACS+ competed with RADIUS by forcing customers to use a proprietary protocol, to the detriment of the standards.  And the reward for 20 years of this anticompetitive behaviour, is that we reward the vendor with the label "IETF approved - standards track protocol".

  Again, there is *zero* technical reason to make TACACS+ a standards track document.  There are many procedural reasons to avoid making TACACS+ a standards track document.  i.e. 20 years of IETF consensus.

  Those are my objections.  Please explain how the document is *massively different* for implementors with two words changed: "Informational" versus "Standards Tack".  Please explain why we should ignore 20 years of IETF consensus.

> Is there a meaningful way to address this difference in scopes? Would it help if we make it explicitly about network element AAA for management purposes and avoid chatting about NAS?

  I have no objection to standardization of the functionality which is now proprietary in TACACS+.  I think it's a good idea.  But rubber-stamping TACACS+ without even *mentioning* device management in the draft is bizarre at best.

>  1) In the face of differing implementations, we cannot provide a simple recap of what works but we feel we have to make a statement on how it should work in the first place (e.g. removing ambiguities) without introducing major incompatibilities.
>  2) Device management AAA as used in the field today carries security risks. To address some of them, authors decided to slap some lipstick on a pig in the form of TLS tunnel.

  Neither of those reasons requires a standards track document.

> I'm sure I'm missing something here, but from what I understand, the main objection is procedural as in the draft wasn't properly adopted by workgroup to work on it. As long as that is addressed in accordance with the procedure, the draft could become IETF draft which WG would discuss and modify as it sees fit and one which could ultimately be considered for standards track RFC. I though we were in that process, but if it was botched, we certainly want to have that addressed.

  No.  The main objection (which would be seen in the IETF 94 minutes, but they're missing) is the label "standards track".

  The fact that the procedure used to make it standards track was "flexible" raises alarm bells.

> I understand and appreciate the sensitivity of IETF even appearing to give "a seal of approval" to some random vendor stuff. I certainly know how this work could be misinterpreted if not handled in a very transparent manner. But instead of a flat out refusal to deal with this protocol as it stands today, I would like to appeal for suggestions on how to address this in order to bring value to the community and industry.

  Make the document informational.

  The rest of the content doesn't need to change.

> There must be something that TACACS+ is doing at least good enough while RADIUS isn't doing it so much better to replace it.

  Command authorization, because the vendor refuses to standardize it in RADIUS.  Which they could have done any time in the last 20 years.  They refused.

  Well... they refused.  I fail to see how refusing to follow the standards process means the we should reward them with an official standards track RFC.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Feb 2016 09:10:30 -0500

On Feb 11, 2016, at 1:14 AM, Mikael Abrahamsson <[email-masked]> wrote:
> As an operator that has been running TACACS for 15+ years, my answer to that is:
> 
> "I don't care".
> 
> I want the IETF to publish an RFC documenting TACACS as it's in use currently. It's in wide use, and I don't see a reason not to let a document through that documents what's already in use and potentially adds a few more features.

  Please explain why the draft should be a standards track document, instead of informational.

  And the document does not describe TACACS+ as it is currently in use.  As such, it does not meet your criteria.

> If someone came and asked for a new WG for TACACS, that would be a different matter.

  But that's what's being done here.  The OPSAWG is the WG which is working on TACACS+. 

  Alan DeKok.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 Feb 2016 15:58:02 +0100 (CET)

>  But that's what's being done here.  The OPSAWG is the WG which is working on TACACS+.

Clarification, nobody has asked to form a TACACS WG.

Also, just for clarification, your objection is that the proposed document 
is standards-track, and you want it to be informational? When reading your 
email it seems sometimes that you don't want this to be a OPSAWG document 
at all, sometimes that you don't want TACACS documented as an RFC at all, 
sometimes that your main objection is that there has been a procedural 
error.

I want TACACS to become documented as an RFC, preferably all functionality 
currently in wide spread use. In your view, how do we get that done?

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Feb 2016 10:25:33 -0500

On Feb 11, 2016, at 9:58 AM, Mikael Abrahamsson <[email-masked]> wrote:
> Also, just for clarification, your objection is that the proposed document is standards-track, and you want it to be informational? When reading your email it seems sometimes that you don't want this to be a OPSAWG document at all, sometimes that you don't want TACACS documented as an RFC at all, sometimes that your main objection is that there has been a procedural error.

  My objection is all of that.  When people say "We want the draft to be standardized for reason X", I have objections to X.  For many versions of X.

- there are procedural issues with WG adoption of the document

- even if there were no procedural issues, the document violates IETF consensus as described in RFC 3127

- even if there were no procedural issues or violation of IETF consensus, the document does not describe the stated use-case for why it's being adopted

- even if none of the above happened, the functionality in the document overlaps 100% with RADIUS, and is therefore technically unnecessary

- even if none of the above happened, the protocol could be sufficiently documented via publication as an information document, instead of a standards track document

  For each reason individually, and for all of those reasons together, this document should not be a standards track document.

> I want TACACS to become documented as an RFC, preferably all functionality currently in wide spread use. In your view, how do we get that done?

  Publish it was an informational document, via an individual submission and AD sponsorship.

  Alan DeKok.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Feb 2016 08:31:05 -0800

On Thu, Feb 11, 2016 at 7:25 AM, Alan DeKok <[email-masked]>
wrote:

> > Also, just for clarification, your objection is that the proposed
> document is standards-track, and you want it to be informational? When
> reading your email it seems sometimes that you don't want this to be a
> OPSAWG document at all, sometimes that you don't want TACACS documented as
> an RFC at all, sometimes that your main objection is that there has been a
> procedural error.
>
>   My objection is all of that.  When people say "We want the draft to be
> standardized for reason X", I have objections to X.  For many versions of X.
>
> - even if there were no procedural issues or violation of IETF consensus,
> the document does not describe the stated use-case for why it's being
> adopted
>
> - even if none of the above happened, the functionality in the document
> overlaps 100% with RADIUS, and is therefore technically unnecessary
>
> - even if none of the above happened, the protocol could be sufficiently
> documented via publication as an information document, instead of a
> standards track document
>
>
>   For each reason individually, and for all of those reasons together,
> this document should not be a standards track document.
>
> > I want TACACS to become documented as an RFC, preferably all
> functionality currently in wide spread use. In your view, how do we get
> that done?
>

I do not have a dog in this hunt, but I agree with Alan that the "WG
standardization process"
should not be used to rubber-stamp or simply document a vendor protocol. It
should be
used where multiple competing documents are evaluated as a starting point
for the WG.

An AD-sponsored Informational RFC is the correct process if you want to
rubber-stamp
a document without a consensus-based process.

>   Alan DeKok.
Andy

---

From: t.petch <[email-masked]>
Date: Thu, 11 Feb 2016 17:09:57 +0000

<at the bottom>

Tom Petch

----- Original Message -----
From: "Andrej Ota" <[email-masked]>
Sent: Thursday, February 11, 2016 12:29 PM

> on this within IETF and not reject all work on it.

The IETF process is that each contributor must disclose any known IPR -
"all those contributing to the working group's discussions must disclose
the existence of any IPR the Contributor or other IETF participant
believes Covers or may ultimately Cover the technology under
discussion." [BCP0079]
except that I know that US legal liability makes companies there keep
their staff in ignorance of such IPR so what I expect, and do not yet
see, is a disclosure from the company in question.  That can and does
make a difference to the decisions of the IETF.

Tom Petch

------------------------------------------------------------------------
--------

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 11 Feb 2016 12:19:37 -0500

>   I submit that we should be parsimonious with the IETF "stamp of approval".  Publishing a proprietary vendor protocol as an *IETF standard protocol* is a huge problem.

there's no 'stamp of approval' yet, wg adoption is really just "this
is something that the wg is interested in working on" It may flounder
and die, or it may blossom into a useful standards document.

>   Cisco had 18 years to submit the document for consideration by the IETF.  They decided not to.  That's fine, it's their decision.

as a reminder it's not 'cisco' but the authors as individuals... who may have:
  A) been pulled away from the work for other reasons

  B) not wanted to get abused by ietf folk for something that is
working and has adoption across a wide swath of the industry

  C) other - it's not super important I suppose really WHY they didn't
pursue this work in 1996... Almost all vendors today implement tacacs+
(mostly tac+) for AAA services on their devices after all.

>   This isn't publishing extensions to existing documents, where the WG has been disbanded.  This isn't publishing documents which are relevant to multiple working groups, but don't really belong in…

oddly there's not a 'networking working group' anymore, since the work
fits well with 'ops' area work this doesn't seem like a bad place for
it to happen.

>   This is creating an entirely new standard protocol, which is in direct competition to existing, and active, working groups.  Worse, it's a protocol which the vendor refused to document for 18 yea…

it's not 'entirely new', it's actually 20 yrs old, needs improvements
for security AND operations/management reasons and is used across
almost all network equipment in large networks (private networks,
public networks, enterprise networks, etc).

>   Now that they're getting bit by interoperability issues, they're seeking the IETF stamp of approval.  It's a complete end-run around the entire IETF process.

I don't think the complaint is 'interoperability issues' as much as:
   "Gosh, this should be standardized so we have a platform to make
improvements to the security problems we see in the active protocol
today."

-chris

---

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Thu, 11 Feb 2016 17:21:03 +0000

Let me follow up on that, to make sure there are no obstacles form that
perspective.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 11 Feb 2016 12:50:11 -0500

On Wed, Feb 10, 2016 at 3:51 PM, Alan DeKok <[email-masked]> wrote:
> 6174

is about what teh datatracker implements, not about the actual
process... I think maybe you mean: 7221

"Handling of Internet-Drafts by IETF Working Groups"

particularly you might be interested in:
https://tools.ietf.org/html/rfc7221#section-2

note that this is 'common steps' though, there's not a hard
requirement for an adoption call, if the chairs feel the work applies
it can be adopted without this step.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 11 Feb 2016 12:51:06 -0500

On Wed, Feb 10, 2016 at 3:51 PM, Alan DeKok <[email-masked]> wrote:
> RFC 2016

this also doesn't seem to apply to the discussion at hand...

"Uniform Resource Agents (URAs)"

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 11 Feb 2016 12:54:34 -0500

> 8. This document is competes directly with two existing working groups, RADEXT and DIME, to create a third AAA protocol.

DIME charter text:
"The Diameter Maintenance and Extensions WG will focus on maintenance and
  extensions to the Diameter protocol required to enable its use for
  authentication, authorization, accounting, charging in network access,"

RadExt Charter text is less clear except that their milestones are
explicit and focused on the 'network access' problem, not the 'network
managment' or 'network operations' or 'network adminsitration'
problem(s).

So, I think calling out to these is also out of scope.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 11 Feb 2016 13:00:11 -0500

> TACACS+ has 100% functionality overlap with RADIUS.

you keep saying this, but I can't get a radius server to authorize my
command on a network device in my network... you seem absolutely sure,
but I'm absolutely sure (because I've driven down this road a few
times with 4 different vendors if IP gear and 3 different optical
vendors) you are incorrect.

I think you are very much in the rough, and I'm not clear on why you
are as vigorous about this. There are network operators on this list
and in the rest of the world that have said: "tac+ is how I AAA my
network gear, I need it to be improved/worked-on/etc, please do that
for me"

also: "I support this draft, and want to see it complete the IETF
process... so I can then start having better security of the
management of my global network elements."

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 11 Feb 2016 13:01:55 -0500

> That said, I think the process here has been very very

1) cite your sources
2) show your work
3) it doesn't really seem like that's the case, at all.
   (see previous cites by mr carpenter)

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Feb 2016 20:36:00 +0100

Hi Alan,

I'm not unsympathetic to the idea that we should focus efforts where
possible, and I'm also not interested in piling on.  But I think a
comment is in order regarding RFC 3127 and then I have a proposal for a
way forward.

> - even if there were no procedural issues, the document violates IETF consensus as described in RFC 3127

One has to put into perspective what was going on back then.  Many
different approaches were proposed to cover not only AAA but policy in
general, and the market was at risk of fragmentation.  There was a
pretty visible and dare I say heated process at the IETF that turned
into an attempt to align those who wanted to pursue policy with COPS and
COPS-PR and those who wanted to do something with RADIUS/Diameter.   
RFC 3127 and its predecessor RFC 2989 represented hard work in the
context of the efforts going on at the IETF at the time.  It was a tool
upon which the ADs relied to organize the work of O&M *at the time*.

However, in the 15 interceding years, what's become clear is that RADIUS
has broad applicability for a great many AAA uses; and for some cases
TACACS+ is appropriate.  For these purposes, such as command
authorization, TACACS+ is a defacto standard, no matter what the IETF
process says.  The nascence of this space is long past.  RFC 3127 was
never intended to be a constraint so far into the future but rather a
guide to ADs at the time as to how to proceed.

The choice here, it seems to me, is really one of change control.  I
agree with you, Tom, and others who write that the IETF doesn't just
rubber stamp protocols.  On the other hand, changes should be made with
due care toward what is deployed.  I personally have faith that our
processes and good community involvement would provide for a good path
forward on this.

In summary, if people want a standard, I propose the following way forward:

1.  An applicability statement for TACACS+ that describes when TACACS+
is appropriate for use;
2.  The proper following of working group process;
3.  Appropriate and timely IPR declarations; and
4.  It should be clear that the IETF has the necessary rights to effect
changes.

Thoughts/Comments?

Eliot

---

From: Robert Drake <[email-masked]>
Date: Thu, 11 Feb 2016 14:46:11 -0500

>    One WG should not be able to over-rule the rest of the IETF.

Does another WG want to take up the reins of fixing TACACS+?

>    Those are my objections.  Please explain how the document is *massively different* for implementors with two words changed: "Informational" versus "Standards Tack".  Please explain why we should…

Does anyone want to take up the reins of fixing the procedural errors of 
the TACACS+ draft so it meets the requirements for standards track?

>    I have no objection to standardization of the functionality which is now proprietary in TACACS+.  I think it's a good idea.  But rubber-stamping TACACS+ without even *mentioning* device manageme…
I would say it's an oversight and not malicious.  Perhaps writing the 
authors and asking them to add something about this would be good, or if 
you like you might contribute a paragraph or two.  It looks like the 
original draft does mention device management in the Abstract, as well 
as giving documentation on how to do authorization and accounting for 
commands (as part of the REQUEST packet body).

I haven't looked again at the new draft to see if it retains that 
information, but if not it probably needs to be put back in.

>    Neither of those reasons requires a standards track document.
I would argue #1 does require standards track, unless the difference 
between "standards track" and "informational" is largely academic. We 
need to be able to push vendors on compatibility.  I don't know enough 
about the IETF processes to know if this is really true, but I don't 
think there would be 50 emails about this if it was okay with everyone 
to change to informational.

<deleted some stuff below here>
>    Well... they refused.  I fail to see how refusing to follow the standards process means the we should reward them with an official standards track RFC.
Is the RADIUS WG going to add support for command authorization?  It 
seems like if RADIUS wanted this then one vendor refusing to submit a 
standard wouldn't be a barrier.  Surely anyone could write a standard 
and propose it as a draft?

>    Alan DeKok.
Robert

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Feb 2016 15:21:03 -0500

On Feb 11, 2016, at 2:36 PM, Eliot Lear <[email-masked]> wrote:
> One has to put into perspective what was going on back then.  Many different approaches were proposed to cover not only AAA but policy in general, and the market was at risk of fragmentation.  There was a pretty visible and dare I say heated process at the IETF that turned into an attempt to align those who wanted to pursue policy with COPS and COPS-PR and those who wanted to do something with RADIUS/Diameter.    RFC 3127 and its predecessor RFC 2989 represented hard work in the context of the efforts going on at the IETF at the time.  It was a tool upon which the ADs relied to organize the work of O&M at the time.

  I understand.  I was involved in those discussions at the time.  As a less public figure than I am now, but I was still a participant.

> However, in the 15 interceding years, what's become clear is that RADIUS has broad applicability for a great many AAA uses; and for some cases TACACS+ is appropriate.  For these purposes, such as command authorization, TACACS+ is a defacto standard, no matter what the IETF process says.  The nascence of this space is long past.  RFC 3127 was never intended to be a constraint so far into the future but rather a guide to ADs at the time as to how to proceed.

  I welcome new protocols (even old ones) to solve problems that existing protocols don't solve.

> The choice here, it seems to me, is really one of change control.  I agree with you, Tom, and others who write that the IETF doesn't just rubber stamp protocols.  On the other hand, changes should be made with due care toward what is deployed.  I personally have faith that our processes and good community involvement would provide for a good path forward on this.
> 
> 1.  An applicability statement for TACACS+ that describes when TACACS+ is appropriate for use;
> 4.  It should be clear that the IETF has the necessary rights to effect changes.

  Those are all good steps. 

  I'd still like to know why it's necessary to have the cachet of an IETF standard for a protocol which is vendor-specific.  And for which the *functional* change control will still reside with the vendors.  And for which the vendors *could* have standardized it via an IETF protocol at any time in the past 20 years, and refused, because they saw benefits in bypassing the standardization process.

  i.e. the contents of any device management authorization exchange are entirely vendor specific, and due to the way TACACS+ is being used, *must* remain vendor-specific.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Feb 2016 15:30:16 -0500

> Does another WG want to take up the reins of fixing TACACS+?

  That's not my point.  My point is that we have IETF consensus on topics.  A WG shouldn't be able to over-ride IETF consensus without having a larger discussion.  i.e. Involving the people who established IETF consensus, and explaining why the WG needs to go against it.

  With reasons.  Not "It's popular".

> I would argue #1 does require standards track, unless the difference between "standards track" and "informational" is largely academic. We need to be able to push vendors on compatibility.  I don't know enough about the IETF processes to know if this is really true, but I don't think there would be 50 emails about this if it was okay with everyone to change to informational.

  I think the discussions are because most people don't see much of a difference between standards track and informational.  I do.

> Is the RADIUS WG going to add support for command authorization?  It seems like if RADIUS wanted this then one vendor refusing to submit a standard wouldn't be a barrier.  Surely anyone could write a standard and propose it as a draft?

  It would be well within the scope of RADEXT.  The RADEXT WG would (I'm guessing) be OK with standardizing it.

  But while anyone can write a standard, any standard is pointless unless it's implemented.  And the vendors have refused to standardize command authorization in RADIUS.

  Because they saw it as a competitive advantage to bypass the IETF.  Now that they have problems with inter-operability, they're looking for IETF approval.

  Again, why is there a need to have the document as standards track?  RADIUS accounting (RFC 2866) is Informational, for crying out loud.  Are we really saying that RADIUS / RADEXT WG with an active history going back to 1996 is *not* going to have a standards track protocol, but TACACS+ gets one, because "it's popular"?

  That's an amazing interpretation of the IETF consensus, and IETF process.  Maybe I'm naive, but it looks a while lot to me like one WG has to follow the rules to get a protocol standardized, and another WG doesn't.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Feb 2016 15:33:58 -0500

On Feb 11, 2016, at 1:00 PM, Christopher Morrow <[email-masked]> wrote:
> command on a network device in my network...

  Because the vendors refused to standardize it, and refused to cede change control to the IETF.

> are as vigorous about this.

  I've been explaining.  In detail.

  I have this odd idea that processes and consensus matter.  If they don't, then I'm going to declare myself the dictator of RADEXT, and demand publication of any crazy idea I come up with.  Because processes don't matter.

> There are network operators on this list

  Will those vendors cede change control to the IETF for the contents of TACACS+?  i.e. the commands being authorized?

  No?

  Then... TACACS+ won't be an IETF protocol, will it?

> management of my global network elements."

  Vendors do all kinds of inventive things.  Things which are perceived as useful, and which are widely deployed.

  Not all of them are made IETF standards.  I have this strange idea that there is "process" and "consensus" required for IETF standardization.  Not just "it's popular, so *boom*, it's a standard!".

  Alan DeKok.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 12 Feb 2016 07:01:39 +0100 (CET)

On Thu, 11 Feb 2016, Alan DeKok wrote:

>  I'd still like to know why it's necessary to have the cachet of an IETF 
> standard for a protocol which is vendor-specific.

It is not vendor specific. In the past 15 years I have used TAC+ on Cisco, 
Juniper, Huawei and others. That's what we used, and if you wanted to 
provide IP core equipment, that's what you had to support.

Basically, if you're sending packets through an IP core network today, 
those devices are likely to do AAA using TAC+. Apart from that, these IP 
core routers use mechanisms that are "all" documented in an IETF RFC.

I just don't understand your objection to also documenting the AAA 
protocol that is in super widespread use in the industry.

To me, it's like you would be saying that IS-IS shouldn't be in the IETF 
because it was originally an ISO protocol. It's equally absurd.

---

From: t.petch <[email-masked]>
Date: Fri, 12 Feb 2016 09:41:09 +0000

<at the end>

----- Original Message -----
From: "Eliot Lear" <[email-masked]>
Sent: Thursday, February 11, 2016 7:36 PM

Hi Alan,

In summary, if people want a standard, I propose the following way
forward:

Thoughts/Comments?

<tp>

Eliot

Looking at the Informational RFC in the RFC-index, I see

Cisco Architecture for Lawful Intercept in IP Networks
Cisco Systems NetFlow Services Export Version 9
Cisco's Mobile IPv4 Host Configuration Extensions
Cisco Systems UniDirectional Link Detection (UDLD) Protocol
Cisco Systems' Private VLANs: Scalable Security in a Multi-Client
Environment
Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs
Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying
Material
[mmm RADIUS!]
etc etc

so the question in my mind, is why not do the same now (especially as I
understand that the work was started along these lines in 1997)?

Mikael says
"and if you wanted to provide IP core equipment, that's what you had to
support"
suggesting that a de facto standard exists and provides interoperability
without any involvement of the IETF so again, an Informational RFC from
a vendor would seem more than adequate.

Why does anyone want Standards Track?  I am suspicious until I have a
plausible answer to that (IPR being only one area of suspicion and even
a plausible answer may not allay my suspicions).

Tom Petch

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 12 Feb 2016 11:19:09 +0100

Tom,

> understand that the work was started along these lines in 1997)?

Actually the work started long before THAT, even.  I think it dates to
1993 if memory serves.  Again, in my mind this is a matter of whether or
not the IETF wants change control, and I suspect that matters more to
the operators than to anyone at Cisco.  I am given to understand that
occasionally some operators get touchy about something not being a standard.

But speaking plainly, this isn't a science experiment.  It isn't
something anyone is floating as a suggestion.  It's what's being done in
the network today, and it is supported across multiple implementations. 
It is a defacto standard.  Unless there's very good reason not to do
so[*], let's just call it what it is.  And again, I would reiterate:
let's also make clear what it's not.  A good applicability statement
should help with that.

Eliot
[*] A very good reason would be if it doesn't meet the requirements for
specifications that the IETF generally laid out.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Feb 2016 07:23:41 -0500

On Feb 12, 2016, at 5:19 AM, Eliot Lear <[email-masked]> wrote:
> 1993 if memory serves. 

  Pretty much.  RFC 2989 and RFC 3127 are the outcomes (~y2000), not the start of the process.

> It is a defacto standard.

  Like IPX, or any number of other non-IETF protocols.

  That doesn't mean they deserve RFC status, much less a standards track document.

>  Unless there's very good reason not to do

  The discussion here has been that TACACS+ is a AAA protocol.  If I believe that, I also have to believe that it's such a terrible AAA protocol, that it wasn't even considered in the discussion in RFC 3127.

  i.e. at the time the original draft was published, the major networking companies (including Cisco via their employees) and the ITEF consensus was that TACACS+ was not suitable for consideration as an AAA protocol.

  We're welcome to re-visit that decision.  Priorities change, and we learn new things.

  But the cognitive dissonance here is mind-boggling.  People say that TACACS+ is a AAA protocol, but the requirements on AAA protocols don't apply, because it's not a AAA protocol.  It's a device management protocol.  Even though the document doesn't describe device management, or even contain the terms "device management" or "device administration".

  By that logic, war is peace, freedom is slavery, ignorance is strength.

  I've asked repeatedly why the document should be granted standards track status.  The argument is largely "it's widely used".  Well, so what?  Many other protocols are *more* widely used, and aren't standards track.

  Again, while there are many widely used protools as information, or not even RFCs, while there are inconsistent arguments in favour of the protocol, while a self-described AAA protocol goes against IETF consensus, while a self-described AAA protocol is so inadequate that it wasn't even considered in RFC 3127, while there were procedural issues making it a WG document...

  Why, exactly, are is the WG full-steam ahead in making it a standards track document?

  It looks like the IETF ideal of "individuals" is failing here.  There are large forces behind the scenes pushing for standardization, and that is winning over petty things like individuals without deep pockets, and IETF process.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Feb 2016 07:29:09 -0500

On Feb 12, 2016, at 1:01 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> It is not vendor specific. In the past 15 years I have used TAC+ on Cisco, Juniper, Huawei and others. That's what we used, and if you wanted to provide IP core equipment, that's what you had to support.

  I understand.  But let's be realistic here.  TACACS+ started out as a vendor-specific protocol.  Undocumented.  Proprietary.  Everyone else implemented it in order to be compatible with the major vendor at the time.

  Like IPX.  Like any number of Microsoft proprietary protocols, for example.

  And for those protocols, everyone agrees they're really vendor-specific, even though we have multiple implementations.

  Why do you have a different standard for TACACS+?

> Basically, if you're sending packets through an IP core network today, those devices are likely to do AAA using TAC+. Apart from that, these IP core routers use mechanisms that are "all" documented in an IETF RFC.

  So it *is* a AAA protocol?

  Good.  The requirements of RFC 2989 should apply.  And the conclusions of RFC 3127 should apply.  TACACS+ was such a poor AAA protocol that it wasn't even considered in RFC 3127.  Since the protocol hasn't changed since then, there are no *technical* reasons why we should re-visit the consensus shown in RFC 3127.

> I just don't understand your objection to also documenting the AAA protocol that is in super widespread use in the industry.

  I've been explaining in detail.

> To me, it's like you would be saying that IS-IS shouldn't be in the IETF because it was originally an ISO protocol. It's equally absurd.

  To me, it's like you're not even reading my counter-arguments.

  It's easy to dismiss someone's views when you don't pay attention to them.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 12 Feb 2016 14:26:02 +0100

Hello,

>   It would be well within the scope of RADEXT.  The RADEXT WG would (I'm guessing) be OK with standardizing it.

chair-hat on:

RADEXT's charter states

"The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol pending approval of the new work from the Area Director"

So feature additions are indeed well inside the current charter scope.

>   Because they saw it as a competitive advantage to bypass the IETF.

chair-hat off for the rest of this mail:

That's true. Cisco even has devised a mapping between RADIUS attributes
and authorization commands usually transported over TACACS+. The RADIUS
VSA "cisco-av-pair" basically takes TACACS+ syntax inside.

As a random example, quickly googled:

http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4.0/user/guide/ad.html

Quoting the section "About the cisco-av-pair RADIUS attribute":

"[...]cisco-av-pair, supports the inclusion of many AV pairs by using
the following format:

attribute sep value

where attribute and value are an AV pair supported by the releases of
IOS implemented on your AAA clients, and sep is = for mandatory
attributes and asterisk (*) for optional attributes. You can then use
the full set of Terminal Access Controller Access Control System
(TACACS+) authorization features for RADIUS."

Many of the commands that TACACS+ can understand in Cisco devices have
direct RADIUS VSA counterpart. The syntax also /allows/ for per-command
authorization in that same VSA.

That last sentence in the doc above even wants to imply that per-command
authorization is possible.

The catch is that one can even send the converted per-command-authz
syntax inside the VSA, and a Cisco device nicely ignores it. It process
other attributes from the same group in the same way (I tried that,
admittedly nearly a decade ago meanwhile), so this is quite clearly
visible *bad will* and not a technology gap.

For some reason, some people see this and conclude "TACACS+ is better,
because I can send per-command-authorization". While a much more natural
conclusion would be to complain about the obvious bug or bad-will
limitation in the product.

Consequently, I can even halfways understand that the same people want
TACACS+ standardised; while others who are not in that IMHO flawed line
of thinking want it to go away and never come back.

I myself need to have one stepchild instance of TACACS+ server running
in our network because we need to have per-command authorisation at a
few places. The product that runs TACACS+ is called "Radiator", which is
actually a RADIUS server that runs TACACS+ in a niche of its memory
because it can; while doing so much more with RADIUS. That is quite
telling IMHO.

This story goes to show that those who have to deal with TACACS+ or the
lack of per-command-authorization in RADIUS in their real deployment
life have a story to tell, and feel strongly about the issue, and maybe
even loathe TACACS+ for its anti-competitiveness in that respect; while
others love it for allowing them to do something they otherwise can't.

This would explain the heatedness of the debate.

>  Now that they have problems with inter-operability, they're looking for IETF approval.
> 

My personal opinion is that documenting the protocol is probably good
because it is so widespread (-> Informational). But it's also so low
priority that I wouldn't care much if it weren't documented at all
(->/dev/null).
Rather than seeing a standards-track document I'd rather see Cisco
living up to their promise of "the full set of Terminal Access
Controller Access Control System (TACACS+) authorization features for
RADIUS" in actual deployed code; it would immediately make the necessity
for TACACS+ go away; at which point nobody would care about documenting
this then-obsolete piece of network technology any more.

About process, at least in RADEXT we always ask for document adoption,
and we have a good debating culture at this early stage; so passing the
WG adoption threshold means something. I'm a bit shocked to learn that
this is apparently different in osawg.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Stefan Winter <[email-masked]>
Date: Fri, 12 Feb 2016 14:51:53 +0100

Hello,

> managment' or 'network operations' or 'network adminsitration'

The sentence "The RADIUS Extensions Working Group will focus on
extensions to the RADIUS protocol pending approval of the new work from
the Area Director"

is quite clear, IMHO: new features so long as the AD allows us to.

We can work on standardisation of the previous "cisco-av-pair" when
there are volunteers to do it, and if our (OPS area) ADs allow us to do it.

There is not even a charter update needed.

> So, I think calling out to these is also out of scope.

It's not.

Greetings,

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Feb 2016 08:58:39 -0500

> is quite clear, IMHO: new features so long as the AD allows us to.

  In addition, RADIUS has been used for network administration since it's origins.  RFC 2058 makes it clear that it is *explicitly* intended to authenticate, authorize, and do accounting for administrators logging into network equipment:

https://tools.ietf.org/html/rfc2058#section-5.6
 
  Has Service-Type of:

      Administrative      The user should be granted access to the
                                  administrative interface to the NAS from which
                                  privileged commands can be executed.

  Any counter-argument that RADIUS isn't intended for "network operations" or "network administration" is false, and has been documented publicly as being false for two decades.

  The "command authorization" is *explicitly* in scope for RADIUS, and has *always* been in scope for RADIUS.  As Stefan says, it's only due to one vendors anti-competitive behaviour that we're even having this discussion.

  Alan DeKok.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 12 Feb 2016 15:07:55 +0100 (CET)

>  So it *is* a AAA protocol?

I actually do not know what criteria you put in the AAA term. It might be 
different from what I use it for.

For me TACACS does the following things:

It checks username/password when I login, and the TAC+ server says if I 
can login or not with those credentials.
It sends CLI commands I run on the router to the TAC+ server, and the TAC+ 
server grants or doesn't grant me to run those individual commands, on a 
per-command basis. It also records what commands I ran.

That's what I thought the "Authentication, Authorization, Accounting" 
meant.

As far as I have understood, Radius/Diameter doesn't do the last 
function(s) I described. Why is that?

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Feb 2016 09:22:04 -0500

On Feb 12, 2016, at 9:07 AM, Mikael Abrahamsson <[email-masked]> wrote:
> I actually do not know what criteria you put in the AAA term. It might be different from what I use it for.

  This is getting silly.  The document describes itself as an AAA protocol.  I'm willing to accept that.

  But most times I mention it's an AAA protocol, the response is "NO! the rules for AAA protocols don't apply!  It's a device management protocol!"

  I find such circular arguments unconvincing, and downright anti-social.

> It checks username/password when I login, and the TAC+ server says if I can login or not with those credentials.
> It sends CLI commands I run on the router to the TAC+ server, and the TAC+ server grants or doesn't grant me to run those individual commands, on a per-command basis. It also records what commands I ran.
> 
> That's what I thought the "Authentication, Authorization, Accounting" meant.

  By that standard, SQL and LDAP are AAA protocols.  They authenticate administrators, authorize them to do some tasks and not others, and perform accounting / logging on the commands run by those administrator.s

> As far as I have understood, Radius/Diameter doesn't do the last function(s) I described. Why is that?

  Because your understanding is wrong?

  RADIUS does that.  Not for every vendor, but it's explicitly designed to do that.

  The *common* use-case for network management is that command authorization is done via TACACS+.

  And why is that?

  Because of a anti-competitive behaviour by a major networking vendor.  Who saw it being as beneficial to *not* standardize command authorization.  Despite (was Stefan pointed out) their own documentation which says it works in RADIUS, but which the switches completely ignore!

  Now that they're getting bitten by interoperability issues, they want a rubber-stamp on the protocol as standards track.

  I've explained this repeatedly.  I suggest reading my messages to see what my argument is.  That would help you to avoid asking questions which have already been answered repeatedly.

  Speaking of repeated questions... I've asked this question repeatedly:

  Why is it necessary to have a standards track document?  What's wrong with informational?

  I've respected you by answering your questions and explaining my position.  Please consider doing the same for me.

  Alan DeKok.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 12 Feb 2016 15:30:58 +0100 (CET)

>  I've respected you by answering your questions and explaining my position.  Please consider doing the same for me.

As far as I know, I have never insisted it needs to be a standards track 
document. I just re-read all my email I have sent on this issue, and I 
have consistently used the term "documented in an RFC".

... so you blame me for not reading your email, but it seems you're not 
reading mine, or putting words in my mouth I never uttered and asking me 
to argue for a position I have never taken.

I don't care if the document is Informational or Standards track, but I 
still want the document. You have opposed the document to be created at 
all, and that's what I have been arguing against.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Feb 2016 09:40:29 -0500

On Feb 12, 2016, at 9:30 AM, Mikael Abrahamsson <[email-masked]> wrote:
> As far as I know, I have never insisted it needs to be a standards track document. I just re-read all my email I have sent on this issue, and I have consistently used the term "documented in an RFC".

  Forgive me, but you were opposing my position.

> ... so you blame me for not reading your email, but it seems you're not reading mine, or putting words in my mouth I never uttered and asking me to argue for a position I have never taken.

  No.  I never said you refused to answer the question.  I had never asked you the question directly before.

> I don't care if the document is Informational or Standards track, but I still want the document. You have opposed the document to be created at all, and that's what I have been arguing against.

  And again, please read my messages.  Including the one you just replied to.

  I have *repeatedly* said that I'm OK with it being an informational RFC.  This whole conversation began with me requesting that the document be an informational RFC.

  Just.. enough, already.  Please.

  Alan DeKok.

---

From: t.petch <[email-masked]>
Date: Fri, 12 Feb 2016 16:18:57 +0000

----- Original Message -----
From: "Alan DeKok" <[email-masked]>
To: "Eliot Lear" <[email-masked]>
Sent: Friday, February 12, 2016 12:23 PM

> Actually the work started long before THAT, even.  I think it dates to

RFC1492 is dated July 1993 but what I find more interesting than the
timeline is the content of that RFC

" The original TACACS protocol specification does exist.  However, due
   to copyright issues, I was not able to obtain a copy of this document

   and this lack of access is the main reason for the writing of this
   document.  This version of the specification was developed with the
   assistance of Cisco Systems, who has an implementation of the TACACS
   protocol that is believed to be compatible with the original
   specification.  To be precise, the Cisco Systems implementation
   supports both the simple (non-extended) and extended versions.  It is
   the simple version that would be compatible with the original.

   Please keep in mind that this is an informational RFC and does not
   specify a standard, and that more information may be uncovered in the
   future (i.e., the original specification may become available) that
   could cause parts of this document to be known to be incorrect."

which I find delightful.  How you build an Internet Standard with that
as a starting point I am unsure but an ISE submission from an involved
manufacturer (which, in the end, the IESG has to say does or does not
conflict with the work of the IETF) would seem more appropriate.

Tom Petch

  Pretty much.  RFC 2989 and RFC 3127 are the outcomes (~y2000), not the
start of the process.

  That doesn't mean they deserve RFC status, much less a standards track
document.

> specifications that the IETF generally laid out.

  The discussion here has been that TACACS+ is a AAA protocol.  If I
believe that, I also have to believe that it's such a terrible AAA
protocol, that it wasn't even considered in the discussion in RFC 3127.

  i.e. at the time the original draft was published, the major
networking companies (including Cisco via their employees) and the ITEF
consensus was that TACACS+ was not suitable for consideration as an AAA
protocol.

  We're welcome to re-visit that decision.  Priorities change, and we
learn new things.

  But the cognitive dissonance here is mind-boggling.  People say that
TACACS+ is a AAA protocol, but the requirements on AAA protocols don't
apply, because it's not a AAA protocol.  It's a device management
protocol.  Even though the document doesn't describe device management,
or even contain the terms "device management" or "device
administration".

  By that logic, war is peace, freedom is slavery, ignorance is
strength.

  I've asked repeatedly why the document should be granted standards
track status.  The argument is largely "it's widely used".  Well, so
what?  Many other protocols are *more* widely used, and aren't standards
track.

  Again, while there are many widely used protools as information, or
not even RFCs, while there are inconsistent arguments in favour of the
protocol, while a self-described AAA protocol goes against IETF
consensus, while a self-described AAA protocol is so inadequate that it
wasn't even considered in RFC 3127, while there were procedural issues
making it a WG document...

  Why, exactly, are is the WG full-steam ahead in making it a standards
track document?

  It looks like the IETF ideal of "individuals" is failing here.  There
are large forces behind the scenes pushing for standardization, and that
is winning over petty things like individuals without deep pockets, and
IETF process.

  Alan DeKok.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 12 Feb 2016 16:34:29 +0000

On Fri, Feb 12, 2016 at 8:26 AM Stefan Winter <[email-masked]>
wrote:

> standard wouldn't be a barrier.  Surely anyone could write a standard and
> propose it as a draft?
> >
> >   But while anyone can write a standard, any standard is pointless
> unless it's implemented.  And the vendors have refused to standardize
> command authorization in RADIUS.
> >
> >   Again, why is there a need to have the document as standards track?
> RADIUS accounting (RFC 2866) is Informational, for crying out loud.  Are we
> really saying that RADIUS / RADEXT WG with an active history going back to
> 1996 is *not* going to have a standards track protocol, but TACACS+ gets
> one, because "it's popular"?
> >
> >   That's an amazing interpretation of the IETF consensus, and IETF
> process.  Maybe I'm naive, but it looks a while lot to me like one WG has
> to follow the rules to get a protocol standardized, and another WG doesn't.
>

<no hats at all>
That is working on the assumption that the reason that operators are using
TACACS+ instead of RADIUS is /only/ because of this feature. In many cases
it is also because operators already have TACACS servers installed and / or
find TACACS+ *much* simpler to deploy and manage. RADIUS is a grand
protocol - it has many bells and whistles and extra functionality, but e.g:
shrubbery's tac_plus is free, comes with many distributions, and is dead
simply to install and configure.
</no hats>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Feb 2016 11:51:50 -0500

On Feb 12, 2016, at 11:34 AM, Warren Kumari <[email-masked]> wrote:
> That is working on the assumption that the reason that operators are using TACACS+ instead of RADIUS is /only/ because of this feature. In many cases it is also because operators already have TACACS servers installed and / or find TACACS+ *much* simpler to deploy and manage.

  Please suggest which operators use TACACS+ for general user authentication, roaming, etc.

  I'm unaware of any TACACS+ roaming consortium.  I'm aware of multiple RADIUS / Diameter roaming consortium.

  Please suggest *why* TACACS+ is simpler to deploy and manage than RADIUS servers.  That statement is... surprising, to be polite.  Installing and configuring a new networking daemon is a matter of a few minutes on any modern Unix distribution.

> RADIUS is a grand protocol - it has many bells and whistles and extra functionality, but e.g: shrubbery's tac_plus is free, comes with many distributions, and is dead simply to install and configure.

  So?

  As a biased person, FreeRADIUS is free, comes with *all* distributions, and is dead simple to install and configure.  It's packaged with every single Unix distribution on the planet.  It's shipped by essentially every network equipment manufacturer other than Cisco, Alcatel-Lucent, and Juniper as their embedded RADIUS solution.  It supports all of the relevant RADIUS RFCs.  It *alone* has probably 10x the install base of all of the TACACS+ servers, combined, world-wide.

  Simple "it's popular" is no argument.  I say this as the author of the most popular RADIUS server on the planet.

  Heck, it supports DHCP, BFD, and we're working on Diameter support.

  Again.. so?

  Alan DeKok.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 12 Feb 2016 18:32:26 +0000

On Fri, Feb 12, 2016 at 11:51 AM Alan DeKok <[email-masked]>
wrote:

> > That is working on the assumption that the reason that operators are
> using TACACS+ instead of RADIUS is /only/ because of this feature. In many
> cases it is also because operators already have TACACS servers installed
> and / or find TACACS+ *much* simpler to deploy and manage.
>
Still no hats....

You are right -- I left out the important "for engineer authentication to
network devices".

>   Please suggest *why* TACACS+ is simpler to deploy and manage than RADIUS
> servers.

I said that operators find it simpler to deploy and manage -- perhaps this
is because it is what many operators are used to, or because it has fewer
knobs and whistles.

That statement is... surprising, to be polite.  Installing and configuring
> a new networking daemon is a matter of a few minutes on any modern Unix
> distribution.
>

Having installed and run both RADIUS (mainly FreeRADIUS, but a little bit
of Radiator) and have written a few TACACS servers, and installed and run
tac_plus for a number in large (and small) deployments, *I* find it much
simpler -- and, seeing as lots of network operators choose TACACS+ for
their network device authentication, I suspect that others do too.

> > RADIUS is a grand protocol - it has many bells and whistles and extra
> functionality, but e.g: shrubbery's tac_plus is free, comes with many
> distributions, and is dead simply to install and configure.
>
>   So?
>
>   As a biased person, FreeRADIUS is free, comes with *all* distributions,
> and is dead simple to install and configure.  It's packaged with every
> single Unix distribution on the planet.  It's shipped by essentially every
> network equipment manufacturer other than Cisco, Alcatel-Lucent, and
> Juniper as their embedded RADIUS solution.  It supports all of the relevant
> RADIUS RFCs.  It *alone* has probably 10x the install base of all of the
> TACACS+ servers, combined, world-wide.
>
>   Simple "it's popular" is no argument.  I say this as the author of the
> most popular RADIUS server on the planet.
>

As part of the IETF NOC team - "Thanks!"
We've used FreeRADIUS and it works -- I think I've even submitted a patch
or two (sometime around the IETF meeting in Beijing). It does *many*
things, and does them well -- but sometimes you don't really need a tool
that does many things, you just want something simple and easy.

This isn't (and doesn't need to be turned into) RADIUS versus TACACS+ --
lots of people use TACACS+ (for whatever reason), and having it documented
seems (to me) like a good idea.
Telling people that they are wrong for wanting to use a tool *that they
have chosen to use* seems unhelpful.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Feb 2016 13:51:40 -0500

On Feb 12, 2016, at 1:32 PM, Warren Kumari <[email-masked]> wrote:
> ... *I* find it much simpler -- and, seeing as lots of network operators choose TACACS+ for their network device authentication, I suspect that others do too.

  i.e. people find a TACACS+ daemon easier to deploy, because they choose TACACS+ as a protocol, because the features they need are only implemented in TACACS+

  I don't see that one follows from the other.

> We've used FreeRADIUS and it works -- I think I've even submitted a patch or two (sometime around the IETF meeting in Beijing). It does *many* things, and does them well -- but sometimes you don't really need a tool that does many things, you just want something simple and easy.

  We're getting off-topic here... but people use that particular tool for non-standard uses because they find it easier to install and deploy than other tools.  And because it has features that other tools don't have.

  So I'm entirely sympathetic to the argument that TACACS+ has features RADIUS doesn't have.  i still have many, many, concerns about it.

> This isn't (and doesn't need to be turned into) RADIUS versus TACACS+ -- lots of people use TACACS+ (for whatever reason), and having it documented seems (to me) like a good idea.
> Telling people that they are wrong for wanting to use a tool *that they have chosen to use* seems unhelpful.

  As I've argued, they don't have a choice.  The vendors made the choice for them, via proprietary protocol and functionality lock-in.  Claiming "free choice" is just... odd.

  I'm not telling people they're wrong, please don't make this argument a personal one.

  I'm happy for them to use TACACS+.  I'm happy to see the protocol documented as an informational RFC.

  I'm *not* happy with pretty much everything else around the subject.

  Alan DeKok.

---

From: Randy Bush <[email-masked]>
Date: Sat, 13 Feb 2016 09:38:18 +1300

does this wg have a chair?

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 13 Feb 2016 09:44:09 +1300

> does this wg have a chair?

seems so.  thank you, scott.

randy