Re: [OPSAWG] I-D Action: draft-dahm-tacacs-security-01.txt

2022-09-02 Thread Marc Huber
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

Re: [OPSAWG] TACACS+ SSH Enhancements Document

2022-09-04 Thread Marc Huber
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: -

Re: [OPSAWG] TACACS+ SSH Enhancements Document

2022-09-08 Thread Marc Huber
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

Re: [OPSAWG] TACACS+ SSH Enhancements Document

2022-11-03 Thread Marc Huber
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

Re: [OPSAWG] TACACS+ SSH Enhancements Document

2022-11-07 Thread Marc Huber
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,

Re: [OPSAWG] TACACS+ SSH Enhancements Document

2022-11-23 Thread Marc Huber
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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-01.txt

2022-12-01 Thread Marc Huber
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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt

2023-07-05 Thread Marc Huber
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

[OPSAWG]Re: TACACS+ w/ TLS 1.3 implementations

2024-06-27 Thread Marc Huber
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

[OPSAWG]Re: OPSAWG Digest, Vol 205, Issue 20

2024-07-09 Thread Marc Huber
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

Re: [OPSAWG] TACACS+ SSH Enhancements Document

2022-08-31 Thread Marc Huber
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