Re: [OPSAWG] FW: New Version Notification for draft-dahm-opsawg-tacacs-01.txt

> We would really appreciate any feedback on this document. Personally I > think it is really useful, but we need the WG to review and provide > feedback. I have read this draft and support publication. > On Sun, Oct 4, 2015 at 4:18 PM, Douglas Gash (dcmgash) > wrote: > >

Re: [OPSAWG] TACACS+, a suggestion

Seems that in the time bikeshedding, this could have already been in WGLC. Outstanding work! ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

Why is there IPR on this draft? Is this because of section 3? A section that is unnecessary and could be entirely removed without affecting the draft in any manner? Otherwise, I think it absolutely absurd that there is IPR on this document. ___

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

Sun, Apr 15, 2018 at 02:52:43PM +, li zhenqiang: > Why do you think this is unusual and not common? Possibly, with due respect, because he is not an operator? While ASes often do so internally, not all reveal it externally or not ubiquitously. Browse https://onestep.net/communities/ to

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

Sun, Apr 15, 2018 at 12:32:49PM -0400, Joel M. Halpern: > (the authors would not have written it if no one wanted it.) eh, that might not be a valid argument :) > Also, one of the arguments for doing this in the router is that you can > get more timely and precise correlation. Except that for

Re: [OPSAWG] ??: RE: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

> Could you provide any more details on what specifically is being > patented? Given that the document does not define new protocol mechanics > and only adds in codepoints and element encodings, what can be > practically patented there? Indeed. Please just withdraw the IPR. Or, shall we

[OPSAWG] [internet-dra...@ietf.org: I-D Action: draft-dahm-tacacs-security-00.txt]

, and SSH Public Keys Authors : Thorsten Dahm Douglas Gash Andrej Ota John Heasley Filename: draft-dahm-tacacs-security-00.txt Pages : 22 Date: 2022-03-31

Re: [OPSAWG] I-D Action: draft-dahm-tacacs-tls13-00.txt

Thu, Jun 30, 2022 at 07:09:14PM +, heasley: > Thu, Jun 30, 2022 at 03:05:33PM +, Joe Clarke (jclarke): > > [JC] As chair, I will call for adoption of this work by the WG. I read > > Alan’s recent reply and understand how he feels concerning this approach to > > m

Re: [OPSAWG] I-D Action: draft-dahm-tacacs-tls13-00.txt

Fri, Jul 08, 2022 at 10:14:02AM -0400, Alan DeKok: > On Jul 8, 2022, at 10:06 AM, Joe Clarke (jclarke) > wrote: > > > > I was saying that when I read Alan’s comments it seemed like he wanted for > > T+ protocol changes and extensibility added to the tacacs-tls13 draft > > I would prefer

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

Andrej Ota > John Heasley > Filename: draft-dahm-opsawg-tacacs-security-00.txt > Pages : 14 > Date: 2022-06-02 > > Abstract: >The TACACS+ Protocol [RFC8907] provides device administration for &

Re: [OPSAWG] I-D Action: draft-dahm-tacacs-tls13-00.txt

Wed, Jun 29, 2022 at 03:48:30PM +, Joe Clarke (jclarke): > Thanks for taking on this work and to Alan for the initial round of comments. > I've read this draft, and below are my comments as a contributor/individual. Hey, Thanks for reviewing. I'll make the suggested updates which I've

Re: [OPSAWG] I-D Action: draft-dahm-tacacs-tls13-00.txt

Thu, Jun 30, 2022 at 03:05:33PM +, Joe Clarke (jclarke): > See below. > > > > Section 3.2 > > > > You make reference to the proper "TACACS+ Session", but there is no > > reference either in your terminology section or to the T+ RFC. I feel a > > reference is needed here. > > This is

Re: [OPSAWG] I-D Action: draft-dahm-tacacs-tls13-00.txt

> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : TACACS+ TLS 1.3 > Authors : Thorsten Dahm > Douglas Gash > Andrej Ota >

Re: [OPSAWG] [internet-dra...@ietf.org: I-D Action: draft-dahm-tacacs-security-00.txt]

Tue, May 03, 2022 at 09:58:31AM +0200, Alan DeKok: > On May 3, 2022, at 12:23 AM, heasley wrote: > >> It may be good to have a note that the existing TACACS+ port can be used > >> for TLS, if both ends are configured to require TLS. That means systems > >> can us

Re: [OPSAWG] [internet-dra...@ietf.org: I-D Action: draft-dahm-tacacs-security-00.txt]

Tue, Apr 05, 2022 at 05:15:21PM -0400, Alan DeKok: > This is a quick review based on first impressions. Hi. Thanks for the cursory review and again for your comments prior to submission. I'll try to address your remaining points. > It may be good to have a note that the existing TACACS+

Re: [OPSAWG] Status of T+/TLS work

Tue, Oct 18, 2022 at 12:14:39PM +, Joe Clarke (jclarke): > Hello, authors. Ahead of IETF 115, we’d like to get an update on the status > of this work. Since adoption, on-list traffic has been silent (though there > has been discussion on the SSH work). > > I believe there are still some

