Hi Mohamed, having ingested 9525 (Thank you for pointing it out), we have updated the TLS Ident section thusly (NB, we moved from SN to subjectAltName as 9525 pointed out its weakness).
New: 3.3. TLS Identification For the client-side validation of presented server identities, implementations MUST follow the process specified in [RFC9525]. Identifier types DNS-ID, IP-ID or SRV-ID are applicable for use with the TLS TACACS+ protocol, selected by operators depending upon the deployment design. Although limited wildcards are permitted in [RFC9525], they MUST NOT be used in presented server identities for Purposes of TLS for TACACS. For the server-side validation of client identities, implementations MUST allow operators to specify which certificate fields are to be used for client-identification, to verify that the client is a valid source for the received certificate and that it is permitted access to TACACS+. Implementations MUST support either: Network location based validation methods as described in Section 5.2 of [RFC5425]. or Client Identity validation of a shared identity in the certificate subjectAltName. This is applicable in deployments where the client securely supports an identity which is shared with the server. This approach allows a client's network location to be reconfigured without issuing a new client certificate, in this case, only the server mapping needs to be updated. Implementations SHOULD support the TLS Server Name Indication extension (Section 3 of [RFC6066]), and SHOULD include the server domain name in the SNI "server_name" extension of the client hello. Original: 3.3. TLS Identification In addition to authentication of TLS certificates, implementations MUST allow operators to specify which certificate fields are to be used for peer-identification, to verify that the peer is a valid source for the received certificate and that it is permitted access to TACACS+. Implementations MUST support either: Network location based validation methods as described in Section 5.2 of [RFC5425]. or Device Identity based validation methods where the peer's identity is used in the certificate subjectName. This is applicable in deployments where the device securely supports an identity which is shared with its peer. This approach allows a peer's network location to be reconfigured without issuing a new client certificate. Only the local server mapping needs to be updated. Implementations SHOULD support the TLS Server Name Indication extension (Section 3 of [RFC6066]), and SHOULD include the server domain name in the SNI "server_name" extension of the client hello. Certificate Provisioning is out of scope of this document. From: Douglas Gash (dcmgash) <dcmg...@cisco.com> Date: Monday, 22 April 2024 at 10:21 To: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Cc: John Heasley <h...@shrubbery.net>, Andrej Ota <and...@ota.si>, Thorsten Dahm <thorsten.d...@gmail.com>, opsawg@ietf.org <opsawg@ietf.org> Subject: Re: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt. Thanks Mohamed, please see inline… <Doug/> From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Date: Friday, 19 April 2024 at 18:31 To: Douglas Gash (dcmgash) <dcmg...@cisco.com> Cc: John Heasley <h...@shrubbery.net>, Andrej Ota <and...@ota.si>, Thorsten Dahm <thorsten.d...@gmail.com>, opsawg@ietf.org <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> 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: 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> 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), 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, assuming that we do end up requesting a new port number</Doug> 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> 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> 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 To unsubscribe send an email to opsawg-le...@ietf.org
