Subject: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 5 Jan 2015 20:46:09 +0000

Dear NETCONF Members,

we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07.

The document can be found at:
    http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07

Please review and send your comments to the WG mailing list by January 19, 2015 EOB PT.

The document is planned to publish as a standard track document.
As a minimum please state that you have read/reviewed and whether you support the publication.

Please indicate also if you plan to implement or have already implementation experience with the rfc5539bis draft.

Thank you.
Mehmet and Mahesh

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 11 Jan 2015 16:58:09 +0000

All,

this is a friendly reminder on the WGLC we started on January 5th for draft-ietf-netconf-rfc5539bis-07.

Please review and send your comments to the WG mailing.
If you have read the document but don't have any comments, please state whether you support the publication.

Thanks,
Mehmet

From: Netconf [mailto:[email-masked]] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich)
Sent: Monday, January 05, 2015 9:46 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07

Dear NETCONF Members,

Thank you.
Mehmet and Mahesh

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 18 Jan 2015 15:50:40 +0000

Dear NETCONF WG,

we did not get any comments yet on rfc5539bis draft during the WGLC.

Please review and provide your comments on the document and/or
please indicate if you think the document is ready for publication.

If we do not get any comments or support by the deadline (January 19, 2015 EOB PT) the WGLC will be seen as unsuccessful.

Regards,
Mehmet

From: Netconf [mailto:[email-masked]] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich)
Sent: Sunday, January 11, 2015 5:58 PM
To: [email-masked]
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07

All,

Thanks,
Mehmet

Dear NETCONF Members,

Thank you.
Mehmet and Mahesh

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 18 Jan 2015 16:04:21 +0000

Hi All,

technically spoken, I support the publication of 5539bis draft.

It is well-written and addresses the issues we discussed appropriately.

There are two minor issues concerning outdated references.
- there is a -08 version available for draft-ietf-uta-tls-bcp-07
- RFC4742 has been replaced by RFC6242

Cheers,
Mehmet

From: Netconf [mailto:[email-masked]] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich)
Sent: Sunday, January 18, 2015 4:51 PM
To: [email-masked]
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07

Dear NETCONF WG,

Regards,
Mehmet

All,

Thanks,
Mehmet

Dear NETCONF Members,

Thank you.
Mehmet and Mahesh

---

From: Xiang Li <[email-masked]>
Date: Sun, 18 Jan 2015 14:09:11 -0600

Hi

I have read this draft. I support its publication as a RFC.  We will 
implement it.

Just a minor comment :

In "Introduction", currently it reads:

    ... Implementations MUST support mutual TLS certificate-based 
authentication [RFC5246].  This
    assures the NETCONF server of the identity of the principal who
    wishes to manipulate the management information.  It assures the
    NETCONF client of the identity of the server for which it wishes to
    manipulate the management information.

I think an "also" should be added in the last sentence in the paragraph 
above. I.e.:

    ... Implementations MUST support mutual TLS certificate-based 
authentication [RFC5246].  This
    assures the NETCONF server of the identity of the principal who
    wishes to manipulate the management information.  It*also* assures the
    NETCONF client of the identity of the server for which it wishes to
    manipulate the management information.

Thanks

-Xiang

On 1/5/2015 2:46 PM, Ersue, Mehmet (NSN - DE/Munich) wrote:
> _http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis__-07_ 
> <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07>
> Please indicate also if you plan to implement or have already 
> implementation experience with the rfc5539bis draft.
> Thank you.
> Mehmet and Mahesh
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
--
Xiang Li,
Seguesoft, Champaign, IL
(217) 721-5341

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Jan 2015 13:45:38 +0100

> - there is a -08 version available for draft-ietf-uta-tls-bcp-07

This is a tool synchronization issue and will resolve itself.

> - RFC4742 has been replaced by RFC6242

The reference to RFC4742 must stay as is, see the text in section 3.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Jan 2015 13:46:54 +0100

OK

/js

---

From: Alan Luchuk <[email-masked]>
Date: Mon, 19 Jan 2015 10:09:18 -0500 (EST)

Hello,

>From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>Thread-Topic: WG Last Call for draft-ietf-netconf-rfc5539bis-07
>Date: Sun, 18 Jan 2015 15:50:40 +0000
>
>Dear NETCONF WG,
>
>If we do not get any comments or support by the deadline (January 19, 2015 =
>EOB PT) the WGLC will be seen as unsuccessful.

SNMP Research has an implementation of RFC5539. We anticipate updating it 
to the latest standards as engineering resources allow.  We support 
publishing draft-ietf-netconf-rfc5539bis-07.

Regards,
--Alan

 ------------------------------------------------------------------------------
 Alan Luchuk               SNMP Research, Inc.          Voice:  +1 865 573 1434
 Senior Software Engineer  3001 Kimberlin Heights Road  FAX:    +1 865 573 9197
 luchuk at snmp.com        Knoxville, TN  37920-9716    http://www.snmp.com/
 ------------------------------------------------------------------------------

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Jan 2015 21:46:30 +0100 (CET)

Hi,