Re: [OPSAWG] Status of T+/TLS work

Mon, Oct 31, 2022 at 04:59:33PM +, Joe Clarke (jclarke): > Thanks for the summary, heas. > > I re-read the text, and, yes, you do cover a number of the situations > (including potential ways to handle clients with TLS going forward). On > another doc I reviewed as part of the OPS DIR, it

Re: [OPSAWG] I-D Action: draft-dahm-opsawg-tacacs-security-01.txt Douglas Gash , John Heasley ,

ecurity and SSH Public Keys > Authors : Thorsten Dahm > Douglas Gash > Andrej Ota > John Heasley > Filename: draft-dahm-opsawg-tacacs-security-01.txt > Pages : 14

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

: TACACS+ TLS 1.3 > Authors : Thorsten Dahm > Douglas Gash > Andrej Ota > John Heasley > Filename: draft-ietf-opsawg-tacacs-tls13-01.txt > Pages : 11 >

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

Thu, Dec 01, 2022 at 06:00:53PM +, Joe Clarke (jclarke): > I’ve read the -01 revision, and the new text in Section 4 seems logical to > me. Being a bit pedantic, it might be good to reference that section when > deciding on the correct ERROR to send. No problem; that will be in the next

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

> From: Alan DeKok > On Dec 1, 2022, at 1:14 PM, Marc Huber wrote: > We're just going through this with RADIUS. We defined RADIUS over TLS 10 > years ago, and left the MD5 obfuscation in. > > We're now updating it to remove MD5. In hindsight, it was a mistake. > Among other things,

Re: [OPSAWG] TACACS+ SSH Enhancements Document

> Hi Douglas et al., > > I'd suggest to reduce your proposed model to: > > - The TACACS+ authentication is extended to allow the TACACS+ > client to request the SSH client's public key from the TACACS+ server, > based on the client's public key fingerprint, for verification. > > This results in

Re: [OPSAWG] Update on T+/TLS

Wed, Mar 08, 2023 at 07:34:21PM +, Joe Clarke (jclarke): > Hello, authors. I’m not sure if you’re planning to request a speaking slot > for IETF 116, but we would like to get an update of the current state of this > work (and author’s thoughts on next steps). After publishing -01, there

Re: [OPSAWG] Update on T+/TLS

Fri, Mar 10, 2023 at 07:14:07PM +, Joe Clarke (jclarke): > Thanks, heas. Will you be getting this next rev in before the cut-off on > Monday? > > Joe Honestly, I had missed that Monday was the cut-off date. I will try to have at least the new version of the TLS draft submitted. Cheers

[OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02

> This document was presented in Prague. The authors have addressed all the > comments and believe it's ready for further working group discussion. > > https://tools.ietf.org/html/draft-zheng-opsawg-tacacs-yang-02 > > This email starts a two weeks poll for adoption. > > If you support adopting

[OPSAWG] Request for comment regarding TLS in TACACS+

With draft-ietf-opsawg-tacacs-13 nearing RFC status, we intend to return to one of the subjects with which this draft began: adding TLS support to TACACS+. We will submit a draft to OPSAWG adding TLS support for TACACS+ to include: - separate well-known port for TLS (no STARTTLS

[OPSAWG] re opsawg-tacacs-yang & ietf-system user-authen-order

Regarding the question, on the second to last page of the opsawg-tacacs-yang presentation slides, about the must in model ietf-system, which I believe was whether to add a must for tacacs, remove the must for radius, or do nothing; that must seems wrong to me. I would expect the system to react

Re: [OPSAWG] re opsawg-tacacs-yang & ietf-system user-authen-order

Wed, Nov 20, 2019 at 05:30:29AM +, Joe Clarke (jclarke): > Lada replied on YANG docs with a suggestion for the T+ module authors. While > we can’t affect the authentication-order node, the tacacsplus container could > be defined like: > > augment "/sys:system" { > container tacacs { >

Re: [OPSAWG] [Last-Call] Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

Fri, May 08, 2020 at 09:45:51AM +, Wubo (lana): > I'll have to look at the model again; i do not recall if the model allows for > particular accounting types w/o augmentation. > > [Bo] The accounting type you mentioned, I understand, is that the System > model needs to be augmented.

Re: [OPSAWG] [Last-Call] Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

Thu, May 07, 2020 at 03:02:24PM +0200, Ladislav Lhotka: > > [Bo] Please see if the definition below is correct: > > typedef tcsplus-server-type { > >type bits { > > bit authentication { > >description > > "When set, the server is an authentication

Re: [OPSAWG] TACACS++, please...

es, Thorsten, Andrej and I are actively engaged, and have been joined by > >> a new team member (John Heasley). > >> > >> > >> > >> There may be one or two minor other additions to enhance security that > >> are also coming along for submissio

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

Andrej Ota > John Heasley > Filename: draft-dahm-tacacs-security-01.txt > Pages : 15 > Date: 2022-06-02 > > Abstract: >The TACACS+ Protocol [RFC8907] provides device administration for >routers, network