Subject: [OPSAWG] APPEAL: re AAA protocols and IETF consensus

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

I think most people aren't aware of the history of AAA protocols in the iETF.  This message summarizes relevant documents in the area, and makes an appeal to the WG to remove the document as a WG document.

  RADIUS was standardized in 2000 in RFC 2058, after years of WG discussion.  The original protocol goes back to 1993, unlike the TACACS+ draft, which was submitted in 1997.

  Diameter was standardized in 2003 in RFC 3588, again after years of WG discussion.  TACACS+ was never considered by the IETF as an AAA protocol.

  The IETF created a process to specify requirements for AAA protocols.  This process is documented in RFC 2989 [1] (2000), which had about 20 authors from all major networking companies at the time.  It solicited submissions, and established a panel to evaluate the submissions.  The results are documented inRFC 3127 [2] (2003).  TACACS+ was not even considered, as it did not meet the requirements set out in RFC 2989.

  What is happening here is that a single WG is re-visiting a multi-year process which involved dozens of experts in the area.  A process which established IETF consensus.  A process which was started almost two decades ago, and finished 13 years ago.

 While RFC 2989 and RFC 3127 are "informational", they are only informational because they do not document a protocol design.  They do, however, document IETF consensus.

  Standardizing a new AAA protocol without IETF-wide discussion means we're ignoring the requirements of RFC 2989, and discarding the results shown in RFC 3127.

  Standardizing TACACS+ is like a single WG standardizing IPv8 on it's own, after decades of work on IPv6, without achieving wider IETF consensus, or even updating the WG charter.  It's one WG doing a complete end-run around IETF consensus.

  The document draft-ietf-opsawg-tacacs-00.txt *explicitly* describes itself as an AAA protocol in it's abstract.  Despite the authors stating it is for "device administration", that phrase *does not appear in the document*.  Despite claims that it is not an AAA protocol, the document itself claims TACACS+ is an AAA protocol.  The document discusses user authentication, authorization, and accounting, in a manner which overlaps 100% with RADIUS.

  In fact, RADIUS has more capability than TACACS+.  RADIUS is standardized to transport many more attributes which describe hundreds of possible pieces of information.  The TACACS+ document documents little more than the base protocol, and a less than 30 kinds of information it can transport.

  The TACACS+ functionality therefore *explicitly* overlaps 100% with RADIUS.  It is explicitly *not* "device authorization".  It is uniformly inferior to RADIUS in functionality and capability.  It meets none of the requirements set out in RFC 2989, and wasn't even considered in RFC 3127.

  The only *technical* capability that TACACS+ has which RADIUS doesn't is "device administration".  Perhaps what is meant here is "command authorization", in which individual administrator commands are authorized via the AAA protocol.  However, this capability is *not* documented in the draft, which means that any "device administration" remains a proprietary vendor extension, and entirely outside of the control of the IETF.

  The document overturns nearly two decades of IETF consensus.  It competes directly with an established IETF protocol.  It's functionality is explicitly inferior to RADIUS.  It's suggested use-case is entirely undocumented in the draft.

  Therefore, I ask the WG, chairs, and AD, to withdraw this document as a WG item.  It is entirely inappropriate for a standards track document.

[1] https://tools.ietf.org/html/rfc2989

[2] https://tools.ietf.org/html/rfc3127

---

From: joel jaeggli <[email-masked]>
Date: Wed, 10 Feb 2016 21:58:21 -0800

