Re: [OPSAWG] Update on T+/TLS

[heasley]

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 mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Update on T+/TLS

[heasley]

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 
> a discussion on whether or not the obfuscation should be allowed within the 
> TLS encap.  I don’t think that was concluded, though it seems like there is 
> more support for NO.
> 
> Speaking as chair, I’d like to see this move forward, and perhaps it’s in or 
> close to a state where we can do a WG LC?
> 
> Thanks.
> 
> Joe

Hey Joe,
We'd hoped to have an updated draft two weeks ago, but the delay is because
of me.  Just a lack of time.

We will have an update for both drafts next week.  I do not think that
the TLS draft is quite ready for a LC.  I expect that there will be at
least one more round of discussion.  I do hope that the other draft will
subsequently be ready for an adoption call.

Cheers

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

Hello, This submission has no changes from -00, it is only to bump the
expiration date.

Fri, Dec 09, 2022 at 11:38:29AM -0800, internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> Title   : TACACS+ Security and SSH Public Keys
> Authors : Thorsten Dahm
>   Douglas Gash
>   Andrej Ota
>       John Heasley
>   Filename: draft-dahm-opsawg-tacacs-security-01.txt
>   Pages   : 14
>   Date: 2022-12-09
> 
> Abstract:
>The TACACS+ Protocol [RFC8907] provides device administration for
>routers, network access servers and other networked computing devices
>via one or more centralized servers.  This document, a companion to
>the TACACS+ protocol [RFC8907], adds new packet formats to improve
>security and function and support for SSH [RFC4716] public keys.
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs-security/

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

> 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, leaving MD5 in means that it's difficult to run 
> implementations in a FIPS environment.
> 
>   Plus, what key do you use for the MD5 obfuscation?  Do you leave the old 
> one in the admin interfaces?  And add TLS?
> 
>   I think that the current approach is best.  Drop the 20+ year-old 
> obfuscation.  Just use modern crypto.

Speaking only for myself, I agree with Alan.  But, I am curious what
devices, that will adopt new TACACS specs, do not support TLS?

>   I'd suggest requiring TLS-PSK.  It's likely easy to update implementations 
> / interfaces to add a PSK.  In contrast, certificates are more complex.

We did consider TLS-PSK in-depth.  As I recall, without looking back at the
notes, we thought that this support might be best addressed in a separate
draft because we considered certificates to be the most secure solution
and it was not clear (to me) that (non-resumption) PSK was fully baked in
TLS1.3, eg: draft-ietf-tls-external-psk-guidance.

>   Plus, operational experience with RADIUS shows that certificate management 
> is a big problem.  There are many issues with certificates:
> 
> * do the client / server use Web CAs for certificate valdation?  Are these 
> web CAs shipped with the product?  How are they updated?
> 
> * If a private CA is used, then the implementations have to be updated to 
> allow for configuration of CAs in addition to client certs
> 
> * certificate expiry is rare enough that people forget how to renew them, but 
> often enough that they have to be renewed regularly
> 
> * web CAs won't issue certs for non-web use.  So to get a cert, you have to 
> claim you're putting it on a web server, and add id-kp-serverAuth in order to 
> pass web CA validation
> 
> * How are the certificates validated?  There is a long list of things which 
> can be done to validate the certificate.  Some RFCs have guidance, but 
> implementation experience shows that those aren't enough.
> 
>   I'd suggest checking the certificate validation rules in RFC 5216 and RFC 
> 9190  (EAP-TLS), and RFC 6614 (RADIUS/TLS).  The operational issues are 
> similar.  It may also be useful to look at RFC 7585 (dynamic server discovery 
> via DNS).
> 
>   I'd suggest also looking at the TLS configuration in FreeRADIUS here:  
> https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/raddb/mods-available/eap#L177
> 
>   It's for EAP-TLS, but the requirements for TACACS+ with TLS would be 
> similar.  There are a large number of options for configuring certificates, 
> validation methods, CAs, PSKs, etc.  Nearly all of these would be required 
> when TACACS+ is used with TLS.
> 

These are challanges for many.  But, support for certificate authentication
must improve as it becomes demanded for gnxi, netconf, telemetry, hiba,
sztp, and so on.

