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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]>, Alanna Paloma <[email protected]> >> Cc: Alice Russo <[email protected]>, [email protected], NETCONF WG Chairs >> <[email protected]>, Per Andersson <[email protected]>, RFC Editor >> <[email protected]>, auth48archive <[email protected]> >> Resent-From: <[email protected]> >> Resent-To: [email protected], [email protected], [email protected] >> >> Hi Kent, >> >>> On Sep 3, 2024, at 12:18 PM, Kent Watsen <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Mahesh, >>> >>>> On Aug 29, 2024, at 6:27 PM, Mahesh Jethanandani <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi Kent, >>>> >>>>> On Aug 29, 2024, at 1:59 PM, Kent Watsen <[email protected] >>>>> <mailto:[email protected]>> 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 >>>> [email protected] <mailto:[email protected]> >> >> Mahesh Jethanandani >> [email protected] <mailto:[email protected]> >> >> >> >> >> >> > > _______________________________________________ > netmod mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
