Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt

[Jan-Frederik Rieckers <[e-mail]>]

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: [e-mail] | Fon: [phone] | Fax: [phone]
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.de

Vorstand: 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