mirror of
https://github.com/kanidm/kanidm.git
synced 2025-02-23 20:47:01 +01:00
98 lines
3.5 KiB
ReStructuredText
98 lines
3.5 KiB
ReStructuredText
Multiple Device Enrollment Workflow
|
|
-----------------------------------
|
|
|
|
As we continue to develop kanidm, we'll add support for OTP and Webauthn. A constraint we must
|
|
consider is that many webauthn devices are tied to (bound) to the device. This could be a yubikey
|
|
nano that may not pluginto a phone, a built in touch id, a tpm, or even a softtoken in firefox.
|
|
|
|
As a result, we must have a way for an account to be able to authenticate the addition of a new
|
|
webauthn token *without* being able to provide an existing token to the new device.
|
|
|
|
We must also consider that the process should be simple and easy to follow. We have taken
|
|
inspiration from existing systems to support this.
|
|
|
|
Situation
|
|
=========
|
|
|
|
We have a user with a device E(nrolled), and a device N(ew) that they wish to be able to use.
|
|
|
|
Each device contains a unique webauthn device that is inseperable from the device.
|
|
|
|
Each device may be connected to a seperate Kanidm instance - IE we can not assume that
|
|
the data in the system may be point-in-time consistent due to replication as an asynchronous
|
|
process.
|
|
|
|
The process "will" come under attack. It must not be an avenue for partial credential disclosure.
|
|
|
|
The enrollment process and credentials issued must only be for the purpose of enrollment of webauthn
|
|
devices and must not grant any other permission.
|
|
|
|
The overall security of the system must not be "lowered" to allow the enrollment to occur.
|
|
|
|
Schema
|
|
======
|
|
|
|
MFAEnrollmentToken: TOTP/HOTP seed/counter
|
|
WebauthnCredential: Storage of a webauthn pubkey
|
|
WebauthnCredentialRequest: Storage of a webauthn pubkey that is awaiting acceptance.
|
|
|
|
Preparation
|
|
===========
|
|
|
|
When the account is created, a private recovery TOTP seed is created and stored in the account
|
|
as an MFAEnrollmentToken.
|
|
|
|
This is so that all replicas in the topology have the same credential tokens available.
|
|
|
|
The "login" page has an "enroll new device" option.
|
|
|
|
A claim for self write to webauthn registration must exist.
|
|
|
|
Process
|
|
=======
|
|
|
|
Device N is accessed (which is not yet enrolled). The "enroll new device" option is selected.
|
|
|
|
The username is entered. This goes to the next step
|
|
|
|
The TOTP is requested.
|
|
|
|
On the enrolled device E, the TOTP is "generated". It is then typed into device N.
|
|
|
|
Device N then prompts for the user primary password (if exists).
|
|
|
|
The session is logged in with a single self-write claim that allows creation of a webauthn pub key
|
|
on the account. alt: the server just does the change as internal system to bypassword acp, but I think
|
|
there are some attack vectors here.
|
|
|
|
The session has a 5 minute timelimit.
|
|
|
|
Device N challenged for a webauthn registration process. The public key is written to the account's
|
|
WebauthCredentialRequest.
|
|
|
|
On Device E, the user approves the WebauthCredentialRequest, and it is moved from WebauthCredentialRequest
|
|
to WebauthnCredential. It may now be used.
|
|
|
|
|
|
Possible Issues
|
|
===============
|
|
|
|
TOTP has a time window, and if we are near that window it may not last long enough. We could consider
|
|
HOTP instead, assuming that the HOTP has not been accessed +- 10 times between the replicas.
|
|
|
|
Handling for accounts with no user primary password.
|
|
|
|
Device E may be connected to a different replica to Device N, so there may be a delay in requested
|
|
token enrollments from appearing in the request list.
|
|
|
|
Device N may have to wait for replication back for the WebauthnCredential to appear.
|
|
|
|
|
|
Possible Changes
|
|
================
|
|
|
|
Do not require the approval step, as an OTP has already been provided, which is evidence of possesion
|
|
of an account which has sufficent permissions.
|
|
|
|
|