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

[Peter Marrinon <[e-mail]>]

Hello,

Thanks to the authors for their work on this.

This feedback is based on my own review and some comments from people in my team who will be implementing this in our internal TACACS+ system. Our issues are relatively minor; we generally believe we could take most of this standard and implement it as intended. The first four points highlight issues where the intent of wording was sufficiently unclear to cause confusion. The rest are mainly typos and minor clarity issues.


ISSUES THAT CAUSED CONFUSION

3.2 Based on some questions from a developer in my team, it may be beneficial to explicitly state that earlier versions of TLS MUST NOT be supported. I think the text implies it but explicitly stating it may stop someone also adding support for earlier versions.

3.2.1 Cipher Requirements: "The cipher suites offered or accepted SHOULD be configurable so that operators can adapt." It is slightly unclear what the operators are adapting. Is this meant to be "The cipher suites offered or accepted SHOULD be configurable by operators" or is there a subtlety I'm missing?

3.3 TLS identification: There does not appear to be any network location based validation methods in section 5.2 of RFC5425. Is it meant to be a reference to the using a wildcard with a domain?

6.1 TLS Use: "Unsecure Connections would be better served by separate Servers from the TLS Servers." It is not immediately obvious to me why this would be better than a good implementation on a single server that successfully manages TLS and unsecure connections in a way that prevents downgrade attacks. Some more context would be useful so that this sentence is interpreted as intended. If a recommendation is being made, perhaps "would be better served by" should be replaced by something with "MAY" in it.


TYPOS AND CLARITY

2.3 Peer: Change "the peer is the TACACS+ Server is the Client" to "the peer of the TACACS+ Server is the Client".

3 2. Peer Authentication: "The use of shared keys to add and remove the MD5 obfuscation..." in unclear.

3.2 TLS Connection: Missing full stop at end of third paragraph.

3.2.2.1 TLS Certificate Path Verification:
- Change "Path" to "path" in first sentence.
- Change "entire chain of the remote's certificate is stored on the local Peer" to "entire chain of the remote Peer's certificate is stored on the local Peer."
- Arguably the second paragraph is an operations consideration and should be removed or replaced by a reference to "6.4 Unreachable Certificate Authority (CA)". Alternatively, a cross reference could be added to the existing text.

6.1 TLS Use: "Redundant lists" and "Server lists" are undefined and used inconsistently. Possible rephrasing is: "When introducing TLS to TACACS+ within a network, there is likely to be a period where there is a mixture of TACACS+ servers and/or port combination that support TLS and those that do not. During this period, a mixture of the two types of servers in a single list of TACACS+ servers configured on a client SHOULD be minimised. After migration, the production deployment SHOULD NOT mix the two types of servers within a list configured on a client."

6.3. Downgrade attacks in TLS: missing "... in" after "options".

8. Discussion on Separate port vs Negotiated TLS: Change "it allows easy blocking the unobfuscated" to "it allows easy blocking of the unobfuscated".

I hope this is useful.

Regards,

Peter


Peter Marrinon
Principal Cloud Network Engineering Manager
Azure Networking
Office: [phone]
[e-mail]

[Microsoft Logo]

From: OPSAWG <[e-mail]> On Behalf Of [e-mail]
Sent: Thursday, July 6, 2023 5:24 PM
To: Joe Clarke (jclarke) <[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt

Hi Joe, all,

Thanks.

I went and reviewed the spec in more detail. I'm afraid that simply pointing to that section in 7605 is not sufficient, especially that the spec:

  *   requests for a service name: which can be used to discover address/port used by a server
  *   asks for implementations to support a configuration knob to provide alternate port number.
  *   Assumes that the IP address of the server has to be configured anyway. One would argue that the port number can be configured as well.
  *   recommends to separate unsecure vs secure servers: which means that the recommended deployment is to expose distinct IP addresses, and hence no demultiplexing issues.

I think that many parts can be simplified by leveraging existing specs, mainly: RFC9325 and draft-ietf-uta-rfc6125bis. Also, some considerations about provisioning are worth to be covered (even if this would be tagged as out of scope).

FWIW, some more comments can be found at:

  *   pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-tacacs-tls13-03-rev%20Med.pdf
  *   doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-opsawg-tacacs-tls13-03-rev%20Med.doc

Hope this helps.

Many thanks to the authors for their effort to progress this spec.

Cheers,
Med

De : Joe Clarke (jclarke) <[e-mail]<mailto:[e-mail]>>
Envoyé : mercredi 5 juillet 2023 17:18
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt

Fair point.  I was agreeing to the dedicated port for tacacss.  That said, I do believe tacacss meets the secure requirement set forth in 7605 with respect to creating a new, secure service that replicates and insecure service in a non-backwards compatible way.

That part of Section 7.1 should be cited as a justification for the assignment.

Joe

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, July 5, 2023 at 11:04
To: Joe Clarke (jclarke) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt
Hi Joe, all,

On the port number point, I'm afraid that the arguments in Section 8 are more for justifying why distinct port numbers might be useful, not why a well-known port number has to be assigned. I would suggest to strengthen that part before making the request (see more in rfc6335#section-7.2 and also rfc7605#section-7).
Cheers,
Med

De : OPSAWG <[e-mail]<mailto:[e-mail]>> De la part de Joe Clarke (jclarke)
Envoyé : mercredi 5 juillet 2023 16:42
À : [e-mail]<mailto:[e-mail]>
Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt

Thanks for the update on this document.  I've reviewed this new version in its entirety.  To summarize:


·         TACACS+ TLS will use a dedicated "tacacss" TCP port number

·         Obfuscation is prohibited by TACACS+ TLS compliant clients/servers (within the tunnel)

These were two issues I believe were discussion points in the WG.  As a contributor, I am convinced that both make sense for the reasons put forth in the draft.  Hopefully during the migration process, implementors won't forget the obfuscation on non-TLS sessions.

I like the migration section, but I am curious why, after migration, one would need any legacy servers at all (regardless of server lists).  I can see having my "DEVICE_ADMIN" T+ list having both TLS servers first followed by legacy servers while I sus out the stability of the new implementation.  But when I'm satisfied, I likely would remove the legacy servers altogether.  Moreover, at least with Cisco config, I assume I'd have each server defined with various TLS attributes and it wouldn't matter what list they are in.

I guess what I'm suggesting is dropping the second paragraph in Section 6.2 and saying something to the effect of, when migration from legacy, obfuscated T+ to T+ TLS, insecure and secure servers MAY be mixed in redundant service lists.  However, secure servers SHOULD be tried first before falling back to insecure servers.

As a nit, Indication is misspelled in Section 3.3.

As co-chair:


·         WG, please review this draft!

·         Authors, any thoughts to what port number to use for tacacss or whatever IANA can assign?  I'd like to see a few more reviews before pinging the ADs on early allocation.

·         Are there any implementations of this thus far?  If so having an Appendix for them would help.

Joe

From: OPSAWG <[e-mail]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Thursday, June 29, 2023 at 10:55
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Operations and
Management Area Working Group (OPSAWG) WG of the IETF.

   Title           : TACACS+ TLS 1.3
   Authors         : Thorsten Dahm
                     Douglas Gash
                     Andrej Ota
                     John Heasley
   Filename        : draft-ietf-opsawg-tacacs-tls13-03.txt
   Pages           : 12
   Date            : 2023-06-29

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.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-03.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tacacs-tls13-03

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
OPSAWG mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/opsawg

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.