Hi, here the answer to the questions regarding PKIDs:
On 04.03.24 11:06, Alexander Clouter wrote:
Why not just *always* send the list of PKIDs? How is this list formed by a server *before* it knows the user identity? Is a possible that the anon identify from Phase 1 is enough to perform this?
The list is formed by the server AFTER querying for the user's identity. Taking a step back: For the FIDO authentication, we have two authentication options:(I always use "PKID" in this mail, the FIDO terminology uses "Credential ID" and "Public Key Credential source", but for the server, both are just arbitrary strings that uniquely identify a public key, I still have to read the FIDO specs in full to decide which of these terms I should use in the final document)
Option 1: Discoverable Credentials.The client knows the RelyingParty ID and has a credential stored for that RPID. It can simply sign the request, and includes both the signature and the PKID used for the signature in the answer. The server recognizes the user by the PKID the client sends, and can look up the public key for that particular PKID and then verify the signature.
Option 2: Server-Side Credentials.The client knows the RelyingParty ID, but has no discoverable credentials, so it needs additional information. The client sends its username to the server, and only now the server has enough information to compile the list of PKIDs.
This is just a simple "SELECT PKID from USER_DB where USER='<username>'" The server simply looks up all PKIDs that is has stored for this user.(Theoretically, the server could compile this list earlier if the client sent its real identity in the anonymous identity, but we shouldn't even make that a possibility, some vendor will think "hey, that's a great idea, let's ignore that this is supposed to be an ANONYMOUS identity and fill in our real identity". (Just a random thought, not that this happened before)
The PKIDs are the "containers" with which the FIDO Authenticator can reconstruct the private key that was generated during registration and can sign the request with that private key.
Since every PKID is bound to one specific FIDO Authenticator and with non-discoverable credentials, the Authenticator does not store state locally, there is no way of determining the PKID in any other way than having the server send a list over.
I hope that made it clearer.As you asked for some resources (not sure whether they are suitable as bedtime-stories though *grin* )
https://www.w3.org/TR/webauthn/ has a lot of good definitions and descriptions on how certain things work, I'd suggest looking at these terms specifically:
* "Credential ID" * "Discoverable Credential" * "Server-side Credential"
I am trying to reconcile these two descriptions and the closest I can get is it seems in practice PKIDs can only be offered by the server after seeing the identity? By introducing EAP Identity an implementer would be more easily able to proxy the inner FIDO authentication but the downside of this is it would bring in an extra round trip as the server still has to send after the EAP Identity response "now do FIDO" and the client cannot initiate this. On a related note, as a passing thought though I am not sure how this could work, opportunistically could the client make use of the SubjectAltName from the outer TLS jacket of Phase 1 to infer a suitable PKID and avoid needing to make an 'information' round trip? If the server side thinks the peer has picked incorrectly, that is when it responses with the list of PKIDs as it now also knows the peer's identity.
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 https://www.dfn.deVorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 136623822
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
