On Mar 4, 2024, at 10:39 AM, Jan-Frederik Rieckers <rieck...@dfn.de> wrote: > 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.
I think this is a good idea. >> 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". Using "mandatory" bits in a protocol has been difficult. Diameter has them, and they've proven less useful than initially thought. But I do like a list of error tuples. It's not always possible to map complex failure onto one 3-digit decimal number. > 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. I agree, and I believe separate Success / Failure indicators are useful. > 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. Yes. > 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? A counter-point is that all EAP methods implement TLVs already, so adding more / similar code is easy. The downside is that CBOR is likely more expressive than TLVs, and perhaps what people should be moving towards. There's no reason to stick with TLVs simply because we've been using them for years. It's 2024, new technologies exist. > (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 think tho that the EAP implementations don't need to implement CBOR in order to do CTAP2, right? They just hand the data to another library, and it does the work. > 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. I agree completely. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
