Hi Mahesh, Please see inline.
Cheers, Med De : Mahesh Jethanandani <mjethanand...@gmail.com> Envoyé : jeudi 12 septembre 2024 00:49 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : Kent Watsen <kent+i...@watsen.net>; netmod@ietf.org Objet : Re: [netmod] AD - Re: AUTH48: RFC-to-be 9644 <draft-ietf-netconf-ssh-client-server-40> for your review Hi Med, The reference of QUIC is to the protocol, RFC 9000, not NETCONF over QUIC, an I-D as you note; just as the reference is to SSH protocol, RFC 4252, not NETCONF over SSH, RFC 6242. [Med] I understand the intent is to cite the transport themselves, but the text refers to MTI of these “YANG-based management protocols”. I don’t think we can make any claim about QUIC here as we don’t have an authoritative spec for that. If we want to cite QUIC, some further tweaking to the text is needed, IMO. On Sep 11, 2024, at 2:57 AM, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: Hi Kent, I like the NEWER better compared to the initial NEW you shared, however I think some more tweaking is needed. I understand why you cited QUIC as well, but we don’t have formally a spec for mapping with QUIC (I know there is an individual I-D). We actually don’t need to be exhaustive here and cite every transport option. The proposed NEWER changes a little bit the approach from the **recommending the use of MTI** to simply listing available MTI. [mj] Why do you say that? The statement says the protocols have mandatory-to-implement … [Med] Having an MTI does not mean that MTI is actually used/enabled. Cheers, Med De : Kent Watsen <kent+i...@watsen.net<mailto:kent+i...@watsen.net>> Envoyé : mercredi 11 septembre 2024 00:10 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Cc : netmod@ietf.org<mailto:netmod@ietf.org> Objet : Re: [netmod] AD - Re: AUTH48: RFC-to-be 9644 <draft-ietf-netconf-ssh-client-server-40> for your review Hi Med, NEWER (this is what I’m asking RFC Editor to do for the suite of client-server drafts) This section is modeled after the template described in Section 3.7 of [RFCAAAA]. The "<module-name>" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have mandatory-to-implement secure transport layers (e.g., SSH [RFC4252], TLS [RFC8446], QUIC [RFC9000]) and mandatory-to-implement mutual authentication. Kent // contributor On Sep 4, 2024, at 10:28 AM, Kent Watsen <kent+i...@watsen.net<mailto:kent+i...@watsen.net>> wrote: Hi Med, A number of client-server drafts (in the NETCONF WG) are in AUTH48. One AD-level issue raised on all the drafts regards the Security Considerations section not following the template in RFC 8407 or the template in rfc8407bis. You can see the discussion below. My suggestion follows. OLD: This section uses the template described in Section 3.7 of [RFCAAAA]. The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. These network management protocols are required to use a secure transport layer and mutual authentication, e.g., SSH [RFC6242] without the "none" authentication option, Transport Layer Security (TLS) [RFC8446] with mutual X.509 authentication, and HTTPS with HTTP authentication (Section 11 of [RFC9110]). NEW: This section is modeled after the template described in Section 3.7 of [RFCAAAA]. The <module-name> YANG module defines "grouping” and “container” statements that are designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have mandatory-to-implement secure transport layers (e.g., SSH [RFC4252], TLS [RFC8446], QUIC [RFC9000]) and mandatory-to-implement mutual authentication. ALSO NEW? (Add after the above paragraph?) For the NETCONF protocol [RFC6241] , transport mapping documents include: - Using the NETCONF Protocol over Secure Shell (SSH) [RFC6242] - Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication [RFC 7589] - Using NETCONF over QUIC connection [NETCONF-QUIC] For the RESTCONF protocol [RFC8040], the mandatory-to-implement transport is HTTPS, as defined in: - HTTP/1.1 [RFC9112] - HTTP/2 [RFC9112] - HTTP/3 [RFC9112] Thoughts? Kent // contributor Begin forwarded message: From: Mahesh Jethanandani <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> Subject: Re: AD - Re: AUTH48: RFC-to-be 9644 <draft-ietf-netconf-ssh-client-server-40> for your review Date: September 3, 2024 at 5:41:58 PM EDT To: Kent Watsen <kent+i...@watsen.net<mailto:kent+i...@watsen.net>>, Alanna Paloma <apal...@amsl.com<mailto:apal...@amsl.com>> Cc: Alice Russo <aru...@amsl.com<mailto:aru...@amsl.com>>, netconf-...@ietf.org<mailto:netconf-...@ietf.org>, NETCONF WG Chairs <netconf-cha...@ietf.org<mailto:netconf-cha...@ietf.org>>, Per Andersson <peran...@cisco.com<mailto:peran...@cisco.com>>, RFC Editor <rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>>, auth48archive <auth48arch...@rfc-editor.org<mailto:auth48arch...@rfc-editor.org>> Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>> Resent-To: kent+i...@watsen.net<mailto:kent+i...@watsen.net>, per.i...@ionio.se<mailto:per.i...@ionio.se>, res...@yahoo.com<mailto:res...@yahoo.com> Hi Kent, On Sep 3, 2024, at 12:18 PM, Kent Watsen <kent+i...@watsen.net<mailto:kent+i...@watsen.net>> wrote: Hi Mahesh, On Aug 29, 2024, at 6:27 PM, Mahesh Jethanandani <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> wrote: Hi Kent, On Aug 29, 2024, at 1:59 PM, Kent Watsen <kent+i...@watsen.net<mailto:kent+i...@watsen.net>> wrote: Hi Mahesh (and Alice/Alanna) 10) <!--[rfced] *AD - We note that the text in Sections 5.1 - 5.7 does not exactly match the YANG security considerations boilerplate text at <https://wiki.ietf.org/group/ops/yang-security-guidelines>, including missing citations to RFC 8446. Please review and let us know if the text requires any updates. --> We have two options. There is the YANG security guidelines template that Alice points to, and then there is rfc8407bis template, that has been fairly stable for sometime. Even if you do not want to use the latter, because it is still a draft, we should adopt the guidelines that Alice points to. Do you disagree? Yes, I sort of do disagree. 1) They are “guidelines”, which suggests variability MAY occur. I will agree that they are guidelines, and as such can have variability in how they are used, specially as it applies to modules that are only defining enumerations or identities. However, comparing the guidelines in rfc8407bis to what is in the draft for ietf-ssh-server and ietf-ssh-client modules, I notice that - There is no reference to RFC6242 for NETCONF over SSH in this draft. - There is no reference to RFC8446 for RESTCONF over TLS in this draft. Was there a reason to not have those references? A few comments: - RFC8446 is TLS 1.3 (not RC over TLS) - In rfc8407bis, I think RFC6242 was supposed to be RFC4252 (for SSH transport). That is, it’s not suppose to be “NC over SSH”. - Also in rfc8407bis, I don’t think the HTTPS w/ authentication part is critical. - Also in rfc8407bis, it would be great to add QUIC to the list of transports… Following addresses the above, and makes the existing text more like what rfc8407bis should be (IMO). Can we can work with Med to update the text in rfc8407bis to match the following? OLD: The "ietf-ssh-client" YANG module defines "grouping" statements that are designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols have mandatory-to-implement secure transport layers (e.g., SSH, TLS) with mutual authentication. NEW: The "ietf-ssh-client" YANG module defines "grouping" statements that are designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have mandatory-to-implement secure transport layers (e.g., SSH [RFC4252], TLS [RFC8446], QUIC [RFC9000]) and mandatory-to-implement mutual authentication. A similar update would be in the "ietf-ssh-server" YANG module section too. Background: from a Security-analysis perspective, what is important to know is that a secure transport and mutual authentication is used. That’s why the text above focuses on just saying that. Thanks for the clarification. Alanna, I am good with the updated text. If we want rfc8407bis to enumerate all known NC/RC-to-transport RFCs, I suggest putting that text into its own paragraph, following the NEW paragraph above. We can work with Med to update rfc8407bis to do this also - yes? Please do. Do you want to spawn a separate thread with Med on the netmod mailing list? Thanks. 2) They contain incorrect/outdated statements, which SHOULD be fixed. 3) the updates to the rfc8407bis template are, by and large, due to my attempts to fix the above. Has this been brought up with the authors of rfc8407bis? If the statements are indeed outdated or incorrect, they should be addressed before the WG decides to publish rfc8407bis. Yes, the text currently in rfc8407bis is, in large part, my attempt to fix the text in RFC 8407. I do suggest we work with Med to tweak this section accordingly. IMO, the biggest issue is that the current text says that it "follows the template defined in https://datatracker.ietf.org/doc/html/rfc8407#section-3.7.1”. But it doesn’t follow that template. Option-1: Simply tweak that sentence OLD: This section follows the template defined in... NEW: This section is modeled after the template defined in... I am ok with this option. Thanks Kent // author Thanks. Option-2: Rewrite to match old/legacy/wrong RFC 8407 template - honestly, I’m unsure if it’s possible (due to there being only groupings) Option-2: Rewrite to match new/better rfc8407bis template, and point to it instead. - It’s an Informative reference, so no MISREF would occur. Kent // as author, and progenitor of Section 3.7.1 in RFC 8407 Mahesh Jethanandani mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> Mahesh Jethanandani mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> _______________________________________________ netmod mailing list -- netmod@ietf.org<mailto:netmod@ietf.org> To unsubscribe send an email to netmod-le...@ietf.org<mailto:netmod-le...@ietf.org> ____________________________________________________________________________________________________________ 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. _______________________________________________ netmod mailing list -- netmod@ietf.org<mailto:netmod@ietf.org> To unsubscribe send an email to netmod-le...@ietf.org<mailto:netmod-le...@ietf.org> Mahesh Jethanandani mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> ____________________________________________________________________________________________________________ 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.
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