How certificates are rotated, how to load chains for a private CA or
to avoid issues if isolated, etc did not seem (to me) particular to
network devices and therefore did not need to be addressed in the draft.
We have tried to be minimalists about what belongs.

I was not aware that some CAs would only issue certificates for web.

Thanks, I will look at those references (again).  We did take clues from
reading about TLS support for other protocols, including syslog and radius.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

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 version.  Thanks

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

Wed, Nov 30, 2022 at 09:04:04PM -0800, internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Operations and Management Area Working Group 
> WG of the IETF.
> 
> Title   : TACACS+ TLS 1.3
> Authors : Thorsten Dahm
>   Douglas Gash
>   Andrej Ota
>   John Heasley
>   Filename: draft-ietf-opsawg-tacacs-tls13-01.txt
>   Pages   : 11
>   Date: 2022-11-30
> 
> Abstract:
>The TACACS+ Protocol [RFC8907] provides device administration for
>routers, network access servers and other networked computing devices
>via one or more centralized servers.  This document, a companion to
>the TACACS+ protocol [RFC8907], adds Transport Layer Security
>(currently defined by TLS 1.3 [RFC8446]) support and obsoletes former
>inferior security mechanisms.
> 

This addresses two of the comments made by Joe Clarke.  Among which,
Joe asked that mishandling of the TAC_PLUS_UNENCRYPTED_FLAG in a TLS
connection be treated as FAIL, which means that the authen or author
failed and the client would stop and not proceed to other servers or
methods.

Upon reviewing to make this change, we concluded that this was not
quite the correct behavior, based on the current behavior of similar
errors in RFC8907 (S4.5 specifically), it should proceed to other servers
or methods.

So, the draft, in S4, now specifies returning ERROR rather than FAIL or
ignoring the deprecated flag.  Hopefully, this change agrees with
everyone.

We still have some operators/security considerations to address and the
issues raised by Alan.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] TACACS+ SSH Enhancements Document

[heasley]

> 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 a simple one-time request-response exchange for each key
> the client presents:
> 
>  1. SSH client connects to SSH server (once)
>  2. SSH server calculates public key fingerprint/hash
>  3. SSH server queries TAC+ server for user/fingerprint
>  4. TAC+ server replies with PASS and fingerprint, or FAIL
>  5. SSH server verifies fingerprint
>  1. if match: continue with next step
>  2. if not match: continue with next client key (step 2)
>  6. SSH server accepts connection based on fingerprint match

Hey Marc,
Thanks for your suggestion.  It is a great idea.  We would like to ask
or present a few clarifying questions or comments, as follows.

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
necessary to fit into the openssh AuthorizedKeysCommand behavior, and is
not a burden.

We think that you are suggesting that both the Tacacs Server *and* the
Tacacs Client/SSH Server validate the key, rather than the SSH server
blindly accepting the Tacacs PASS/FAIL.  Is that correct?

We think that the hash type for the fingerprint must be included in the
packets between the Tacacs speakers.  The hash type has changed before and
we should expect it will change again.

Are you suggesting the tacacs exchange of fingerprints be binary or encoded
to an ascii representation?  I presume base64 encoded.

Does step 5.2 imply a Tacacs session per-key offered by the SSH client,
or a continuation of the existing session?  Suspect you are omitting the
detail here, but a continuation is our expectation.

It seems like there must be a step 7, where the Tacacs Client informs the
Tacacs Server of the result of Step 2 (eg: no more keys to offer) or 6 (eg:
fingerprint match result).

> This is even compatible with OpenSSH's "AuthorizedKeysCommand" model. It
> can't get easier than that, and it just works.
> 
> On the TAC+ side:
> 
>   * #define TAC_PLUS_AUTHEN_TYPE_SSHKEY or whatever (my PoC code uses
> "8", but YMMV)
>   * let the TAC+ client start an authC request with that code, with
> username set and the data field set to the key hash
>   * let the TAC+ server return an approriate return code, with the
> public key in the data field, preferably in OpenSSH format
  ^^

We, or I, do not understand the argument for the openssh format.  The
ietf has the rfc4716 format.  Why wouldn't we use that?  I realize that
might be a whole lot of opinion, which is ok.

> 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.

We'd like to see your code, if you can share it.

> Thanks,
> 
> Marc

