Subject: Re: [Netconf] rfc5539bis > - NC over TLS with mutual X.509 authentication

From: Alan Luchuk <[email-masked]>
Date: Fri, 31 Oct 2014 10:19:26 -0400 (EDT)

Hello,

>From: "Juergen Schoenwaelder" <[email-masked]>
>To: "t. petch" <[email-masked]>
>Cc: "Kent Watsen" <[email-masked]>; <[email-masked]>
>Sent: Monday, October 27, 2014 2:55 PM
>>
>> the editor does not understand the edits since I do not see clear
>> agreement of the scope of the document and thus there won't be a new
>> version before the cutoff. It makes a major difference to me
>> whether the document is
>>
>> - NC over TLS with mutual X.509 authentication
>>
>> or
>>
>> - NC over TLS plus a structure to plug in new authentication
>>   mechanisms
>
>I think that limiting this I-D to mutual X.509 authentication resolves
>the issues that have been raised.

+1

>
>Juergen commented on the mix of MAY, MUST etc causing confusion and that
>becomes simpler when there is just one approach to be specified.
>
>Martin commented on not knowing what to do about other forms of
>authentication - well, keep them out of this I-D and let anyone who
>wants to produce a separate I-D thereon.  After all, the specification
>of TLS, and of SSH, is littered with I-Ds adding new forms of
>authentication so that would be nothing new.
>
>Tom Petch
>

Also, included below is the following new proposed text for Section 2.4.1, 
and a new section 2.4.2.  The new section 2.4.2 would displace the existing 
section 2.4.2 to have 2.4.3, and so on.  Thoughts on this?

Regards,
--Alan

Section 2.4.1  Verifying the NETCONF Server Identity
----------------------------------------------------

The NETCONF client MUST verify the identity of the NETCONF server.
The NETCONF client MAY use the procedure documented in Section 2.4.2
to verify the identify of the NETCONF server.  The NETCONF client MAY 
use an alternate procedure to verify the identity the NETCONF server.

If the NETCONF client uses an alternate procedure to verify the identity 
of the NETCONF server, then the alternate procedure must 
provide a level of verification comparable to the procedure documented 
in Section 2.4.2.  One example of an alternate procedure for verifying
the NETCONF server's identity would be to compare the X.509 certificate 
presented by the NETCONF server against a local store of 
already-verified X.509 certificates and identity bindings.

If the NETCONF client attempts to connect to a NETCONF server, and the
NETCONF server fails the identity verification step, then the NETCONF 
client MUST notify the user that the NETCONF server identity 
verification failed, and  1) either terminate the connection, or  
2) request user confirmation to proceed with the connection.

Section 2.4.2  Standard Procedure for Verifying the NETCONF Server Identity
---------------------------------------------------------------------------

If the NETCONF client uses this documented procedure to verify the 
identify of the NETCONF server, then the NETCONF client MUST follow
follow this procedure completely.

The NETCONF client MUST verify the integrity of the X.509 certificate
presented by the NETCONF server.  To do this, the NETCONF client MUST:

-  Use the certificate path validation algorithm described in 
   Section 6 of [RFC 5280].

-  Validate the X.509 certificate presented by the NETCONF server 
   to a trust anchor configured in the NETCONF client.

To prevent man-in-the-middle attacks, after verifying the integrity of 
X.509 certificate presented by the NETCONF server, the NETCONF 
client MUST verify the identity of the NETCONF server.  To verify the 
identity of the NETCONF server:
  
-  The NETCONF client MUST have information about the expected identity 
   of the NETCONF server to which it connected, and from which it received
   a presented X.509 certificate.  This NETCONF server identity information 
   MUST be pre-configured in the NETCONF client before it initiates the 
   connection to the NETCONF server.

-  The X.509 certificate presented by the NETCONF server must contain
   information about the NETCONF server's identity.  

-  The NETCONF client MUST extract the NETCONF server identity information 
   from the X.509 certificate presented by the server.   The NETCONF client 
   MUST compare the extracted server identity to the pre-configured server 
   identity information according to the rules and guidelines defined in 
   [RFC 6125].  If the comparison succeeds, then the NETCONF server 
   identity is verified, and the connection can proceed.  If the comparison
   fails, then the NETCONF server identity verification has failed.  The 
   NETCONF client must handle the NETCONF server identity verification 
   failure as documented above.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 31 Oct 2014 21:42:20 +0000

>>the issues that have been raised.

I also +1 to limiting 5539bis to just mutual X.509 auth.  That said, I
thought that this was already the case, or at least the intent, with all
the references to RFCs 5280 and 6125 and what not.

>section 2.4.2 to have 2.4.3, and so on.  Thoughts on this?

I'm not sure if adding more sections or more words is needed - maybe this
is a case where less is more?   Maybe we *only* need to 1) state that
server authentication MUST be via PKIX as defined in RFCs 5280 and 6125
and 2) state anything not already covered by RFCs 5280 and 6125.

Also, I noticed that you didn't touch the original section 2.4.2. (Client
Identity).   This is the section that is currently missing a statements
along the lines of:
  - the client MUST present a X.509 certificate
  - the client MAY also present a chain of intermediate certs to a trust
anchor the server is expected to trust
  - the server MUST authenticate the client's certificate
  - the server MAY authenticate the client's certificate using PKIX to a
configured trust anchor
  - the server MAY authenticate the client's certificate if it's an exact
match to a previously trusted client certificate.

Also, I think the last two paragraphs in 2.4.2 should be moved to 2.4.3
(group everything about usernames to one section) and the add a statement
to 2.4.3 like:
  - the server MUST have a configurable mapping from the presented client
certificate to the NETCONF username, such as the cert-to-name algorithm
defined in section 4.1 of draft-ietf-netmod-snmp-cfg-08

Thanks,
Kent