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

From: Alan Luchuk <[email-masked]>
Date: Wed, 3 Jun 2015 14:17:19 -0400 (EDT)

Hi Kent,

>Thanks again for another great review.  Below are my responses to your
>comments.  I was hoping to receive more comments before posting an updated
>draft, but went ahead and posted -06 just now to reflect this update.

You're welcome!

>>Page 6, section 2.1, item C5:
>>-----------------------------
>>
>>The text reads:
>>
>>       validation data (e.g., pinning, using the entire host key or
>>       certificate as the lookup key) or via certificate path validation
>>
>>Perhaps delete the word "pinning"?
>>
>>Upon first read, I was not sure what "pinning" meant.  Upon a second read,
>>I assume that "pinning" is defined by the rest of the phrase in
>>parenthesis.
>
>
>I addressed this specific issue by changing the wording to "...to a
>previously trusted or 'pinned' value".  So it becomes self-defining.  Is
>this is acceptable?

I think the new text is clearer.

>
>>As an unrelated issue, the phrase suggests the _entire_ certificate is
>>used 
>>as the lookup key.  Is this what was intended?
>
>Yes, but looking at it more carefully, I felt that the entire bullet point
>wasn't clear enough and hence rewrote that section.  Please see the
>diff for details: 
>https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-06.txt

Thanks for the suggestion.  I studied this differences fairly carefully.
The new text is more specific, and I agree it is an improvement from the 
previous text in draft-05.  

Nit:  Would it clarify the text in item "C6" to change "reference identifier" 
to "server reference identifier"?  

FWIW, I'm not fond of the term "reference identifier", but it is probably
the best choice.  Alternatives would probably be more wordy, and reduce
the overall clarity of the text.

Regards,
--Alan

---

From: Kent Watsen <[email-masked]>
Date: Wed, 3 Jun 2015 19:17:11 +0000

>previous text in draft-05.

No new split infinitives?  ;)

>the overall clarity of the text.

This term comes from RFC 6125, Section 1.8.  A reference to it should be
added.  But looking at 6125 again, I see it defines "identifier" as being
of two kinds "reference" and "presented".   In C6, though discussing
presented identifiers, I think just using "identifier" by itself makes the
most sense.  Same for section 2.2.  What do you think?

Kent

---

From: Alan Luchuk <[email-masked]>
Date: Wed, 3 Jun 2015 17:28:11 -0400 (EDT)

Hello,

>No new split infinitives?  ;)

I can go back and look again  :-)

>most sense.  Same for section 2.2.  What do you think?

I agree that just using "identifier" by itself will be the simplest and
clearest.  

Also, I agree that adding a reference to RFC 6125 would be helpful (and 
to include section 1.8, if possible.)

Regards,
--Alan

---

From: t.petch <[email-masked]>
Date: Tue, 9 Jun 2015 11:31:32 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Alan Luchuk" <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 03, 2015 8:17 PM
> No new split infinitives?  ;)

No but there might be the avoidance thereof in S4
"the server MUST also send any intermediate certificates leading up to
the trust anchor the clients are expected use to authenticate it.  "

And in s.4, " This reversal is incongruous with [RFC4253], ", I wonder
if incongruent is intended.

I like Alan's changes.

One issue from earlier is what methods of authentication are acceptable.
5539bis now says X.509 certificate,  RFC6242 is silent; I don't know
where Restconf is heading.  This I-D sort of implies that servers will
only offer certificates or host keys, in which case I would like to see
that made explicit.

On client authentication by servers, we seem not to require it.  I have
read and re-read
"3.  The NETCONF or RESTCONF Server
3.1.  Protocol Operation "
and can see no mention thereof.

Tom Petch

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 Jun 2015 21:46:45 +0000

Hi Tom,

>the trust anchor the clients are expected use to authenticate it.  "

Good catch, this is what I have now:

   If a certificate is sent, the server MUST also send any intermediate
   certificates leading up to the trust anchor the client will use to
   authenticate the server's certificate with.

OK?

>if incongruent is intended.

Searching "incongruous vs incongruent" returns a surprising number of
responses.  It seems that this is a common question!  My reading is that
"incongruous" is the better option here, so I plan to leave it as it is.

>only offer certificates or host keys, in which case I would like to see

True, RFC6242 is silent, for which I'm happy as it extends it to support
RFC 6187.  RESTCONF, like 5539bis, is also exclusively X.509:
https://tools.ietf.org/html/draft-ietf-netconf-restconf-05#section-2.2.
I'm not sure what to do about your last comment - any concrete suggestions?

It is relatively easy to lock TLS to X.509, but SSH is all over the map.
SSH calls it a "host key" (RFC 4251, Section-4.1), and host keys
correspond to public key algorithms (RFC 4253, Section 7.1), and there are
a number of algorithms
(http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-pa
rameters-19), some using certificates (e.g., RFC 6187).  So an SSH host
key can be a certificate too...

>and can see no mention thereof.

We have this on the client side:

   C7  After the server's host key or certificate is validated, the SSH
       or TLS protocol proceeds as normal to establish a SSH or TLS
       connection.

