Page tree
Skip to end of metadata
Go to start of metadata

Samenvatting

Waarom is deze RFC nodig?

RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound vertelt dat de gebruikte certificaten gevalideerd moeten worden. Dit betekent dat de gegevens van het gebruikte certificaat overeen moeten komen met vooraf geconfigureerde credentials. Hierbij gaat het om het certificaat dat in de backchannel gebruikt wordt. In de huidige situatie is binnen het MedMij afsprakenstelsel hier nog geen concrete oplossing voor beschreven. Het doel van deze RFC is daarmee het duidelijk beschrijven van deze validatie en de benodigde implementatie van systemen.

Oplossingsrichting

Voeg (een identifier van) het gebruikte G1 (of EV) certificaat toe aan de OCL, zodat deze gebruikt kan worden voor de benodigde validatie.

Aanpassing van

Dit vergt een aanpassing van het afsprakenstelsel in het hoofdstuk Applicatie. Daarnaast zal de R&A aangepast moeten worden, zodat deze gegevens geregistreerd kunnen worden. De gegevens moeten worden toegevoegd aan de OCL. Deelnemers moeten aan het token-endpoint de controle toevoegen van het certificaat met de gegevens in de OCL.

Impact op rollen

DVZA, zij moeten de nieuwe informatie gebruiken om de juiste validatie uit te voeren. Bij ieder request op het token-endpoint moet deze validatie uitgevoerd worden.

Impact op beheer

De gegevens van de verschillende deelnemers in de R&A moeten uitgebreid worden. Dit is in de huidige situatie een handmatige actie die door beheer moet worden uitgevoerd.

Impact op RnA

De nieuwe gegevens moet geregistreerd kunnen worden. Hiervoor moet een veld aan de schermen en aan de database worden toegevoegd. Dit veld moet ook worden toegevoegd aan de OCL.

Impact op Acceptatie

Ja, Gedurende de acceptatie moet getest worden of certificaten goed gevalideerd worden. Dus testen met valide en invalide certificaten.

Gerelateerd aan (Andere RFCs, PIM issues)


Eigenaar
Implementatietermijn

1.4.0

Motivatie verkorte RFC procedure (patch)


Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
Productmanager Stichting MedMij

Productmanager Beheerorganisatie

Leadarchitect Stichting MedMij

Leadarchitect Beheerorganisatie

Ontwerpteam




Deelnemersraad

Eigenaarsraad

Principe's

Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

NvT

11 Stelselfuncties worden vanaf de start ingevuld

Positief

2 Dienstverleners zijn transparant over de gegevensdiensten 

NvT

12 Het afsprakenstelsel is een groeimodel

Positief

Dienstverleners concurreren op de functionaliteiten

NvT

13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders

Positief

Dienstverleners zijn aanspreekbaar door de gebruiker

NvT

14 Uitwisseling is een keuze

NvT

De persoon wisselt gegevens uit met de zorgaanbieder

Positief

15 Het MedMij-netwerk is gebruiksrechten-neutraal

NvT

MedMij spreekt alleen af wat nodig is

Positief

16 De burger regisseert zijn gezondheidsinformatie als uitgever

NvT

De persoon en de zorgaanbieder kiezen hun eigen dienstverlener

NvT

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

NvT

De dienstverleners zijn deelnemers van het afsprakenstelsel

NvT

18 Afspraken worden aantoonbaar nageleefd en gehandhaafd

Positief

10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling

NvT

19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat

Positief

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.

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.

DreigingKansImpactDreigingsID (intern)Maatregelen
Overname code (en daarmee token) door een andere deelnemer.Klein, de al aanwezige maatregelen dekken een groot deel van het risico af.Groot, data kan worden gedeeld met een partij die hiervoor geen autorisatie heeft gekregen.

Al aanwezig:

  • Gebruik whitelist, hierdoor kunnen alleen deelnemers gebruikmaken van deze mogelijkheid.
  • Beperkte houdbaarheid code, hierdoor kan een code een beperkte periode omgewisseld worden voor een token.
  • Terugtrekken code en token, hierdoor worden code en eventueel uitgegeven token invalide en kunnen niet meer gebruikt worden.

Nieuw:

  • Controle client_id, code en PKI certificaat op de token endpoint, hierdoor kan alleen het certificaat gebruikt worden dat vooraf is geconfigureerd.
DVP/PGO heeft geen/onjuiste informatie opgevoerd in stelslenode

Middel

Hoog, DVZA's zullen verzoeken van de betreffende DVP gaan weigeren
  • Goede voorlichting in de aanloop van de release
  • Actief benaderen DVP/PGO's
  • Probleem kan door PGO zelf vastgesteld én zelfstandig verholpen worden in productie
Bij een certificaatswissel zullen de gegevens op de stelselnode gecontroleerd en indien noodzakelijk aangepast moeten wordenMiddelHoog, DVZA's zullen verzoeken van de betreffende DVP gaan weigeren
  • Documentatie voor deelnemers hierop aanvullen
  • Probleem kan door PGO zelf vastgesteld én zelfstandig verholpen worden in productie

Bijlagen



  • No labels