Thanks again, Marc.

Prost

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

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 was decided that grouping 
> text about (in that case) forward-looking considerations was worth it.
> 
> In this case, the document is short, and perhaps that isn’t needed.  I defer 
> to the general views of the WG and the authors on this.

Super; thanks!  I will publish the current version with the other fixes that
you requested later today.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

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 outstanding edits to make on this work based 
> on adoption feedback, and we’d like to continue to progress this.  When do 
> you think you’ll have a -01 ready for review?

Hey Joe,  You had raised 3 questions/requests.  Of these, we have addressed
two in unpublished text, but the third we find ourselves unsure about what
you want.

You'd asked for an operators considsrations sections.  More specifically,
fallback to legacy T+ and migration to certificates.  We feel that some,
perhaps most, of this is covered in various sections of the current
document, particularly the security considerations section.

So, we want to ask if the existing text is sufficient (excluding the
omission of migration to certificates) or if you would like duplication of
these detail in an operations consideration section?  We also considered
splitting the Security considerations section, trying to separate ops from
implementation.  There also might be opportunity to point to existing
documents.  Please guide us.

Alan DeKok raised two TLS-related questions.  No one else commented about
these, so we are asking some other TLS experts to comment.

Douglas is drafting a more complete description of the alternative SSH
pubkey syntax & process, to which WG response was more positive than the
original proposal.

We have not received any comments besides what was on the WG maillist.  We
have solicited comment from a few vendors about both drafts, which has been
positive and supports the approach of limiting change, compared to
re-engineering the protocol for a more modern approach.

-heas

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

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 the tls13 draft is just "TACACS+ over TLS".
> 
>   I also reviewed the proposed additions to TACACS+ which is currently in the 
> tls13 draft.  But I believe that they belong elsewhere.

There are no other additions in dahm-tacacs-tls13, only deprecations
related to adding TLS.  Perhaps you are thinking of the original composite
draft, which we split by request, or the second draft from that split
(dahm-opsawg-tacacs-security).

The next version -f dahm-tacacs-tls13 *will* add one thing, a status code
that is necessary to fulfill Joe's request about handling the deprecation
of the unencrypted flag.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

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 
> > more of a straight TLS encap around T+.  I would like to hear what others 
> > in the WG think.
> 
> Speaking for myself only; I might have misunderstood this point of Alan's
> and will have to review that email.  I think that the approach is
> straight-forward; start tls, once established, start tacacs, tacacs, end
> tacacs, end tls.  How much easier could it be.
> 
> We did specify a few TLS constraints, that Alan questioned.  We're open to
> discussing those details, but I think we need input from more tls experts
> and believe this can occur after adoption.  IIRC, that was our response at
> the beginning of May when the composite draft was submitted.

Hey Joe.
We reviewed the emails and draft and have concluded that we do not
understand what you mean by "more of a straight TLS encap around T+."
The proposal is as I suggested above.

https://www.ietf.org/id/draft-dahm-tacacs-tls13-00.html

There is text or lack of regarding SNI, resumption ticket lifetime, and
0RTT data that Alan has commented about, but otherwise nothing unusual.
We believe the text is correct but are not TLS experts and think that
these can wait for adoption.

Please explain which part is not straight.  Are you perhaps refering to
a part of the other draft?

https://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs-security/

Thanks

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

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 defined in rfc8907 S3.5 and S2 of the draft refers to 8907 S3.  Is
> this not an acceptable way to do this?
> 
> [JC] It struck me as warranting a 2.x sub-section.

Do you mean repeat the definitions or have a subsection saying X, Y, Z defs
are from 8907 S3?  We were trying to avoid duplication.

> > Section 4
> >
> > "The TACACS+ server or client receiving TACACS+ Packets MUST process
> >the packet as if TAC_PLUS_UNENCRYPTED_FLAG was set.  The actual value
> >of TAC_PLUS_UNENCRYPTED_FLAG flag in the TACACS+ header MUST be
> >ignored."
> >
> > But what if the flag isn’t set and obfuscation is used?  That’s an error, 
> > and MUST result in the termination of the Session (at least that’s what I 
> > would think).  This should be clarified,
> 
> The sections says that the flag MUST be ignored on receipt and SHOULD set
> on transmission.  I will attempt to make it clearer.
> 
> This seems like a common way to deprecate a flag.  Do you still think that
> the unset flag on receipt should be an error?
> 
> [JC] I personally do as it could be that obfuscation is being done and this 
> will ultimately lead to the inability to process the PDU.  That said, I’m 
> more in favor of a strong obsolescence of the obfuscation.

