Document toolboxDocument toolbox

RFC0006 Expliciete eisen 2-factor authenticatie

MijSamenvatting

Waarom is deze RFC nodig?

Meerdere DVP implementeren dit anders en zijn de authenticatiemethodes qua veiligheid en betrouwbaarheid wezenlijk anders tussen een DVP en DVZA, terwijl dit niet het geval zou moeten zijn.

Oplossingsrichting

Stel expliciete eisen aan de wijze van twee factor authenticatie voor een DVP. Verwijs hierbij bijvoorbeeld naar NIST SP 800-63B

Aanpassing van

Normenkader norm: A.9.4.1Beperking toegang tot informatie

Impact op rollen

DVP

Impact op beheer


Gerelateerd aan (Jira issues)


Eigenaar


Implementatietermijn

Tbv release 1.2.0

Motivatie verkorte RFC procedure (patch)

Constatering dat auditoren dit onvoldoende kunnen beoordelen en dat we goede kwaliteit van de tweede factor willen, die ook echt een tweede factor is. Voorbeeld een verificatiecode opgestuurde naar een e-mailadres is niet altijd een betrouwbare twee factor. Voorstel om te verwijzen naar norm bijvoorbeeld NIST SP 800-63B en dat de 'sterkte' van de tweede factor vergelijkbaar is wat er bij de DVZA wordt gebruikt, lees nu DigiD.


Goedkeuring

BeoordelaarDatumReactieToelichting
Productmanager


Ontwerpteam


?


Principe's

Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

Positief

11 Stelselfuncties worden vanaf de start ingevuld

Positief

2 Dienstverleners zijn transparant over de gegevensdiensten 

Positief

12 Het afsprakenstelsel is een groeimodel

Positief

3 Dienstverleners concurreren op de functionaliteiten

Positief

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

Positief

4 Dienstverleners zijn aanspreekbaar door de gebruiker

Positief

14 Uitwisseling is een keuze

Positief

5 De persoon wisselt gegevens uit met de zorgaanbieder

Positief

15 Het MedMij-netwerk is gebruiksrechten-neutraal

Positief

6 MedMij spreekt alleen af wat nodig is

Positief

16 De burger regisseert zijn gezondheidsinformatie als uitgever

Positief

7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener

Positief

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

Positief

9 De dienstverleners zijn deelnemers van het afsprakenstelsel

Positief

18 Afspraken worden aantoonbaar nageleefd en gehandhaafd

Positief

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

Positief

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

Positief

Uitwerking

DVP's mogen geen DigiD gebruiken als authenticatie methode voor toegang tot het PGO (DVP). Dit omdat DigiD dan verplicht tot het verwerken van het BSN wat uitgesloten is in het MedMij afsprakenstelsel.


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.

Het gebruik van e-mail als tweede factor is niet toegestaan voor MedMij, niet meer gaan toestaan omdat voor toegang tot e-mail ook volstaan wordt met iets wat je weet.

Bijlagen




Nog geen bestanden gedeeld hier.

Info NIST en Schneiner


https://www.schneier.com/blog/archives/2016/08/nist_is_no_long.html



Q-B11:

Is the use of email acceptable in two-factor authentication?

A-B11:

NIST SP 800-63B does not allow the use of email as a channel for single or multi-factor authentication processes. This is specified in Section 5.1.3.1, Out-of-Band Authenticators:

[Authentication] methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication.


Van <https://pages.nist.gov/800-63-FAQ/>


Dus het gebruik van e-mail als tweede factor  is niet toegestaan voor MedMij. DVP


5.1.3 Out-of-Band Devices


An out-of-band authenticator is a physical device that is uniquely addressable and can communicate securely with the verifier over a distinct communications channel, referred to as the secondary channel. The device is possessed and controlled by the claimant and supports private communication over this secondary channel, separate from the primary channel for e-authentication. An out-of-band authenticator is something you have.


The out-of-band authenticator can operate in one of the following ways:


- The claimant transfers a secret received by the out-of-band device via the secondary channel to the verifier using the primary channel. For example, the claimant may receive the secret on their mobile device and type it (typically a 6-digit code) into their authentication session.


- The claimant transfers a secret received via the primary channel to the out-of-band device for transmission to the verifier via the secondary channel. For example, the claimant may view the secret on their authentication session and either type it into an app on their mobile device or use a technology such as a barcode or QR code to effect the transfer.


- The claimant compares secrets received from the primary channel and the secondary channel and confirms the authentication via the secondary channel.


The secret's purpose is to securely bind the authentication operation on the primary and secondary channel. When the response is via the primary communication channel, the secret also establishes the claimant's control of the out-of-band device.


Van <https://pages.nist.gov/800-63-3/sp800-63b.html#sec5>


EIDAS norm:


Bij het authenticatieniveau is niet alleen van belang dat er een goede betrouwbare tweede factor wordt gekozen/gebruikt maar ook de uitgifte van het authenticatiemiddel zelf. Daarbij zijn authenticatieniveau substantieel en hoog van belang.