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: rieck...@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 https://www.dfn.deVorstand: 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