Where "proceeds as normal" is intended to include the client
authentication step.  The closest equivalent on the server side is in the
beginning go S5:

   S5  Once the SSH or TLS connection is established, the ...

Where it's only tangentially implied.

Complicating matters, client auth in RESTCONF only occurs in the secure
transport when using the ClientCertificate authentication scheme.  When
using either the Basic or Digest authentication schemes, authentication
occurs post-TLS in the HTTP layer.  So implying client authentication
always occurs as part of TLS connection establishment is not entirely
accurate.  

This is why I was trying to hide all the client authentication steps
behind the "proceeds as normal" clause and similar clauses in C8 and S5
regarding starting the NETCONF/RESTCONF protocols.  I'm weary of this
exploding into a lot of text.  Can you suggest a simple fix?

Thanks,
Kent

---

From: "Jonathan Hansford" <[email-masked]>
Date: Wed, 10 Jun 2015 09:41:30 +0100

Hi Kent,

Re S4, the resulting sentence feels a little clumsy and the intent is
not that clear to me. Presumably the intent is that "the server MUST
send any intermediate certificates the client will use to authenticate
the server's certificate" and the "leading up to the trust anchor" is
provided as context. Should it not also be "all" rather than "any"?
How about:
If a certificate is sent, the server MUST also send all intermediate
certificates leading up to the trust anchor. These will be used by the
client to
authenticate the server's certificate.
Jonathan
----- Original Message -----
From: "Kent Watsen" 
To:"t.petch" , "Alan Luchuk" , "[email-masked]" 
Cc:
Sent:Tue, 9 Jun 2015 21:46:45 +0000
Subject:Re: [Netconf] draft-ietf-netconf-call-home-05.txt

 Hi Tom,

 If a certificate is sent, the server MUST also send any intermediate
 certificates leading up to the trust anchor the client will use to
 authenticate the server's certificate with

 OK?

 Searching "incongruous vs incongruent" returns a surprising number of
 responses. It seems that this is a common question! My reading is
that
 "incongruous" is the better option here, so I plan to leave it as it
is.

 >only offer certificates or host keys, in which case I would like to
see

 True, RFC6242 is silent, for which I'm happy as it extends it to
support
 RFC 6187. RESTCONF, like 5539bis, is also exclusively X.509:
 https://tools.ietf.org/html/draft-ietf-netconf-restconf-05#section-2.2.
 I'm not sure what to do about your last comment - any concrete
suggestions?

 It is relatively easy to lock TLS to X.509, but SSH is all over the
map.
 SSH calls it a "host key" (RFC 4251, Section-4.1), and host keys
 correspond to public key algorithms (RFC 4253, Section 7.1), and
there are
 a number of algorithms
 (http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-pa
 rameters-19), some using certificates (eg., RFC 6187). So an SSH
host
 key can be a certificate too...

 Where "proceeds as normal" is intended to include the client
 authentication step. The closest equivalent on the server side is in
the
 beginning go S5:

 Complicating matters, client auth in RESTCONF only occurs in the
secure
 transport when using the ClientCertificate authentication scheme.
When
 using either the Basic or Digest authentication schemes,
authentication
 occurs post-TLS in the HTTP layer. So implying client authentication
 always occurs as part of TLS connection establishment is not entirely
 accurate. 

 This is why I was trying to hide all the client authentication steps
 behind the "proceeds as normal" clause and similar clauses in C8 and
S5
 regarding starting the NETCONF/RESTCONF protocols. I'm weary of this
 exploding into a lot of text. Can you suggest a simple fix?

 Thanks,
 Kent

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

---

From: t.petch <[email-masked]>
Date: Thu, 11 Jun 2015 10:44:18 +0100

---- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "t.petch" <[email-masked]>; "Alan Luchuk" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, June 09, 2015 10:46 PM

Hi Tom,

OK?

<tp>
OK also OK with Jonathan's alternative

!!!

It is relatively easy to lock TLS to X.509, but SSH is all over the map.
SSH calls it a "host key" (RFC 4251, Section-4.1), and host keys
correspond to public key algorithms (RFC 4253, Section 7.1), and there
are
a number of algorithms
(http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh
-pa
rameters-19), some using certificates (e.g., RFC 6187).  So an SSH host
key can be a certificate too...

<tp>
yes but I think worth making explicit, saying something along the lines
that that for TLS, the scope of authentication is the same as for
5539bis, namely X.509 certificates while for SSH, any method defined for
SSH will do.  The current text sort of implies a greater restriction and
it is that that I wanted to clarify.

<tp>

