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
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+ por
> 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
>
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
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 remov
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
&
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 defin
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
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 that
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 ou
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 wa
> 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
: TACACS+ TLS 1.3
> Authors : Thorsten Dahm
> Douglas Gash
> Andrej Ota
> John Heasley
> Filename: draft-ietf-opsawg-tacacs-tls13-01.txt
> Pages : 11
>
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 ver
> 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, leav
ecurity and SSH Public Keys
> Authors : Thorsten Dahm
> Douglas Gash
> Andrej Ota
> John Heasley
> Filename: draft-dahm-opsawg-tacacs-security-01.txt
> Pages : 14
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 was
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
__
> 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:
> > Dear Opsawg List,
> >
>
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
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 find
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 g
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.
___
OPSAWG
> 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 write
> Reviewer: Yingzhen Qu
> Review result: Has Issues
>
> 190 To ensure separation of TACACS+ traffic that uses TLS from that which
> 191 does not (Section 5.3), they will be deployed on different ports.
> Q: This seems to contradict with section 5.1.1, which says "TACACS+ servers
> that
Sun, Aug 04, 2024 at 04:38:27PM +, heasley:
> "will" probably ought be "SHOULD".
Sorry, that is wrong; this
"Instead, separate Non-TLS TACACS+ servers can be set up to cater for these
clients."
should change; s/can be/SHOULD be/
_
> We’re up to WG LC on this draft. We want to reconfirm any known IPR related
> to this work:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/
> Are you aware of any IPR that applies to draft identified above?
> Please state either:
"No, I'm not aware of any IPR that applies to
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
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
Fri, Jun 03, 2022 at 04:05:20AM +, John Heasley:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> > Title : TACACS+ Security and SSH Public Keys
> > Authors : Thorsten Dahm
> &g
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 functio
> 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
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 no
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 {
>m
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 server.
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. Current
36 matches
Mail list logo