Subject: Re: [Netconf] draft-ietf-netconf-call-home-03.txt

From: Alan Luchuk <[email-masked]>
Date: Fri, 16 Jan 2015 16:28:49 -0500 (EST)

Hi Kent,

>Thank you for your review!

You're welcome, and thanks for your clarifications.

>>Sections 2.1/3.1
>>----------------
>>
>>After the establishment of the TCP connection:
>>
>>-  The NETCONF/RESTCONF server _immediately_ starts the SSH-server or
>>   the TLS-server protocol;
>>
>>-  The NETCONF/RESTCONF client _immediately_ starts the SSH-client or
>>   the TLS-client protocol;
>>
>>Is it possible for a race condition to occur that might cause SSH or TLS
>>connection problems?
>
>
>The "immediately" is meant to be interpreted more as "no more TPC data is
>exchanged" than "without temporal delay".  There isn't a race condition
>here.  Just like with a standard (not reversed) connection, the TCP stacks
>will buffer the data until the SSH/TLS layers get initialized.  Do you
>agree?

Yes.  

>>Section 3.2
>>-----------
>>
>>I think this section does a pretty good job of describing the issues,
>>listing the alternatives, and the pros/cons of each alternative.  That
>>said, I had to read this section several times very carefully.  I _think_
>>I understand what it is saying.  Does the following briefly summarize the
>>ideas?
>
>One small correction on the last case.  In advance of the first connect,
>the client should (not must) also know the unique-identifer expected in
>the server's certificate.  By example, an NMS should know the
>serial-numbers for devices it expects to connect to it, in order to be
>certain the devices are legitimate.
>
>Otherwise, is this section still OK?

I think the bulk of the text can be kept intact, but might be clarified
with a few relatively small changes.  The comments below highlight what
I found confusing.  On the other hand, if nobody else was confused, then 
maybe the text should not be changed.  Use your judgement.

Section 3.2, third paragraph:
-----------------------------

Would it be appropriate to change "credentials" to "identity"?  This is the 
only paragraph where the term "credentials" is used.  

When I saw "credentials", I thought of something like a password, host key, 
or X.509 cert, rather than simply the server's identity.  If changing 
"credentials" to "identity" is not appropriate, then perhaps adding one 
sentence that defines the term credentials.

Section 3.2, fifth paragraph:
-----------------------------

The following is hard to parse.

   Without examining the contents of the host-key or certificate, it is 
   possible to form an identity for the NETCONF/RESTCONF server using it 
   directly (e.g., a fingerprint), since each NETCONF/RESTCONF server is 
   assumed to have a statistically unique public key, even in virtualized
   environments.  

Perhaps splitting like so?

   Without examining the contents of the host-key or certificate, it is 
   possible to form an identity for the NETCONF/RESTCONF server using it 
   directly (e.g., a fingerprint).  This works because each NETCONF/RESTCONF 
                                 ^^^^^^^^^^^^^^^^^^^^^
   server is assumed to have a statistically unique public key, even in 
   virtualized environments.  

The following sentence reads:

   This strategy also provides a mechanism to verify the NETCONF/RESTCONF 
   server...

Would the following clarify what is being verified?

   This strategy also provides a mechanism to verify the identity of the 
   NETCONF/RESTCONF server...                            ^^^^^^^^^^^^^^^

Section 3.2, sixth paragraph:
-----------------------------

One of the sentences reads:

   This strategy's use of PKI enables a NETCONF/RESTCONF client to
   transparently authenticate NETCONF/RESTCONF servers

Would it be appropriate to change the text to read:

   This strategy's use of PKI enables a NETCONF/RESTCONF client to
   transparently authenticate the identity of NETCONF/RESTCONF servers

This is the only paragraph where the term "authenticate" is used.

I hope these suggestions are useful.

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: Kent Watsen <[email-masked]>
Date: Sat, 17 Jan 2015 00:18:30 +0000

>>will buffer the data until the SSH/TLS layers get initialized.  Do you

Do you think the current text can be improved to make this interpretation
clearer?

>Section 3.2, third paragraph:

We could say "verify identity" as well.  Think of the questions the client
is asking:

  - who is trying to connect to me?         (identity)
  - how do I know that it is really you?    (verify identity)

What gets tricky is that verifying identity is done by verifying
credentials (public key, proof that the server possesses the private key,
and optionally certificates for PKI (host cert, cert chain, and trust
anchor cert).

So I think that it's OK as written, but I can see "verify identity" as
being easier on the reader, so:

Agreed - done (switched out use of "credential" term)

>Section 3.2, fifth paragraph:

Agreed - done!

>   NETCONF/RESTCONF server...                            ^^^^^^^^^^^^^^^

Agreed - done!

>Section 3.2, sixth paragraph:

We're really talking about authenticated the certificate here, so I change
this as follows instead:

-  transparently authenticate NETCONF/RESTCONF servers
+  transparently authenticate the NETCONF/RESTCONF server's certificate

>This is the only paragraph where the term "authenticate" is used.

Verify and authenticate are synonyms - these aren't technical words.  I'm
using them interchangeably throughout the draft (more than just this
paragraph).   I don't think this is an issue, does anyone else?

Thanks again,
Kent

---

From: Alan Luchuk <[email-masked]>
Date: Mon, 19 Jan 2015 11:12:42 -0500 (EST)

Hello,

Thanks for considering the comments, and the replies and explanations.

>From: Kent Watsen <[email-masked]>
>To: Alan Luchuk <[email-masked]>, "[email-masked]" <[email-masked]>
>Subject: Re: [Netconf] draft-ietf-netconf-call-home-03.txt
>Date: Sat, 17 Jan 2015 00:18:30 +0000

>Do you think the current text can be improved to make this interpretation

I think the text is clear as it is, and should not be changed.  

I made the comment because I wasn't certain whether or not a race condition
existed.  If there is no race condition, there is no need to change the 
existing text.

>  - how do I know that it is really you?    (verify identity)

Thanks!  This explanation makes very good sense.  These were not obvious 
to me upon a first read of the document.

I think other new readers of the document would benefit if this explanation
could be shoe-horned into the existing text, but I wouldn't delay the
document to add it.

Regards,
--Alan

---

From: Kent Watsen <[email-masked]>
Date: Fri, 23 Jan 2015 22:32:05 +0000

Hi Alan,

Thanks again for your comments!

>could be shoe-horned into the existing text, but I wouldn't delay the

I opened issue #11 to track this change:

  https://github.com/netconf-wg/call-home/issues/11

I think this is a "minor" issue, needing WG review, but not needing a lot
of discussion.  Hence I went ahead and modified the text (see diff below)
and moved the issue to the "Review" state.

https://github.com/netconf-wg/call-home/commit/cd4a5f674d7e57a06d7cd0dc8d1b
153d72a573a3

If no one disapproves of this change next week, I'll submit a -04 draft
incorporating it then.  Last-call is close!

Thanks,
Kent