2.3 Authenticatie

LOA 1

1. De gebruiker MOET in staat worden gesteld om de website/app van de authenticatiedienst en alle andere partijen in het netwerk te authenticeren.

2. De HM MOET in het keuzescherm voor de AD tonen bij welke dienst de Gebruiker gaat inloggen.

3. De AD MOET in het aanlogscherm tonen bij welke Dienstverlener de Gebruiker gaat aanloggen.

4. Optioneel: De AD/MU MAG de Gebruiker aanbieden om de notificatiemethode voor LoA4 (onder d.) toe te passen op de lagere LoA's.

5. Het authenticatiemechanisme MOET 'enige' bescherming bieden tegen ondertaande dreigingen:

   1. Raden (guessing): dreiging dat een geheim gegeven (cryptografische sleutel, PIN, etc.) in de communicatie wordt geraden.

   2. Afluisteren (eavesdropping): dreiging dat informatie in de communicatie wordt afgeluisterd ten behoeve van analyse en vervolgaanvallen.

   3. Overnemen van een sessie (hijacking): dreiging dat een geauthenticeerde communicatiesessie wordt overgenomen door een aanvaller.

   4. Naspelen (replay): dreiging dat toegang verkregen wordt tot gevoelige informatie door eerder verzonden berichten opnieuw te versturen of te vertragen.

   5. Man-in-the-middle: dreiging waarbij de aanvaller onafhankelijke verbindingen maakt met beide communicatiepartners en berichten aanpast en/of invoegt.

   6. 'Enige bescherming' MOET worden aangetoond door middel van een risicoanalyse en bijbehorende mitigerende maatregelen.

6. De Deelnemers in het Stelsel MOETEN zekerstellen dat de risico's van identiteitsfraude en misbruik van de middelen worden geanalyseerd en gemitigeerd tot het toepasselijke betrouwbaarheidsniveau.

Ad 1: Dit kan bijvoorbeeld op basis van een TLS  certificaat of een digitale handtekening op basis van een vertrouwd certificaat.

LOA 2

Hetzelfde als LoA1 met toevoeging van:

1. Single Sign-On (SSO) is toegestaan.

LOA 3

Hetzelfde als LoA1 met toevoeging van:

1. Bij gebruik van het authenticatiemechanisme MOET de Gebruiker expliciet duidelijk gemaakt worden dat hij een authenticatie in de context van eHerkenning uitvoert.

2. De toegang tot diensten van elke afzonderlijke dienstverlener MOET het aanloggen met behulp van het middel vereisen.

3. Het authenticatiemechanisme MOET bescherming bieden tegen de meeste van deze dreigingen:

   1. Raden (guessing): dreiging dat een geheim gegeven (cryptografische sleutel, PIN, etc.) in de communicatie wordt geraden.

   2. Afluisteren (eavesdropping): dreiging dat informatie in de communicatie wordt afgeluisterd ten behoeve van analyse en vervolgaanvallen.

   3. Overnemen van een sessie (hijacking): dreiging dat een geauthenticeerde communicatiesessie wordt overgenomen door een aanvaller.

   4. Naspelen (replay): dreiging dat toegang verkregen wordt tot gevoelige informatie door eerder verzonden berichten opnieuw te versturen of te vertragen.

   5. Man-in-the-middle: dreiging waarbij de aanvaller onafhankelijke verbindingen maakt met beide communicatiepartners en berichten aanpast en/of invoegt.

   6. Bescherming MOET worden aangetoond door een risicoanalyse en bijbehorende mitigerende maatregelen.

4. De MU/AD MOET jaarlijks het authenticatiemechanisme onderwerpen aan een risico analyse daarbij rekening houdend met (nieuwe) aanvalstechnieken en kwetsbaarheden. Dit omvat een vergelijking van de gebruikte cryptografische algoritmen en sleutellengtes met de actuele 'good practice'. Indien de analyse daar aanleiding toe geeft worden middelen aangepast en/of vervangen.

5. Het correct functioneren van het authenticatiemechanisme MOET weerstand bieden tegen fysieke en logische manipulatie door een aanvaller met een 'moderate attacker' potentieel in de zin van Annex B van de Common Criteria (ISO 15408-3 en valuatie norm ISO/IEC 18045).

Implementatietermijn

Voor punt 1 en 2 geldt:
De Wet Digitale Overheid is sinds 1 juli 2023 van kracht. Echter, de bijbehorende Ministeriële Regeling is op het moment van deze aanpassing d.d. mei 2024 nog niet gereed.

Ad 1: Doel is om hiermee het risico voor de gebruiker te verminderen in het geval dat zijn applicatie/browser is gecorrumpeerd.

