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.1Bepekring 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 of andere |
Maarten Schmidt
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
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.