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

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

Hi, now the rest of the comments for this one.
Again, thanks so much for reading through this and commenting. It really 
helps :)

On 03.03.24 13:39, Alexander Clouter wrote:
> Section 4.2
> -----------
> This is almost impenetrable. For an implementer, it helps to be able to see what you have to build and using existing RFCs as an example, working with wire serialisation formats it really helps to show the structure, either through (A)BNF, explicit structure/records like in TLS or the literally bit packing.
> 
> Of course for this fancy pants CBOR malarkey, this will not do, but it looks as if CDDL (RFC8610) would help make this section a lot clearer and probably would not be considered a big ask for those working with CBOR to gain familiarity with.

The message structure is not yet fixed, that's why I didn't put in much 
of an effort to formalize the structure, if it is going to change much.

But of course, once we have the message format fixed, a formalized 
description of the message syntax will be coming.

> Is there a reason to discern the difference between 'request' and 'response' for each type? Do you expect the server to have a passkey to authenticate to the client? At the moment it looks like a bunch of extra conditionals I would need to add to my code, we no idea the action I should take if I see an unexpected one.

My main idea was to prevent reflection attacks from the get-go. If we 
have a clear specification in which direction a message is going, we can 
spot bad behavior more easily.


> For the errors, I would remove the success/error/failure type and just communicate this through the *presence* of a list of error tuples (<type[enum]>, <fatal[bool]>, <description[str]>) in your map; you may wish to include here a '<required[bool]>' in the tuple as a way for the server (or client) to communicate to the peer "you must understand and not ignore this, otherwise abort".

Definitely a thing to think about.
I am always very much in favor of explicitly stating what is going on 
instead of relying on implicit information, that the peer may overlook 
if the order of the message items were chosen in a specific way.
At the very least I would have a separate Success and Failure indicator.

To join the "Failure" and "Error" into one message with the possibility 
to set a "fatal" boolean to true, that would be fine by me.

My plan is to work on an implementation at the Hackathon and I hope that 
the implementation will give me some insight in what is actually useful 
and at which points I tripped myself up with my 
then-brilliant-now-not-so-brilliant ideas.


> Passing a list of 'Credential IDs' makes me nervous only in that how big could this list get? Thinking if you wore the hat of a service provider handling multi-tenant access for various clients and their users may have enrolled at multiple realms under the superset of your tenants. These things are at least 16 bytes so is returning 100 a problem? It is only probably around 2 round trips of EAP fragments or so which may mean it is a non-problem? Really, not stating this is an actual problem, I am just trying to put a crazy wild example out there to exaggerate where this machinery may creek.

Definitely a thing to think about.
In the deployment section, we encourage people to prefer using 
Discoverable Credentials, with that you wouldn't have any Credential IDs 
going over the wire anyway.
If you use Server-Side Credentials, then the server must send a list of 
all Credential IDs associated with that particular user, so the FIDO 
Authenticator can choose the right one. But in reality, I don't think 
that this would exceed 20 Credential IDs in any reasonable use case.

Of course, if a person re-registers the same key a hundred times (which 
is not difficult at all, because with Server-Side Credentials usually 
the FIDO Authenticator does not save anything, so there is no resource 
exhaustion on the Authenticator's side), that could pose a problem. But 
to be honest, if a user excessively registers FIDO tokens, there should 
be a safeguard before, so the EAP part never has to deal with this problems.

I think there is no harm in adding a sentence like "A server SHOULD not 
send more PKIDs than <set reasonable number here>" with reasoning 
explaining the fragmentation issues and length of EAP handshake etc.

The technical limit I think is restricted by the amount of EAP 
roundtrips that most NAS allow, I think most Access Points will abort 
the EAP conversation on their own if they saw more than 50 roundtrips.


> Instead of a map for your attributes, I would be inclined to lean towards a tagged data item (major type 6) as:
> 
>   * smaller
>   * faster, the implementation would be an integer compare/jump table (unless you *guarantee* keys are fixed 32/64bits length)
>   * more familiar to an implementer in the EAP space (I do not think I have seen anything else use a map construct in EAP or RADIUS?)
>   * I am a grumpy old fart and love my TLV's, maybe others share this opinion...about TLVs, not me of course! :)

To be honest, I hate TLV, especially with fixed-length types.
Either you waste resources by defining a 2 byte or 4 byte type field, or 
you run into resource exhaustion if your type field was too small.
I don't expect that we would run into a problem with that with this 
specification soon, even with extensions, but why risk it?

(I'm not fixed on using CBOR for the message format, but since CTAP2 
also uses CBOR at least the client needs to have a CBOR library anyway.)

I haven't understood CBOR Tags fully yet, if we can reach the same goal 
with tags instead of maps, I'm all for it.

> 
> Myself, I would fold 'PKID' into 'PKIDs' and make it a 'list of length one' when used, but really this is a matter of personal taste.

Again, I like to be explicit. If we have an attribute that says "MUST be 
of length one", some vendor will ignore it, on the sending or receiving 
side. How do we deal with two PKIDs? do we take the first one? The last 
one? Do we abort completely?
I find it better to be explicit, this way we avoid such errors in 
implementation from the get-go.

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