Subject: [Netconf] Fw: WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed

From: t.petch <[email-masked]>
Date: Fri, 6 Mar 2015 16:59:58 +0000

I have read, and re-read and re-read ... section 3.2 of call-home and I
 am struggling.  I am reminded of rfc5539bis where we started out with
 something similar and ended up with
 "  The NETCONF client MUST check the identity of the server according
to
    Section 6 of [RFC6125]."
 which I think was a great idea.

 We cannot go quite that far with the call-home I-D but think we should
 be
 heading in that direction.

 Surely all we need to say, in essence, is that because the server has
 initiated the connection then we have no reference identity and so
 RFC6125 cannot apply.  Therefore the client must be preconfigured with
 whatever it will trust from the server, be that a certificate or a host
 key.  And it should be the certificate of the server; a CA certificate
 on
 its own is not enough since, as we have said already, we have no
 reference identity so knowing that the end user certificate chains back
 to a valid CA is not enough (in general).

 And yes, preconfiguring information is a pain but if you want security,
 you have to do it.

 So along those lines I offer a new 3.2

 ====================================================
 3.2.  Server Identification and Authentication

    When a NETCONF/RESTCONF client initiates the
    connection to the NETCONF/RESTCONF server, the client has prior
 knowledge of the identity of the NETCONF/RESTCONF server it is
 connecting to.  When using TLS or SSH with certificates,
    the NETCONF client can then check the identity of the server
 according to
    Section 6 of [RFC6125].
    Similar considerations apply when using SSH with host keys.

 When the connection is initiated by the NETCONF/RESTCONF server, the
 NETCONF/RESTCONF client does not have any prior knowledge of the
 identity of the NETCONF/RESTCONF server which has initiated the
 connection.  The NETCONF/RESTCONF
  client must derive the identity of the NETCONF/RESTCONF server from
  information provided by the network or by the NETCONF/RESTCONF server
    itself.  This section describes strategies a NETCONF/RESTCONF client
    can then use to identify a NETCONF/RESTCONF server.

 A NETCONF/RESTCONF client must also authenticate the identity of the
 server.  This is always an issue but especially so when the
 NETCONF/RESTCONF server initiates the connection since this approach is
 common for newly deployed NETCONF/RESTCONF servers.

 The first piece of information that a NETCONF/RESTCONF client learns
 when the server initiates the connection is the IP address of the
 NETCONF/RESTCONF server, i.e the source address of the TCP connection.
 This IP address is an identifier but is only reliable in networks that
 use known static addresses.  This case is infrequent; so it is NOT
 RECOMMENDED to identify a NETCONF/RESTCONF server by its source IP
 address.

 The next piece of information a NETCONF/RESTCONF client learns is
 provided by the NETCONF/RESTCONF server in the form of a host-key (for
 SSH) or a certificate (for SSH or TLS).  This host-key or certificate,
 either in its
 entirety or as a fingerprint, can be used to look up an identifier for
 the NETCONF/RESTCONF server.  Each NETCONF/RESTCONF
 server is assumed to have a statistically unique public key, even in
 virtualized environments.  This approach also provides authentication
in
 that a secure connection can only be established when the
 NETCONF/RESTCONF server can demonstrate possession of
 the matching private key.  This approach is common with SSH clients but
 could be used equally well by TLS clients.  It may be the required when
 the NETCONF/RESTCONF servers have self-signed certificates.

 [** I do not understand the next OLD paragraph and so am guessing here.
 Doubtless I will be told where my guesses are wrong]

 A variation on the previous option can be used when the manufacturer of
 the NETCONF/RESTCONF servers is a trusted CA and provisions the
 NETCONF/RESTCONF servers with certificates such as is described by
 [Std-802.1AR-2009].  After verifying that the certificate is valid
 [RFC5280], an identifier can be extracted from the certificate, e.g.
 from the subjectAltName.  The NETCONF/RESTCONF client SHOULD still be
 configured with the CA certificate and a list of expected identifiers
of
 the NETCONF/RESTCONF servers, as supplied by the manufacturer.

 [Which seems very close to the usual RFC6125 case - what am I missing?]

    Note that while TLS uses X.509 certificates by default, using X.509
    certificates with SSH requires both the NETCONF client and server to
    support [RFC6187].
 ==================================================
 I would probably cut down on the number of times NETCONF/RESTCONF
 appears but am not too bothered by it.

 Which is all the comments I currently have on
 draft-ietf-netconf-call-home-04.

 Tom Petch

> ----- Original Message -----
> From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, March 03, 2015 10:16 PM
> Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04
and
> draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and
> server-model-06 available - All Open issues closed
>
>
> Dear NETCONF WG,
>
> we hereby issue a WG Last Call for 2 weeks for the drafts below:
>
> https://tools.ietf.org/html/draft-ietf-netconf-call-home-04
> https://tools.ietf.org/html/draft-ietf-netconf-server-model-06
>
> Please review and send your comments to the NETCONF WG mailing list by
> March 17, 2015 EOB PT.
>
> Call Home and Server Model drafts are planned to publish as standard
> track documents.
>
> Please state explicitly that you have read/reviewed and whether you
> support the publication of the drafts.
> Please indicate also if you plan to implement or have already
> implementation experience with the these drafts.
>
> Thank you,
> Mehmet and Mahesh
>
> From: Netconf [mailto:[email-masked]] On Behalf Of ext
Ersue,
> Mehmet (NSN - DE/Munich)
> Sent: Thursday, February 05, 2015 5:30 PM
> To: [email-masked]
> Subject: [Netconf] call-home-04 and server-model-06 available - All
Open
> issues closed
>
> All,
>
> all call-home issues have been solved and there are 3 issues for
> server-model draft in REVIEW state.
> See
>
https://github.com/netconf-wg/call-home/issues?q=is%3Aissue+is%3Aclosed
> and
> https://github.com/netconf-wg/server-model/issues.
>
> Please check the provided solutions in the updated drafts and comment
> before we go to WGLC after the end of Restconf LC.
>
> https://tools.ietf.org/html/draft-ietf-netconf-call-home-04
> https://tools.ietf.org/html/draft-ietf-netconf-server-model-06
>
> Regards,
> Mehmet
>
> --=====2634486923681469604=-
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 6 Mar 2015 18:39:46 +0000

Hi Tom and Juergen,

Thank you for all your comments so far.  I will more fully engage in this
thread after the draft submission deadline has past.  I just wanted to let
you know why I haven't replied yet.

Thanks again,
Kent

On 3/6/15, 11:59 AM, "t.petch" <[email-masked]> wrote:

>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf