On Mon, Dec 29, 2014 at 04:25:56PM +0900, Randy Bush wrote:
Rfc6613: TLS or IPsec transport is shown as mandatory for RADIUS over TCP.
sweet. can you ref conforming implementations?
FreeRADIUS and Radiator can do RADSEC, as well as radsecproxy, so
it can be used to protect e.g.
On 12/28/2014 5:02 PM, Robert Drake wrote:
3. authentication and authorization caching and/or something else
Is this related to the TACACS server being down and the long time out to
hit local authen/author? Sorry, a little late to this party :)
tv
Far too much discussion on this IMO. If you're that paranoid about it,
just use the nuclear launch keys approach. Create the local account
password, split it, give half of it to one party, half to the other. Then
two separate parties must be engaged to use the account. Done.
Sincerely,
Clay
We are able to implement TACAS+. It is my understanding this a fairly old
protocol, so are you saying there are numerous bugs that still need to be
fixed?
A question I have is TACAS+ is usually hosted on a server, and networking
devices are configured to reach out to the server for
Colton,
Yes, that's the 'normal' way of setting it up. Basically you still have to
configure a root user, but that user name and password is kept locked up
and only accessed in case of catastrophic failure of the remote
authentication system. An important note is to make sure that the fail
safe
Scott,
Thanks for the response. How do you make sure the failsafe and/or root
password that is stored in the device incase remote auth fails can't be
accessed without having several employees engaged? Are there any mechanisms
for doing so?
My fear would be we would hire an outsourced tech. After
Change the root when any senior person leaves. It shouldn't be known to a
large set of staff members. During the bubble burst rifs we were changing them
on 40k+ devices every week. Make sure you verify the pass before disconnecting
the login acct making the change. Also make sure you
On Mon, Dec 29, 2014 at 09:32:51AM -0600, Colton Conor wrote:
Scott,
Thanks for the response. How do you make sure the failsafe and/or root
password that is stored in the device incase remote auth fails can't be
accessed without having several employees engaged? Are there any mechanisms
for
Colton,
The best thing is to create the password with a random generator so it's
impossible for most people to memorize in a short amount of time. It
should be ~14 characters long with mixed cases, numbers, and special
characters. That password should be tested once and then put in an
envelope
On 12/29/2014 10:32 AM, Colton Conor wrote:
My fear would be we would hire an outsourced tech. After a certain
amount of time we would have to let this part timer go, and would
disabled his or her username and password in TACAS. However, if that
tech still knows the root password they could
At 11:06 AM 12/29/2014, you wrote:
On 12/29/2014 10:32 AM, Colton Conor wrote:
My fear would be we would hire an outsourced tech. After a certain
amount of time we would have to let this part timer go, and would
disabled his or her username and password in TACAS. However, if
that tech still
At 11:06 AM 12/29/2014, you wrote:
On 12/29/2014 10:32 AM, Colton Conor wrote:
My fear would be we would hire an outsourced tech. After a certain
amount of time we would have to let this part timer go, and would
disabled his or her username and password in TACAS. However, if
that tech still
On 12/28/2014 10:21 PM, Christopher Morrow wrote:
and I wonder what percentage of 'users' a vendor has actually USE tac+
(or even radius). I bet it's shockingly low...
true.. even in large-ish environments centralized authentication
presents problems and can have a limited merit. Up to some
In the Cisco world the AAA config is typically set up to try tacacs first,
and local accounts second. The local account is only usable if tacacs is
unavailable. Knowledge of the local username/password does not equate to
full time access with that credential. Also, you would usually filter the
Glad to know you can make local access only work if TACAS+ isn't available.
However, that still doesn't prevent the employee who know the local
username and password to unplug the device from the network, and the use
the local password to get in. Still better than our current setup of having
one
If someone has physical access to a Cisco router they can initiate a
password recovery; tacacs vs local account doesn't matter at that point.
On Mon, Dec 29, 2014 at 12:28 PM, Colton Conor colton.co...@gmail.com
wrote:
Glad to know you can make local access only work if TACAS+ isn't
available.
Making the TACAC+ server unavailable is fairly easy - a small LAN-based
DDoS would do it, or a firewall rule change somewhere in the middle. Either
would cause the router to failover to it's local account.
- this is based on the fact that said attacker has some sort of access
previously and
: NANOG [nanog-boun...@nanog.org] On Behalf Of Colton Conor
[colton.co...@gmail.com]
Sent: Monday, December 29, 2014 9:28 AM
To: Michael Douglas
Cc: NANOG
Subject: Re: The state of TACACS+
Glad to know you can make local access only work if TACAS+ isn't
available.
However, that still doesn't
Picking back up where this left off last year, because I apparently only
work on TACACS during the holidays :)
On 12/30/2013 7:28 PM, Jimmy Hess wrote:
Even 5 seconds extra for each command may hinder operators, to the extent
it would be intolerable; shell commands should run almost
On Sun, Dec 28, 2014 at 6:02 PM, Robert Drake rdr...@direcpath.com wrote:
Picking back up where this left off last year, because I apparently only
work on TACACS during the holidays :)
avoiding relatives? :)
On 12/30/2013 7:28 PM, Jimmy Hess wrote:
Even 5 seconds extra for each command
I don't understand why vendors and operators keep turning to TACACS. It
seems like they're often looking to Cisco as some paragon of best security
practices. It's a vulnerable protocol, but some times the only thing to
choose from.
One approach to secure devices that can support only TACACS or
On (2013-12-30 05:06 -0500), Robert Drake wrote:
TACACS+ was proposed as a standard to the IETF. They never adopted
it and let the standards draft expire in 1998. Since then there
If continued existence of TACACS+ can be justified at IETF level, in parallel
with radius and diameter, I have
I don't think radius nor kerberos nor ssh with certificates supports
command authorization, do they?
On Dec 30, 2013 6:33 AM, Saku Ytti s...@ytti.fi wrote:
On (2013-12-30 05:06 -0500), Robert Drake wrote:
TACACS+ was proposed as a standard to the IETF. They never adopted
it and let the
Nor accounting...
On Dec 30, 2013 8:48 AM, Christopher Morrow christopher.mor...@gmail.com
wrote:
I don't think radius nor kerberos nor ssh with certificates supports
command authorization, do they?
On Dec 30, 2013 6:33 AM, Saku Ytti s...@ytti.fi wrote:
On (2013-12-30 05:06 -0500), Robert
On (2013-12-30 08:49 -0500), Christopher Morrow wrote:
Nor accounting...
I think this is probably sufficient justification for TACACS+. I'm not sure if
command authorization is sufficient, as you can deliver group via radius which
maps to authorized commands.
But if you must support accounting,
Hi,
On Mon, 30 Dec 2013, Christopher Morrow wrote:
I don't think radius nor kerberos nor ssh with certificates supports
command authorization, do they?
it is with radius afaik ...
Greetings
Christian
--
Christian Kratzer CK Software GmbH
Email: c...@cksoft.de
On Dec 30, 2013 9:01 AM, Saku Ytti s...@ytti.fi wrote:
On (2013-12-30 08:49 -0500), Christopher Morrow wrote:
Nor accounting...
I think this is probably sufficient justification for TACACS+. I'm not
sure if
command authorization is sufficient, as you can deliver group via radius
which
On Dec 30, 2013, at 9:01 AM, Christian Kratzer ck-li...@cksoft.de wrote:
Hi,
On Mon, 30 Dec 2013, Christopher Morrow wrote:
I don't think radius nor kerberos nor ssh with certificates supports
command authorization, do they?
it is with radius afaik ...
RADIUS does not support command
On Mon, Dec 30, 2013 at 8:11 AM, Javier Henderson jav...@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
On Dec 30, 2013, at 6:42 PM, Jimmy Hess mysi...@gmail.com wrote:
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
On Mon, Dec 30, 2013 at 6:05 PM, Javier Henderson jav...@kjsl.org wrote:
Are you talking about Cisco routers? The default timeout value for TACACS+
is five seconds, so I’m not sure where you’re coming up with thirty
seconds, unless you have seven servers listed on the router and the first
31 matches
Mail list logo
