I've had a closer look at draft-dahm-tacacs-security-01 this evening.
While I'm perfectly fine with the "Extended Authentication" packet
formats, I think it would make sense to add these extensions to "version
1.2" authorization and accouting packets, too. @the authors: please
consider adding tha
On Aug 31, 2022, at 10:41 PM, Alan DeKok wrote:
> My related question is what *else* do people envision doing with
> TACACS+? If it's 1-2 things and then done, a small change can be
> acceptable. If there's a long list of new things to do, then it's time
> to do TACACS+ 2.0.
My favorites are:
-
On Sept 08, 2022, at 12:47 p.m., Douglas Gash wrote:
The alternative approach is to utilise the authentication packet data field.
This field is used for all exchange of authentication materials in the current
T+ protocol for applications such as CHAP based authentication flows.
The exchange of
Hi,
apologies ... I've still some trouble to understand what kind of
advantage the "allow the TACACS+ client to request the public keys from
the TACACS+ server" option could give. On the implementation side, I
have absolutely no trouble about the "T+ sends public-key to router"
approach, that's e
er return an approriate return code, with the
public key in the data field, preferably in OpenSSH format
Please support this approach. I've even managed to released PoC code for
that, which virtually proves that all this is trivial to implement, both
on the client and server side.
Thanks,
Hi Heas,
thank you for reviving the topic!
On 23.11.2022 07:05, heasley wrote:
Does the Tacacs Server return the matching key to the Tacacs Client or
the fingerprint? In step 4, you wrote fingerprint, but wrote key below.
We believe returning the key is not strictly necessary, but might be
nec
Hi,
I've the gut feeling that
Peers MUST NOT use Obfuscation with TLS.
A TACACS+ client initiating a TACACS+ TLS connection MUST set the
TAC_PLUS_UNENCRYPTED_FLAG bit, thereby asserting that Obfuscation is
not used for the Session. All subsequent packets MUST have the
TAC_PLUS_U
Hi authors,
I still unsure whether the
Obsolescence of TACACS+ Obfuscation
section could hinder implementations and migrations using TLS wrappers
(load balancers, e.g.). I'd still suggest to change the "MUST" clauses
regarding obufuscation to "SHALL". There's no gain to change the
protocol at
Hi,
On 27.06.2024 17:01, Joe Clarke (jclarke) wrote:
Who has implemented this draft or are planning to do so?
https://github.com/MarcJHuber/event-driven-servers/tree/master/tac_plus-ng
is a TACACS+ server implementation supporting TLS1.3 and is quite likely
to match the draft requirements, bu
lly useful and would possibly aid in the adoption of this new
modality for T+. I would be in favor of option 2. I would also like
to hear from people like Rod Persky and Marc Huber who mentioned
possible implementations.
===
As a chair, I’m glad to see this email this morning. Going into today
I
Hi,
sorry to chime in, but this is getting out of hand.
This "new format" you think you're seeing isn't new, it's a slight
variation of the current implementations, with portions copied from
authorization/accounting to authentication, with wider argument lengths.
It perfectly suits the current c
11 matches
Mail list logo