Hi Douglas, Please see inline.
Cheers, Med De : Douglas Gash (dcmgash) <dcmg...@cisco.com> Envoyé : lundi 22 avril 2024 11:22 À : 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. Thanks Mohamed, please see inline... <Doug/> From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Date: Friday, 19 April 2024 at 18:31 To: Douglas Gash (dcmgash) <dcmg...@cisco.com<mailto:dcmg...@cisco.com>> Cc: John Heasley <h...@shrubbery.net<mailto:h...@shrubbery.net>>, Andrej Ota <and...@ota.si<mailto:and...@ota.si>>, Thorsten Dahm <thorsten.d...@gmail.com<mailto:thorsten.d...@gmail.com>>, opsawg@ietf.org<mailto:opsawg@ietf.org> <opsawg@ietf.org<mailto:opsawg@ietf.org>> Subject: RE: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt. Hi Douglas, Please see inline. Cheers, Med De : Douglas Gash (dcmgash) <dcmg...@cisco.com<mailto:dcmg...@cisco.com>> Envoyé : vendredi 19 avril 2024 18:46 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Cc : John Heasley <h...@shrubbery.net<mailto:h...@shrubbery.net>>; Andrej Ota <and...@ota.si<mailto:and...@ota.si>>; Thorsten Dahm <thorsten.d...@gmail.com<mailto:thorsten.d...@gmail.com>>; opsawg@ietf.org<mailto: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. <Doug>Got it, will clarify that this section just relates to PSK and dosent impact the use of other PKI options</Doug> 2. 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. <Doug>So we didn't have in mind any additional configuration at the T+ level other than the regular TACACS+ for this, (where clients will have servers defined and vice versa) [Med] I checked rfc8907 but failed to see where this was described. I suggest you include a note to basically echo what you said. Thanks. , with the caveat of the restrictions in 5.2. TACACS+ Configuration (to ensure that TLS and non TLS can be easily differentiated at implementation level to reduce the likelihood of operators accidentally mixing TLS and non TLS traffic which may lead to downgrade attacks.) </Doug> Also, given that you define "tacacss", do you had in mind to use that for service discovery? <Doug> not at this point, it is more for IANA considerations [Med] Then, call that explicitly: "Considerations about service discovery are out of scope." , assuming that we do end up requesting a new port number</Doug> [Med] The name can be registered independent of whether a port number is assigned. 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 <Doug>To restate to ensure I'm on your page : the actual T+ protocol won't have the domain name embedded anywhere, so this is OOB of tacacs and encapsulated within the TLS transport and peer configuration, which can validate as usual as it knows the peer connection details. We will clarify that recommendation. If there is somehting we're missing there, LMK, thanks !</Doug> [Med] The point is that, without making a assumption about how the client is aware about a name of the server, leverage 9525 validation based on that provisioned name and the certificate presented. I think this is important to cover because certificate bound on an IP address may not be available. FWIW, 6125 used to have this text: Some certification authorities issue server certificates based on IP addresses, but preliminary evidence indicates that such certificates are a very small percentage (less than 1%) of issued certificates. 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. <Doug>Agreed, I think there was a discussion on that, and it was discounted. We'll make that explicit</Doug> [Med] Thank you. 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. ____________________________________________________________________________________________________________ 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