ok.

> > Overall, I think this document warrants an Operators Considerations section 
> > to describe interoperability with legacy T+.  That is, thoughts around 
> > configuring a fallback legacy T+ server along side a tacacss server (or 
> > servers); thoughts on migrating from a shared key to certificate-based 
> > validation; etc.
> >
> > You address some of this in different parts of the document where you talk 
> > about PSKs, mixing legacy and tacacss on a single server, and the need to 
> > provide some port flexibility, but I think a centralized section might help 
> > bring focus to those migrating to this.
> 
> Sure, completely reasonable.  But I don't want to expend that effort unless
> this will be adopted.  Seems like that could lead to quite a bit of
> rearrangement.
> 
> > Additionally, if there are working or PoC implementations of this, some 
> > lessons learned (perhaps in an appendix) could be useful.
> 
> There are none that I know of.  I would not make that effort unless there is
> adoption or at least a commitment to adopt the draft.
> 
> [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 
> more of a straight TLS encap around T+.  I would like to hear what others in 
> the WG think.

Speaking for myself only; I might have misunderstood this point of Alan's
and will have to review that email.  I think that the approach is
straight-forward; start tls, once established, start tacacs, tacacs, end
tacacs, end tls.  How much easier could it be.

We did specify a few TLS constraints, that Alan questioned.  We're open to
discussing those details, but I think we need input from more tls experts
and believe this can occur after adoption.  IIRC, that was our response at
the beginning of May when the composite draft was submitted.

Prost

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  
>  
> Title   : TACACS+ Security and SSH Public Keys
> Authors : Thorsten Dahm
>   Douglas Gash
>   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
>routers, network access servers and other networked computing devices
>via one or more centralized servers.  This document, a companion to
>the TACACS+ protocol [RFC8907], adds new packet formats to improve
>security and function and support for SSH [RFC4716] public keys.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs-security/
>  
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-dahm-opsawg-tacacs-security-00.html


We have received no comments about this draft, which I presume means no
technical objections exist.  So, I would like to ask the Chairs for an
adoption call.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

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 removed from your message.

> 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 defined in rfc8907 S3.5 and S2 of the draft refers to 8907 S3.  Is
this not an acceptable way to do this?

> Section 4
> 
> "The TACACS+ server or client receiving TACACS+ Packets MUST process
>the packet as if TAC_PLUS_UNENCRYPTED_FLAG was set.  The actual value
>of TAC_PLUS_UNENCRYPTED_FLAG flag in the TACACS+ header MUST be
>ignored."
> 
> But what if the flag isn’t set and obfuscation is used?  That’s an error, and 
> MUST result in the termination of the Session (at least that’s what I would 
> think).  This should be clarified,

The sections says that the flag MUST be ignored on receipt and SHOULD set
on transmission.  I will attempt to make it clearer.

This seems like a common way to deprecate a flag.  Do you still think that
the unset flag on receipt should be an error?

> Overall, I think this document warrants an Operators Considerations section 
> to describe interoperability with legacy T+.  That is, thoughts around 
> configuring a fallback legacy T+ server along side a tacacss server (or 
> servers); thoughts on migrating from a shared key to certificate-based 
> validation; etc.
> 
> You address some of this in different parts of the document where you talk 
> about PSKs, mixing legacy and tacacss on a single server, and the need to 
> provide some port flexibility, but I think a centralized section might help 
> bring focus to those migrating to this.

Sure, completely reasonable.  But I don't want to expend that effort unless
this will be adopted.  Seems like that could lead to quite a bit of
rearrangement.

> Additionally, if there are working or PoC implementations of this, some 
> lessons learned (perhaps in an appendix) could be useful.

There are none that I know of.  I would not make that effort unless there is
adoption or at least a commitment to adopt the draft.

Thanks

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

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 use existing firewall rules, etc. for TACACS+TLS.
> > 
> > We discussed this and question whether this needs to be discussed in
> > the (any) document, because it is not unlike any other service, which may
> > be configured by the admin to use any port they wish.
> 
>   The point is to suggest that it can be done.  i.e. It's acceptable for 
> people to manually configure both client and server as both (a) TLS, and (b) 
> using port 49.
> 
>   i.e. just drop the use of legacy TACACS+ entirely.

This has been address in draft-dahm-tacacs-tls13-00.

> > We also question if suggesting the use of 49/tcp will incite its use and
> > therefore the pitfalls described in S8.2?.
> 
>   Allowing a new port just for TLS is fine, too.  But I do agree that 
> STARTTLS is not useful.
> 

The other items that you mention have not yet been.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

> 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
>   John Heasley
>   Filename: draft-dahm-tacacs-tls13-00.txt
>   Pages   : 11
>   Date: 2022-06-02
> 
> Abstract:
>The TACACS+ Protocol [RFC8907] provides device administration for
>routers, network access servers and other networked computing devices
>via one or more centralized servers.  This document, a companion to
>the TACACS+ protocol [RFC8907], adds Transport Layer Security
>(currently defined by TLS 1.3 [RFC8446]) support and deprecates
>former inferior security mechanisms.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-dahm-tacacs-tls13/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-dahm-tacacs-tls13-00.html
> 

This draft represents the TLS support portion of the original draft.

The separation was requested by the Chairs and Alan DeKok.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[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
>   Douglas Gash
>   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 access servers and other networked computing devices
>via one or more centralized servers.  This document, a companion to
>the TACACS+ protocol [RFC8907], adds new packet formats to improve
>security and function and support for SSH [RFC4716] public keys.
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-dahm-tacacs-security/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-dahm-tacacs-security-01.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-dahm-tacacs-security-01

This version represents the latter part of the separation of TLS
support from other topics that were part of the previous version.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

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+ port can be used 
> for TLS, if both ends are configured to require TLS.  That means systems can 
> use existing firewall rules, etc. for TACACS+TLS.

We discussed this and question whether this needs to be discussed in
the (any) document, because it is not unlike any other service, which may
be configured by the admin to use any port they wish.

We also question if suggesting the use of 49/tcp will incite its use and
therefore the pitfalls described in S8.2?.

>   Section 3.2 says:
> 
> the resumption ticket_lifetime SHOULD be configurable, including a zero 
> seconds lifetime.
> 
>   I'm not sure what a "zero-seconds lifetime" would mean.  It may be better 
> to just omit the ticket in that case.

It means discard the ticket.  See rfc 8446 S4.6.1.  If I (not speaking
for the other authors) understand the TLS 1.3 spec correctly, it might not
be possible to omit the ticket.

Also, IIRC, we discussed resumption in the context of an anycast or
load-balanced deployment, where there is no guarantee that the same physical
server would answer a request and there is no standard mechanism to
distribute tickets among servers, so both client and server likely want the
option to disable tickets.  An attempt by a client to resume with a server
that does not have the given ticket can recover, but it takes time.

We also had a concern about 0-RTT, which we mention in S8.1.2.  I think
that 0-RTT is only possible with resumption - no ticket, no resumption,
and either side could enforce that.

Tell me if I'm wrong.  Else, if adopted, we would ask one of the TLS experts
to review and expect that they can help address resumption tickets and 0-RTT.
Russ Housley had made many helpful comments prior to adding these text to
the draft, but we have not yet asked that he review it again.

>   It would be good to mention that TLS Server Name Indication (SNI) SHOULD be 
> supported (https://datatracker.ietf.org/doc/html/rfc6066#section-3).  That 
> way one server can act as the TACACS+ host for multiple domains, and switch 
> between them using SNI.
> 

We had discussed this in the same context prior to submission.  We concluded
it was not necessary, and that less (text) is more.  I believe that data in
tacacs itself can be used to achieve this too.

We are not opposed to adding it and suspect there is some utility we are
missing.  We'd like more input and if there is interest, add it after
adoption.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

OPSAWG participants,
An initial draft for, among other things, adding TLS transport for TACACS+
has been submitted.  It needs your scrutiny and your comments are requested.

TiA

Note that this would update RFC8907, not 8097 indicated in the header.

- Forwarded message from internet-dra...@ietf.org -

From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-dahm-tacacs-security-00.txt
Date: Thu, 31 Mar 2022 11:20:44 -0700


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : TACACS+ Security, TLS, 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

Abstract:
   The TACACS+ Protocol [RFC8907] provides device administration for
   routers, network access servers and other networked computing devices
   via one or more centralized servers.  This document, a companion to
   the TACACS+ protocol [RFC8907], adds new packet formats to improve
   security and function, Transport Layer Security (currently defined by
   TLS 1.3 [RFC8446]) support, and support for SSH [RFC4716] public keys
   and deprecates former inferior security mechanisms.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-dahm-tacacs-security/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-dahm-tacacs-security-00.html

- End forwarded message -

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[John Heasley]

Thu, Jun 10, 2021 at 06:37:05PM -0400, Warren Kumari:
> On Thu, Apr 22, 2021 at 11:27 AM Warren Kumari  wrote:
> 
> > On Thu, Apr 22, 2021 at 11:18 AM Douglas Gash (dcmgash) 
> > wrote:
> >
> >> Hi Warren,
> >>
> >>
> >>
> >> Yes, 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 submission to the views of the WG.
> >>
> >
> > Just FYI, there are 459 people on the OpsAWG list; this means we have
> > almost 500 witnesses to what I'm going to interpret as "We'll have this
> > done in a few days/weeks" :-)
> >
> > Seriously though, thank you. The TACACS YANG document was discussed
> > recently, and a bunch of ADs said "Oi! We largely approved the original
> > document on the understanding that you'd fix this. Pay up now..."
> >
> >
> A gentle poke -- we eagerly await something to look at

Its coming, slowly.  Sorry, IETF is not a career for us.

If anyone would like to educate me about some finer details of TLS 1.3,
please contact me off-list.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[john heasley]

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. Currently, the System model only defines 
> authentication.

Hey.  System model has no accounting that I see.  what am i missing;
where are the accounting types defined?

> About the model, do you think the "all" bit is still necessary?

I am not advocating for nor against; only trying to explain how 'accounting'
type might be used, which seemed to be misunderstood.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[john heasley]

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.";
> >  }
> >  bit authorization {
> >description
> >  "When set, the server is an authorization server.";
> >  }
> >  bit accounting {
> >description
> >  "When set, the server is an accounting server.";
> >  }
> >  bit all {
> >description
> >  "When set, the server can be all types of TACACS+ servers.";
> >  }
> > 
> >}
> >description
> >  "server-type can be set to authentication/authorization/accounting 
> > or any combination of the three types.
> >   When all three types are supported, either "all" or the three 
> > bits setting can be used;
> >  }
> > 
> > 
> > I would drop the all.   I know that I suggested it, or an asterisk, but I 
> > was thinking that this was a common  case.  Joe suggests that no accounting 
> > is the commoner - I do not have sufficient exposure to know - in which case 
> > I would not bother with 'all'.  Whether or not to make auth/auth  the 
> > default I have no particular view on - as I say, I lack the exposure to be 
> > confident about that.
> > 
> > Having 'all' adds complexity, two ways to something, while making a small 
> > saving in message size - on balance, not worth it.
> 
> Agreed. Lada

