[OPSAWG]Re: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt: 9525 Section

["Douglas Gash (dcmgash)" <[e-mail]>]

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) <[e-mail]>
Date: Monday, 22 April 2024 at 10:21
To: [e-mail] <[e-mail]>
Cc: John Heasley <[e-mail]>, Andrej Ota <[e-mail]>, Thorsten Dahm <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt.
Thanks Mohamed, please see inline… <Doug/>

From: [e-mail] <[e-mail]>
Date: Friday, 19 April 2024 at 18:31
To: Douglas Gash (dcmgash) <[e-mail]>
Cc: John Heasley <[e-mail]>, Andrej Ota <[e-mail]>, Thorsten Dahm <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt.
Hi Douglas,

Please see inline.

Cheers,
Med

De : Douglas Gash (dcmgash) <[e-mail]>
Envoyé : vendredi 19 avril 2024 18:46
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : John Heasley <[e-mail]>; Andrej Ota <[e-mail]>; Thorsten Dahm <[e-mail]>; [e-mail]
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: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 17 April 2024 at 16:42
To: Douglas Gash (dcmgash) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: John Heasley <[e-mail]<mailto:[e-mail]>>, Andrej Ota <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> De la part de Douglas Gash (dcmgash)
Envoyé : mercredi 20 mars 2024 16:40
À : [e-mail]<mailto:[e-mail]>
Cc : John Heasley <[e-mail]<mailto:[e-mail]>>; Andrej Ota <[e-mail]<mailto:[e-mail]>>
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: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 20 March 2024 at 15:27
To: Douglas Gash (dcmgash) <[e-mail]<mailto:[e-mail]>>, Douglas Gash (dcmgash) <[e-mail]<mailto:[e-mail]>>, Andrej Ota <[e-mail]<mailto:[e-mail]>>, John Heasley <[e-mail]<mailto:[e-mail]>>, Thorsten Dahm <[e-mail]<mailto:[e-mail]>>
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.