On Mon, Dec 30, 2013 at 8:11 AM, Javier Henderson <javier@kjsl.org> wrote:
Given the problem of remote auth; the restriction of choice of protocols is dictated by what protocols the relying party device supports. This is the problem: You are at the mercy of your router vendor, to support the authentication protocol functionality. Things are workable, but in a sad state. Obviously, providing highly robust, highly secure remote authentication, is not a high priority among the router vendors. They pay lip service to the whole thing. In many cases you might be better off with local auth. How do you feel about having to wait 30 seconds between every command you enter to troubleshoot, to fail to the second server, if the TACACS or RADIUS system is nonresponsive, because the dumb router can't remember which TACACS servers are up and which ones are down, and always tries the first one in the list first? At least RADIUS has the concept of a "dead timer" :) By all rights; routers should be implementing authorization using LDAP over TLS, with a locally cached persistent copy of the directory and credentials (so users can still log in, and their command exec rights cached, in case of network outages).. and authentication with either user SSH public key published in LDAP, Kerberos/GSSAPI with Smartcard and other 2factor auth/OTP support, or LDAP BIND using SASL. RADIUS and TACACS+ are what you get, because they've been there forever, and frequently enough deemed "good enough". Some routers have limited Kerberos support; although, usually, not support for Kerberos ticket forwarding SPNEGO / Negotiate authentication using GSSAPI over SSH. (Over encrypted Telnet, Yes) RADIUS and TACACS+, without IPSEC or TLS encapsulation of all the traffic are both highly insecure by today's standards, and in theory should not be used. Unfortunately; on many network devices, these are your only native central authentication options! Fallback plan: The network should be designed so such connections are not allowed to cross an untrusted Layer 2 domain. If an attacker can sniff auth traffic --- TACACS+ is particularly susceptible to decryption of the entire session including user credentials, whereas RADIUS is particularly susceptible to the possibility of authentication replay. Depending on the router vendor; the available functionality with each protocol, varies..... Cisco is most noted for providing rich functionality over TACACS+ for shell authorization and accounting, and providing very limited RADIUS support. It is not that RADIUS is limited --- its that your device vendor's RADIUS featureset is limited -- which, for all intents and purposes, means, the features available to you are more limited, if you use such gear.
On Dec 30, 2013, at 9:01 AM, Christian Kratzer <ck-lists@cksoft.de> wrote:
Hi, it is with radius afaik ... RADIUS does not support command authorization or accounting.
RADIUS protocol supports accounting; and there is no reason RADIUS start-stop accounting events cannot be sent for every shell command --- this is not a protocol limitation, this is a device implementation limitation. Some devices can provide per-command authorization by embedding the command being run in an Access-Request. RADIUS protocol response messages can encapsulate any attribute-value pair that can be sent in a TACACS response. using Vendor-specific attributes. There is a restriction on IOS devices, that arbitrarily forbids certain vendor-specific Attribute-value pairs from being encapsulated in the RADIUS reply message; per-command authorization is among prevented software capabilities of the router, not a limitation of the RADIUS protocol. http://wiki.freeradius.org/vendor/Cisco#Command-Authorization ' cisco-avpair = "shell:cmd=show" would do the trick to authorize the "show" command. except that there is a tiny note for the commands "cmd" and "cmd-arg" saying that they cannot be used for encapsulation in the Vendor-Specific space. These two are the ONLY ones.'
-jav
-- -JH