[NEW] Take username from client certificate

[zuiderkwast]

The problem/use-case that the feature addresses

Avoid managing user passwords for ACL when we already use TLS with mutual authentication.

When password rotation is required and also certificate rotation is required, it becomes complex to rotate both of them.

Description of the feature

The server can take the username from the client's certificate, the comman name (CN=username) field. It seems to be common practice.

When this field matches an existing user, the client gets authenticated as this user as if the AUTH command had been used.

Alternatives you've considered

Use AUTH or HELLO and manage passords and do password rotation for each user, in addition to TLS certificates rotations.

Additional information

[omanges]

Is this something which I can pickup like as getting started work for understanding the code base ?

[zuiderkwast]

@omanges Yes, feel free! I'll assign you to this issue then. Don't hesitatet to ask questions.

[omanges]

@zuiderkwast So, to clarify, we want to connect directly as the user whose CN name is present in the certificate when someone uses the same certificate to establish a TLS connection, rather than connecting as the default user. Correct?

[zuiderkwast]

Yes, correct.

Maybe we need a config to enable this feature. @madolson WDYT?

[madolson]

We can figure out the details in the PR. High level the TSC was okay with this type of feature.

Personally I like the idea of having a config which allows you to configure which certificate field should authenticate the connection. By default it is none, but you can configure it to be the CN or O some other field. tls-auth-client-authentication-field: none Maybe?

[zuiderkwast]

Personally I like the idea of having a config which allows you to configure which certificate field should authenticate the connection. By default it is none, but you can configure it to be the CN or O some other field. tls-auth-client-authentication-field: none Maybe?

I agree with this, but the suggested name tls-auth-client-authentication-field contains "auth" twice. Also note that the existing config tls-auth-clients (to require/allow/forbid client cert) has "clients" in plural.

How about tls-auth-clients-field?

As for the possible values, I think Common Name (CN) is the first choice. O (Organization) doesn't seem unique and is probably not common to use as a username.

Another possible fields to use is Subject Alternative Name (SAN) and here there are multiple types defined in RFC 5280, 4.2.1.6:

• rfc822Name for email addresses, can be used if emails are used as usernames.
• dNSName for hostnames, can be used to identify machines rather than humans.

I'm fine with adding only none and cn (for Common Name) for now though and we can add more fields in the future.