search

netconf-wg / netconf-over-quic

0 stars 1 forks source link

Clarify authentication #19

Open aochagavia opened 3 weeks ago

aochagavia commented 3 weeks ago

Relevant text:

5.1. Using QUIC Handshake Authentication

NETCONF over QUIC uses QUIC which uses TLS version 1.3 or greater. Therefore, the TLS handshake process can be used for endpoint authentication.

5.1.1. Using Third-Party Authentication

A third-party authentication mechanism can also be used for endpoint authentication, such as a TLS client certificate.

I think it makes sense to have a single section, as follows:

5.1 Endpoint authentication

  Since the QUIC protocol uses TLS for its handshake, endpoint authentication
  for NETCONF over QUIC happens at the TLS level. A server identifies to the
  client through its TLS certificate, whereas a client identifies to the server
  through its TLS client certificate.
aochagavia commented 3 weeks ago

By the way, a more precise definition could be found in RFC 7589 about NETCONF over TLS, which uses server and client certificates for authentication. Here's the relevant excerpt:

The peer acting as the NETCONF client MUST act as the TLS client. The TLS client actively opens the TLS connection and the TLS server passively listens for the incoming TLS connections. The well-known TCP port number 6513 is used by NETCONF servers to listen for TCP connections established by NETCONF over TLS clients. The TLS client MUST send the TLS ClientHello message to begin the TLS handshake. The TLS server MUST send a CertificateRequest in order to request a certificate from the TLS client. Once the TLS handshake has finished, the client and the server MAY begin to exchange NETCONF messages. Client and server identity verification is done before the NETCONF message is sent. This means that the identity verification is completed before the NETCONF session is started.

There's also section 7, specifying how the client's identity should be validated (it's too long to quote here).