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

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