On 2/10/16 9:00 PM, Alan DeKok wrote:
> I think most people aren't aware of the history of AAA protocols in
> the iETF.  This message summarizes relevant documents in the area,
> and makes an appeal to the WG to remove the document as a WG
> document.
> 
> RADIUS was standardized in 2000 in RFC 2058, after years of WG
> discussion.  The original protocol goes back to 1993, unlike the
> TACACS+ draft, which was submitted in 1997.
> 
> Diameter was standardized in 2003 in RFC 3588, again after years of
> WG discussion.  TACACS+ was never considered by the IETF as an AAA
> protocol.
> 
> The IETF created a process to specify requirements for AAA protocols.
> This process is documented in RFC 2989 [1] (2000), which had about 20
> authors from all major networking companies at the time.  It
> solicited submissions, and established a panel to evaluate the
> submissions.  The results are documented inRFC 3127 [2] (2003).
> TACACS+ was not even considered, as it did not meet the requirements
> set out in RFC 2989.
> 
> What is happening here is that a single WG is re-visiting a
> multi-year process which involved dozens of experts in the area.  A
> process which established IETF consensus.  A process which was
> started almost two decades ago, and finished 13 years ago.
> 
> While RFC 2989 and RFC 3127 are "informational", they are only
> informational because they do not document a protocol design.  They
> do, however, document IETF consensus.
> 
> Standardizing a new AAA protocol without IETF-wide discussion means
> we're ignoring the requirements of RFC 2989, and discarding the
> results shown in RFC 3127.
> 
> Standardizing TACACS+ is like a single WG standardizing IPv8 on it's
> own, after decades of work on IPv6, without achieving wider IETF
> consensus, or even updating the WG charter.  It's one WG doing a
> complete end-run around IETF consensus.
> 
> The document draft-ietf-opsawg-tacacs-00.txt *explicitly* describes
> itself as an AAA protocol in it's abstract.  Despite the authors
> stating it is for "device administration", that phrase *does not
> appear in the document*.  Despite claims that it is not an AAA
> protocol, the document itself claims TACACS+ is an AAA protocol.  The
> document discusses user authentication, authorization, and
> accounting, in a manner which overlaps 100% with RADIUS.
> 
> In fact, RADIUS has more capability than TACACS+.  RADIUS is
> standardized to transport many more attributes which describe
> hundreds of possible pieces of information.  The TACACS+ document
> documents little more than the base protocol, and a less than 30
> kinds of information it can transport.
> 
> The TACACS+ functionality therefore *explicitly* overlaps 100% with
> RADIUS.  It is explicitly *not* "device authorization".  It is
> uniformly inferior to RADIUS in functionality and capability.  It
> meets none of the requirements set out in RFC 2989, and wasn't even
> considered in RFC 3127.
> 
> The only *technical* capability that TACACS+ has which RADIUS doesn't
> is "device administration".  Perhaps what is meant here is "command
> authorization", in which individual administrator commands are
> authorized via the AAA protocol.  However, this capability is *not*
> documented in the draft, which means that any "device administration"
> remains a proprietary vendor extension, and entirely outside of the
> control of the IETF.
> 
> 
> The document overturns nearly two decades of IETF consensus.  It
> competes directly with an established IETF protocol.  It's
> functionality is explicitly inferior to RADIUS.  It's suggested
> use-case is entirely undocumented in the draft.
> 
> Therefore, I ask the WG, chairs, and AD, to withdraw this document as
> a WG item.  It is entirely inappropriate for a standards track
> document.

Ok,

we operate under the order of precidence in 2026:

https://tools.ietf.org/html/rfc2026#section-6.5

I expect that prior to intercession on my part that an appeal will
commence with the chairs considering the appeal.

thanks
joel

---

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

>   The IETF created a process to specify requirements for AAA protocols.  This process is documented in RFC 2989 [1] (2000), which had about 20 authors from all major networking companies at the tim…

2989 is titled: "Criteria for Evaluating AAA Protocols for Network Access"

2989 is explicitly not about 'device management' or 'device
administration' access management (AAA).
tacacs+ is explicitly about 'device management' or 'device
administration' access management (AAA).

I don't think 2989 applies at all to this discussion.

3127 says: "This memo represents the process and findings of the Authentication,
   Authorization, and Accounting Working Group (AAA WG) panel evaluating
   protocols proposed against the AAA Network Access Requirements,"

again, not applicable to 'device management' / 'device administration'
... so not applicable to this discussion, at all.

