On Sun, Dec 28, 2014 at 9:21 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Dec 28, 2014 at 6:02 PM, Robert Drake <rdrake@direcpath.com> wrote: [snip] Juniper, at least, does the authorization cache on the device trick... That seems nice...
and I wonder what percentage of 'users' a vendor has actually USE tac+ (or even radius). I bet it's shockingly low...
Well, the percentage of users doing per-command authorization is probably much lower than the percentage simply using Tac+ for login authentication and accounting only or accounting and exec authorization. What happens in this case in terms of failure handling is probably OK for the common scenario. For many use cases it should probably be a workable tradeoff to simply have AAA server reply with the shell:priv-lvl=1 or shell:priv-lvl=10, and make the choice to authorize commands locally by customizing which commands different privilege level numbers have, and make sure all devices have the same scheme; limiting AAA usage to once per shell. The cases where that's no solution, are most likely PCI or other higher security environments where the usability problems with TACACS+ failover simply have to be accepted, use a dedicated OOB network for AAA servers, and a HA clustered pair of AAA servers dedicated to each and every site --- sharing a virtual service IP address.
So, here is my TACACS RFC christmas list: 1. underlying crypto RADIUS over TCP and DIAMETER have underlying crypto. Rfc6613: TLS or IPsec transport is shown as mandatory for RADIUS over TCP.
Getting to some answer other than: "F-it, put it i clear text" for new protocols on routers really is a bit painful... not to mention ITARs sorts of problems that arise.
The average cheap-o smartphone ships with a TLS library; I think it's safe to say your router should have one. They shouldn't have too many problems... after all, this type of equipment already includes SSH protocol. So why not have an option for setting up a SSH session to tunnel authentication requests over?
-chris
2. ssh host key authentication - having the router ask tacacs for an authorized_keys list for rdrake. I'm willing to let this go because many
I would be content for them to just support OpenSSH CA certificate-based authorization of a user's SSH key. If the key is signed by a trusted SSH CA, valid and not expired, and the session would be valid according to the certificate, then they can authenticate using one of their listed principals. Authenticate using key signed by valid certificate as first factor, perform second factor authentication against Kerberos server, authorize against LDAP or Tacacs server.
vendors are finding ways to do key distribution, but I'd still like to have a standard (https://code.google.com/p/openssh-lpk/ for how to do this over LDAP in UNIX)
SSSD is handling this on Redhat. It's probably best to consider that how to use an "openssh public ssh key" is specific to the OpenSSH application. It makes sense that if the public key is for use with GPG/PGP to authenticate, etc, then the LDAP attribute should be something different, again specific to the application and the key format that application uses. http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/user-keys.h... AuthorizedKeysCommand or PubKeyAgent is used on the openssh server. But within the single-signon daemon SSSD-Ldap; the LDAP attribute for a user object's SSH key is a configurable setting. Within the IPA LDAP schema, there is an added ipaSshPubKey user attribute. I think this as close as you get to a 'standard' for now. dn: cn=schema add:attributeTypes: ( 2.16.840.1.113730.3.8.11.31 NAME 'ipaSshPubKey' DESC 'SSH public key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'IPA v3' ) add:objectClasses: ( 2.16.840.1.113730.3.8.12.11 NAME 'ipaSshGroupOfPubKeys' ABSTRACT MAY ipaSshPubKey X-ORIGIN 'IPA v3' ) add:objectClasses: ( 2.16.840.1.113730.3.8.12.12 NAME 'ipaSshUser' SUP ipaSshGroupOfPubKeys AUXILIARY X-ORIGIN 'IPA v3' ) add:objectClasses ( 2.16.840.1.113730.3.8.12.13 NAME 'ipaSshHost' SUP ipaSshGroupOfPubKeys AUXILIARY X-ORIGIN 'IPA v3' )
3. authentication and authorization caching and/or something else
-- -JH