Note that enabling certain types of accounting is rare, at least in my
opinion.  eg: enabling login accounting is not rare, while command
accounting is rare because it is expensive esp. on some particular devices.

Also, rare or not, enabling it for a tacacs server is sort of orthogonal.
it will not be used for that purpose unless some form of accounting is
enabled.

I'll have to look at the model again; i do not recall if the model allows
for particular accounting types w/o augmentation.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[john heasley]

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 {
>must "not(derived-from-or-self("
>   + "../sys:authentication/sys:user-authentication-order, 'tacacs')"
>   + "or server";
>list server {
>   ...
>}
>  }
> }
> 
> In this manner, T+ can provide enforcement.  Lada also mentioned that this 
> would have been a better way of handling RADIUS in ietf-system.  Certainly 
> this could be an item for a .bis, but not sure if this alone is worth taking 
> on that work.

That would be an improvement, but I still assert that this constraint is
not necessary nor desired - tacacs nor radius - if I'm reading that
correctly (XPATH often confuses me).

ps. parens imbalanced?

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[john heasley]

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 differently to missing sever
configuration than to a list of servers that all fail to respond.  Some
vendors have done this historically in cli.

Whether ietf-system should be changed, I do not know it is worth the effort.
If the WG agrees that its existence is wrong, that might be another question
for yang doctors.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[john heasley]

