The state of TACACS+

Jimmy Hess mysidia at gmail.com
Mon Dec 29 06:38:12 UTC 2014


On Sun, Dec 28, 2014 at 9:21 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Sun, Dec 28, 2014 at 6:02 PM, Robert Drake <rdrake at 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.html
 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



More information about the NANOG mailing list