>   Standardizing a new AAA protocol without IETF-wide discussion means we're ignoring the requirements of RFC 2989, and discarding the results shown in RFC 3127.

it doesn't seem like 'IETF-wide discussion' is being missed at all, actually.

>   The document draft-ietf-opsawg-tacacs-00.txt *explicitly* describes itself as an AAA protocol in it's abstract.  Despite the authors stating it is for "device administration", that phrase *does n…

perhaps, but you seem to have content questions, did you make these
comments to the authors?

>   In fact, RADIUS has more capability than TACACS+.  RADIUS is standardized to transport many more attributes which describe hundreds of possible pieces of information.  The TACACS+ document docume…

I'm not sure that the three points here are relevant to the
discussion, we don't always want more things in the knife drawer, we
want the right knife for the job.

>   The TACACS+ functionality therefore *explicitly* overlaps 100% with RADIUS.  It is explicitly *not* "device authorization".  It is uniformly inferior to RADIUS in functionality and capability.  I…

because 2989 and 3127 are not about the problem tac+ solves.

For network operations the meaning of AAA is different than that used
for 'dialup users' (or equivalent as the technology advances).

o Authorizing users of your network access to the network is different
than authorizing administration/management of the devices which make
the network.

o Accounting for the device administration activities is not the same
acocunting for bits/time spent on a customer

o Authenticating a device administrator is likely very different from
authenticating a user of the network

>   The only *technical* capability that TACACS+ has which RADIUS doesn't is "device administration".  Perhaps what is meant here is "command authorization", in which individual administrator command…

I think you mean to rephrase and aim this comment to the editors... so
they can add a note about it in the draft. I do see discussion of
authorization and why it's important/used in the original
grant-tacacs-02 draft, and in the draft-dahm version 02 there's this:

https://tools.ietf.org/html/draft-dahm-opsawg-tacacs-01#section-5

this seems to have some level of detail and useful information about
the authorization process/work/packets.

>   The document overturns nearly two decades of IETF consensus.  It competes directly with an established IETF protocol.  It's functionality is explicitly inferior to RADIUS.  It's suggested use-cas…

i don't know that 'two decades' is particularly important, much has
changed over the last 20 yrs in the IETF and the Internet and in stuff
provided by vendors/etc. Making device administration better and more
secure over time is a win for operations, networks and users.

-chris

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Feb 2016 08:31:51 +1300

As far as I can tell the only point at issue here is two words in the
third header line of the draft:

"Intended status: Standards Track"

There doesn't seem to be any dispute that TACACS+ is a widely deployed
protocol and that this is a competent description of it, and as already
observed the WG chairs didn't exceed their authority in the adoption
process. Since the WG hasn't yet even been asked (by WGLC) whether the
document should be approved, I can't see what appealable decision has
been taken, since basically no decision has been taken.

Could we perhaps have a rational debate about whether the draft should be
on the standards track or not? It's a perfectly valid question to ask.

Standardising multiple solutions to similar problems is not unknown in the
IETF; in fact it's rather common in both the Routing Area and the
Ops and Management Area. But otoh, RFC 1958 (another Informational
document) does say:
   3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

Regards
   Brian

---

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

> administration' access management (AAA).

  The TACACS draft is silent on device management.  The only discussion in the draft of functionality is AAA.

  For you, the AAA RFCs I mentioned don't apply to a self-described AAA document.  Because the document really (wink wink) applies to device management.  Which it doesn't talk about.

  i.e. A isn't the same as B because A is really the same as C, even though A claims to be the same as B.

  This is logic so twisted as to become farcical. 

> ... so not applicable to this discussion, at all.

  Then you should be in favour of not standardizing the TACACS+ document, because it doesn't talk about device management either.

> it doesn't seem like 'IETF-wide discussion' is being missed at all, actually.

  Forgive me if I'm missing a wider CC list.  Are the people who wrote RFC 2989 and RFC 3127 involved in this discussion?  No?  Then a wider IETF discussion is being missed.