> 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 this document please say so, and please give an 
> indication of why you think it is important. Also please say if you will be 
> willing to review and help the draft.

I support adoption.  As with RADIUS, a model is necessary to configure
Tacacs+ servers on Tacacs+ client devices.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Request for comment regarding TLS in TACACS+

[john heasley]

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 functionality)
- address use of PSKs & TLS-Certs
 
We invite comment about these and/or other TLS-related functionality
for inclusion in the draft.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[heasley]

> 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 another without the IPR?

* I'd have read the patent application, but the registration form on the
  CN patent search page does not appear to work.
  
http://www.pss-system.gov.cn/sipopublicsearch/inportal/i18n.shtml?params=902F004CA61084A284089435EAAEA94F59CC921A916ADCEB

___
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

[heasley]

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 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

[heasley]

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 geolocation of 
> address blocks, upstream correlation seems to be quite sufficiently 
> stable and precise.  NLRI may come and go.  I fone has geo-information, 
> it is unlikely to change.

This may have been answered, but in case not or un-clear; what I and I
believe others refer to here as geo location, is different from what you
and randy are talking about in the sense of the IETF's prefixes.  I do not
always care about that location.

I am placing my own marks on routes - where I hear them; region, country,
metro, relationship with the neighbor, etc.  Though it is not the whole
story, this is typically of more interest to me.

