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. > 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. Neither of those reasons requires a standards track document. > 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. 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. > 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. 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. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
