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.
> On Sep 11, 2024, at 2:57 AM, 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 … > > Cheers, > Med > > De : Kent Watsen <kent+i...@watsen.net> > Envoyé : mercredi 11 septembre 2024 00:10 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > Cc : 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 > <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 > <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
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
