3.3.1.18 Algorithm for Determining Client Access to the Server during SMB Over QUIC Mutual Authentication

The server MUST implement an algorithm for determining client access to the server during SMB over QUIC Mutual Authentication.

The server MUST perform the algorithm if the ServerCertificateMappingEntry.RequireClientAuthentication is TRUE and ServerCertificateMappingEntry.SkipClientCertificateAccessCheck is FALSE.

The server MUST perform the algorithm after QUIC determines that the client certificates are valid and trusted.

Once the server receives the client certificate chain, the server MUST go through each certificate and compute the SHA256 hash and obtain the issuer name for each certificate. Certificates are identified for access control purposes using their SHA256 hash or issuer property.

For each client certificate received, the server MUST look up all AccessControlEntry entries of the issuer in ServerCertificateMappingEntry.AccessControlList. The algorithm MUST match the SHA256 hash of the received issuer certificate with the SHA256 hash of the certificate corresponding to AccessControlEntry.

The server MUST perform the following validations:

A client MUST be granted access only if at least one “allow” entry is found and no “deny” entry is found. Only one “allow” entry is required for access in the chain which indicates that all the certificates below it in the certificate tree are allowed. For the same reason, only one “deny” entry in the chain will cause the client access to be denied. For example, an entry for a leaf certificate will only apply to that certificate. An entry for a certificate authority certificate will apply to all the leaf certificates in the chain up to the certificate authority certificate. The server MAY support root SHA256 entries even though the root certificate is not included in the certificate chain.

Figure: Certificate chain example

Consider the certificate hierarchy above and suppose the following entries are present in ServerCertificateMappingEntry.AccessControlList:

AccessControlEntry[1]: Deny to client_cert_2 based on its SHA256 hash

AccessControlEntry[2]: Deny to root_cert based on its SHA256 hash

AccessControlEntry[3]: Allow to any certificate issued by root_cert

AccessControlEntry[4]: Deny to any certificate issued by inter_cert_2

In this example, client_cert_1 is granted access, but client_cert_2 and client_cert_3 are denied access.

Consider each chain separately.

Chain 1: root_cert -> inter_cert_1 -> client_cert_1.

There is an issuer entry for issuer name root_cert. client_cert_1 is below root_cert in the certificate chain of trust, so the “allow” applies to client_cert_1. The deny SHA256 entry for root_cert has no effect. The server does not have access to the root certificate and so it cannot compute its SHA256 hash. Therefore, client 1 is granted access.

Chain 2: root_cert -> inter_cert_1 -> client_cert_2

The root_cert allow entry applies to client_cert_2, but there is a deny entry for client_cert_2, and so client 2 does not have access. The deny entry for client_cert_2 does not apply to client_cert_1 since client_cert_1 is not below client_cert_2 in the certificate chain of trust.

Chain 3: root_cert -> inter_cert_2 -> client_cert_3

The root_cert allow entry applies to client_cert_3, but there is a deny entry for inter_cert_2. The deny entry applies to client_cert_3 since client_cert_3 is below inter_cert_2 in the certificate chain of trust. Therefore, client 3 is denied access.