Hello, Douglas (and other authors).  Seeing as since we’re gearing up for IETF 
119, I wanted to check to see when you might have a response and another 
version of the document planned in order to update the WG on progress.  
Ultimately, this is the reason we did the original T+ informational draft, and 
I know there are interested parties in seeing this work progress.

Thanks.

Joe

From: OPSAWG <opsawg-boun...@ietf.org> on behalf of Douglas Gash (dcmgash) 
<dcmgash=40cisco....@dmarc.ietf.org>
Date: Thursday, January 25, 2024 at 10:22
To: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>, 
opsawg@ietf.org <opsawg@ietf.org>
Cc: John Heasly <h...@shrubbery.net>, Andrej Ota <and...@ota.si>
Subject: Re: [OPSAWG] Submission of new version of TACACS+ TLS Spec (V4)
Hi,

Thanks for your further review.

We will check through your comments against the latest version and identify the 
missing items, then continue this thread on what their acceptable resolution 
could be.

Thanks,

The Authors.

From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>
Date: Thursday, 25 January 2024 at 14:34
To: Douglas Gash (dcmgash) <dcmg...@cisco.com>, opsawg@ietf.org 
<opsawg@ietf.org>
Cc: John Heasly <h...@shrubbery.net>, Andrej Ota <and...@ota.si>
Subject: RE: Submission of new version of TACACS+ TLS Spec (V4)
Hi Authors, all,

Many thanks for your effort on this document.

I managed finally to read the new version. I’m afraid that some of the comments 
in 
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-tacacs-tls13-03-rev%20Med.pdf
 were not addressed or at least I fail to see how they are.

For example, I still don’t think that we can separate the discussion of the 
port number from how the IP address of the server is configured. I still also 
think that cipher suite discuss can be offloaded to RFC9325 (which btw should 
be cited as normative; also, please note that RFC7525 is now obsoleted by 
RFC9325).

Cheers,
Med

De : OPSAWG <opsawg-boun...@ietf.org> De la part de Douglas Gash (dcmgash)
Envoyé : vendredi 22 décembre 2023 17:54
À : opsawg@ietf.org
Cc : John Heasly <h...@shrubbery.net>; Andrej Ota <and...@ota.si>
Objet : [OPSAWG] Submission of new version of TACACS+ TLS Spec (V4)

Dear OPSAWG,

Many thank for all the comments on the Secure TACACS+ (TLS) draft v3.

We have submitted a revised doc which intention to address the concerns and 
comments. It is rather later than originally planned, our apologies for the 
delay. We will look forward to addressing the corresponding issues form this 
revision in a timelier manner.

Some brief notes regarding the broader topics raised in v3, all items of 
course, are open for re-aligning as the group sees fit.

Regarding the allocation of a specific port, a key motivation concerns the 
pervasive use of default ports in current configurations. Ensuring the client 
implementations work correctly with default ports now TLS is introduced, to 
minimise burden for operators whilst avoiding wrinkles with downgrade attacks 
does require said new default port to be allocated, and we will explicitly 
mention this in a new section in the new doc. We hope this should help account 
for our request for an allocated port.
RFC9325 does look a timely reference, and we have tried to delegate what we can 
from the new TACACS+ doc to it.
Tracking the discussion on the deprecation of obfuscation option inside TLS, 
our current reading is that:
All TLS traffic must NOT use obfuscation.
Setting the non-obfuscation option (TACACS has a flag for unencrypted)  is 
mandatory for all TLS TACACS+ traffic.
The aim is to avoid any ambiguity and to remove MD5 operations from this level 
of the protocol.
We hope we have addressed the raised issues nits and ambiguities.

Best regards, the Authors.


____________________________________________________________________________________________________________

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

Reply via email to