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 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<mailto: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
