I've posted a revised agenda for the EMU session at IETF 118. That can be
found at:
https://datatracker.ietf.org/meeting/118/session/emu
The change is to slip 5 minutes into the schedule for a follow-up discussion
of EAP-EDHOC. This was a topic during IETF 116. At that time, it was decided
that
On Oct 31, 2023, at 6:28 AM, josh.howl...@gmail.com wrote:
> Playing Devil's Advocate and going a bit OT: this is an excellent goal, so
> why stop at EAP-FIDO?
>
> We could define a similar validation logic for the existing TLS-based methods
> to obtain the same benefit. For example:
> * The
On Oct 31, 2023, at 3:12 AM, Jan-Frederik Rieckers wrote:
> But actually I don't know if **provisioning** the credentials in-band is such
> a good idea.
> Because, in order to provision the credentials, the user needs to prove that
> they are authorized, and how would they do that?
That was
> For the current EAP-TLS based methods, the "service" of putting on the
> harness and hooking you in is not provided. And that is exactly what I want to
> achieve with the TLS part of EAP-FIDO. The users shoulnd't see any of the
> certificate check parameters, it should be implicit and that is
On 30.10.23 17:39, Behcet Sarikaya wrote:> - The draft talks about Fido
but there is no introduction to Fido. Yes,
you gave the standards references but I think that is not sufficient.
I have a T2TRG draft:
https://datatracker.ietf.org/doc/draft-irtf-t2trg-security-setup-iot-devices/
On 30.10.23 12:20, Hannes Tschofenig wrote:> you cannot complain about
the use of TLS in EAP when the EAP method you
propose relies on TLS. The TLS-based authentication is an essential part
of the FIDO solution. Without TLS it is completely insecure.
I don't complain about TLS or EAP-TLS
On 30.10.23 15:55, Alan DeKok wrote:
Today's turnkey EAP provisioning solutions are not *conceptually* dissimilar
to this (often using self-signed CAs with EAP-TLS for mutual authn; and LDAP
to the Enterprise directory to authz the client cert's SAN). The onboarding
would just be transparent