Ad 2: Met SSO is het authenticatiemechanisme op LoA3 tussen dienstverleners kwetsbaar voor Hijacking, Man-in-the-Middel en Man-in-the-Browser aanvallen. Slechts voor diensten van een enkele dienstverlener is SSO op LoA3 toegestaan binnen 2.4 Beheer en organisatie. 

Ad 3: SSO-beleving' is toegestaan op LoA3 voor Diensten van verschillende dienstverleners, binnen 2.4 Beheer en organisatie. Bij een 'SSO-Beleving' gebruikt de AD bijvoorbeeld een geldige gebruikers-sessie in combinatie met een gebruikers-consent, onafhankelijk van de browser die hij gebruikt. 

Ad 5: De wijze waarop conformiteit met deze eis wordt aangetoond is aangegeven in paragraaf 2.4.7 Compliance en Audit.

LOA 4

Hetzelfde als LoA3 met toevoeging van:

1. Het authenticatiemechanisme MOET de Gebruiker notificeren (onafhankelijk van de browser die hij gebruikt) van zijn inlogpoging bij een specifieke dienst of dienstverlener .

2. De notificatie MOET zijn gekoppeld aan het gebruik van diensten op het niveau van het middel.

3. De Deelnemer MAG een optie aanbieden om de notificatiedienst door de gebruiker zelf aan en uit te laten zetten voor diensten op het LoA van het middel of lager.

4. De notificatie ZOU de Gebruiker binnen een tijdsbestek MOETEN bereiken zodat de notificatie zijn beslissing om de inlog voort te zetten of af te breken kan beïnvloeden.

5. Het middel MOET een betrouwbaar (trusted) kanaal bevatten ten behoeve van betrouwbare notificatie en bevestiging, ook wanneer zijn voor inlog gebruikte applicatie of het platform (o.a. PC) waarop de applicatie actief is gecorrumpeerd is. Dit kanaal MOET de mogelijkheid bevatten om de gebruiker elementen in het authenticatieverzoek te laten bevestigen.

6. De Deelnemer MOET de Gebruiker bij het aanbieden van de notificatiedienst er op attenderen dat hij als Gebruiker zelf verantwoordelijk is voor de beveiliging van zijn browser en zelf dus ook verantwoordelijk draagt voor de beslissing om in te loggen.

7. Het correct functioneren van een authenticatiemechanisme (en het middel) MOET weerstand bieden tegen fysieke en logische manipulatie door een aanvaller met een 'High attacker' potentieel in de zin van Annex B van de Common Criteria (ISO 1508-3 en evaluatie norm ISO/IEC 18045).

Implementatietermijn

Voor punt 5 geldt:
De Wet Digitale Overheid is sinds 1 juli 2023 van kracht. Echter, de bijbehorende Ministeriële Regeling is op het moment van deze aanpassing d.d. mei 2024 nog niet gereed.

Doel van de eis is om de Gebruiker in staat te stellen een fout of inbreuk in de communicatie te herkennen en bij twijfel de informatietransactie af te breken. Het is altijd mogelijk dat de browser van de Gebruiker gecompromitteerd raakt daarom is voor LoA4 is een extra maatregel opgenomen die bij implementatie gekoppeld mag worden op het middel of op de dienst. Een voorbeeld is verzending van een SMS als een internet browser wordt gebruikt om in te loggen. Bij frequent gebruik van een middel voor diensten op lagere LoA's kan dat door de gebruiker als bezwarend worden ervaren om steeds SMS's te ontvangen, daarom mag een optie aangeboden worden om de dienst door de gebruiker zelf uit te laten zetten. Ook mag de optie worden aangeboden de de gebruiker notificatie te koppelen aan het gebruik van diensten op het LoA van het middel of lager. 

Ad 5: Het gaat er om dat de gebruiker via het 'trusted' kanaal hoogst betrouwbaar informatie over zijn inlog bij de DV of dienst kan worden gegeven en om hoogst betrouwbare bevestiging kan worden worden gevraagd van een specifiek transactiegegeven. Deze betrouwbaarheid blijf bestaan ook al is de gebruiker slachtoffer van een aanval op zijn inlog-applicatie zoals zijn browser en de PC van de gebruiker (man-in-the-browser attack/man-in-the-front attack). Bij het nemen van maatregelen voor het betrouwbare kanaal wordt uitgegaan van het idee dat de gebruikersomgeving is gecorrumpeerd.

Ad 7: De wijze waarop conformiteit met deze eis wordt aangetoond is aangegeven in paragraaf 2.4.7 Compliance en Audit.