> > 2. I am not persuaded by the two arguments given in section 6.3 for not > > reusing existing tunnelled methods. > > I'm open to discuss this with an open mind, the first draft is just the > way that I imagined it, if there are reasons to do it another way, I'm > not set on the current spec. > > > * Misconfiguration of server certificate validation parameters: perhaps I am > missing something, but in terms of the UI can't this be solved by disabling > the > parameter options/fields if the EAP-FIDO inner method is selected? > > Definitely this could be done. Maybe I'm just too pessimistic here to > expect that UIs will get it wrong.
Ok -- just checking my understanding was correct :) > > * Export of TLS material: I thought this TLS material is often required by > phase 2 of other tunnelled methods? E.g. for validating cryptobindings. > > I don't know exactly what you mean by that? > The current spec uses exported TLS material to generate the FIDO > challenge, so the FIDO-Auth is bound to the TLS tunnel. Most tunnel methods bind phases 1 and 2; I don't believe this should be a problem. > One question would be if we can achieve the opoosite, that is: binding > the exported MSPPE-Keys to the FIDO auth too, not just the TLS tunnel. What would be the goal for this? > > 3. I have unsure about tying this specification so tightly to the WebPKI. > > There > is a tremendous convenience in using the WebPKI for validating the server > certificate, but the WebPKI is not a well-defined concept. In practice, it is > the > bucket of CAs that my OS vendor preinstalls on my device. The conflation of > protocol design (fixed in code) with operational choices taken by > third-parties > (so subject to change) could lead to unexpected outcomes. > > I agree with your last sentence, we definitely introduce a third party > that we cannot control (or even anticipate their actions). > But the idea here is to build a system where we have a default way of > configuration that is somewhat secure, and since we can't really > establish a trusted EAP-FIDO CA that every device will trust, leveraging > the WebPKI for that is the next best thing. When you say "default", would this permit other user-provisioned trust anchors as well? Josh _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
