Subject: [Netconf] draft-ietf-netconf-rfc5539bis-03.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 May 2013 22:43:43 +0200

Hi,

I have posted a new revision - here is the summary of the changes:

A.1.  draft-ietf-netconf-rfc5539bis-03

   o  Added support for call home (allocation of a new port number,
      rewrote text to allow a NETCONF client to be a TLS server and a
      NETCONF server to be a TLS client).

   o  Merged sections 2 and 3 into a new section 2 and restructured the
      text.

   o  Extended the IANA considerations section.

   o  Using the cert-to-name mapping grouping from the SNMP
      configuration data model and updated the examples.

   o  Creating an extensible set of YANG (sub)modules for NETCONF
      following the (sub)module structure of the SNMP configuration
      model.

The call home support is still somewhat incomplete and we continue
working on that (e.g., we may want to configure where to call home,
which credentials to use, and the policy used to call home).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 17 May 2013 20:59:16 +0000

A number of issues with section 2.4.1 (Server Identity)

1. "hostname" text may be outdated

  -03 says:

      "Particularly, the NETCONF client MUST check its understanding of the
       NETCONF server hostname against the server's identity as presented
in
       the server Certificate message, in order to prevent
man-in-the-middle
       attacks."

  I know this text was in RFC 5539, but RFC 6125 doesn't use this language
in
  it's "Verifying Service Identity" section, likely because it was realized
  that checking "hostname" isn't actually what's needed.  Interestingly,
RFC
  6125 has a "Prior Art" section (Appendix B), where it quotes other RFC's
  statements and, in fact, has NETCONF-TLS listed in B7.  This suggests
that
  our text should to be updated to match RFC 6125.

2. NETCONF client/server --> TLS client/server

  These crypto rules regard the TLS layer and, as such, I think the
client/server
  qualifications need to be TLS (not NETCONF)

  There is a caveat to this, though, as there is another way to envision
the
  Call Home reversal happening.  What is defined now, in section 2.1.2
(Call
  Home) is this:

      NETCONF Server  <--------  NETCONF Client
        TLS Client    -------->    TLS Server
        TCP Server    -------->    TCP Server

  Alternatively, we might envision:

      NETCONF Server  <--------  NETCONF Client
        TLS Server    <--------    TLS Client
        TCP Server    -------->    TCP Server

  That is, the NETCONF server still initiates the connection, but then
  immediately takes on the role of the TLS server.  If this were the case,
  then the existing text is OK because the NETCONF/TLS client/server
  identities would always be aligned.  Still, to be safe, it might be
  better to s/NETCONF/TLS/g

3. The NETCONF client SHOULD be the TLS client (not server)

   Actually, we actually want the NETCONF client to be the TLS client (not
   server), so that it's clear that it is the side sending the client
   certificate, from which the NETCONF username is derived.

   Further evidence is found in draft-agl-tls-encryptedclientcerts-00
   and draft-badra-tls-identity-protection-02.txt.  Both these drafts
   attempt to address privacy issues with sending client certificates
   in the clear, as is currently the case.  While neither draft has
   reached RFC status, it is clearly an identified problem and we'd
   want whatever solution is ultimately defined to seamlessly apply
   to NETCONF-TLS Call Home cases as well.

4: RFC 6125-based matching is invalid for Call Home behind NAT case

  -03 says:

      "Matching is performed according to the rules and guidelines defined
       in [RFC6125]."

  In the Call Home case, the only thing the NETCONF client receives besides
  the certificate is the NETCONF server's src-addr.  But, this src-addr is
  meaningless in cases where the NETCONF server's address is NAT-ed, and
  thus cannot be used to compare the identity presented in the certificate.
  The only thing an NETCONF client could do would be to compare the
identity
  in the certificate to some expected value(s).  Thus, for NAT-ed call home
  cases, this text becomes critical:

      "If the NETCONF client has external information as to the expected
       identity of the NETCONF server, the hostname check MAY be omitted."

Thanks,
Kent

On 5/10/13 4:43 PM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

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