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

Heikki Vatiainen wrote: > 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 There are no entities like in XML, so that won't

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

Alan DeKok wrote: > ALPN would be much simpler, I think. The downside there is that > every time you rev the protocol, you have to register a new ALPN name. > That's annoying. I don't know if it would be acceptable to register an > ALPN _prefix_, and then just self-allocate ve

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

On 05.03.24 13:40, Alan DeKok wrote: On Mar 5, 2024, at 5:46 AM, Jan-Frederik Rieckers wrote: 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

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

On Mar 5, 2024, at 5:46 AM, Jan-Frederik Rieckers wrote: > 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

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

On 05.03.24 10:33, Heikki Vatiainen wrote: On Tue, 5 Mar 2024 at 09:56, Alexander Clouter > 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 sol

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

On Tue, 5 Mar 2024 at 09:56, Alexander Clouter 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 C

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

On Mon, 4 Mar 2024, at 19:11, Alan DeKok wrote: > 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. Th

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

On Mar 4, 2024, at 10:39 AM, Jan-Frederik Rieckers 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 woul

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

On Mar 3, 2024, at 7:57 AM, Jan-Frederik Rieckers wrote: > The idea here is that future versions may signal some information outside the > TLS tunnel. Our first idea, where this kind of still stems from was that the > server signals the RPID outside the TLS tunnel, so the client can verify that

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

Hi, here the answer to the questions regarding PKIDs: On 04.03.24 11:06, Alexander Clouter wrote: Why not just *always* send the list of PKIDs? How is this list formed by a server *before* it knows the user identity? Is a possible that the anon identify from Phase 1 is enough to perform this

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

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 bui

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

On Mon, 4 Mar 2024, at 10:06, Alexander Clouter wrote: > On Fri, 1 Mar 2024, at 21:08, Jan-Frederik Rieckers wrote: >> I just posted a new version of the EAP-FIDO draft. >> >> [snipped] >> >> Comments are welcome, as always. > > Trying to understand the need for 'Credentials IDs (PKIDs) in the > a

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

On Fri, 1 Mar 2024, at 21:08, Jan-Frederik Rieckers wrote: > I just posted a new version of the EAP-FIDO draft. > > [snipped] > > Comments are welcome, as always. Trying to understand the need for 'Credentials IDs (PKIDs) in the authentication request. My thinking here is "I miss my EAP Identity

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

Jan-Frederik Rieckers wrote: > I just posted a new version of the EAP-FIDO draft. > We had some discussion on the name "EAP-FIDO" at the last IETF and we > have come up with some name options since, but none of them resonate > with me yet. I see the issue. > I have started

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

Thanks so much for the comments. I'll respond to some from the top of my head, the others I'll address some time next week. On 03.03.24 13:39, Alexander Clouter wrote: Section 4.1.2 - It just popped up as an idea in my reply to the the SEC review of TEAP but... EAP-TLS sub-method

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

On Fri, 1 Mar 2024, at 21:08, Jan-Frederik Rieckers wrote: > Comments are welcome, as always. Section 4.1.2 - It just popped up as an idea in my reply to the the SEC review of TEAP but... EAP-TLS sub-methods have been copying the version bits since forever. Maybe it is time to break

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

Hi emu folks, I just posted a new version of the EAP-FIDO draft. We had some discussion on the name "EAP-FIDO" at the last IETF and we have come up with some name options since, but none of them resonate with me yet. I have started a pad with different name options, everyone is invited to c