I have reviewed draft-ietf-netconf-rfc5539bis-07 and have the
following mostly minor comments:

o  section 5

  OLD:

   the integrity of the certificate presented by the peer.  presented

  NEW:

   the integrity of the certificate presented by the peer.  The
   presented

o  section 6

  This section is still confusing to me.

  In the second sentence, the text states that "the hostname check MAY
  be omitted" - but the text hasn't mentioned any hostname checks so
  it is not clear what this refers to.

  The second paragraph talks about how matching is performed - but
  matching of what?

  Tom Petch suggested better text in an email from June 10, 2014, but
  that text was never finished, I think.

o  section 7

  The text says:

   The NETCONF protocol [RFC6241] requires that the transport protocol's
   authentication process MUST result in an authenticated NETCONF client
   identity whose permissions are known to the server.

  I think this is an odd usage of 2119 MUST, since it merely states
  what NETCONF requires.  I suggest:

  NEW:

   The NETCONF protocol [RFC6241] requires that the transport protocol's
   authentication process results in an authenticated NETCONF client
   identity whose permissions are known to the server.

o  section 7

  OLD:

      The server maintains an ordered list of mappings of certificates
      to names.  The username is derived by considering each list entry

  NEW:

      The server maintains an ordered list of mappings of certificates
      to NETCONF usernames.  The username is derived by considering
      each list entry

o  section 7

  The textual description of the algorithm refers to node names from
  the original YANG model, like 'map-type' and 'cert-to-name', without
  further explanation.  These node names should be removed, and the
  intention explained instead.

o  section 7

  I think the last sentence is wrong.  The way I read it is that first
  we run the algorithm (matching certificates and extract a name), and
  then we validate this resulting name to see if it is valid.  If it
  is not valid, we drop the session.

  I think that the idea is that for each list entry, we match the
  certificate, extract a name, and then check its validity.  If the
  cert doesn't match, or if we cannot extract a name, or if the name
  is invalid, we continue to the next list entry.

  (in any case, the behavior described here should be clarified also
  in ietf-netconf-server-model)

o  nit

  s/base:1.1/:base:1.1/g   (two occurences I believe - yes, this error
  is also present in RFC 6242, and it is really minor, but it is easy
  to fix here)

/martin

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 25 Jan 2015 11:30:39 -0800

[Chair hat off]

I support the publication of this draft. The draft has been well written and believe it is ready for LC.

In addition to the two references that Mehmet mentioned, please address/update the reference to draft-ietf-netmod-snmp-cfg to RFC 7407.

[Chair hat on]

Separately, and only because it is mentioned in this document, we need to clean up the description around how the username is extracted from a certificate. This can happen in the netconf-server draft. The three documents talk about a algorithm to extract the username, but the only option that is clear (at least to me) is when the username is ’specified’.

Thanks.

> On Jan 5, 2015, at 12:46 PM, Ersue, Mehmet (NSN - DE/Munich) <[email-masked]> wrote:
> 
> Dear NETCONF Members,
>  
>     http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07>
>  

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Jan 2015 11:27:50 +0100

> In addition to the two references that Mehmet mentioned, please address/update the reference to draft-ietf-netmod-snmp-cfg to RFC 7407.

I am confused since draft-ietf-netconf-rfc5539bis-07 does not
reference draft-ietf-netmod-snmp-cfg except in appendix B which is
marked as "to be removed by RFC Editor before publication".
 
> Separately, and only because it is mentioned in this document, we need to clean up the description around how the username is extracted from a certificate. This can happen in the netconf-server dra…

If the text in rfc5539bis is not clear, we should try to improve
it. Do you think the text in rfc5539bis is unclear or are you talking
about the netconf-server document specifically? (Note that I will
address Martin's comments regarding the algorithm, which however are
minor changes.)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Jan 2015 11:50:57 +0100

>    the integrity of the certificate presented by the peer.  The

fixed
 
>   that text was never finished, I think.

Perhaps all that needs to be done is change the order of the
sentences in this section. Does this text resolve the issue?

   The NETCONF client MUST carefully examine the certificate presented
   by the NETCONF server to determine if it meets the client's
   expectations.  In particular, the NETCONF client MUST check its
   understanding of the NETCONF server hostname against the server's
   identity as presented in the certificate presented by the server, in
   order to prevent man-in-the-middle attacks.  If the NETCONF client
   has external information as to the expected identity of the NETCONF
   server, the hostname check MAY be omitted.
 
>    identity whose permissions are known to the server.

The MUST was coming straight out of RFC 6241 (section 2.2 page 12) but
your proposal makes sense since people might wrongly read this MUST as
being a NC over TLS MUST while is it really an RFC6241 MUST.
 
>       to NETCONF usernames.  The username is derived by considering

fixed
 
>   intention explained instead.

ack - I will reword those portions to avoid these references
 
>   in ietf-netconf-server-model)

I checked RFC 6353 and indeed it treats a value that does not satisfy
the tmSecurityName requirements as a soft-error and continue the
search (description of snmpTlstmCertToTSNTable). So I will make the
suggested change.

