> 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
> From: Alan DeKok
> On Oct 30, 2023, at 9:53 AM, josh.howl...@gmail.com wrote:
> > It would be very interesting if the initial registration could be
> > performed in-band of EAP (using WebPKI).
>
> That would be very useful. It's a balance between making the draft
useful
> (large, long
> It's almost 2024, and MDM is still difficult. There are a large number
of
> companies who are happy to charge recurring monthly fees, per user, for
> MDM solutions. That's bad for everyone but them.
This is true, but EAP-FIDO is still not a free lunch:
- EAP-FIDO implies the existence of a
> If you can do an onboarding SSID, there are many simpler things which
can
> be done, too. e.g. downloading configuration files from a captive
portal.
Yes, but not with a managed Chromebook... My point being that bootstrapping
EAP configuration provisioning is not just a problem for BYOD.
> As a goal, we need to migrate to more use of EAP-TLS in home environments.
I discovered recently that you can't provision a client cert for EAP-TLS onto a
Chromebook using the Google MDM. Instead, you configure the MDM with
information that enables the Chromebook to obtain one using SCEP
> From: Alan DeKok
> On Oct 24, 2023, at 8:56 AM, josh.howl...@gmail.com wrote:
> > To be clear, what I mean is whether there is another IETF protocol that
> > *mandates* the use of WebPKI?
>
> All of them.
>
> Not explicitly, but implicitly.
>
> I think the way out here is to not
> > So I see this as two new methods:
> >
> > 1) tunnelled FIDO - for use in TTLS, PEAP, or other TLS-based EAP
methods.
> >
> > 2) TLS-based method with tunnelled FIDO - it can make new / stronger
> > requirements on CA validation, server identity, etc.
>
> So (2) would be the moral equivalent
> So I see this as two new methods:
>
> 1) tunnelled FIDO - for use in TTLS, PEAP, or other TLS-based EAP methods.
>
> 2) TLS-based method with tunnelled FIDO - it can make new / stronger
> requirements on CA validation, server identity, etc.
So (2) would be the moral equivalent of (1) inside
> > 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.
>
Hi Jan-Fred,
It is good to see this work progressing.
1. I agree with Hannes' observation that it isn't necessary to premise EAP-FIDO
on the claimed weaknesses of other EAP methods. I suggest replacing paragraphs
2-5 with content summarising the proposal. In particular I am surprised that
The Network Endpoint Assessment (NEA) Working Group worked on this problem:
https://datatracker.ietf.org/wg/nea/about/
Josh
> -Original Message-
> From: Emu On Behalf Of Hannes Tschofenig
> Sent: Friday, October 13, 2023 9:16 AM
> To: emu@ietf.org
> Subject: [Emu] Network Access
The fragmentation issue that Heikki mentions is specific to EAP over RADIUS,
where RADIUS is using UDP transport. It isn’t a property of EAP itself, and so
I don’t follow why this makes EAP impractical for IoT.
Josh
From: Emu On Behalf Of Behcet Sarikaya
Sent: Thursday, July 27, 2023
> I would suggest that these attacks aren't very relevant. Or if they
are, there
> is very little which can be done about them.
+1
An AAA infrastructure is a logical extension of the NAS that enables
authentication, key derivation and other security functions to be
externalised. That
I support this; although I am curious in Dans opinion as to whether GSS on
top of CoAP is also worth considering, as a way of leveraging the GSS EAP
and other mechanisms (such as Kerberos).
Josh
From: Emu On Behalf Of Göran Selander
Sent: 07 December 2020 14:08
To: Laurent Toutain ;
14 matches
Mail list logo