No:-(  I had not thought through the RESTCONF implications.  I will
think some more but will probably end up leaving it as is unless anyone
else picks up on it.

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Fri, 12 Jun 2015 20:55:41 +0000

Hi Jonathan,

I went with your first sentence, with a minor tweak.  I left out your second sentence, since it seemed unnecessary the more I looked at it (hopefully you agree!).  Here is where we are at now:

   S4  As part of establishing the SSH or TLS connection, the NETCONF/
        RESTCONF server will send its host key or certificate to the
        client.  If a certificate is sent, the server MUST also send all
        intermediate certificates leading up to the certificate's trust
        anchor.  How to send a list of certificates is defined for SSH in
        [RFC6187] Section 2.1, and for TLS in [RFC5246] Section 7.4.2.

You like?

Thanks,
Kent

From: Jonathan Hansford <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 10, 2015 at 4:41 AM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>, "t.petch" <[email-masked]<mailto:[email-masked]>>, Alan Luchuk <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt

Hi Kent,

Re S4, the resulting sentence feels a little clumsy and the intent is not that clear to me. Presumably the intent is that "the server MUST send any intermediate certificates the client will use to authenticate the server's certificate" and the "leading up to the trust anchor" is provided as context. Should it not also be "all" rather than "any"? How about:

If a certificate is sent, the server MUST also send all intermediate
certificates leading up to the trust anchor. These will be used by the client to
authenticate the server's certificate.

Jonathan

----- Original Message -----
From:
"Kent Watsen" <[email-masked]<mailto:[email-masked]>>

To:
"t.petch" <[email-masked]<mailto:[email-masked]>>, "Alan Luchuk" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc:

Sent:
Tue, 9 Jun 2015 21:46:45 +0000
Subject:
Re: [Netconf] draft-ietf-netconf-call-home-05.txt

Hi Tom,

OK?

Thanks,
Kent

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

---

From: Kent Watsen <[email-masked]>
Date: Fri, 12 Jun 2015 20:57:39 +0000

Hi Tom,

>it is that that I wanted to clarify.

I tried inserting some text into the Introduction, but there wasn't an
easy way to do it.  So I rather ask, where are you picking up this greater
restriction in the text?

>>On client authentication by servers, we seem not to require it.

I added this new section:

   S5  In most cases, establishing the SSH or TLS connection also
       entails server authentication of client credentials; only with
       RESTCONF do some client authentication schemes occur after the
       secure transport connection (TLS) has been established.  If
       client authentication is required, and the client is unable to

       successfully authenticate itself to the server in an amount of
       time defined by local policy, the server SHOULD close the
       connection.

What do you think?

I disagree that client auth seems not required, in that it's required by
the draft's normative references:

1. RFC 6241 says "NETCONF connections MUST be authenticated.  The
transport protocol is responsible for authentication of the server to the
client and authentication of the client to the server."

2. RFC6242 says: "The identity of the SSH client MUST also be verified and
authenticated ..."

3. 5539bis says "The NETCONF server MUST verify the identity of the
NETCONF client ..."

4. restconf-07 says "The RESTCONF server MUST authenticate client access
..."

I'm hoping that the new S5 and the normative references address your
concern - do they?

Thanks,
Kent

---

From: Jonathan Hansford <[email-masked]>
Date: Sat, 13 Jun 2015 10:31:25 +0100

Hi Kent,

Looks good to me.

Jonathan

> On 12 Jun 2015, at 21:55, Kent Watsen <[email-masked]> wrote:
> 
> Hi Jonathan,
> 
> From: Jonathan Hansford <[email-masked]>
> To: Kent Watsen <[email-masked]>, "t.petch" <[email-masked]>, Alan Luchuk <[email-masked]>, "[email-masked]" <[email-masked]>
> "Kent Watsen" <[email-masked]>
> 
> To:
> "t.petch" <[email-masked]>, "Alan Luchuk" <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc:
> 
> Sent:

---

From: t.petch <[email-masked]>
Date: Sat, 13 Jun 2015 12:53:15 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "t.petch" <[email-masked]>; "Alan Luchuk" <[email-masked]>;
<[email-masked]>
Sent: Friday, June 12, 2015 9:57 PM

Hi Tom,

I tried inserting some text into the Introduction, but there wasn't an
easy way to do it.  So I rather ask, where are you picking up this
greater
restriction in the text?

<tp>
Funny you should ask:-) Look at your other post

"As part of establishing the SSH or TLS connection, the NETCONF/
        RESTCONF server will send its host key or certificate to the
        client.  "
which to me says it is certificate or it is host key and it cannot be
anything else!  Ditto C5 or C7. But if noone else joins in, perhaps best
left as is.

What do you think?

<tp>

Perhaps 'MUST close' but otherwise ok.  And of course when you know the
References intimately having worked on them since draft-wasserman, then
yes, you will know the requirement for authentication - but I think
there is no harm and some benefit in repeating it here, since the vast
majority of uses of TLS do not call for client authentication - it is us
that is out on a limb here.

Tom Petch

1. RFC 6241 says "NETCONF connections MUST be authenticated.  The
transport protocol is responsible for authentication of the server to
the
client and authentication of the client to the server."

2. RFC6242 says: "The identity of the SSH client MUST also be verified
and
authenticated ..."

Thanks,
Kent

---

From: t.petch <[email-masked]>
Date: Sat, 20 Jun 2015 09:46:49 +0100

And your reference to 5539bis needs updating:-)

Tom Petch

----- Original Message -----
From: "t.petch" <[email-masked]>
To: "Kent Watsen" <[email-masked]>; "Alan Luchuk"
<[email-masked]>; <[email-masked]>
Sent: Saturday, June 13, 2015 12:53 PM
Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt