On 2/11/2016 9:06 AM, Alan DeKok wrote:
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.
Does another WG want to take up the reins of fixing TACACS+?
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.
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?
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.
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.
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.
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>
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.
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
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
