Re: [netconf] a comment on draft-ietf-netconf-tls-client-server-15

[Kent Watsen <[e-mail]>]

[reducing to open parts]


>>> 2.  When this grouping is used in ietf-https-notifs, it looks like
>>>   this:
>>> 
>>> +--rw receivers
>>>    +--rw receiver* [name]
>>>       +--rw name           string
>>>       ...
>>>       |  +--rw server-authentication
>>>       |  |  +--rw ca-certs! {ts:x509-certificates}?
>>>                ...            
>>>       |  |  +--rw server-certs! {ts:x509-certificates}?
>>>                ...
>>> 
>>>  Now, the container 'server-authentication' has
>>>  nacm:default-deny-write, and its contents is mandatory (due to the
>>>  must expression).  This means that it is not possible to configure
>>>  a single receiver without explicit NACM rules for this container.  Is
>>>  that really the intention?
>> 
>> Yes, these are security parameters.  Read access is okay, but only
>> authorized clients should be able to configure them.
> 
> I think it is odd that if I am trusted to configure a tls client, I
> can't fully configure it w/o additional rules.
> 
> For example, suppose the security admin has set up a certificate
> trustore (/truststore/certificate) with trusted certificates.  Now if
> I want to create a receiver of notifications, I want to point to this
> list.  But I can't do that w/o special NACM rules.

Without this default-deny-write, the second administrator could
configure a `local` setting that didn't point to the truststore, or
modify the `truststore` setting to point to potentially improper
truststore definitions.


>>> 4.  The description of ca-certs and server-certs has:
>>> 
>>>     "A server certificate is authenticated if ..."
>>> 
>>>   But you don't specify what it means for a certificate to be
>>>   authenticated.  If the intention is that the meaning depends on
>>>   where it is used, the description of the grouping should specify
>>>   this requirement.
>> 
>> For "ca-certs", the full sentence is: 
>> 
>>          A server certificate is authenticated if it has a valid
>>           chain of trust to a configured CA certificate.";
>> 
>> For server-certs, the full sentence is:
>> 
>>           A server
>>           certificate is authenticated if it is an exact match
>>           to a configured server certificate.";
>> 
>> How is the 2nd-half of these sentences not doing just what you're
>> asking for?
> 
> So the text explains when a server certificate is authenticated.  But
> what is supposed to happen when a server certificate is not
> authenticated?

What happens is TLS/SSH specific, but generally entails the server
sending the client a failure message followed by closing the TCP
connection.


> BTW, should it rather be "A server is authenticated if its certificate
> is an exact match..." etc?

Yes.  Language fixed in all four modules.


Kent // contributor