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

>
> My hope is that we don't have to use JSON in the
> draft, because using JSON implies conversion of binary data to ascii
> text, and I would like to avoid that if possible.


Note that CollectedClientData defines an explicit serialization algorithm
<https://w3c.github.io/webauthn/#clientdatajson-serialization> that is JSON
compatible, but does not require a JSON encoder to write nor a JSON parser
to verify. In case that helps.


I've only briefly skimmed the EAP-FIDO draft so far, but here are a few
more things I noticed:

- The term "residential" keys is used in various places. These should say
"resident" instead of "residential" - the fully spelled out original term
was "client-side-resident public key credential source
<https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#client-side-resident-public-key-credential-source>".
Also consider using the new term "discoverable credential/key" instead,
unless you need to specifically address the storage mode rather than
whether the key can be used without providing its credential ID. (If you do
make such a distinction between "resident" and "discoverable" you should
also clearly define that in the document - or use a different term -
because otherwise these terms are generally considered synonyms.)
- Very minor nitpick: Section 6.1.1
<https://www.ietf.org/archive/id/draft-janfred-eap-fido-00.html#name-discoverable-credentials-vs>
remarks
that "[a security token using non-resident keys] is stateless and thus the
number of keypairs and scopes it manages is infinite". I would say
"unlimited" or "unbounded" rather than "infinite".
- Typo in "4.3.2. Potocol Sequence"
- Typo in "registratrion" in section 6.1
- Examples of UV in section 6.1.2
<https://www.ietf.org/archive/id/draft-janfred-eap-fido-00.html#name-user-involvement-during-reg>
should include PIN, as to not imply that UV is always biometric.
- Section 4.3.1
<https://www.ietf.org/archive/id/draft-janfred-eap-fido-00.html#name-message-format>
- echoing Adam's comment, in order to prevent cross-protocol attacks: the
"Additional Client Data (2)" attribute MUST NOT allow free-form binary data
without restriction. The EAP client MUST impose some kind of structure
outside of the caller's (server's?) control, such that the resulting
signature cannot be a valid WebAuthn signature. For example, by adding a
protocol-specific prefix to the "Additional Client Data" (even when empty),
or by embedding it as the `challenge` attribute in a CollectedClientData
structure with a protocol-specific `type` attribute.
- The Authentication Response
<https://www.ietf.org/archive/id/draft-janfred-eap-fido-00.html#name-authentication-response>
structure
should probably contain a field analogous to clientDataJSON
<https://w3c.github.io/webauthn/#dom-authenticatorresponse-clientdatajson>
in WebAuthn, as the `authData` and hash of "Additional Client Data" are
signed together. Even if the "Additional Client Data" is empty, the
signature will be over `authData || SHA256(<empty byte string>)`, not over
just `authData`. Thus the verifier needs to know the preimage of that hash
suffix. Unless the preimage can be reliably reconstructed some other way,
it should probably be conveyed in the authentication response (as an opaque
byte string that must not be modified in transit).

Hope that helps!

Emil Lundberg

Senior Software Engineer | Yubico <http://www.yubico.com/>




On Tue, Nov 7, 2023 at 10:52 AM Jan-Frederik Rieckers <rieckers@dfn..de>
wrote:

> Hi Adam,
>
> Thanks for your reviews. It's highly appreciated.
> We're very happy to see the positive feedback on the draft and we hope
> that this is a way out of the certificate mess we currently have
> especially in eduroam.
>
> Some replies to your review inline right now, I'll read through them in
> detail after the IETF and incorporate them into a new draft version.
>
> On 06.11.23 07:44, Adam Langley wrote:
> > The definition in
> >
> https://www.ietf.org/archive/id/draft-janfred-eap-fido-00.html#section-6.1.1
> <
> 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.
>
> Thanks. I wasn't sure what the correct term right now is, because it was
> renamed multiple times, but if "discoverable credential" is the current
> correct term, we'll replace it.
> (It's much more descriptive than "passkeys" anyway)
>
>
> > 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.)
>
> We'll look into that. My hope is that we don't have to use JSON in the
> draft, because using JSON implies conversion of binary data to ascii
> text, and I would like to avoid that if possible.
>
> We will look at cross-protocol attacks closely to ensure that there
> won't be an attack vector there.
>
> >
> > 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.
>
> Thanks for this text, we can look it through and include that in our
> security considerations. I'ts really good input.
>
> One of the main reason that RPID is not mentioned yet is that the
> specification regarding the actual FIDO/CTAPv2 part that is performed by
> the supplicant has not received the proper attention (mostly because the
> technical spec was written within the last 3 days before the draft
> deadline) and the focus was primarily on the base protocol and message
> exchange to give people a good rough idea what it is we want to do.
>
> > 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
> > <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?
>
> We had discussions about the relation between NAI (Realm), RPID and the
> expected server name during the side meeting. It's definitely something
> we will focus our attention on.
> Our aim is to have the "one string to rule them all", because we want to
> give users the most fool-proof way of configuring.
>
>
> The discussion on the EAP-FIDO draft has been taken place on the emu WG
> Mailing list, you can follow the discussion there, there was already a
> bit of discussion, the archive can be found here:
> https://mailarchive.ietf.org/arch/browse/emu/
>
>
> Cheers,
> Janfred
>
> --
> Herr Jan-Frederik Rieckers
> Security, Trust & Identity Services
>
> E-Mail: rieckers@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.de
>
> Vorstand: 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
>