RFC0042 Validatie van certificaten op het token endpoint

Samenvatting

Goedkeuring

Principe's

Uitwerking

Voor de beveiling van de communicatie wordt op netwerk-niveau gebruikgemaakt van TLS 1.2 (en TLS 1.3). Hierbij wordt gebruikgemaakt van twee typen PKIoverheidcertificaten:

• Voor frontchannelverkeer moeten publieke CA2020 eindcertificaten onder de EV-root worden gebruikt.
• Voor backchannelverkeer moeten private CA2020 eindcertificaten onder de G1-root worden gebruikt.

Voor autorisatie op applicatieniveau wordt gebruikgemaakt van OAuth 2.0 en hierbinnen van de Authorization Code flow. Binnen deze flow worden verschillende endpoints aangeroepen. Op de authorization server zijn dit het authorization endpoint en het token endpoint. Bij het authorization endpoint spreken we van frontchannelverkeer, waarbij in de browser gebruikgemaakt wordt van redirects. De PGO en de authorization server hebben hierbij geen direct contact met elkaar, er worden dan ook geen certificaten uitgewisseld. Bij het token endpoint is dit anders. Het token endpoint dient voor het omwisselen van een authorization code voor een access token. Hierbij communiceren de PGO en de authorization server wel direct met elkaar en spreken we over backchannelverkeer. Mutual TLS is aan de orde. RFC8705 van Internet Engineering Task Force (IETF) zegt het volgende:

2.  Mutual TLS for OAuth Client Authentication

For all requests to the authorization server utilizing mutual-TLS client authentication, the client MUST include the "client_id" parameter described in Section 2.2 of OAuth 2.0 [RFC6749]. The presence of the "client_id" parameter enables the authorization server to easily identify the client independently from the content of the certificate. The authorization server can locate the client configuration using the client identifier and check the certificate presented in the TLS handshake against the expected credentials for that client. The authorization server MUST enforce the binding between client and certificate, as described in either Section 2.1 or 2.2 below.

2.1.1.  PKI Method Metadata Value

For the PKI method of mutual-TLS client authentication, this specification defines and registers the following authentication method metadata value into the "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters].

tls_client_auth
Indicates that client authentication to the authorization server will occur with mutual TLS utilizing the PKI method of associating a certificate to a client.

2.1.2.  Client Registration Metadata

In order to convey the expected subject of the certificate, the following metadata parameters are introduced for the OAuth 2.0. Dynamic Client Registration Protocol [RFC7591] in support of the PKI method of mutual-TLS client authentication. A client using the "tls_client_auth" authentication method MUST use exactly one of the below metadata parameters to indicate the certificate subject value that the authorization server is to expect when authenticating the respective client.

tls_client_auth_subject_dn
A string representation -- as defined in [RFC4514] -- of the expected subject distinguished name of the certificate that the OAuth client will use in mutual-TLS authentication.

Kort gezegd betekent bovenstaande op applicatieniveau dat:

1. de PGO de client_id toevoegt aan een verzoek.
2. client authentication wordt uitgevoerd op basis van mutual TLS.
3. de PGO gebruikmaakt van een G1 eindcertificaat of een EV eindcertificaat.
4. de authorization server het gebruikte certificaat moet valideren tegen vooraf geconfigureerde credentials.
5. de authorization server de benodigde configuratie kan vinden met de client_id.

De punten 4 en 5 moeten worden uitgewerkt in het MedMij afsprakenstelsel en betekenen wijzigingen voor de deelnemers, met name de DVZA's.

Voorstel

Breidt de OCL uit met de CN van het certificaat dat gebruikt wordt bij de aanroep van het token-endpoint. De ontvangende authorization server kan deze informatie gebruiken om de validatie van het certificaat uit te voeren. Dit is in lijn met hetgeen beschreven wordt in RFC 8705. In versie 1.4.0 wordt de implementatie van deze controle als 'optioneel' beschreven. In de volgende versie wordt dit dan verplicht, mits er geen andere oplossing voor authenticatie en autorisatie wordt voorgesteld.

De nieuwe regel wordt aan het afsprakenstelsel toegevoegd:

Om deze controle uit te kunnen voeren moet de common name uit het certificaat van de DVP worden opgenomen in de OAuthClientList (OCL). De benodigde  wijziging in de OCL wordt hieronder weergegeven:

    <xs:complexType name="OAuthclient">
        <xs:sequence>
            <xs:element name="Hostname" type="ocl:Hostname"/>
            <xs:element name="CommonName" type="ocl:CommonName"/>
            <xs:element name="OAuthclientOrganisatienaam" type="ocl:OAuthclientOrganisatienaam"/>
            <xs:element name="Interfaceversies" type="ocl:Interfaceversies"/>
        </xs:sequence>
    </xs:complexType>

Risico's

Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.

Bijlagen