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]
