On Fri, Feb 12, 2016 at 8:26 AM Stefan Winter <[email protected]> wrote:
> Hello, > > >> 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. > > 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. > > > 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. > > 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. > > > > 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. > > 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. > <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> > > 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 > > > > > Alan DeKok. > > > > _______________________________________________ > > OPSAWG mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/opsawg > > > > > -- > 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 > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
