Hi Douglas,

Please see inline.

Cheers,
Med

De : Douglas Gash (dcmgash) <dcmg...@cisco.com>
Envoyé : vendredi 19 avril 2024 18:46
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>
Cc : John Heasley <h...@shrubbery.net>; Andrej Ota <and...@ota.si>; Thorsten 
Dahm <thorsten.d...@gmail.com>; opsawg@ietf.org
Objet : Re: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt.


Hi Mohamad,

We are working through the comments and enhancements that you kindly sent.

There are two comments that we'd be grateful if you could clarify:


  1.  BMI10: "What about raw public keys?" (on: Implementations MAY support TLS 
authentication with Pre-Shared Keys): I'm guessing this relates to fact that, 
as we mention only PSK, that this indicates that we mean to imply that non PSK 
authentications are not included. If this is the case, then for sure, we will 
clarify that they are. If you have something else in mind, please expand, 
thanks!
[Med] Yeah.


  1.  BMI16: "What about configuration of name/address/port number of the 
server?" (on: Certificate Provisioning is out of scope of this document.), 
would be grateful if you could please expand on what you had in mind here
[Med] Clients should be provided with the IP address(es) and alternate port 
number (if the default is not used) of the server. Clients may also require to 
be provided with the domain name of the server. Also, given that you define 
"tacacss", do you had in mind to use that for service discovery?

Please note that if a name is also provided to the client, then you may 
indicate that the name will be used also for rfc9525 validation to compare the 
domain name with the certificate that is provided. If no name is provided, do 
you assume that the certificate is

BTW, I wonder whether you need to indicate whether the certificate authority 
that issued the server certificate will need to support at least DNS-ID and 
SRV-ID identifier types? I don't think URI-ID is needed. Similarly, do we need 
to include a mention about wildcard "*"? I think it SHOULD NOT.

Feel free to grab whatever useful for you. Thanks.

Many thanks!

From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
<mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>
Date: Wednesday, 17 April 2024 at 16:42
To: Douglas Gash (dcmgash) <dcmg...@cisco.com<mailto:dcmg...@cisco.com>>, 
opsawg@ietf.org<mailto:opsawg@ietf.org> 
<opsawg@ietf.org<mailto:opsawg@ietf.org>>
Cc: John Heasley <h...@shrubbery.net<mailto:h...@shrubbery.net>>, Andrej Ota 
<and...@ota.si<mailto:and...@ota.si>>
Subject: RE: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt
Hi Douglas, all,

Thank you for taking care of the comments. I managed to review the latest 
version. FWIW, the comments can be retrieved here:


·         Pdf: 
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-opsawg-tacacs-tls13-06-rev%20Med.pdf

·         Doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/2024/draft-ietf-opsawg-tacacs-tls13-06-rev%20Med.doc

There are still some points to be fixed, but I think the document is getting 
stable more and more.

Cheers,
Med

De : OPSAWG <opsawg-boun...@ietf.org<mailto:opsawg-boun...@ietf.org>> De la 
part de Douglas Gash (dcmgash)
Envoyé : mercredi 20 mars 2024 16:40
À : opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : John Heasley <h...@shrubbery.net<mailto:h...@shrubbery.net>>; Andrej Ota 
<and...@ota.si<mailto:and...@ota.si>>
Objet : Re: [OPSAWG] New Version Notification for 
draft-ietf-opsawg-tacacs-tls13-06.txt

Dear OPSAWG,

We have uploaded a new version of the doc, primarily to address as much as 
possible of the comprehensive review kindly submitted by Mohamed Boucadair. We 
thank Mohamed for the time and trouble taken to the review the doc so 
thoroughly. We will be happy to discuss further any omissions or new comments 
and rectify quickly.

And we will endeavour to respond ASAP to any other comments of any kind on the 
doc.

Many thanks,

Regards,

The Authors.

From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>
Date: Wednesday, 20 March 2024 at 15:27
To: Douglas Gash (dcmgash) <dcmg...@cisco.com<mailto:dcmg...@cisco.com>>, 
Douglas Gash (dcmgash) <dcmg...@cisco.com<mailto:dcmg...@cisco.com>>, Andrej 
Ota <and...@ota.si<mailto:and...@ota.si>>, John Heasley 
<h...@shrubbery.net<mailto:h...@shrubbery.net>>, Thorsten Dahm 
<thorsten.d...@gmail.com<mailto:thorsten.d...@gmail.com>>
Subject: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt
A new version of Internet-Draft draft-ietf-opsawg-tacacs-tls13-06.txt has been
successfully submitted by Douglas C. Medway Gash and posted to the
IETF repository.

Name:     draft-ietf-opsawg-tacacs-tls13
Revision: 06
Title:    TACACS+ TLS 1.3
Date:     2024-03-20
Group:    opsawg
Pages:    15
URL:      https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-06.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/
HTML:     https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-06.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tacacs-tls13
Diff:     
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tacacs-tls13-06

Abstract:

   The Terminal Access Controller Access-Control System Plus (TACACS+)
   Protocol [RFC8907] provides device administration for routers,
   network access servers and other networked computing devices via one
   or more centralized servers.  This document adds Transport Layer
   Security (TLS 1.3) support and obsoletes former inferior security
   mechanisms.



The IETF Secretariat

____________________________________________________________________________________________________________

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

Reply via email to