> perhaps, but you seem to have content questions, did you make these

  I think dealing with larger issues is a higher priority than editorial comments.

>>  The TACACS+ functionality therefore *explicitly* overlaps 100% with RADIUS.  It is explicitly *not* "device authorization".  It is uniformly inferior to RADIUS in functionality and capability.  It meets none of the requirements set out in RFC 2989, and wasn't even considered in RFC 3127
> 

  And neither is the TACACS+ document.

> authenticating a user of the network

  Remind me again where the TACACS+ document discusses that?

> the authorization process/work/packets.

  Which is a vague discussion of "authorization".  It misses "device management" entirely.

> secure over time is a win for operations, networks and users.

  While I agree with that, there were many opportunities over the last 20 years to standardize device management in the IETF.  The vendors refused.  Because (as I've said repeatedly), they saw benefits in avoiding the standards process.

  Now that they're getting bitten by inter-operability problems, *oops*, it's time get a rubber stamp on the protocol.

  I welcome publishing the document as an information draft.  I see no reason why it should be an IETF standard.  And so far, I haven't seen a convincing argument from anyone else.  The arguments in favour amount to:

- just 'cause

- it's widely used

- it's not an AAA protocol, even though it's explicitly an AAA protocol

  Alan DeKok.

---

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

> "Intended status: Standards Track"

  For me, that's just the tip of the iceberg.  There isn't much point in talking about more minor issues when there are major issues still unresolved.

> protocol

   I agree.

> and that this is a competent description of it,

  Sort of.  It's a description of the TACACS+ base protocol as a generic AAA protocol.  Which *on it's face* has 100% overlap with RADIUS.

 The defence of TACACS+ is entirely related to use-cases which aren't in the document.

 Even if we publish this document as a standards track document, the contents of the device management queries and responses can *only* be vendor specific.  Each vendor has their own command-line syntax which, while similar, have proprietary differences.  So the *use-case* of the protocol remains entirely vendor-specific.

  So the base protocol would be documented, but the practical application thereof would be 100% vendor proprietary.  That's an unusual use-case for an IETF standard protocol.

> and as already

  Does this mean that WG adoption is a meaningless step?  That charter updates are meaningless steps?

  I'm a little surprised to see a public decision by a WG chair be described as "no decision".  That's... legalese I didn't expect in the IETF.

> on the standards track or not? It's a perfectly valid question to ask.

  I've been asking for reasons why it should be adopted. The answers are largely "it's widely used".

  Well, so is IPX.  IPX has multiple implementations by multiple vendors, and is running in probably 1000 times as many systems as TACACS+.  It's even older than TACACS+.  It's still in use.

  Sure, IPX overlaps with IPv4, but heck... it's widely used, so let's make it an IETF standard protocol.

  If you find those reasons unconvincing, you should find the reasons for TACACS+ adoption unconvincing, too.

  Alan deKok.

---

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

On 12/02/2016 09:14, Alan DeKok wrote:
>   Does this mean that WG adoption is a meaningless step?

Yes, in terms of the IETF process rules for approving a document are concerned.
The notion of formal WG adoption is useful innovation, but it isn't actually
required by the rules.

>  That charter updates are meaningless steps?

Charter updates are formal step, but the OPSAWG charter is already written
to encompass work of this kind. As I hinted before, it's unfortunate that
the WG milestones haven't been updated recently, but that's true of many WGs.
We are collectively sloppy on that.

>   I'm a little surprised to see a public decision by a WG chair be described as "no decision".  That's... legalese I didn't expect in the IETF.

It's no decision on the disposition of the document. Until the end of a WG last call,
the document is completely open for discussion and change by the WG.

>   I've been asking for reasons why it should be adopted. The answers are largely "it's widely used".

Actually I think you've been asking for reasons why it should standardised, and there
are only two words in the draft header that affect that question. I don't really have
an opinion on that.

>   If you find those reasons unconvincing, you should find the reasons for TACACS+ adoption unconvincing, too.

TACACS+ is used by IP operators, so it seems relevant in a way that IPX isn't.
But if you want to propose an IPX BOF in the Internet Area, or request a slot
in a future INTAREA WG meeting for IPX, you're obviously free to do so.

Rgds
   Brian

---

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

On Feb 11, 2016, at 5:54 PM, Brian E Carpenter <[email-masked]> wrote:
> to encompass work of this kind.

  Except that the charter says new work will require IESG approval.

> As I hinted before, it's unfortunate that

  That's a non sequitur. I never discussed milestones.

> We are collectively sloppy on that.

  Speaking for myself, I don't work for a large company.  I don't have a CEO who can apply "behind the scenes" pressure to get things pushed ahead.  My main involvement is in a small WG that most people don't care about.

  As such, my main protection and guidance is the documented IETF process.  If we ignore that process, then we're letting large companies do what they want, simply because they're large companies.

> in a future INTAREA WG meeting for IPX, you're obviously free to do so.

  Which pretty much misses the point of my argument.

  There are many protocols used on the wider internet which have many more deployments across more vendors than TACACS+.  Those protocols are not documented in RFCs.

  So... why this one?

  The only answer so far is that "it's supported by large companies".

  Alan DeKok.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Feb 2016 08:03:47 +1300

Alan,

Since you keep repeating yourself, forgive me if I do the same.

Several days ago I answered this point:
>>> 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.

>   That's a non sequitur. I never discussed milestones.

Milestones are part of the WG charter.

>   The only answer so far is that "it's supported by large companies".

No, that it's *used* by many operators. However, the real point about putting it
on the standards track is that it would move change control of the text to the IETF.
That's a valid point to debate. Is there any win in that for the community, as
opposed to leaving it entirely in the hands of "large companies"?

If this was only about rubber-stamping I would agree with you.

   Brian

---

From: Alan DeKok <[email-masked]>
Date: Sun, 14 Feb 2016 15:17:57 -0500

> on the standards track is that it would move change control of the text to the IETF.

  TACACS+ the *existing* protocol is not under change control of the IETF.  That's my reason for suggesting publication of the protocol *as it exists today* via an informational RFC.  First, to document it.  Second, to make it clear that the protocol being documented was not created under IETF change control.

  TACACS+ as it exists tomorrow is absolutely well within the scope of the IETF.  Any "future TACACS+" can be produced under IETF change control, with whatever label the IETF wants.

> opposed to leaving it entirely in the hands of "large companies"?

  I've tried to make my argument clear.  I have *never* suggested leaving the protocol entirely in the hands of large companies.

> If this was only about rubber-stamping I would agree with you.

  I see the current document as conflating the two points I discussed above. 

* As such, it comes across as "rubber stamping" the historical TACACS+ protocol as an IETF standard, because it's issuing a standards-track document for "historical TACACS+ plus TLS".

*  the OPSAWG is defining a new (to the world and IETF) standard network administration protocol as work so minor that it doesn't require a charter update, Where more commonly we would have a WG devoted to defining a critically important network administration protocol

*  It's an AAA protocol, but the AAA requirements shouldn't apply, because it's not really an AAA protocol.

*  It's a network management protocol for "device administration" or "device management", a use-case which is so vital that the phrases aren't even mentioned in the document.

*  It's not a new protocol because it's been around for 18 years, but in order to give the IETF change control, we have to add new bits and TLS transport... which makes it a new protocol.

  The whole thing looks like special pleading to me.

  As such, I'm requesting a clear separation of topics, and a clear statement of applicability.  That the historical protocol be documented separately from the future protocol.  That documents clearly state it's *not* a AAA protocol, and *should not* be used in situations where AAA protocols are used today.  That it's a network management protocol, and it should be limited to that use-case.

  The thing which is amazing for me is that there is enormous push-back to my request for consistently applying logic, the IETF process, and IETF consensus.

  Alan DeKok.