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. 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
0x8A39DC66.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
