On 30.10.23 15:55, Alan DeKok wrote:
Today's turnkey EAP provisioning solutions are not *conceptually* dissimilar to this (often using self-signed CAs with EAP-TLS for mutual authn; and LDAP to the Enterprise directory to authz the client cert's SAN). The onboarding would just be transparent for an end-user because of the browser/OS/TPM integration (so no "installer" to download and execute). It would be very interesting if the initial registration could be performed in-band of EAP (using WebPKI).That would be very useful. It's a balance between making the draft useful (large, long delay), or getting it done quickly, but perhaps missing features. I think the ideal approach is for EAP-FIDO to allow: * authentication via FIDO as discussed * provisioning of FIDO credentials * de-provisioning of credentials. The last one is hard, as how do you de-provision credentials if you've deleted them, and you can't prove who you are?
I completely agree that **de-provisioning** of credentials should be part of the protocol.
There are two parts of that problem (just from the top of my head:Firstly: deleting the EAP-specific configuration (as in: "Dear client, I don't know you, please stop asking"). This can be as simple as sending a simple message, but has the problem that faulty configurations in the beginning can't be debugged, because the moment the client connects it gets the delete request and deletes the profile.
The second part is the actual FIDO credential. If we provision a Passkey In-Band, then we need to have a way of deleting that passkey. From the top of my head I'd say that the server should keep the credentials of deleted users for a period of time and when they try to log on they get a "pls delete" request. The client ACK's the request and then the server can delete the credential.
But actually I don't know if **provisioning** the credentials in-band is such a good idea. Because, in order to provision the credentials, the user needs to prove that they are authorized, and how would they do that?
Send a password together with their provisioning request?This is not secure, since the user can again type in a wrong domain and this way unintentionally give the password away to a malicious third party.
Obtain a shared secret to calculate a MAC to authorize the request?Here we have the Catch-22 again. How do the users obtain the shared secret? Via a web portal? Then the user can simply register their credential via WebAuthn.
I admit that with the current idea of the protocol flow the OOB-registration adds a small layer of complexity for the administrators, but I gather that it will be much more easy for the users.
And the additional workload for the provisioning is well investedAnd regarding the "oh, but now the RADIUS admins need to talk to the web admins" argument: The RADIUS admins already need to talk to the IdM admins to gain access to the user database (esp. if password-based authentication methods are used). So if the RADIUS and web admins don't want to talk to each other: fine, they don't need to. The web admins just need to provision the FIDO token and write them back to the IdM database and the RADIUS admins can access the FIDO public keys from the database.
With the current movement the FIDO alliance is pushing this is actually a great step, because the FIDO Passkey that is already provisioned for logging into the account in the web can now simply be used for network access as well.
Cheers, Janfred -- Herr Jan-Frederik Rieckers Security, Trust & Identity Services E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370 Pronomen: er/sein | Pronouns: he/him __________________________________________________________________________________DFN - Deutsches Forschungsnetz | German National Research and Education Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V. Alexanderplatz 1 | 10178 Berlin www.dfn.deVorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
