On Tue, 7 May 2024 at 19:00, <mohamed.boucad...@orange.com> wrote: > Hi Tiru, > > > > Many thanks for the review. Forwarding it to the list, fwiw. > > > > I trust the authors will follow up. See one comment inline. > > > > Cheers, > > Med > > > > *De :* tirumal reddy <kond...@gmail.com> > *Envoyé :* mardi 7 mai 2024 15:17 > *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > *Cc :* draft-ietf-opsawg-tacacs-tl...@ietf.org > *Objet :* Re: Request to review draft-ietf-opsawg-tacacs-tls13 > > > > > > My comments on the use of TLS in the draft. > > 1. > > TACACS+ over TLS takes the protocol defined in [RFC8907], removes the > option for MD5 obfuscation, and specifies the use of TLS (version 1.3 > or later) for transport using a new well-known default server port > number. The next sections provide further details and guidance. > > Comments> I suggest to use normative language that TACACS+ MUST use TLS > 1.3. You may want to add that "It is expected that TACACS+ as described in > this document will work with future versions of TLS." > > You may also want to say that earlier versions of TLS MUST NOT be used, > > 2. Implementations MUST support TLS 1.3 [RFC8446] and MAY permit TLS 1.3 > session resumption. If resumption is supported, the resumption > ticket_lifetime SHOULD be configurable, including a zero seconds > lifetime. > > Comment> Session resumption is an in-built feature of TLS 1.3 and I don't > see the need to use "MAY". > > > 3. This document makes no cipher suite recommendations, but > recommendations can be found in the TLS Cipher Suites section of the > Section 4.3 of [RFC9325]. > > Comment> I don't see a need to refer to RFC9325 (it is specific to (D)TLS > 1.2). > > *[Med] My understand is that RFC covers 1.3 given that it says explicitly: > * > > > > *This BCP applies to TLS 1.3, TLS 1.2, and earlier versions.* >
The draft refers to RFC9325 in section 3.2,1 as follows: This document makes no cipher suite recommendations, but recommendations can be found in the TLS Cipher Suites section of the Section 4.3 of [RFC9325]. Comment> Section 4.3 of RFC9325 refers to Section 9.1 of TLS 1.3 [RFC8446] for cipher suites. I don't see any use of referencing RFC9325 in this section. Further, the ciphersuites currently mandated by RFC8446 may not be recommended in future, it is better to follow the IANA registry, https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4; it has a column which indicates whether a ciphersuite is recommended or not. The draft may also want to refer to the warning in https://datatracker.ietf.org/doc/html/rfc8447#section-8 (it explains that recommended ciphersuites may be broken in future). -Tiru > > > *The tacacs+ spec has also the following:* > > > > * Those implementing and deploying* > > * Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3* > > * outlined in [RFC9325], or its subsequent versions.* > > > > * This document outlines additional restrictions permissible under* > > * [RFC9325]. For example, any recommendations referring to TLS 1.2,* > > * including the mandatory support, are not relevant for Secure TACACS+* > > * as TLS 1.3 or above is mandated. * > > > > RFC9325 is referred to in several places in the document and the same > comment applies. > > 4. 3.2.2.1. TLS Certificate Path Verification > > Implementations MUST support certificate Path verification as > described in [RFC5280]. > > Because a peer could be isolated from a remote peer's Certificate > Authority (CA), implementations MUST support certificate chains > (a.k.a. bundles or chains of trust), where the entire chain of the > remote's certificate is stored on the local peer. TLS Cached > Information Extension [RFC7924] SHOULD be implemented. This MAY be > augmented with Raw Public Keys [RFC7250]. > > Comment> Is it referring to PKIX-based authentication or use of local CA > or both ? Please elaborate. > Comment> How will the client identify the server identity (domain name) ? > Comment> I am assuming the client MUST verify the chain of certificates up > to a trust anchor as described in Section 6 of [RFC5280]. The client > SHOULD use the default system or application trust anchors, unless > otherwise configured. > Comment> Why "SHOULD" and not use "MUST" ? > Comment> What is the need to support raw public keys ?. The main security > challenge with raw public keys is how to associate the public key with a > specific entity and revocation (e.g., private key is compromised). > > 5. 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. > > Comment> You may want to leverage SAN instead of subjectName (for example, > see https://www.rfc-editor.org/rfc/rfc8310.html#section-8.1). > Comment> I am not sure what you mean by "Network location based validation > methods" ? > > 6. 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. > > Comment> Please explain the exception scenarios where SNI is not required. > > 7. If TLS Encrypted Client Hello becomes standardized and applicable to > TLS 1.3, then it SHOULD be included in Secure TACACS+ implementation. > > Comment> It will be a standard and ECH is already deployed. I don't think > ECH is applicable to TACACS deployment (e.g., ECH will require a public > provider, see > https://www.ietf.org/archive/id/draft-ietf-tls-esni-18.html#section-3). > > > > Cheers, > > -Tiru > > > > On Thu, 25 Apr 2024 at 13:24, <mohamed.boucad...@orange.com> wrote: > > Hi Tiru, > > > > Can you please review this document (draft-ietf-opsawg-tacacs-tls13-07 - > TACACS+ TLS 1.3 > <https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/>) and > share comments/suggestions you may have? > > > > The document is short and easy to read. > > > > Feel free to send your review to the opsawg mailing list or here. I will > then relay them, unless you have objections. > > > > Thank you. > > > > Cheers, > > Med > > Orange Restricted > > > > > > Orange Restricted > > ____________________________________________________________________________________________________________ > > 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