>   is also present in RFC 6242, and it is really minor, but it is easy

fixed

/js

---

From: Kent Watsen <[email-masked]>
Date: Mon, 26 Jan 2015 17:41:53 +0000

>   server, the hostname check MAY be omitted.

Yes, this reordering helps the text flow better, but:

1) the term "hostname" may be outdated, RFC 6125 uses the term "reference
identifier"
  
2) should this whole section be essentially just a reference RFC 6125,
section 6?   - is this RFC trying to add anything to or on top of the
procedures defined there?

PS: we've discussed the "hostname check may be omitted" text before:
http://www.ietf.org/mail-archive/web/netconf/current/msg08810.html

Kent

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 26 Jan 2015 18:30:24 +0000

Ignore both the comments. Apparently, I was looking at an older (-04)
version of the draft.

On Mon Jan 26 2015 at 2:27:54 AM Juergen Schoenwaelder <
[email-masked]> wrote:

> > In addition to the two references that Mehmet mentioned, please
> address/update the reference to draft-ietf-netmod-snmp-cfg to RFC 7407.
>
> > Separately, and only because it is mentioned in this document, we need
> to clean up the description around how the username is extracted from a
> certificate. This can happen in the netconf-server draft. The three
> documents talk about a algorithm to extract the username, but the only
> option that is clear (at least to me) is when the username is ’specified’.
> >
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Jan 2015 22:20:23 +0100

> 1) the term "hostname" may be outdated, RFC 6125 uses the term "reference

Trying to translate this into RFC 6125 terminology leads to this:

   The NETCONF client MUST carefully examine the certificate presented
   by the NETCONF server to determine if it meets the client's
   expectations.  In particular, the NETCONF client MUST check its
   understanding of the NETCONF server's reference identifier (e.g., its
   hostname) against the server's presented identity encoded in the
   certificate presented by the server, in order to prevent man-in-the-
   middle attacks [RFC6125].  If the NETCONF client has external
   information as to the expected presented identity of the NETCONF
   server, the check of the presented identity against the reference
   identity MAY be omitted.

   Matching is performed according to the rules and guidelines defined
   in [RFC6125].  If the match fails, the NETCONF client MUST either ask
   for explicit user confirmation or terminate the connection and
   indicate the NETCONF server's identity is suspect.

Is this clearer now?
   
> procedures defined there?

Not really. The problem is that we are going in circles. Some people
want the ID to say less, then other people want to say more, then
again people want the text the proper terminology, then other people
find the text too difficult to read/understand. A real short version
of this section would be this:

   The NETCONF client MUST check the identity of the server according
   to RFC 6125. If the check fails, the NETCONF client MUST either ask
   for explicit user confirmation or terminate the connection and
   indicate the NETCONF server's identity is suspect.

I personally like this short version most.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 26 Jan 2015 22:50:48 +0100 (CET)

>    indicate the NETCONF server's identity is suspect.

Should we be even more explicit and refer to section 6?

> I personally like this short version most.

Me too.  But I note that in case of match failure, your text says MUST
[...] terminate the connection, whereas 6125 says SHOULD.  This is
either a reason for not trying to provide a shorter version of the
authoritative text, or it should be pointed out explicitly.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Jan 2015 23:01:35 +0100

> authoritative text, or it should be pointed out explicitly.

OK. So here is an even shorter version:

    The NETCONF client MUST check the identity of the server according
    to Section 6 of RFC 6125.

This is a slight change form RFC 5539 but then RFC 6125 did not exist
back then and so it probably makes sense to align RFC 5539bis with RFC
6125.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Jan 2015 00:54:42 +0000

>    to Section 6 of RFC 6125.

That seems almost too short, but I agree that a short normative reference
is better than copy/paste text.

>back then and so it probably makes sense to align RFC 5539bis with RFC

True.

Question: the title and text refer to "X.509", but both RFC 5246 and RFC
5280 refer to "X.509v3" or "X.509 v3".  Does it matter?

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Jan 2015 08:12:04 +0100

> is better than copy/paste text.

Unless anything technically is missing, I prefer to keep the text
short and not start another iteration in the editing loop.

> 5280 refer to "X.509v3" or "X.509 v3".  Does it matter?

RFC 5246 requires X.509v3, I do not think we need to repeat the X.509
certificate version number in the title. Does this fix a real problem?
I would say it does not. Does it improve readability? I think not. Do
other RFCs use X.509 in the title? I only found RFC 6187, that is 1/41
that have X.509 in the title. Issue closed.

/js

PS: This revision of RFC 5539 started in October 2011 (!) and the I-D
    has had an interesting journey (adding PSK, adding call home,
    adding a config data model, splitting off call home, splitting of
    the config data model, removing PSK) and I really want to get this
    RFC 5539 update off my table.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Jan 2015 08:23:41 +0100

> Please review and send your comments to the WG mailing list by January 19, 2015 EOB PT.

Mehmet and Mahesh,

I have posted draft-ietf-netconf-rfc5539bis-08 which I believe
addresses the WG last call comments. Please check and if you agree,
please produce a document writeup and move the I-D over to the IESG.

/js