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. site-to-
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 C
ooks.
I hope this provides some insight to those that may need it.
From: 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
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 wanted
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
wrote:
> Glad to know you can make local access only work if TACAS+ isn't
> available. However, that still
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 de
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
i
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 ar
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 k
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 k
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 st
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 t
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
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 underst
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
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
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 authentication.
> Rfc6613: TLS or IPsec transport is shown as mandatory for RADIUS over TCP.
sweet. can you ref conforming implementations?
randy
On Sun, Dec 28, 2014 at 9:21 PM, Christopher Morrow
wrote:
> On Sun, Dec 28, 2014 at 6:02 PM, Robert Drake 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
On Sun, Dec 28, 2014 at 6:02 PM, Robert Drake 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 may hinder ope
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
instan
On Mon, Dec 30, 2013 at 6:05 PM, Javier Henderson 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
> six are dead/
On Dec 30, 2013, at 6:42 PM, Jimmy Hess 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
> which TACACS serve
On Mon, Dec 30, 2013 at 8:11 AM, Javier Henderson 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
On Dec 30, 2013, at 9:01 AM, Christian Kratzer 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 authorizati
On Dec 30, 2013 9:01 AM, "Saku Ytti" 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
> maps
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 (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,
Nor accounting...
On Dec 30, 2013 8:48 AM, "Christopher Morrow"
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" wrote:
>
>> On (2013-12-30 05:06 -0500), Robert Drake wrote:
>>
>> > TACACS+ was
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" 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 standard
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 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 RAD
Ever since first using it I've always liked tacacs+. Having said that
I've grown to dislike some things about it recently. I guess, there
have always been problems but I've been willing to leave them alone.
I don't have time to give the code a real deep inspection, so I'm
interested in other
34 matches
Mail list logo