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

[Alexander Clouter <[e-mail]>]

On Fri, 1 Mar 2024, at 21:08, Jan-Frederik Rieckers wrote:
> I just posted a new version of the EAP-FIDO draft.
>
> [snipped]
>
> Comments are welcome, as always.

Trying to understand the need for 'Credentials IDs (PKIDs) in the authentication request.

My thinking here is "I miss my EAP Identity request", which may be completely mis-placed, but considering the payloads of an authentication request and information request it looks really close to a plain EAP Identity exchange.

The reasoning the document provides is:

authentication request:
-----------------------
"A list of acceptable Credential IDs. This can be used to trigger a re-authentication of a specific credential or to provide a list of the Credential IDs for a *specific user* [my emphasis], if Server-Side Credentials are used"

"can include authentication requirements, additional client data and a list of Credential IDs"

information request: 
--------------------
"If a client does not have sufficient information to perform the FIDO authentication, the client can send an information request message to the server.This is the case if Server-Side Credentials are used, since the FIDO Authenticator needs the list of acceptable Credential IDs to access the actual credentials on the FIDO Authenticator."

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?

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