If a neighbor AS does similarly and sends them to me, I could make use of
them.  However, as you observed, these are all choices local to the AS -
the values, whether to send them, etc.  There is definitely a maintenance
cost associate with using this data and a question of accuracy.

Other's comments about accuracy and burden of external enrichment are valid.
Whether this particular additional resolution is much of a burden on routers,
I suspect not, but I am not an implementer.

Authors: please use a spell checker.  Also seems a few of the reference
links are broken.

___
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

[heasley]

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 the geo tag values of various ASes.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] TACACS+, a suggestion

[heasley]

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] FW: New Version Notification for draft-dahm-opsawg-tacacs-01.txt

[heasley]

> 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,
> >
> > We have uploaded a second revision of the TACACS+ protocol specification
> > which we believe is ready for publication subject subject to port
> > allocation.
> >
> > Please see details below.
> >
> > The essential difference from the first revision is the change of TLS
> > option support using a separate port as opposed to the original Start TLS
> > mechanism.
> >
> > We would be very grateful for the opinion of the list regarding the
> > suitability of document for publication as an RFC.
> >
> > Many thanks,
> >
> > Thorsten, Andrej, Doug.
> >
> >
> > On 02/10/2015 16:25, "internet-dra...@ietf.org" 
> > wrote:
> >
> >>
> >>A new version of I-D, draft-dahm-opsawg-tacacs-01.txt
> >>has been successfully submitted by Douglas C. Medway Gash and posted to
> >>the
> >>IETF repository.
> >>
> >>Name:  draft-dahm-opsawg-tacacs
> >>Revision:  01
> >>Title: The TACACS+ Protocol
> >>Document date: 2015-10-02
> >>Group: Individual Submission
> >>Pages: 38
> >>URL:
> >>https://www.ietf.org/internet-drafts/draft-dahm-opsawg-tacacs-01.txt
> >>Status: https://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/
> >>Htmlized:   https://tools.ietf.org/html/draft-dahm-opsawg-tacacs-01
> >>Diff:
> >>https://www.ietf.org/rfcdiff?url2=draft-dahm-opsawg-tacacs-01
> >>
> >>Abstract:
> >>   TACACS+ provides access control for routers, network access servers
> >>   and other networked computing devices via one or more centralized
> >>   servers.  TACACS+ provides separate authentication, authorization and
> >>   accounting services.  This document describes the protocol that is
> >>   used by TACACS+.
> >>
> >>
> >>
> >>
> >>
> >>Please note that it may take a couple of minutes from the time of
> >>submission
> >>until the htmlized version and diff are available at tools.ietf.org.
> >>
> >>The IETF Secretariat

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg