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

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

On 05.03.24 10:33, Heikki Vatiainen wrote:
> On Tue, 5 Mar 2024 at 09:56, Alexander Clouter <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Using an entire serialiser to support only a map carrying attributes
>     with 1->3 *predetermined* keys seems a bit of a cannon to deal with
>     a mosquito solution as they go. As a hypothetical, would people have
>     a stronger opinion here if CBOR was swapped for protocol buffers or
>     ASN.1 in the document?
> 
> 
> Ok, I'll bite. I've worked recently with ASN.1 (hello GSM world) and 
> found it much easier to work than I initially though. I found the 
> interoperability of different MAP and TCAP (again GSM) implementations 
> to work well together. In other words, the software I made successfully 
> talked to other software from the beginning. This allowed the work to 
> concentrate on the software functionality instead of serialising bits on 
> the line.
> 
> I'd say the main point is: use encoding that's appropriate for the task. 
> ASN.1 suits for 2G/3G complex things. Simple TLVs have so far worked 
> well with EAP.
> 
> I haven't worked with CBOR, but I'd be interested to know if, for 
> example, how careful we need to be with serialiser/deserialiser to avoid 
> problems similar to exponential expansions attacks [1], etc. TLVs are 
> known for people working on Radius/Diameter/EAP. With CBOR it would be 
> useful if the draft were to have information to avoid potential 
> problems, especially if the CBOR input can come from untrusted sources. 
> I'm sure this information is available, and it would help the 
> implementers if they're notified about what to look out for, if needed.
> 
> [1] https://en.wikipedia.org/wiki/Billion_laughs_attack 
> <https://en.wikipedia.org/wiki/Billion_laughs_attack>

Well, the beauty of CBOR is that it is very easily extendable.
I completely agree that, with the limited list of map keys, using CBOR 
instead of TLVs seems like shooting cannons at mosquitos, but if in the 
future we want to do more with this, we can.

Resource exhaustion is a problem in CBOR, as it is in any other 
serialization/deserialization solution.

Here a quote from the CTAP2 spec regarding the use of CBOR in CTAP2 and 
how they deal with the problem:

https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#message-encoding

> Because some authenticators are memory constrained, the depth of nested CBOR structures used by all message encodings is limited to at most four (4) levels of any combination of CBOR maps and/or CBOR arrays. Authenticators MUST support at least 4 levels of CBOR nesting. Clients, platforms, and servers MUST NOT use more than 4 levels of CBOR nesting.

They also limit the length of a CBOR message, with a recommendation that 
every authenticator MUST support at least messages of 1024 bytes and 
that platforms have to respect the max message length signaled by the 
authenticator.

We could say something similar about the allowed depth and length of the 
CBOR messages sent in EAP-FIDO.

One thing that I still have to look into is how we would deal with 
multiple Discoverable Credentials registered for the same RPID, one 
solution would be to send a signature from all of them, and at least 
then I would put the tuple (Credential ID, authdata, signature) in a 
CBOR map, and have the possibility to put multiple of these maps in the 
message.


I'll try to get some Face2Face time with some CBOR experts and talk to 
them about the way they would suggest using CBOR in this protocol.


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