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

Beoordelaar	Datum	Reactie	Toelichting
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

	Bestand	Gewijzigd

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.