Re: EAP method based on FIDO (@ IETF this week)

On Sun, Nov 5, 2023 at 8:02 PM Samuel Weiler <weiler@w3.org> wrote:

> Colleagues,
>
> FYI, Janfred Rieckers gave a HotRFC talk this evening about a new EAP
> method using FIDO authentication, with the aim of using it for
> eduroam.
>
> Abstract:
>
> https://datatracker.ietf.org/meeting/118/materials/agenda-118-hotrfc-sessa-10#h.tjo1wugzr3lx
>
> Slides:
>
> https://datatracker.ietf.org/meeting/118/materials/slides-118-hotrfc-sessa-12-a-new-eap-method
>
> A side meeting on the topic is scheduled for Monday at 1800 (Prague
> local time) and it's on the EMU agenda on Tuesday.
>
> https://datatracker.ietf.org/meeting/118/materials/agenda-118-emu-02


Thanks for the note. A scattering of remarks, from quibbles to larger
concerns:

The definition in
https://www.ietf.org/archive/id/draft-janfred-eap-fido-00.html#section-6.1.1
isn't quite right. Certainly credentials where the authenticator doesn't
store any state cannot be discoverable, but some authenticators do store
state and yet still create non-discoverable credentials. The important
factor is whether credentials can be found without their credential ID.

The draft uses "Passkeys" to mean discoverable credentials
<https://www.w3.org/TR/webauthn-2/#discoverable-credential>, and the word
"passkey" should not be capitalised. People here will know what you mean,
but it's good to be precise.

The draft contains another WebAuthn-like encoding of assertion requests and
responses. If it used the JSON forms of the request
<https://w3c.github.io/webauthn/#dictdef-publickeycredentialrequestoptionsjson>
 and response
<https://w3c.github.io/webauthn/#dictdef-authenticationresponsejson> you'll
probably save some bother. (If you're already proposing CBOR then the
parsing requirements are similar.) For example, the proposed response
doesn't include the user ID, which will be problematic for some servers.
(However, I'll qualify this recommendation below.)

Because of the possibility of cross-protocol attacks, the client data must
follow the general scheme
<https://w3c.github.io/webauthn/#dictdef-collectedclientdata> from
WebAuthn. I.e. it must be a JSON object. Sounds like you'll want a custom
"type" (which is good) and you can put other fields in there as you wish.
(You can ignore fields other than "type" if the value of "type" is specific
to this scheme.)

The term "RP ID" doesn't appear in the draft, although it does talk about
"scopes". I think "scope" in 6.2 means "RP ID" but this is an important
security issue and precision is warranted here. There are three concerns:

   1. EAP-FIDO assertions must not be valid for authentication in other
   contexts.
   2. EAP-FIDO assertions must not leak secrets to the wrong counter-party.
   3. EAP-FIDO assertions should not be a privacy problem.

Making the client data distinct solves #1. There is, however, a risk of #2
is the validation of RP IDs is different. Secrets may be disclosed via at
least the credBlob, prf, or largeBlob extensions and, if you use the JSON
encoding of requests and responses, that might work "too well" and let
those extensions function. You might want to allowlist extensions that can
pass through.

Lastly, #3 is more minor but an EAP-FIDO peer that is able to assert for an
RP ID that it shouldn't could learn things like the user's ID and
credential IDs for another service.

I'd suggest that "The RPID MUST be validated against the certificate name
(How exactly is still TODO)" should probably reference RFC 6125 and the
asserted RP ID should probably be limited in the same way as WebAuthn does
based on that: https://www.w3.org/TR/webauthn-2/#rp-id. But you lack a
user-specified intended domain, right? (I.e. there's no "target" like the
hostname entered into the URL bar of a browser.) Thus I think you end up
having to iterate over DNS SANs to see if an asserted RP ID is plausibly
valid?


Cheers

AGL